Daily Cybersecurity News – September 22, 2026

What happened

A flaw in WordPress core allowed an anonymous visitor to submit a comment containing a hidden script. When a logged-in administrator later viewed the page, the script executed in their browser and could leverage the admin session to upload a malicious plugin with a web shell, achieving remote code execution on the server.

Tracked as CVE-2026-93485 and dubbed Comment2Shell, the issue stemmed from a gap between comment sanitization on save and reformatting on display. A line break inside an allowed HTML tag attribute caused the tag to split so that attacker-controlled text became a live event handler that ran automatically on page load. WordPress fixed it on September 17 in version 7.1.1. There is no evidence of active exploitation and it is not listed in CISA KEV. Patchstack scored it 7.1 CVSS.

Who is affected

WordPress sites running versions 4.7 through 7.1. Fixed releases include 7.1.1, 7.0.5, 6.9.8 and corresponding patches back to 4.7.36.

The attack required comments to be visible (block themes are default since Twenty Twenty-Two; some classic themes such as Twenty Twenty-One were also affected) and worked best when comment moderation could be bypassed. Sites with open or weakly moderated comments and administrator users who view front-end pages were most exposed.

Why it matters

Anonymous commenters could plant persistent XSS that escalates to full server control once an admin views the page. Uploading a plugin via the admin session is a well-known path to a web shell.

WordPress powers a huge share of the web. Even without confirmed in-the-wild use, the low bar for initial planting and the high payoff of admin RCE make prompt patching essential for operators.

How it could have been prevented

Update immediately to WordPress 7.1.1 or the latest patched release on your branch (7.0.5, 6.9.8, or the matching fix down to 4.7.36).

If you cannot patch at once, disable comments site-wide or close them on individual posts. Treat comment moderation as convenience, not a security boundary. Monitor for unexpected plugin uploads and review admin activity logs.

What happened

CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog and ordered federal agencies to remediate them immediately, confirming active exploitation in the wild. Details of the incidents and actors were not released.

CVE-2025-39964 (CVSS 7.8) is a 14-year-old race condition in the AF_ALG cryptographic socket interface that can corrupt state, crash systems or alter crypto results and enable privilege escalation plus container escape. CVE-2026-53266 (CVSS 8.8) is an out-of-bounds write in ebtables SNAT that can rewrite shared file-backed memory. CVE-2025-39682 (CVSS 9.8) mishandles zero-length TLS records on the receive path when kTLS is used, potentially mixing record types. Public exploits exist for at least two of the flaws. All three require forensic triage of affected assets.

Who is affected

Any system running unpatched Linux kernels that include the affected AF_ALG, ebtables or kTLS code paths. This covers a wide range of servers, containers, cloud instances and appliances across distributions.

Federal civilian agencies face a hard deadline; enterprises and cloud operators running Linux workloads are equally exposed given confirmed exploitation and available exploit code.

Why it matters

Kernel bugs with active exploitation and public proof-of-concepts give attackers a direct path to privilege escalation, container escape or denial of service. A critical 9.8-rated TLS flaw plus two high-severity issues raise the odds of widespread targeting.

Operators of multi-tenant or containerized environments face elevated risk because a single compromised host can affect many workloads. CISA’s highest-priority designation signals immediate action is required.

How it could have been prevented

Apply the latest kernel security updates from your distribution vendor without delay. Prioritize systems exposing AF_ALG sockets, bridge netfilter/ebtables or kernel TLS.

After patching, perform forensic triage for signs of prior exploitation as directed by CISA. Where immediate patching is impossible, restrict local access, disable unused cryptographic or netfilter features, and monitor for anomalous privilege escalations or container breakouts.

What happened

A Chinese-speaking threat actor exploited CVE-2026-7273, a stack-based buffer overflow in Zyxel GS1900 Smart Managed Switches, to compromise 996 devices across 48 countries and exfiltrate configurations, network data and hashed root credentials. GreyNoise observed the activity around 17 August.

