Daily Cybersecurity News – September 21, 2026

What happened

CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog, confirming active exploitation and directing federal agencies to patch immediately.

CVE-2025-39682 (CVSS 9.8) is a critical flaw in TLS receive-path handling of zero-length records on the rx_list. Improper checks during zero-copy decryption let a local attacker cause denial-of-service or memory disclosure.

CVE-2025-39964 (CVSS 7.8) is a race condition from concurrent writes to the same AF_ALG socket that interleaves data and corrupts cryptographic state, enabling crashes or DoS. CVE-2026-53266 (CVSS 8.8) is an out-of-bounds write in the bridge Netfilter ebtables SNAT target; a crafted ARP packet can corrupt memory outside the intended buffer.

Who is affected

Systems running affected Linux kernel versions that include the TLS, AF_ALG crypto, or bridge Netfilter ebtables components. This covers a wide range of servers, desktops, containers, and cloud instances across distributions.

Local access is required for exploitation in the described scenarios, but the broad deployment of the kernel means large populations of multi-user or containerized environments are exposed until patched.

Why it matters

Kernel flaws under active exploitation give attackers reliable primitives for DoS, information leaks, or memory corruption that can escalate to full compromise on multi-tenant hosts.

Operators of production Linux fleets, especially those running untrusted workloads or shared infrastructure, face elevated risk of disruption or further payload delivery. The CISA KEV listing creates compliance pressure for federal and many regulated environments.

How it could have been prevented

Apply vendor kernel updates that resolve CVE-2025-39682, CVE-2025-39964, and CVE-2026-53266 as soon as they are available for your distribution.

Prioritize systems with local user access or container workloads. Monitor for unusual AF_ALG or ebtables activity and restrict unprivileged local access where feasible. Verify patch levels with package managers and reboot into the new kernel.

What happened

Security researchers demonstrated two sandbox escapes in OpenAI's Codex coding agent. The more serious technique, called Heapjack, allowed unsandboxed command execution on the host from Codex's most locked-down mode with no approval prompt or visible UI.

Heapjack abused the node_repl component written into ~/.codex/config.toml. Trusted and untrusted JavaScript contexts shared one Node.js process and heap; untrusted code used v8.getHeapSnapshot() to locate a random authorization token, then forged requests on the pipe to the native parent process.

Both issues were reported on August 12 and patched by OpenAI within eight days. A proof-of-concept used the system open command to launch applications outside the sandbox.

Who is affected

Developers and organizations using OpenAI Codex (CLI or Desktop) prior to the August 2026 patches, especially those opening untrusted or third-party repositories.

Any machine running Codex Desktop inherited the node_repl entry automatically; plain CLI users were also exposed via the shared config.

Why it matters

AI coding agents are granted broad access to source code and local tools. A sandbox escape turns a routine 'ask about this repo' action into remote code execution on the developer's machine.

This expands the attack surface of supply-chain and social-engineering campaigns that deliver malicious repositories. Builders integrating similar agent sandboxes must treat shared-memory or shared-process designs as high-risk.

How it could have been prevented

Update Codex CLI and Desktop to the patched versions released after the August 12 report.

Avoid opening untrusted repositories in Codex until confirmed patched. Review ~/.codex/config.toml for unexpected tool entries, run agents in isolated environments or VMs when handling external code, and monitor for unexpected process launches from Codex parent binaries.

What happened

Threat actors are using ClickFix-style social-engineering lures to deliver a previously undocumented remote access trojan named ChainScript. The malware appears under build names such as ComponentTask33, UpdateDigital, HostShared, and OrchidViolet66, and masquerades as Spotify, Zoom Workplace, or Microsoft Teams installers.

Infection begins with a lure that causes the victim to run a malicious MSI via msiexec.exe. The installer drops a Node.js runtime and launches a JavaScript agent through hidden PowerShell and VBScript stages, placing components under Microsoft-looking paths in %LOCALAPPDATA%. Persistence is established via scheduled task with a Registry Run key fallback.

ChainScript uses an EtherHiding-style C2 discovery method that queries a Polygon smart contract to locate the current WebSocket infrastructure, then provides full remote control including interactive shells, file ops, screenshots, wallet enumeration, payload deployment, and remote JavaScript execution.

Who is affected

Windows users who follow ClickFix-style instructions or download the disguised installers. The campaign has been observed delivering the RAT under popular software brand names.

Any environment where users can execute MSIs or PowerShell/VBScript from untrusted sources is exposed. Related ClickFix activity has also targeted macOS in separate incidents.

Why it matters

ChainScript combines familiar social engineering with blockchain-based C2 rotation, making traditional IP or domain blocklists less effective. Operators gain extensive post-exploitation capabilities, including crypto-wallet theft and live interactive access.

The pattern of using development runtimes (Node.js) and decentralized discovery reflects a broader shift that complicates detection and takedown. Defenders must treat ClickFix lures as high-confidence delivery vectors for full RATs.

How it could have been prevented

Train users to never execute commands or installers presented in 'fix this to fix' prompts from unsolicited sources. Block or alert on msiexec.exe launching unexpected MSIs and on PowerShell/VBScript writing to %LOCALAPPDATA% under Microsoft-looking paths.

Monitor for new scheduled tasks and Run key entries, inspect outbound WebSocket connections, and consider blocking or scrutinizing traffic related to known Polygon contract lookups used for C2. Keep endpoint detection tuned for Node.js agents running from user profile directories.

What happened

The Rust project warned that an ongoing social-engineering campaign is targeting Rust-lang team members and owners of popular crates. Attackers lure victims into video calls framed as job offers or contract work, then trick them into installing software (claimed missing audio codec) or executing code pasted from the clipboard.

