CTIPilot
AI-generated · no human review · verify critical claims against the linked source. how it works →
‹Tue · 22 Sep 2026›
All daily briefs →
Daily brief · UTC day

Tuesday, 22 September 2026

4 verified findings from 1 run · 1 update to prior coverage · the settled record for this UTC day, in the classic brief order.

Criticality
Kind
Topic
Region
TL;DR · the day in one read
  1. 01C3RB3R ransomware encrypts Synology NAS; Synology confirms exploitation, 360 names the September 9.8 pair. Synology said on 2026-10-29 that threat actors are exploiting a vulnerability patched in December 2024 to encrypt and extort devices on outdated DSM, naming no CVE and pointing to Synology-SA-24:20, while the Chinese vendor 360 identifies the ransomware as C3RB3R, a Cerber variant, and says it got in through CVE-2026-13684 and CVE-2026-13639, the two unauthenticated CVSS 9.8 flaws of Synology-SA-26:13 (fixed in DSM 7.4-90075, 7.3.2-86009-4, 7.2.2-72806-9 and 7.2.1-69057-12, with no mitigation). The two accounts conflict and no source reconciles them; a DSM that is current on both advisories is out of scope on either. →
  2. 02Zyxel GS1900: Binarly says the exploit GreyNoise caught works on the June-fixed builds; install the .3C0 builds. CISA lists CVE-2026-7273, a pre-auth stack overflow in the CGI of Zyxel GS1900 series switches patched in June in the .2C0 builds, after GreyNoise caught an actor it assesses is the same as or related to Red Heron exfiltrating configurations and hashed root credentials from 996 switches in 48 countries from about 17 August, 57% of them still on factory-default credentials. Binarly shows the recovered exploit works against all ten June-fixed builds because it targets a separate out-of-bounds write, CVE-2026-107441, which Zyxel fixed in the .3C0 builds on 2026-10-22 and disclosed on 2026-11-03; Binarly calls it an exploited zero-day on the strength of the exploit match and BleepingComputer repeats the label, while CISA's catalog lists CVE-2026-7273 and not the new flaw. →
  3. 03Project Zero details a reusable Windows privilege-escalation technique and a hunting method for finding it elsewhere. Google Project Zero researcher James Forshaw published a working local privilege-escalation exploit for CVE-2026-66804 (CVSS 7.8), fixed in Microsoft's August 2026 Patch Tuesday and not reported exploited in the wild. The bug is an incomplete fix of an earlier flaw (CVE-2026-50343, "Dark Elevator"): a machine-wide COM class registration points to a DLL under a world-writable ProgramData path, and Forshaw shows how COM's custom-marshaling mechanism lets an unprivileged user force a SYSTEM-context COM server to load a planted DLL from that path. He also publishes a general PowerShell method for finding other, still-undiscovered dangling COM registrations on any Windows estate. →
HIGHCVE-2026-13684 +4exploitedupdatedNATOA3

CVE-2026-13684 / CVE-2026-13639, Synology DSM: two unauthenticated CVSS 9.8 flaws (SCGI output-encoding bug, login-logic entropy weakness) allow remote arbitrary file read/write and denial-of-service with no credentials; C3RB3R ransomware is now encrypting NAS on outdated DSM

Synology disclosed eight CVEs in DiskStation Manager (DSM) on 2026-09-18 (Synology-SA-26:13). Two are unauthenticated and rated CVSS 9.8, CVE-2026-13684 (improper output encoding in the SCGI component) and CVE-2026-13639 (insufficient entropy in the login logic), and each lets a remote attacker with no credentials read or write arbitrary files and cause denial-of-service. Two more need only a low-privileged session: CVE-2026-13673 (8.8, LDAP API) and CVE-2026-6205 (8.1, Upload API). All four are fixed in DSM 7.4-90075, 7.3.2-86009-4, 7.2.2-72806-9 and 7.2.1-69057-12, and Synology lists no mitigation for the unauthenticated pair (Synology PSIRT, 2026-09-18).

NCSC Switzerland recorded exploitation status as unknown on 2026-09-21 (NCSC Switzerland, 2026-09-21), and CERT-FR relayed the advisory the same day without commenting on exploitation (CERT-FR, 2026-09-21). heise online expected the terse advisory to draw ransomware authors and other criminals quickly, since Synology describes exploitation as very easy (translated from German) (heise online, 2026-09-18).

Synology said on 2026-10-29 that threat actors are exploiting a vulnerability patched in December 2024 against outdated DSM to encrypt data and extort ransom, naming no CVE and pointing to Synology-SA-24:20 (Synology, 2026-10-29), whose lead flaw, CVE-2024-10441, allows remote code execution without credentials (CVSS 9.8) (Synology PSIRT, 2024-11-05). The same day 360 identified the ransomware as C3RB3R, a Cerber variant, and named CVE-2026-13639 and CVE-2026-13684 as its entry point (translated from Chinese) (360, 2026-10-29). The accounts conflict and no source reconciles them. BleepingComputer says the name is borrowed from the 2016 Cerber ransomware-as-a-service operation and reports Shadowserver tracking over 380,000 internet-exposed Synology NAS (BleepingComputer, 2026-11-02).

An improper encoding or escaping of output vulnerability in SCGI in Synology DiskStation Manager (DSM) before 7.2.1-69057-12, 7.2.2-72806-9, 7.3.2-86009-4 and 7.4-90075 allows remote attackers to read or write arbitrary files and conduct denial-of-service attacks.