The flaw (CVSS 8.8) allows a LAN-based unauthenticated attacker to run OS commands via a crafted HTTP request on firmware 2.90 and earlier. It was patched by Zyxel in June 2026. The exploit arrived in a heavily obfuscated Python script (PyArmor) that primarily targeted GS1900-24 firmware 2.10-2.90 but included options for other models. 564 of the victims still used factory-default credentials. CISA added the CVE to KEV with a 24 September remediation deadline for federal agencies. The same actor or a related one previously hit WordPress via other CVEs and internet-facing Gitea instances.

Who is affected

Organizations and small businesses running unpatched Zyxel GS1900-series Gigabit Ethernet switches (common in offices, schools, hotels and retail). Victims were concentrated in Italy, the United States, Taiwan, South Korea and other EU countries.

Any LAN-reachable device on firmware through 2.90(XXXX.1)C0 was exposed. Default-credential devices were especially easy targets.

Why it matters

Compromised switches give attackers network visibility, credential material and a foothold for lateral movement or persistent access inside SMB and mid-market environments. Exfiltrated configs and root hashes enable further abuse even after the initial shell is lost.

The campaign links to earlier WordPress and Gitea intrusions, showing a versatile actor comfortable with multiple product families. Network devices are often under-patched and sit at critical traffic choke points.

How it could have been prevented

Upgrade GS1900 switches to the fixed firmware released in June 2026 or later. Change any default credentials immediately and restrict management interfaces to trusted VLANs or jump hosts.

Hunt for GreyNoise-provided indicators of compromise, unexpected configuration changes and outbound connections from switch management IPs. Segment switch management networks and monitor for unusual HTTP requests to the CGI endpoints.

What happened

Attackers briefly controlled the maintainer account of the npm package @dforge-core/dforge-mcp and published a malicious release (0.2.21) that carried valid trusted-publishing provenance. The package shipped a previously unseen loader named GHAPPIER.

The window lasted roughly 35 minutes on 9 September after a failed 0.2.20 attempt. The attacker altered the GitHub Actions workflow so pushes to main triggered unattended publishes via OIDC trusted publishing; the attestation remains in Sigstore’s public log. GHAPPIER is a one-line loader inside a larger file that starts a four-stage chain ending in a self-deleting remote shell. It activates only when the MCP server is launched, not on install. CloudSEK linked related artifacts to at least 65 repositories and noted a second payload matching the PolinRider campaign (credential harvesting via empty Ethereum transactions). No evidence of successful organizational compromise was found, and the malicious version was withdrawn.

Who is affected

Users and projects that installed @dforge-core/dforge-mcp version 0.2.21, especially those that subsequently launched the MCP server. Downstream consumers relying on npm’s trusted-publishing attestations were exposed during the short live window.

Developers whose machines or tokens may have been the initial entry point (possibly via malicious extension or package) and any automated CI that pulled the tainted release.

Why it matters

Valid provenance and signatures are not proof of honest source code. Push access to the repository equaled publish access, bypassing typical npm audit checks. The short exposure still seeded a multi-stage remote shell and demonstrated how stolen maintainer credentials turn trusted CI into a supply-chain vector.

Links to PolinRider-style infrastructure raise the possibility of broader credential-theft campaigns targeting developers. Lockfiles pinning the bad version become lasting indicators.

How it could have been prevented

Pin @dforge-core/dforge-mcp to 0.2.22 or later and treat any lockfile entry for 0.2.21 as an indicator of compromise. Rotate any credentials or tokens that may have been present on affected developer machines.

Alert on unexpected changes to release-workflow trigger blocks. Sweep for the chain’s artifacts rather than only the final implant, and prefer install-time verification plus runtime allow-listing for MCP and similar servers. Review GitHub and npm access logs for the affected maintainer account.

What happened

Researchers from i2CAT, the University of Murcia and NEC Laboratories Europe built 5G-Shark, a low-cost tool using open-source software and inexpensive software-defined radio hardware. It lures a phone onto a fake base station via ordinary cell reselection (no jamming or malformed packets) and then queries it.

On the commercial standalone-5G networks tested, permanent identity (SUPI/IMSI) concealment worked in nearly every case. However, temporary identifiers (GUTIs) were often reassigned in near-sequential patterns, allowing an observer to link 84-96 percent of a subscriber’s consecutive re-registrations by value alone and thereby track the phone over time. One operator randomized properly and dropped linkability to about 7 percent. Crafted Registration Reject messages also forced devices into limited-service 3G, infinite retry loops or frozen modems requiring manual reset. The work is a research preprint auditing real networks.

