Daily Cybersecurity News – September 20, 2026

What happened

Three researchers at Hacktron used Anthropic's Claude Opus 5 to chain two flaws and take over ChatGPT and Codex accounts of several OpenAI employees, then reach an internal OpenAI code repository.

The chain started with a bug in Discourse (the software powering OpenAI's public help forum). A specially crafted HEIC/HEIF image triggered a heap buffer over-read in libheif (CVE-2026-32882, CVSS 7.1), which the team combined with AI assistance into remote code execution on the forum server. From there they abused a weakness in OpenAI's shared "Sign in with OpenAI" SSO login system to hijack staff accounts without victim interaction.

This was authorized security research. The team reported the issues, demonstrated access with a harmless pull request in under 72 hours, and stopped. OpenAI fixed the login-side issue about 14 hours after the report and paid a $6,500 bounty on September 1 for the OpenAI-side finding.

Who is affected

OpenAI staff whose ChatGPT and Codex accounts were linked via the public forum SSO, plus any first- or third-party service using the same OpenAI sign-on. Discourse forum instances running vulnerable libheif (versions 1.21.2 and prior) that process HEIC/HEIF uploads.

In theory the same access could have extended to connected services such as GitHub, Slack, and email, though the researchers did not pursue that.

Why it matters

A public forum image-processing bug combined with shared SSO identity created a path from unauthenticated internet input straight to internal staff accounts and code repositories. Staff often connect high-value tools to AI coding agents, so a single identity compromise can cascade far beyond the original service.

The case also shows how AI coding models can accelerate complex exploit chaining that previously required deep manual effort, raising the bar for defenders who must assume sophisticated research-grade attacks become more common.

How it could have been prevented

Patch libheif to versions newer than 1.21.2 and apply Discourse advisories promptly. Treat SSO identity providers as high-value targets: enforce phishing-resistant MFA, review token lifetimes and audience restrictions, and limit which external services can issue or consume staff identity tokens.

Isolate public forum infrastructure from internal identity systems where possible, monitor for unusual SSO logins from forum contexts, and ensure bug-bounty scope and rapid response cover both first-party login flaws and third-party components.

What happened

Security researchers at Accomplish AI found two ways to escape OpenAI's Codex sandbox. The more serious technique, called Heapjack, lets an attacker achieve unsandboxed command execution on a developer's machine simply by having the victim open a malicious repository in Codex and ask a question about the code, with no approval prompt and nothing visible on screen.

Heapjack targets the node_repl component that Codex Desktop writes into the global ~/.codex/config.toml at install time. Both trusted and untrusted JavaScript contexts share one Node.js process and one memory heap. Untrusted code snapshots the heap with v8.getHeapSnapshot(), brute-forces the random UUID token that marks trusted requests, then writes forged requests onto the pipe used by the unsandboxed native parent process.

Both flaws were reported on August 12 and fixed by OpenAI within eight days.

Who is affected

Users of OpenAI Codex (CLI and Desktop app) who open untrusted or third-party repositories. The node_repl entry is written globally with no opt-in, so plain CLI users inherit the exposure as well.

Any developer machine running Codex in its locked-down sandbox mode was potentially reachable via a malicious repo.

Why it matters

Coding agents are designed to execute actions on behalf of developers. A sandbox escape turns a routine "open this repo and explain the code" interaction into full host command execution under the user's privileges. That can steal credentials, install persistence, or move laterally without any further user consent.

As AI coding tools become standard in developer workflows, the trust boundary around the sandbox is critical. Failures here give attackers a low-friction path onto engineering workstations that often hold source code, cloud keys, and production access.

How it could have been prevented

Update Codex CLI and Desktop to the versions OpenAI released after the August 12 report. Avoid opening untrusted repositories in Codex until the agent and its config are confirmed patched.

Review ~/.codex/config.toml for unexpected entries such as node_repl, run Codex under least-privilege accounts or isolated environments when possible, and monitor for unexpected outbound process launches or file writes originating from Codex-related Node processes.

What happened

A critical unauthenticated remote code execution vulnerability in Orkes Conductor, tracked as CVE-2026-58138 (CVSS 9.8), is being actively exploited in the wild according to Fortinet and other telemetry sources.

Vulnerable versions (3.21.21 before 3.30.2) allow remote attackers to submit inline workflow definitions containing malicious JavaScript or Python expressions to the workflow API endpoint before authentication. Unsandboxed GraalVM evaluators configured with HostAccess.ALL or allowAllAccess(true) can be abused via INLINE, LAMBDA, DO_WHILE, and SWITCH task types to invoke arbitrary OS commands through Java reflection or direct subprocess calls.

Fortinet blocked 1,290 attack attempts in a single 24-hour period (a 132% daily increase) and nearly 7,000 attempts between September 2 and 9, 2026. Additional honeypot and research detections confirm exploitation attempts dating back to at least July 2026.

Who is affected

Organizations running Orkes Conductor versions 3.21.21 up to but not including 3.30.2, especially instances with the workflow API exposed to untrusted networks and evaluators left in unrestricted host-access configurations.

Attack volume has been observed from multiple countries including Germany, Hong Kong, Indonesia, the U.A.E., and India.

Why it matters

Pre-authentication RCE on a workflow orchestration platform gives attackers full control of the Conductor process and whatever credentials, secrets, or downstream systems it can reach. Workflow engines often sit at the center of automation pipelines, so compromise can quickly become lateral movement or supply-chain impact.

Active mass scanning and exploitation mean exposed instances are at immediate risk; waiting for scheduled maintenance windows is not viable.

How it could have been prevented

Upgrade immediately to Orkes Conductor 3.30.2 or later. If patching cannot be done at once, restrict external access to the workflow API endpoints, place Conductor behind strong network access controls, and disable or tightly sandbox GraalVM evaluators (avoid HostAccess.ALL / allowAllAccess(true)).

Monitor for suspicious workflow definition submissions containing unexpected JavaScript or Python expressions and for anomalous command execution under the Conductor process identity.

What happened

CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog on or about September 18, 2026, citing evidence of active exploitation. Red Hat also updated its advisories to state the flaws are high risk with known public exploits.

The flaws are: CVE-2025-39682 (CVSS 9.8) - improper check for unusual conditions in the TLS receive path enabling local memory disclosure or denial of service; CVE-2026-53266 (CVSS 8.8) - out-of-bounds write in the ebtables SNAT ARP rewrite path that can lead to DoS or local privilege escalation; and CVE-2025-39964 (CVSS 7.8) - race condition allowing concurrent writes to the same AF_ALG socket, risking crashes or corruption of cryptographic results.

No public details yet describe the exact exploitation method or whether the three are chained together. Federal agencies face a BOD 26-04 remediation deadline of September 21, 2026.

Who is affected

Linux systems running kernels that include the vulnerable TLS, netfilter/bridge ebtables, or AF_ALG code paths. Local authenticated users or processes can trigger the issues.

Federal Civilian Executive Branch agencies are under explicit directive pressure; enterprise and cloud Linux fleets more broadly should treat the KEV listing as a prioritization signal.

Why it matters

Kernel vulnerabilities that enable local privilege escalation or memory disclosure are prime building blocks for attackers who already have a foothold (via phishing, malicious containers, or other user-level access). KEV inclusion means CISA has confirmed real-world exploitation, elevating these beyond theoretical risk.

Short federal deadlines and Red Hat's "high priority" language indicate defenders should not wait for the next routine patch cycle.

How it could have been prevented

Apply vendor kernel updates that address CVE-2025-39682, CVE-2026-53266, and CVE-2025-39964 as soon as they are available from your distribution. Prioritize systems that allow untrusted local code execution or multi-tenant workloads.

Where immediate reboot is difficult, use live-patching services if offered by your vendor, restrict local user privileges, and monitor for unusual TLS, netfilter, or AF_ALG activity. Federal agencies must meet the September 21, 2026 BOD deadline.

What happened

An attacker used a compromised GitHub account belonging to a recently departed CrowdSec employee to copy approximately 170 of the company's private repositories on May 22. The employee's laptop had been infected by malicious versions of TanStack npm packages published on May 11 (tracked as CVE-2026-45321, CVSS 9.6, confirmed exploited and used in ransomware campaigns).

The malicious packages stole credentials including GitHub tokens. CrowdSec had left the former employee's GitHub access open so he could finish work. The copied archive later appeared on an online forum on September 16 and contained source code plus email addresses of 83 users and details on 51 potential investors from 2020.

CrowdSec states the account was used only to copy code, infrastructure and databases were not accessed, and no code was modified. The same TanStack supply-chain attack also affected devices at Mistral AI and OpenAI.

Who is affected

CrowdSec (private repositories, user emails, and older investor data), plus any organizations whose developers installed the 84 malicious versions across 42 @tanstack/* packages. OpenAI and Mistral AI publicly noted employee devices were hit.

Developers who had TanStack packages in their dependency trees during the May 11 window and who stored long-lived GitHub tokens or other secrets on disk.

Why it matters

A popular open-source library supply-chain compromise turned into credential theft that survived employee offboarding because GitHub access was not promptly revoked. Private source code, internal algorithms (including blocklist consensus thresholds), and personal data of users and investors were exposed months later.

The incident illustrates how npm malware that harvests tokens can quietly enable later repository cloning with little noisy activity inside the victim's own cloud environment.

How it could have been prevented

Immediately revoke all access for departing employees, including GitHub organization membership and OAuth tokens, as part of a same-day offboarding checklist. Rotate any tokens or keys that may have resided on developer machines.

Pin and verify npm dependencies, use lockfiles and package-integrity checks, prefer short-lived credentials and hardware-backed GitHub authentication, scan developer endpoints after known supply-chain events, and monitor for unexpected repository clones or new deploy keys. Upgrade away from any TanStack versions published in the malicious window and treat CVE-2026-45321 as actively exploited.

What happened

Widely available AI chatbots and models are driving a sharp increase in the discovery and disclosure of software vulnerabilities, even as some AI labs discuss possible slowdowns on frontier development.

Microsoft issued patches for 974 CVEs in a single recent month, a new record. Oracle shipped 1,448 patches in July versus 309 the prior July. Chrome's two major June releases fixed 1,072 vulnerabilities, more than the previous 23 big releases combined. Mozilla found 271 Firefox flaws in one sprint using Anthropic's Mythos model. Overall CVE counts have roughly doubled year-over-year according to tracking by Empirical Security / cve.icu (over 66,000 recorded by mid-September versus about 33,500 at the same point the prior year).

Experts note that more known vulnerabilities are not automatically more risk if they are patched, but the volume is straining under-resourced security teams and open-source maintainers.

Who is affected

Software vendors, open-source maintainers, enterprise IT and security teams responsible for patching, and any organization running widely used products from Microsoft, Oracle, Google, Mozilla, and countless smaller projects.

Defenders who must triage, prioritize, and deploy fixes at a pace that is accelerating beyond historical norms.

Why it matters

AI-assisted vulnerability research lowers the skill and time required to find bugs, producing a firehose of CVEs. Organizations that already struggled with patch lag now face even larger backlogs, while attackers can also use the same tools to find exploitable issues faster.

The trend magnifies existing weaknesses in patch management, open-source funding, and vulnerability prioritization rather than creating an entirely new class of problem, but the speed of change is real and already measurable in vendor patch volumes.

What happened

The ShinyHunters extortion group breached the Clop (Cl0p) ransomware operation's Tor data-leak site, defaced it, and claims to have stolen server data including source code, Grav CMS plugins, system logs, and the private keys for Clop's onion service.

The intrusion began with what ShinyHunters described as an unauthenticated file-upload vulnerability in Grav CMS. They first uploaded a taunting text file, then fully replaced the site content with ASCII art of their Umbreon logo and a message. BleepingComputer confirmed both the uploaded file and the subsequent defacement were being served from Clop infrastructure.

ShinyHunters asserts that possession of the onion private keys means they can continue to control or impersonate the service even if Clop attempts to regain the original host.

Who is affected

The Clop ransomware group and any victims or affiliates who relied on the integrity of that specific leak site. Organizations monitoring ransomware leak sites for brand or data exposure may see disrupted or spoofed content.

No evidence in the reporting indicates the breach extended to Clop's broader ransomware encryption infrastructure or victim payment systems.

Why it matters

Ransomware leak sites are operational infrastructure. A rival group taking them over demonstrates that even criminal platforms can be fragile and that inter-gang conflict can produce unexpected intelligence (logs, keys, source) for defenders who collect it.

Possession of onion keys enables long-term impersonation or sinkholing risk, which can confuse victims, law enforcement tracking, and researchers who use these sites as signals.

How it could have been prevented

Organizations should not rely solely on criminal leak sites for accurate victim notification status. Maintain independent monitoring, verify claims through multiple channels, and treat any data appearing on such sites as potentially manipulated during gang conflicts.

For any public-facing CMS (including those used internally), ensure file-upload functionality requires authentication, validates content types, and stores uploads outside the web root. Apply Grav CMS updates promptly and isolate Tor-hosted services with least privilege.