Fake companies with convincing LinkedIn pages are created to add legitimacy. The Rust team linked the activity to earlier incidents, including a June wave against prominent developers and the August compromise of the arrayref crate that briefly published malicious packages.

Techniques match those previously associated with North Korean actors, though the team did not name a specific group for the current wave.

Who is affected

Rust core team members, maintainers, and owners of widely used crates on crates.io. Developers who accept unsolicited video-call invitations from apparent recruiters or contractors are the primary targets.

Compromise of maintainer credentials can lead to malicious package publication affecting the broader Rust ecosystem and downstream users.

Why it matters

Successful credential theft or malware deployment against crate owners enables supply-chain attacks that can reach thousands of dependent projects. Prior arrayref compromise demonstrated the real impact.

Nation-state interest in the Rust ecosystem raises the stakes for open-source maintainers who often lack enterprise-grade defenses. Builders relying on popular crates must assume maintainer accounts are high-value targets.

How it could have been prevented

Treat unsolicited job or contract video-call requests with high suspicion. Host calls only on platforms you control or already trust, and never install codecs or run clipboard-pasted commands during such calls.

Enable multi-factor authentication on crates.io, GitHub, and related accounts; regularly review login history and active sessions. Prefer hardware security keys and monitor package publish events for unexpected activity.

What happened

The ShinyHunters extortion group claimed it compromised the Clop ransomware gang, defacing Clop's dark-web leak site with the message 'THIS SITE HAS BEEN PWN3D BY SHINYHUNTERS' and ASCII Pokémon artwork.

ShinyHunters stated it stole private keys, server data, authentication logs, and potentially IP addresses of Clop members. The group left a link to its own leak site and issued a ransom demand, telling reporters it intended to extort Clop.

The incident appears to continue a feud that began in 2025 over competing claims to Oracle E-Business Suite vulnerabilities, including the critical CVE-2025-61882 zero-day both groups used in extortion campaigns.

Who is affected

Primarily the Clop ransomware operators whose leak infrastructure and internal data were allegedly taken. Secondary effects could reach organizations previously victimized by Clop if operational details or keys surface.

No direct impact on legitimate enterprises is claimed beyond the ongoing criminal ecosystem disruption.

Why it matters

Gang-on-gang attacks highlight that ransomware crews operate as competitive, distrustful businesses rather than a unified front. Leaked member IPs, logs, or keys could aid law enforcement or rival actors.

For defenders, the episode underscores that criminal infrastructure is itself fragile and that intelligence from such leaks can sometimes accelerate disruption of extortion operations. It also shows how zero-day ownership disputes drive real-world conflict.

How it could have been prevented

Organizations should continue prioritizing patches for known Clop and ShinyHunters initial-access vectors, including Oracle E-Business Suite updates addressing CVE-2025-61882 and related flaws.

Monitor dark-web leak sites and threat-intel feeds for any newly dumped Clop operational data that might expose additional victim information or tooling. Maintain standard ransomware hygiene: immutable backups, least-privilege access, and rapid isolation playbooks.

What happened

French cybersecurity firm CrowdSec confirmed that source code from approximately 300 GitHub repositories (about 170 private) was stolen. The company attributes the breach to the May 2026 TanStack supply-chain attack in which TeamPCP published 84 malicious artifacts across 42 TanStack packages.

CrowdSec used a TanStack package at the time; the malware likely compromised an API key that granted read access to its private codebase. Stolen material included SaaS console code, AWS Cloud routines, connectors, and automations. No customer credentials or data were found to have leaked.

CrowdSec rotated tokens immediately after the original window and states the leaked code cannot replicate its network or operate out of context. Most private code has since evolved significantly.

Who is affected

CrowdSec itself is the primary victim. Downstream users of CrowdSec open-source components or its SaaS console face no direct credential exposure according to the company.

Any organization that consumed the malicious TanStack packages in May 2026 may have suffered similar key or repository theft.

Why it matters

Even security vendors are exposed to popular open-source supply-chain attacks. Theft of private SaaS and automation code creates long-term reverse-engineering and vulnerability-research risk, even if immediate exploitation is limited.

The four-month detection lag shows how short-lived malicious packages can leave persistent access. Builders must treat dependency compromise as a potential full repository read risk.

How it could have been prevented

Audit and pin dependencies; remove or replace any TanStack packages that were present during the May 2026 malicious window. Rotate all GitHub, cloud, and CI tokens that could have been exposed.

Enable secret scanning, branch protection, and least-privilege PATs. Continuously monitor for unexpected repository clones or API access patterns. Review private code for hard-coded secrets even if none were initially detected.

What happened

Unit 42 detailed how AWS automatically neutralizes publicly exposed IAM access keys by attaching the AWSCompromisedKeyQuarantine managed policy. The process is commonly triggered by GitHub secret scanning partnership notifications or other exposure reports.

When AWS learns of leaked access-key IDs and secrets, it applies the quarantine policy that severely restricts the key's permissions, then notifies the account owner. The managed policy has evolved over successive versions to counter new abuse patterns observed in cloud attacks.

Researchers also outlined CloudTrail monitoring strategies so security teams can detect quarantine events quickly and complete incident response.

Who is affected

AWS customers whose long-term IAM user access keys appear in public repositories, environment files, or other exposure channels. Any account relying on static access keys rather than temporary credentials or roles is in scope.

Organizations that have integrated GitHub secret scanning with AWS receive the fastest automated protection.

Why it matters

Misuse of exposed IAM access keys remains one of the most common initial access vectors into AWS environments. Automated quarantine buys critical time by limiting blast radius before an attacker can fully exploit the key.

Understanding the policy attachment and CloudTrail signals lets defenders confirm containment and rotate credentials without guessing. The evolution of the quarantine policy tracks real attacker techniques, making it a living control rather than a static blocklist.