Who is affected

Mobile subscribers on the tested commercial 5G standalone networks (and potentially others with similar GUTI allocation). Phones from multiple vendors, including a Samsung Galaxy S23 that exhibited denial-of-service behaviors.

Operators whose GUTI reassignment is predictable and device vendors whose modem firmware mishandles certain reject cause codes.

Why it matters

5G was designed to defeat classic IMSI catchers, yet operator choices around temporary identity rotation re-introduce practical tracking. A cheap, passive-looking fake cell can follow a target without user interaction or permanent-identity exposure.

Denial-of-service via reject messages shows additional reliability and safety risks. The gap between a well-randomized operator and a predictable one proves the standard leaves critical privacy knobs in operator hands.

What happened

Ahmed Hossam Eldin Elbadawy, a 24-year-old Texas man, pleaded guilty to federal charges tied to extortion activities of the Scattered Spider cybercrime group. The plea, entered roughly a year earlier, became public through recent court filings seeking forfeiture of criminal proceeds.

Elbadawy acted with co-conspirators Noah Michael Urban and Tyler Robert Buchanan as part of an aggressive subset of The Com. The group used social engineering to obtain credentials and steal sensitive data, focusing on high-net-worth individuals holding significant virtual currency. At least 12 companies across entertainment, telecom, technology and virtual-currency sectors were identified as victims. The crew stole cryptocurrency valued at millions of dollars in high-profile thefts between 2021 and 2022. Prosecutors seek forfeiture of more than $17 million in cryptocurrency plus luxury assets.

Who is affected

The 12-plus companies and high-net-worth individuals targeted between 2021 and 2022, spanning entertainment, telecom, technology and crypto sectors. Victims whose virtual-currency holdings or corporate data were stolen.

Broader organizations that remain potential targets of remaining Scattered Spider or The Com members still at large.

Why it matters

Scattered Spider has been one of the more effective socially engineered extortion crews of recent years. A guilty plea and large forfeiture action demonstrate that U.S. prosecutors can unravel these networks and seize proceeds even years later.

The case underscores the continuing risk of SIM-swapping, help-desk impersonation and credential theft aimed at crypto-rich targets and their employers. Remaining members of the ecosystem may still be active.

What happened

Image-sharing service Gyazo suffered a breach disclosed on 11 September after attackers exploited a vulnerability in an upload server. Roughly 24 million customer records were affected, along with an additional 490 million metadata records tied to images.

Exposed metadata included image IDs, source IP addresses, user-agents, EXIF location data, OCR-extracted text from images, titles, source URLs and hashed passphrases. Because the metadata can be used to construct image URLs, unauthorized viewing of some images became possible; Gyazo temporarily disabled viewing of certain images. The bulk of the stolen metadata relates to images registered on or before January 2019. Helpfeel (the developer) remediated the vulnerability and advised password resets.

Who is affected

More than 23 million Gyazo customers and anyone whose screenshots or images were uploaded to the service, especially developers who routinely capture terminals, config files, API keys or internal tools.

Users whose images contained location EXIF data or sensitive OCR-readable text face elevated follow-on risk even though much of the data is several years old.

Why it matters

Gyazo is widely used for quick screenshot sharing. OCR text turns pixels into searchable credentials, internal URLs, code fragments and documents. EXIF coordinates can reveal home or work locations. URL-construction data lets third parties retrieve images that owners believed were obscure.

Even older secrets retain value if credentials were never rotated. The incident also supplies material for highly targeted phishing that references real past uploads.

How it could have been prevented

Gyazo users should change their passwords on Gyazo and any other site where the same password was reused. Enable multi-factor authentication where available and watch for phishing emails that reference Gyazo or old screenshots.

Developers should assume any credentials, tokens or internal details visible in pre-2019 screenshots may be compromised and rotate them. Organizations should review whether employees used Gyazo for work-related captures containing secrets and treat the metadata exposure as a credential-leak event. Restrict future screenshot tools that perform cloud OCR or retain rich EXIF.