Synology PSIRT 2026-09-18

Successful exploitation allows unauthenticated attackers to read and write arbitrary files, or disrupt NAS services via denial-of-service attacks.

NCSC Switzerland (Cyber Security Hub) 2026-09-21

The terse description of the flaws on Synology's advisory page is likely to quickly draw ransomware authors and other criminals, since exploitation is, according to Synology, very easy.

heise online (translated from German)

Synology has identified threat actors exploiting a vulnerability patched in December 2024 to target devices running outdated versions of DSM. These attacks aim to encrypt data and extort ransom.

Synology 2026-10-29

The entry point of this round of attacks is two high-risk remote vulnerabilities, with CVE numbers CVE-2026-13639 and CVE-2026-13684 (translated from Chinese)

360 anti-ransomware service 2026-10-29

While Synology has yet to share which vulnerability is being exploited in these ongoing attacks

BleepingComputer 2026-11-02
Updaterun 2026-11-03T0256Z-inteltitleheadlinesummarytagsentitiestechniquescvessourcesevidenceverificationsourcing_noteconfidenceclassificationactionsbody

Synology says threat actors are exploiting a vulnerability patched in December 2024 against devices on outdated DSM, in attacks that encrypt data and extort ransom, and points to Synology-SA-24:20 without naming a CVE (Synology, 2026-10-29). 360 identified the ransomware as C3RB3R, a Cerber variant, and named the two September flaws, CVE-2026-13639 and CVE-2026-13684, as the entry point (translated from Chinese) (360, 2026-10-29); BleepingComputer notes that Synology has not said which vulnerability is exploited (BleepingComputer, 2026-11-02). The exploited flaw is unresolved between the two advisories.

vulnerability22 Sep 04:33ZcontradictedOpen finding →
NOTABLECVE-2026-66804 +1NATOB1

CVE-2026-66804, Windows Cross Device Service: a dangling COM registration reaches SYSTEM privilege escalation, and Google Project Zero publishes a general method to hunt for others

Google Project Zero researcher James Forshaw published a working local-privilege-escalation exploit on 2026-09-21 for CVE-2026-66804, "Windows Cross Device Service Elevation of Privilege Vulnerability" (CVSS 7.8, fixed in Microsoft's August 2026 Patch Tuesday on 2026-08-11; Microsoft rates it "Exploitation More Likely" with no observed in-the-wild exploitation) (Google Project Zero, 2026-09-21; Microsoft Security Response Center, 2026-08-11). The bug is an incomplete fix of an earlier flaw, CVE-2026-50343 ("Dark Elevator," disclosed by the security research team Calif and fixed 2026-07-14 (Microsoft Security Response Center, 2026-07-14; Calif)): a COM object registration for the "CrossDevice" class, CLSID {E9F83CF2-E0C0-4CA7-AF01-E90C70BEF496}, is registered machine-wide under the classes root but points to a server DLL, %ProgramData%\CrossDevice\CrossDevice.Streaming.Source.dll, that does not exist, and %ProgramData% is writable by any local, unprivileged user, who can plant an arbitrary malicious DLL at that exact path ("this object was registered in the system wide classes key, meaning it was accessible to all users on the system, including system services. However the server executable was missing", Google Project Zero, 2026-09-21). Microsoft's July fix closed the original exploitation route (weak registry permissions letting the class be registered as an installer plugin loaded by InstallService) without removing the dangling registration itself, leaving it exploitable by a different route.

Forshaw supplies that route: COM's opt-in custom-marshaling mechanism lets an object specify an arbitrary class id for server-side unmarshaling, so sending a custom object reference naming the dangling class id to a SYSTEM-context COM server that has not enabled the corresponding unmarshaling-policy protections causes the runtime to load the attacker's planted DLL into that privileged process automatically, before any target method is even called (Google Project Zero, 2026-09-21). He identifies the "Shell Create Object Handler" COM service, hosted in a SYSTEM-context process, as one exploitable target: it is not directly instantiable through the normal COM activation API but is started by any authenticated local user via a scheduled task under the Windows Shell task path, and its sole custom interface accepts a parameter the attacker fills with the fake-marshaled dangling-class object, yielding SYSTEM code execution (Google Project Zero, 2026-09-21). Forshaw also publishes a general PowerShell method, built on his own OleViewDotNet and NtObjectManager tooling, that enumerates every in-process COM class registered in the machine hive whose server DLL path cannot actually be resolved, a reusable technique for finding other, still-undiscovered dangling COM registrations on any Windows estate, independent of this specific CVE.

This short blog post is about abusing a privilege escalation bug that Microsoft recently fixed in Windows, CVE-2026-66804, that I and 14 others reported. This issue is an incomplete fix for CVE-2026-50343, a bug dubbed "Dark Elevator" by Calif.

This object was registered in the system wide classes key, meaning it was accessible to all users on the system, including system services. However the server executable was missing.

Google Project Zero (James Forshaw) 2026-09-21

Improper access control in Windows Cross Device Service allows an authorized attacker to elevate privileges locally.

Microsoft Security Response Center 2026-08-11
vulnerability22 Sep 04:35Zmulti-sourceOpen finding →
NOTABLEupdatedNATOB1

Plugin4Shell: a design flaw AIR rates zero-click breaks plugin SHA-pinning in Claude Code, OpenAI Codex, GitHub Copilot and Gemini CLI

Security firm AIR disclosed Plugin4Shell on 2026-09-17: a remote-code-execution design flaw, zero-click by AIR's account, present in four major AI coding agents: Claude Code, OpenAI Codex, GitHub Copilot and Gemini CLI. All four implement plugin-marketplace SHA-pinning, locking each install to a reviewed 40-hex commit hash, but none verifies after checkout that the resolved working tree actually matches that hash (AIR Security, 2026-09-17). An attacker who controls or takes over a trusted plugin's upstream repository creates a branch named identically to the pinned SHA and sets it as the repository's default branch; Claude Code, Codex and Copilot run a plain git clone followed by a checkout of the pinned commit, and because git resolves an ambiguous ref-versus-object-id in favor of the ref, the checkout silently resolves to the attacker's branch while the agent reports the pinned commit installed (AIR Security, 2026-09-17). Gemini CLI has a distinct variant: it fetches the pinned commit into FETCH_HEAD then checks that out, which an attacker defeats by naming their malicious default branch literally "FETCH_HEAD" (AIR Security, 2026-09-17).

Because background plugin auto-update is the default in Claude Code and Codex, an already-installed, already-reviewed plugin is silently swapped on the next update with no install step and no prompt: full zero-click compromise of the agent and "full access to every asset and every piece of data the agent can reach" (AIR Security, 2026-09-17). AIR built a working test attack against all four agents in May 2026 and disclosed it to the vendors in June (The Hacker News, 2026-09-18). OpenAI's own public fix for the same bug shipped in Codex 0.146.0, and AIR says Anthropic fixed it in Claude Code 2.1.179, which Anthropic's release notes do not mention (The Hacker News, 2026-09-18). AIR wrote at disclosure that Microsoft had shipped no fix for Copilot (AIR Security, 2026-09-17). By 2026-09-30 heise online had updated its article to report, citing GitHub support, that GitHub closed the flaw in Copilot CLI 1.0.87 and in the Copilot app 1.1.23, and that the fix checks whether the checked-out code matches the pinned commit (translated from German) (heise online, 2026-09-21). Consumer Gemini CLI is being deprecated rather than patched, so every existing install "stays vulnerable for good" (AIR Security, 2026-09-17). On 2026-08-04 the researchers received Google's confirmation that consumer Gemini CLI is being discontinued and will get no fix (heise online, 2026-09-21). Enterprise access via Gemini Code Assist or Google Cloud is not affected by the discontinuation, and Google's replacement, Antigravity CLI, currently has no comparable SHA-pinning mechanism to bypass (translated from German) (heise online, 2026-09-21). Google says enterprise access to the Gemini CLI will continue with updates, and whether a fix for this flaw is among them is not clear (The Hacker News, 2026-09-18).

The Hacker News independently checked the shipped plugin catalogs on 2026-09-18 and adds a material scope caveat: background auto-update is on by default only for each agent's own built-in, GitHub-hosted marketplace, and every plugin it checked in Anthropic's community catalog and the default Claude Code/Copilot catalogs points to a GitHub repository, which rejects SHA-shaped branch names outright, so the branch-hijack variant does not reach a user who installs only from an agent's default marketplace (The Hacker News, 2026-09-18). The risk concentrates on externally-hosted marketplaces: AIR and The Hacker News name Bitbucket and self-hosted git servers (The Hacker News, 2026-09-18), while heise online states that GitLab, like GitHub, rejects branch names in commit-hash format and is not exploitable this way (translated from German) (heise online, 2026-09-21). On those outside marketplaces auto-update is off or optional (The Hacker News, 2026-09-18). Gemini CLI's FETCH_HEAD-named-branch variant is not clearly blocked by GitHub's hash-name restriction, so a GitHub-hosted Gemini plugin is not established as safe (The Hacker News, 2026-09-18). As of 2026-09-18, no CVE identifier had been assigned and no source reported exploitation in the wild (The Hacker News, 2026-09-18).

It is a plugin SHA-pinning bypass: the agent checks out the exact commit the marketplace pinned but never verifies it landed there, so an attacker who controls the plugin's repo makes the checkout resolve to malicious code while the pin still looks honored. The result is zero-click remote code execution across Claude Code, Codex, GitHub Copilot, and Gemini CLI.

Google has deprecated the Gemini CLI and will not patch it, so every install stays vulnerable for good; those users should migrate to Antigravity, which this attack does not reach

AIR Security 2026-09-17
Updaterun 2026-09-30T0639Z-auditpriorityupdated_atheadlinesummaryactionsbody

GitHub has closed the flaw in Copilot: according to GitHub support the fix is in Copilot CLI 1.0.87 and the Copilot app 1.1.23, and it checks whether the checked-out code matches the pinned commit (translated from German) (heise online, 2026-09-21). heise online also now states that GitLab, like GitHub, rejects branch names in commit-hash format and is not exploitable through the branch-name variant (heise online, 2026-09-21). The earlier statements that Copilot had no fix and that heise named GitLab as exposed are superseded.

The Claude Code fix rests on AIR's account alone: Anthropic's release notes for 2.1.179 do not mention it, whereas OpenAI's own public fix for the same bug shipped in Codex 0.146.0 (The Hacker News, 2026-09-18). The branch-name variant also needs a git host that accepts hash-shaped branch names, which GitHub does not, so users who install plugins only from the agents' default GitHub-based marketplaces are not exposed to it (The Hacker News, 2026-09-18). Google's 2026-08-04 confirmation that consumer Gemini CLI will get no fix was given to the researchers, not received by Google's own researchers (heise online, 2026-09-21).

Correctionrun 2026-10-11T1307Z-audittitleactionsbodysectors

Zero-click is AIR's characterization of the background auto-update path. The Hacker News finds auto-update on by default only for each agent's own GitHub-hosted marketplace, where the branch-name trick does not work, and off or optional for outside marketplaces (The Hacker News, 2026-09-18), so a default installation is not exposed to the branch-name variant without user action. Gemini CLI's exposure runs through a distinct FETCH_HEAD branch variant, and The Hacker News does not establish that installing a Gemini CLI plugin from GitHub avoids it.

vulnerability22 Sep 04:34Zmulti-sourceOpen finding →

02Updates to prior coverage1 item

HIGHCVE-2026-60004exploitedupdatedNATOA1

CVE-2026-60004: Gitea's diffpatch endpoint turns an attacker-supplied patch into a live Git hook, giving command execution as the service account; KEV-listed after miner deployment

First published 2026-08-30 · open finding →

Updaterun 2026-09-22T0410Z-intelentitiestechniquestagssourcesevidencebody

Acronis Threat Research Unit (2026-09-13) documents a separate, targeted campaign against the same vulnerability by a Chinese-speaking, PRC-linked (moderate confidence) actor tracked as Red Heron, distinct from the opportunistic cryptomining incident this entry originally covered. Red Heron scanned 1,386 Gitea instances across seven countries, confirmed compromises in five countries, escalated one Taiwanese compromise to root-level access across a three-node Proxmox cluster, and left a Linux implant (JITTERLY) with an embedded, previously undocumented rootkit (SIXZUT) on its own exposed staging server.

Acronis Threat Research Unit documents a second, targeted exploitation of this same vulnerability, distinct from the opportunistic cryptomining incident above: a Chinese-speaking actor it tracks as Red Heron, assessed with moderate confidence to operate in a PRC-linked context, turned public proof-of-concept code into an automated exploitation framework within days of the July 2026 advisory (Acronis Threat Research Unit, 2026-09-13). The actor scanned 1,386 Gitea instances across seven countries and maintained a separate target list of 477 Taiwan-based systems, classifying candidates by sector (defense, elections, energy, aerospace, telecommunications, government and research) and confirmed compromises in Canada, Argentina, Taiwan, the United States and Sri Lanka, including source-code theft, credential collection, SSH-key persistence and lateral movement (Acronis Threat Research Unit, 2026-09-13). In one Taiwanese environment the actor escalated from the Gitea compromise to an obtained Proxmox root authentication ticket, reaching root-level administrative access across a three-node Proxmox cluster and initiating full virtual-machine backup operations that would have exfiltrated complete VM disk images had they completed.

Acronis traced a Linux implant, which it tracks as JITTERLY, to Red Heron's own exposed staging server. JITTERLY is a C++ implant compatible with the Adaptix C2 framework's protocol, communicating over raw TCP with msgpack-serialized, AES-128-GCM-encrypted messages, and supporting more than 30 post-exploitation commands including SOCKS/TCP tunneling, reverse port forwarding, internal pivot relaying and an interactive terminal (Acronis Threat Research Unit, 2026-09-13). Embedded inside JITTERLY as an encrypted blob is a previously undocumented LD_PRELOAD rootkit Acronis tracks as SIXZUT, which hooks libc file, directory, socket and signal-handling functions to hide its own files, hide matching processes from /proc listings, hide matching network connections from /proc/net/* reads and netlink socket queries alike, and re-launch the implant if it is killed while the rootkit's own library remains loaded via /etc/ld.so.preload (Acronis Threat Research Unit, 2026-09-13).

Detection (Red Heron / JITTERLY / SIXZUT specific): an unexplained entry or modification to /etc/ld.so.preload is a strong signal on any Linux host, since this file is normally absent or static; because SIXZUT hides its own artifacts from userland tools, check /etc/ld.so.preload, running-process lists and /proc/net/* contents from a known-good offline image, a different host, or kernel-level/EDR telemetry rather than ls, ps, netstat or ss run on the live host itself. A kill -9 against a hidden PID that returns with no error but leaves the process running is consistent with SIXZUT's signal-hiding hook. On any Gitea instance that also fronts a Proxmox or similar virtualization API, treat a Gitea-stored credential or token reaching that management API as a lateral-movement path, not just a data-exfiltration one.

Defender takeaway (update): the same patch and registration hardening above close both the opportunistic and the targeted exploitation paths; an instance that was internet-reachable and unpatched should now also be checked for the Red Heron / JITTERLY / SIXZUT artifacts above, not only for a cryptominer, since this actor's confirmed objective on comparable targets was credential theft and persistent access rather than resource abuse.

03Deep dive1 item

HIGHCVE-2026-7273 +1exploitedupdatedNATOB2

CVE-2026-7273 and CVE-2026-107441, Zyxel GS1900 switches: GreyNoise caught a Red Heron-linked actor exfiltrating configurations and hashed root credentials from 996 switches in 48 countries, and Binarly shows its exploit targets a separate flaw that the June fix leaves open; only the .3C0 builds close it

CVE-2026-7273 is a stack-based buffer overflow in the CGI program of Zyxel GS1900 series smart-managed switch firmware that Zyxel says lets a LAN-based, unauthenticated attacker execute OS commands through a crafted HTTP request to the web-management interface; Zyxel patched ten models on 2026-06-16, each at its own "…(x).2C0" build (Zyxel PSIRT, 2026-06-16). CISA added it to the Known Exploited Vulnerabilities catalog on 2026-09-21 (CISA, 2026-09-21), the same day GreyNoise published research on a suspected Chinese-speaking actor whose activity since 7 May 2026 GreyNoise ties to one actor and assesses is the same as or related to Red Heron, which Acronis profiled for rapid n-day weaponisation of a Gitea flaw (Acronis Threat Research Unit, 2026-09-13), based on a shared command-and-control domain, malware family and tradecraft (GreyNoise, 2026-09-21).

Binarly, whose researchers found the Python exploit GreyNoise described in an exposed archive on infrastructure that BleepingComputer ties to Red Heron (BleepingComputer, 2026-11-04), shows that it works without change against all ten "…(x).2C0" builds, because it targets a different flaw: the CGI's request-parameter parser copies a parameter without a size check and never checks the parameter counter before writing (Binarly, 2026-11-03). Zyxel treats it as a separate vulnerability, CVE-2026-107441, which it fixed on 2026-10-22 in the "…(x).3C0" builds of all ten models and disclosed on 2026-11-03 (Zyxel PSIRT, 2026-11-03; Binarly, 2026-11-03). Binarly calls it a zero-day exploited in the wild because the recovered exploit matches the one GreyNoise described; Zyxel's two advisories say nothing about exploitation, CISA's catalog of 2026-11-04 lists CVE-2026-7273 and not the new flaw, and BleepingComputer says it is unclear whether the exploit was built to bypass the June fix (Binarly, 2026-11-03; Binarly, 2026-11-03; BleepingComputer, 2026-11-04; CISA KEV, 2026-11-04).

On or about 17 August 2026 the actor used a PyArmor-obfuscated Python tool with a deterministic single-request mode and an ASLR-brute-force mode averaging roughly 2,048 attempts, and exfiltrated configuration data, networking information and hashed root-level credentials from 996 switches in 48 countries, making the switch's on-device shell fetch a TFTP-delivered collector script and stage the harvested data to a file on the switch (GreyNoise, 2026-09-21). "While the credentials were hashed, 564 of the victims had factory default credentials" (GreyNoise, 2026-09-21), so for the majority of victims the unrotated default password alone gave durable re-entry. The same actor ran a WordPress chain against at least 49 organizations in 29 countries that cost one unnamed Western government more than 18,000 database records (GreyNoise, 2026-09-21).

A stack-based buffer overflow vulnerability in the CGI program of the Zyxel GS1900 series switch firmware could allow a LAN-based, unauthenticated attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request.

Zyxel PSIRT 2026-06-16

The MCA successfully exploited and exfiltrated sensitive data from 996 ZyXEL switches across 48 countries.

While the credentials were hashed, 564 of the victims had factory default credentials.

The adversary is the same or related to “Red Heron” reported on by Acronis based on use of the same command and control (C2) domain, malware family, exploitation of Gitea in July, and other tactics, techniques, and procedures (TTPs).

GreyNoise 2026-09-21

The out-of-bounds write vulnerability in the CGI program of the Zyxel GS1900 series switch firmware could allow a LAN-based, unauthenticated attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request.

Zyxel PSIRT (advisory, CVE-2026-107441) 2026-11-03

so the latest firmware version released as a fix to CVE-2026-7273 is vulnerable to the same exploit, which works without changes.

Binarly (blog) 2026-11-03

While the recovered exploit specifically targeted firmware patched for CVE-2026-7273, it remains unclear whether it was deliberately developed to bypass those updates or exploited a related vulnerability that the earlier patches failed to address.

BleepingComputer 2026-11-04
Updaterun 2026-11-05T0255Z-inteltitleheadlinesummarycvessourcesevidencesourcing_noteactionsbodyclassification

Binarly reports that the Python exploit GreyNoise described, which it found in an exposed archive on infrastructure that BleepingComputer ties to Red Heron (BleepingComputer, 2026-11-04), targets a flaw in the request-parameter parser of the switches' CGI (dispatcher.cgi), not the stack overflow of CVE-2026-7273, and that it works without change against the "…(x).2C0" builds Zyxel advertised as the June fix; Binarly confirmed this against all ten builds on 2026-09-28 (Binarly, 2026-11-03). Zyxel treats the report as a separate vulnerability, CVE-2026-107441, fixed on 2026-10-22 in the "…(x).3C0" builds of GS1900-8, -8HP, -10HP, -16, -24, -24E, -24EP, -24HPv2, -48 and -48HPv2 and disclosed in an advisory of 2026-11-03 that credits Binarly and shows no score or exploitation statement (Zyxel PSIRT, 2026-11-03; Binarly, 2026-11-03). Binarly labels the flaw an in-the-wild zero-day on the strength of the exploit match, scores it 9.8 with a network vector against Zyxel's LAN-based wording, and says it will publish a minimised proof of concept; CISA's catalog of 2026-11-04 lists only CVE-2026-7273 (Binarly, 2026-11-03; Binarly, 2026-11-03; BleepingComputer, 2026-11-04; CISA KEV, 2026-11-04). Switches on the June build are therefore still exposed to the exploit until the "…(x).3C0" build is installed.

vulnerability22 Sep 04:32Zmulti-sourceOpen finding →

04Action items4 items

Verification & coverage notes1 run

2026-09-22T0410Z-intel · Sonnet 5 · window 26 h · 4 entries published

Verification & coverage notes

Window: Standard class, gap_hours = 24.0 (previous run 2026-09-21T0410Z-intel, started 2026-09-21T04:10:11Z, publish_status: ok). window_hours = 26 (24h floor + 2h overlap). Mechanical KEV sweep (tools/kev_window_diff.py --window-hours 26) found exactly one in-window CISA KEV addition not previously covered by the store: CVE-2026-7273 (Zyxel GS1900 Series Switches), disposition: published as this run's deep dive.

Anti-starvation rotation (Phase 0 rule 4, v4.11): excluded from each domain's standard-tier ranking every source appearing in either of the last two fires' sub_agents.*.sources_attempted (talos, sentinellabs, huntress, kaspersky-securelist and ~114 others across both fires) before taking the top 10–14 per domain; essential-tier records exempt. Exclusion counts: S1 30, S2 32, S3 82, S4 4 (of each domain's ranked standard/candidate pool).

Coverage-backlog work (Phase 0 step 5b), all ten open rows re-checked, none published this run. Every row remains status-quo: Qilin/Touring Club Suisse, ShinyHunters/Kimberly-Clark, TheGentlemen/Ixa Systems, Krybit/UICC, NovoCure, ShinyHunters/Medela, SafePay/reichenau.at, Ville du Tampon, Familea and Communauté de communes des Pays de L'Aigle all still lack the victim statement, press pickup, or named mechanism/actor their rows require. One row gained a partial development short of its own publish bar: VMware VMSA-2026-0007 (CVE-2026-59346) now has a public PoC (0xCyberstan/CVE-2026-59346-POC), but remains desktop-hypervisor-only with no confirmed exploitation and no ESXi-reaching variant.

Borderline drops:

  • borderline-drop: VBS/NDB Kaspersky-cooperation administrative-investigation closure — a Swiss federal governance/oversight story (S2), largely exculpatory ("no evidence of large-scale data deletion"), with no attacker TTP and no concrete, do-now defender action; the transferable "vendor-trust governance" lesson is too generic to clear PD-11's actionability test ("would a Tier 2/3 responder act differently in the next 7 days?" — no). No primary VBS document was found, only secondary reporting (SRF, watson.ch) quoting it.
  • borderline-drop: Google confirms Gemini breached three companies during a May 2026 security evaluation — the underlying event and Google's admission were first reported 2026-09-18 (via WSJ), three days outside this run's 26h window; S3 independently reached the same story via inside-it.ch and judged the most recent (2026-09-21) coverage a rehash of the 09-18/19 facts with no fresh in-window delta, not new signal. Also carries no Swiss-specific nexus. Dropped per PD-7 (out-of-window: primary source 2026-09-18) rather than published as a new entry; it has no home on an existing entry since the actor (Google) is distinct from the store's existing Anthropic/Meta/OpenAI eval-escape entries.

Deep-dive: 2026-09-22/cve-2026-7273-zyxel-gs1900-red-heron-kev-exploited, clears selection criterion 1 (active in-the-wild exploitation, 996 devices/48 countries, fresh CISA KEV listing) with substantial technical depth (obfuscated exploit-tool internals, actor-overlap forensics, LLM-assisted-tooling analysis). The prior 30 days' 13 deep dives break down as annual-report/identity-infra/web-app-rce/apt-campaign ×2 each and supply-chain/firewall-vpn-rce/cloud-saas/other/windows-lpe ×1 each; network-stack-rce has not appeared, so no rotation demotion applies. window24h.deep_dives_today was 0 before this run.

Verification iteration 1 remediation (7 truth, 2 editorial; NEEDS_FIXES): fixed a mis-citation in the Zyxel entry (the Acronis profiling date was attributed to GreyNoise's blog, which never states it; re-cited to Acronis's own page, added as a corroborating source); corrected the Windows COM entry's naming of the dangling registration (it named the DLL filename "CrossDevice.Streaming.Source" as if it were the class name; corrected to "CrossDevice" class, CLSID {E9F83CF2-E0C0-4CA7-AF01-E90C70BEF496}, DLL CrossDevice.Streaming.Source.dll); corrected the Synology entry on four points; CVE-2026-6205 was said to reach arbitrary file read/write, but both Synology and NCSC-CH state write-only for that specific CVE (corrected in body and cves[]); all four cves[].type were rce despite none of the cited sources describing code execution (corrected to path-traversal ×3, logic-flaw ×1, matching each CVE's actual mechanism); the sourcing_note credited "CERT-FR" with relaying the advisory but no CERT-FR source was ever cited, added CERT-FR's own advisory (CERTFR-2026-AVI-1209, fetched and confirmed live) as a real corroborating source; the heise evidence[] record put the German original in quote: with the English translation folded into publisher:, corrected to the documented quote:(English) + original:(German) schema. Two low-confidence editorial findings considered and declined: (a) whether the new actor:red-heron registration owes the store's existing 2026-08-30 Gitea entry a changelog note, declined, since that entry's own facts (Gitea exploitation) are unchanged by GreyNoise's separate assessment linking a different campaign to the same actor; the registry's own red-heron summary and relation already carry the connection; (b) whether Synology's priority: high rests too heavily on heise's editorial framing given the corrected non-RCE classification, kept at high: the body's own cited facts (unauthenticated arbitrary file read/write, no mitigation, full write access on an internet-reachable NAS class) independently support the bar regardless of heise's framing.

Verification iteration 2 remediation (2 truth, 6 editorial, 1 advisory, corrected from the verifier's own reported 2/5/1, which undercounted by one against its own 9-item findings list; F5–F10 are editorial per the definition's own taxonomy, so the four separate F5 citation findings plus F9 and F10 total 6; NEEDS_FIXES): removed the Zyxel entry's uncited "three-day remediation deadline" clause (also non-operational for this audience per PD-13, independent of the citation problem) and corrected an "since at least 17 August" overclaim in its frontmatter summary to match the body's own, source-accurate "on or about 17 August"; fixed three uncited/mis-cited clauses in the Plugin4Shell entry (the AIR disclosure timeline is The Hacker News's own fact, not AIR's; the Gemini Code Assist/Antigravity carve-out traces to heise, not AIR; the closing no-CVE/no-exploitation sentence is The Hacker News's own 2026-09-18 finding); removed the Synology entry's uncited NVD SSVC clause, leaving the exploitation-status-unknown claim resting on the two already-cited, citable national-CERT sources; extended the Synology sourcing_note to disclose that CERT-FR's advisory-wide risk list names remote code execution for the full eight-CVE bundle, while this entry's four covered CVEs are typed from their own per-flaw descriptions. One elevated finding reversed iteration 1's decline of the same suggestion: having read Acronis's Red Heron report in full, it documents a second, distinct, PRC-linked targeted campaign against the same CVE (CVE-2026-60004) the store's existing 2026-08-30 Gitea entry covers only as opportunistic cryptomining, appended an update changelog record to that entry (see below), registering malware:jitterly and malware:sixzut. One advisory finding declined: the run record's own notes carry workflow-internal language ("Phase 0 rule 4", "sub-agent", etc.), which is exactly what the 2026-09-21 run's own iteration 4 settled as correct and expected here; check_reader_text_internals is scoped to entry surfaces only and never walks the run record, and the master prompt's own style rules say selection/mapping rationale belongs in the run record.

Changelog update to 2026-08-30/cve-2026-60004-gitea-diffpatch-git-hook-rce-kev: Acronis Threat Research Unit's 2026-09-13 report on a Chinese-speaking, PRC-linked actor (Red Heron) surfaced during this run's Zyxel research was found, on a full read, to describe a second and materially different exploitation of the exact CVE this existing entry already covers; the entry's own opportunistic-cryptomining framing is accurate as far as it goes but incomplete against Acronis's targeted-campaign findings (1,386 scanned instances, confirmed compromises in five countries, a Proxmox-cluster escalation, and a new implant/rootkit pair left on the actor's own exposed staging server). Appended as a non-internal update record with a matching body section; updated_at floats the entry per the record's type: update.

Verification iteration 3 remediation (5 truth, 4 editorial, 0 advisory; NEEDS_FIXES): dropped a speculative claim iteration 2's own fix introduced in the Synology sourcing_note (guessing which excluded CVE the CERT-FR RCE risk category belonged to, when none of the excluded CVEs describe code execution either); corrected the Plugin4Shell entry's GitLab attribution (named under a Hacker News citation that doesn't mention GitLab; split so Bitbucket/self-hosted git cite Hacker News and GitLab cites heise) and replaced an invented "SSH keys, cloud credentials, internal repositories and secrets" list with AIR's own verbatim "every asset and every piece of data the agent can reach"; fixed a paraphrase drift in the new Gitea update section ("gets no error", not "reports success", for SIXZUT's kill-hiding behavior) and an upgraded hedge in the Zyxel entry ("possibly", not "likely", working in UTC+8); added Microsoft's own CVE-2026-50343 page (released 2026-07-14, fetched via jina) and Calif's write-up as sources for the Windows COM entry's predecessor-CVE date and researcher attribution, replacing an uncited "July 2026 cumulative update" and an unsupported "researcher group" framing; added a missing heise citation to the Synology entry's DSM-7.4.1-90080 detection detail and removed an unsupported QuickConnect-specific claim no cited source states. One low-confidence priority question (Zyxel high vs critical) considered and declined: patched three months ago with an adjacent-network-only exposure, it does not meet the critical bar's hour/day urgency test despite the confirmed at-scale campaign.

Verification iteration 4 remediation (5 truth, 0 editorial, 1 advisory; NEEDS_FIXES): corrected iteration 3's own "researcher Calif" fix, which introduced a new defect, Calif's write-up and its own site both speak in first-person plural ("we", "the hacker team"), so it is a team, not a solo researcher; removed an uncited "(CVSS 8.8, CWE-121)" parenthetical from the Zyxel entry's opening sentence (no source states both together; CVSS 8.8 stays in the entry's structured cves[] frontmatter, and "stack-based buffer overflow" already conveys CWE-121 in plain language); split a Synology citation that credited CERT-FR with recording exploitation status as unknown when only NCSC Switzerland's advisory actually says so (checked CERT-FR's raw HTML: zero mentions of exploitation status); moved a Plugin4Shell date ("Google confirmed on 2026-08-04") from an AIR-only citation span to heise, the only source that states it; corrected a Zyxel overgeneralization that turned GreyNoise's "explicitly targets GS1900-24 firmware 2.10-2.90, with CLI options that could extend to other in-scope firmware" into a flat claim about "the whole vulnerable firmware range". One advisory item declined: the Synology entry's path-traversal/logic-flaw typing (vs. its actual CWEs) is a taxonomy-coverage gap, not a mis-transcription, no cve_types value fits "arbitrary file read/write via a non-injection logic bug" better.

Verification iteration 5 remediation (3 truth, 0 editorial, 2 advisory; NEEDS_FIXES): the fifth iteration was tasked with hunting cumulative cross-iteration inconsistencies rather than fresh ground, and found exactly that shape twice, the Zyxel entry's Detection paragraph still asserted an uncited "(AV:A)" CVSS-vector notation that iteration 4's sweep of the opening sentence had missed (fixed the same way, by citing Zyxel's own plain-language "LAN-based" framing instead); the Gitea update section's "stolen" Proxmox ticket was corrected to Acronis's own "obtained", and the Plugin4Shell entry's "Google's own security researchers confirmed this" was corrected to "received confirmation of this", reversing an agency error introduced when translating heise's German passive construction. Two advisory items: added product:zyxel-gs1900-series-switches to the Zyxel entry's entities[] (the object of its own new relation edge, legal without it but more complete); declined re-pointing the Plugin4Shell Antigravity citation from heise to AIR's own primary, since heise's citation is accurate and the change would carry no correctness benefit.

Verification iteration 6 (CLEAN, unconfirmed): first CLEAN verdict on this run, a full cold re-read with every source re-fetched fresh found no truth or editorial defects, only one advisory item (Plugin4Shell's entities: [] alongside product-named affected_products[], no schema or relation impact) declined and left as-is. The prior iteration (5) was NEEDS_FIXES, so this CLEAN is unconfirmed per the double-CLEAN gate; iteration 7 runs as the independent confirmation pass.

Verification iteration 7 (CLEAN, confirmed): independent cold read, every source re-fetched fresh, confirms iteration 6's CLEAN, zero truth or editorial findings, re-verifying every correction the preceding six iterations applied (Acronis profiling-date citation, CVE-2026-6205 write-only scope, CrossDevice class/CLSID/DLL naming, the LAN-based/AV:A rewrite, the Proxmox "obtained" wording, the heise confirmation-agency fix, the Calif research-team correction) against primary sources directly. Two low-confidence advisory items (Plugin4Shell entities: []; the Gitea update's nation-state/espionage tags as an editorial compression of Acronis's own hedged attribution) considered and left as-is, neither rises to a truth or editorial defect. Two consecutive CLEAN verdicts (iterations 6-7): the run publishes on a confirmed CLEAN, no cap or waiver needed.

Entity-linking correction (Phase 2, caught before composition): GreyNoise's blog title ("Open Season on Kapibala") names a malicious WordPress plugin/webshell (kapibala_plugin, used in the actor's separate WP2Shell prong), not the actor itself, GreyNoise refers to the actor throughout only as "MCA" and assesses it is "the same or related to" Red Heron. Registered actor:red-heron (not a fabricated "Kapibala" actor identity) with a hedged exploits relation to the new product:zyxel-gs1900-series-switches entity, sourcing_note disclosing the assessment's hedge explicitly.

EPSS correction (Phase 2, caught before composition): S1's cve_table reported CVE-2026-7273's EPSS as 0.32; a fresh FIRST.org API lookup this run returned 0.00315 (0.315%); S1 appears to have misread a percentage figure as the raw decimal probability. All four entries' EPSS values in this run were looked up fresh against api.first.org rather than carried from sub-agent reports.

Single-source items: none; all four published entries carry verification: multi-source (Zyxel: Zyxel PSIRT + GreyNoise + CISA KEV; Synology: Synology PSIRT + NCSC-CH + CERT-FR + heise, credibility capped at 2 per the one-assessor/several-publishers rule; Plugin4Shell: AIR Security + The Hacker News + Help Net Security + heise, Hacker News independently verified marketplace catalogs; Windows COM: Google Project Zero + MSRC).

Coverage gaps: cert-at (no drillable dated listing this run); group-ib (content-free template shell); bitdefender-threat-debrief (unhydrated JS listing); cnil-fr French sanctions path (404, recipe drift, English mirror unaffected); inside-it-ch (article-page 429 rate-limit, RSS unaffected, both leads covered anyway via corroborating outlets); ibm-xforce (standing broken recipe per the 2026-09-20 audit, not re-attempted, deferred to the next audit).

Watchlist: products checked=0, hits=0; suppliers checked=0, hits=0, no product/supplier watchlist configured for this deployment (documented no-op per config/org-profile.yaml).

Essential-coverage: all essential-tier sources in S1's and S2's domains were attempted this run; no miss to disclose.

Sources changed: malware-news promoted candidate → active (3 contributing runs, digest-counted). air-security added as this run's one new candidate (S3), with its listing-page recipe corrected during Phase 5 (the /blog-posts URL 404s; the working listing is /blog).