Breach Watch, September 20, 2026: Three Linux Kernel Flaws Confirmed Exploited
CISO PLATFORM · BREACH INTELLIGENCE
BREACH WATCH
Daily Breach Intelligence for Security Leaders · September 20, 2026

TL;DR for CISOs: CISA added three Linux kernel flaws to its Known Exploited Vulnerabilities catalog on September 18 with a September 21 federal remediation date, Fortinet reported thousands of blocked attacks against an unauthenticated remote code execution flaw in the Orkes Conductor workflow platform, and CrowdSec disclosed that roughly 170 of its private code repositories were copied through a departed employee's GitHub account that had never been closed.

BOTTOM LINE FOR CISOS
  1. Local privilege escalation has moved up the queue. Three kernel bugs that only work for a user who is already on the box are now confirmed as exploited, which tells you attackers are landing first and escalating second. Your patch tiering probably scores these too low.
  2. Internal orchestration platforms are internet-facing more often than teams think. The Orkes Conductor flaw needs no credentials at all, and the traffic Fortinet is blocking is opportunistic scanning, not targeted work.
  3. Offboarding is a security control, not an HR task. CrowdSec lost source code because one leaver kept GitHub access for a few extra weeks. Ask your team today how many departed staff still hold tokens in your code hosting platform.

Lead story: three Linux kernel flaws confirmed as exploited, with a September 21 federal deadline

CRITICAL · ACTIVELY EXPLOITED
Key facts
CVEs: CVE-2025-39682 (CVSS 9.8, kernel TLS receive path), CVE-2026-53266 (CVSS 8.8, ebtables SNAT ARP rewrite path), CVE-2025-39964 (CVSS 7.8, AF_ALG socket race condition)
Product: Linux kernel
Added to KEV: September 18, 2026
Federal remediation date: September 21, 2026, under Binding Operational Directive 26-04
Vendor status: Red Hat updated its advisories for all three on September 19 to acknowledge active exploitation

What happened

CISA placed three Linux kernel vulnerabilities in the Known Exploited Vulnerabilities catalog across two separate alerts on Friday, September 18, citing evidence that attackers are using them. The most severe, CVE-2025-39682, sits in the kernel's TLS receive path and is scored 9.8. According to CISA's entry, it fails to handle an unexpected condition properly, which can let an authenticated local user read memory that should not be visible to them or crash the system.

The second, CVE-2026-53266, is an out-of-bounds write in the ebtables code that rewrites ARP addresses during source network address translation, scored 8.8. The third, CVE-2025-39964, is a race condition on AF_ALG sockets scored 7.8, where two writes to the same socket can collide and either crash the machine or corrupt the result of a cryptographic operation.

Neither CISA nor the reporting around it describes how the three are being used, or whether they are being combined into one chain. That matters for how you prioritize, and we will say plainly that the exploitation detail is not public. What is public is the vendor reaction: Red Hat revised its advisories for all three on September 19 and told customers to treat them as high priority, noting that public exploit code exists.

The timing sits alongside a separate disclosure. On September 18, researcher Asim Manizada published working exploit code for four other Linux kernel local privilege escalation flaws he reported in mid-July, named DirtyAH6 (CVE-2026-80844), TUNderflow (CVE-2026-81000), PPPoEject (CVE-2026-68121), and DiagSpill (CVE-2026-74469). All four are fixed in current kernels, and there are no reports of them being used in attacks. The two events are not connected, but together they mean the supply of usable local-root code against Linux has grown noticeably in one week.

Evidence

Source 1: The Hacker News, "CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild," September 19, 2026
Source 2: Security Affairs, "U.S. CISA adds Linux Kernel flaws to its Known Exploited Vulnerabilities catalog," September 20, 2026
Primary reference: CISA Known Exploited Vulnerabilities Catalog

What this means for your team

Most vulnerability programs push local privilege escalation to the back of the queue because exploitation requires a foothold. That logic held when footholds were expensive. It holds less well now, when initial access is routinely bought, and when the same week produces public exploit code for four more kernel escalation bugs. A confirmed-exploited local escalation flaw is best read as the second half of an attack chain whose first half is already commoditized.

There is a second, quieter exposure. The AF_ALG race condition can corrupt cryptographic results rather than simply crash a process. If you run signing, tokenization, or key derivation on Linux hosts, a silent integrity failure is harder to detect than an outage and harder to explain afterwards. Ask whether your crypto operations would surface a wrong answer or simply return it.

The federal date of September 21 is a useful external anchor when you need to move a maintenance window. You are not bound by it, but it is a defensible number to put in front of an application owner who wants to wait for the next quarterly cycle.

Action checklist
  1. Pull your distribution's advisories for CVE-2025-39682, CVE-2026-53266 and CVE-2025-39964 and identify which of your kernel builds are behind. Container base images and appliance operating systems are the usual blind spots.
  2. Reclassify confirmed-exploited local privilege escalation to your highest patch tier for multi-tenant hosts, developer workstations, CI runners, and anything that accepts untrusted workloads.
  3. Where a reboot cannot happen this week, compensate: restrict who holds interactive shell access on the affected hosts, and alert on unexpected kernel module loads and setuid execution.
  4. Review any cryptographic operation that runs through the kernel crypto API on unpatched hosts, and confirm you would detect a wrong result rather than only a crash.

Orkes Conductor: unauthenticated code execution under opportunistic attack

CRITICAL · ACTIVELY EXPLOITED
Key facts
CVE: CVE-2026-58138 (CVSS v3.1 9.8, CVSS v4 9.3)
Product: Orkes Conductor workflow orchestration platform
Fix: Conductor 3.30.2 or later, released in June 2026
Observed activity: Fortinet reported 1,290 attempts blocked in 24 hours as of September 9, and close to 7,000 between September 2 and 9; Empirical Security recorded in-the-wild exploitation as early as August 21

What happened

Fortinet issued an outbreak alert this week for a flaw that lets anyone who can reach a Conductor server run operating system commands on it without logging in first. Conductor accepts workflow definitions through an API endpoint, and per the NVD description the affected builds evaluate inline JavaScript or Python expressions inside those definitions before authentication is applied. Where the GraalVM evaluator was configured with unrestricted host access, an attacker escapes the scripting sandbox and executes commands with the privileges of the Conductor process.

Fortinet said it observed attackers submitting crafted workflow definitions to the Conductor workflow API. The figures it published show the campaign accelerating: 1,290 attempts blocked in a single day around September 9, which it described as a 132 percent increase in daily activity, and nearly 7,000 across the preceding week. It attributed most of the traffic to sources in Germany, Hong Kong, Indonesia, the United Arab Emirates and India. SecurityWeek, reporting independently on September 18, noted that proof-of-concept code appeared in early August and that exploitation followed shortly after.

Evidence

Source 1: The Hacker News, "Critical Pre-Auth RCE in Orkes Conductor Workflow Platform Exploited in the Wild," September 19, 2026
Source 2: SecurityWeek, "Critical Orkes Conductor Vulnerability Exploited in Attacks," September 18, 2026

What this means for your team

The interesting number here is not the CVSS score. It is the three-month gap between a fix shipping in June and attack volume climbing in September. That gap is the shape of most workflow and orchestration deployments: installed by a platform or data engineering team, pinned to a version that works, and not carried on any patch calendar the security function owns.

The second point is placement. Conductor is internal software by intent, so it rarely gets the hardening review an external application would. Opportunistic scanning does not respect intent. If an instance answers on a routable address, it is an external application whatever the architecture diagram says.

Finally, consider what a Conductor host can reach. Orchestration platforms hold the credentials needed to drive other systems, so command execution there is rarely contained to that one box.

Action checklist
  1. Ask your platform and data engineering teams directly whether Conductor is running anywhere, including in development and in third-party managed environments. Do not rely on the asset inventory alone.
  2. Upgrade to 3.30.2 or later. If that cannot happen immediately, block external access to the workflow API endpoints and place the instance behind network access controls.
  3. Hunt backwards to at least August 21: look for unexpected process execution by the Conductor service account and for workflow definitions containing inline script expressions that nobody on your team authored.
  4. If you find evidence of execution, rotate every credential the Conductor instance holds before you close the incident.

CrowdSec: 170 private repositories copied through a leaver's account

HIGH · CONFIRMED BY THE AFFECTED COMPANY
Key facts
Organization: CrowdSec, French open-source security company, approximately 150,000 users
What was taken: About 170 private GitHub repositories, cloned on May 22, 2026
Personal data involved: Email addresses of 83 users, plus names, email addresses and investment context for 51 potential investors from 2020
Root cause per the company: A GitHub OAuth token from a former employee whose organization access had been left open; his machine was compromised in the May TanStack npm supply chain attack (CVE-2026-45321)
Disclosure: Leak posted to a forum September 16; first CrowdSec statement September 17; fuller report September 18

What happened

On May 11, 84 malicious versions of 42 TanStack npm packages were published. Installing one of them ran code that harvested credentials from the developer's machine, including GitHub tokens, SSH keys and cloud credentials. Eleven days later, on May 22, someone used a GitHub OAuth token belonging to a CrowdSec employee who had already left to clone roughly 170 of the company's private repositories. CrowdSec had kept his organization access open so he could finish outstanding work, and removed the account on May 25.

The company learned of the leak only when the archive was posted to a forum on September 16. Alongside source code for its web console, data science scripts and models, automation scripts, and the consensus algorithm behind its IP blocklists, the archive held the email addresses of 83 users and details on 51 potential investors from a 2020 system. CrowdSec says the account was used only to copy code, that no commits or changes were made, and that its infrastructure and databases were not reached.

The company's account changed between its two statements, and that is worth noting rather than glossing over. Its September 17 statement said no client data, credentials, names or organizations had leaked, and pointed to a backdoored component inside CrowdSec as the likely path. The September 18 report withdrew both points: no malicious TanStack versions were found in CrowdSec's own code, the route was the former employee's account, and user and investor details were in fact exposed. CEO Philippe Humeau apologized to the investors in the report. The same npm compromise also touched other firms, with Mistral AI citing a developer device and OpenAI citing two employee devices and unauthorized access to a limited set of internal repositories.

Evidence

Source 1: CrowdSec, "TanStack Supply Chain Attack Analysis," September 18, 2026
Source 2: The Hacker News, "CrowdSec Says TanStack npm Attack Led to Copy of 170 Private GitHub Repositories," September 19, 2026

What this means for your team

This is a clean, uncomfortable case study in how a supply chain compromise converts into a data loss months later, through a control nobody thinks of as security. The npm packages were the weapon. The open door was an offboarding exception granted for a sensible operational reason and then left in place. Almost every organization grants that exception.

The detection failure is the part worth taking to your own team. CrowdSec says the token left no usable trace in the GitHub logs it could examine and no longer existed by the time it learned of the leak. Mass cloning of private repositories by a single identity is a detection most organizations assume they have and few have actually tested. It is also, unusually, a detection you can go and validate this week.

One more detail deserves attention on its own terms: the company has stated it did not require endpoint protection on developer machines at the time and has since deployed it. Developer endpoints hold the keys to everything downstream, and they are frequently the least monitored devices in the estate because the people using them ask for the exception.

Action checklist
  1. Run a report today of every account in your code hosting organization that belongs to someone who has left, and every personal access token or OAuth grant older than your offboarding window.
  2. Put a hard expiry on post-departure access. If a leaver genuinely needs a few more days, make it a dated exception with an owner, not an open-ended one.
  3. Build and test a detection for bulk cloning of private repositories by a single identity, and confirm your code hosting audit logs retain long enough to investigate a four-month-old event.
  4. Confirm that endpoint protection is actually enforced on developer laptops, and treat any exception there as a risk decision that a named person signs.

SolarWinds patches a hard-coded key in Access Rights Manager

NOTABLE · NO KNOWN EXPLOITATION
Key facts
CVE: CVE-2026-28326 (CVSS 8.8, vector AV:A, adjacent network)
Product: SolarWinds Access Rights Manager, version 2026.2 and all earlier versions
Cause: A hard-coded static cryptographic key permitting unauthenticated remote code execution
Fix: ARM 2026.2.1; advisory published September 17, 2026
Status: No evidence of exploitation reported; not in the KEV catalog
Credit: Kai Huang of Armadin

What happened

SolarWinds published an advisory on September 17 for a flaw in Access Rights Manager, the product many organizations use to review and certify who has access to what across file shares and directory services. The issue is a hard-coded static key, and exploiting it can give an unauthenticated attacker code execution. The CVSS vector matters for prioritization: the score of 8.8 is calculated with an adjacent network attack vector, meaning the attacker needs to already be on the same network segment rather than reaching the server from the internet. SolarWinds reports no exploitation. The same release cycle also addressed 16 flaws in Serv-U, and earlier fixes covered a SAML authentication bypass in Web Help Desk.

Evidence

Source 1: The Hacker News, "SolarWinds Patches ARM Hard-Coded Key Flaw Enabling Unauthenticated RCE," September 19, 2026
Source 2: CVE record for CVE-2026-28326, including the SolarWinds CNA entry and CVSS vector

What this means for your team

A hard-coded key is a design defect rather than a coding slip, which means the same key is in every deployment and cannot be rotated by the customer. Once the value is known, every unpatched instance is equally exposed. That is the reason to move on this despite the adjacent-network vector and the absence of exploitation: the barrier to entry drops to zero the moment someone extracts the key from a binary.

The product context sharpens it. Access Rights Manager is an identity governance tool, so it holds broad read access across file systems and directories by design. Code execution on a governance platform is a fast route to understanding, and then abusing, the permission structure of the whole estate.

Action checklist
  1. Upgrade Access Rights Manager to 2026.2.1. Treat it as a privileged management system, not a reporting tool.
  2. Confirm the ARM server sits on a management network segment that ordinary user workstations cannot reach, which directly addresses the adjacent-network vector.
  3. Review the SolarWinds release for the Serv-U fixes at the same time, since those cover privilege escalation and administrator account creation.

Also notable

  • A supply chain attack on the email platform Brevo used compromised Cloudflare access to inject malicious code into customer websites, with more than 100,000 sites potentially affected. Security Affairs, September 18
  • Japanese software company Helpfeel is notifying users of its Gyazo screenshot service after a flaw in an image upload server exposed 23 million user records. Security Affairs, September 18
  • Working exploit code is now public for four separate Linux kernel local privilege escalation flaws, all fixed upstream, with no reports yet of real-world use. The Hacker News, September 18
  • A flaw called Click2Shell in WordPress core lets a crafted link opened by a logged-in administrator install a theme with no click, and can chain to code execution through a second flaw in that theme. Fixed in WordPress 7.1.1. The Hacker News, September 18
  • A flaw named Plugin4Shell lets the owner of a plugin repository swap code that four AI coding agents had pinned to a reviewed commit hash. Anthropic and OpenAI have patched; GitHub Copilot has no fix and Google will not patch the Gemini CLI. The Hacker News, September 18
  • Microsoft patched a maximum-severity privilege escalation flaw in Azure AI Foundry, CVE-2026-85889, scored 10.0. No customer action is required and there is no evidence of exploitation. The Hacker News, September 18

FAQ

Which Linux kernel CVEs did CISA add on September 18, 2026?

CISA added CVE-2025-39682 (CVSS 9.8, kernel TLS receive path), CVE-2026-53266 (CVSS 8.8, ebtables SNAT ARP rewrite path) and CVE-2025-39964 (CVSS 7.8, AF_ALG socket race condition). All three were listed on evidence of active exploitation, with a federal remediation date of September 21, 2026.

Do the Linux kernel flaws allow remote attacks?

No. All three require a local attacker who already has access to the machine. That is why they matter as the escalation stage of an attack chain rather than as an initial entry point, and why teams that deprioritize local privilege escalation should revisit that rule.

Is CVE-2026-58138 in Orkes Conductor being exploited?

Yes. Fortinet issued an outbreak alert and reported blocking 1,290 attempts in a single 24-hour period around September 9 and close to 7,000 between September 2 and 9. Empirical Security recorded in-the-wild exploitation as early as August 21. The fix, version 3.30.2, shipped in June 2026.

What was actually exposed in the CrowdSec incident?

Roughly 170 private GitHub repositories, including the company's web console, data science scripts and models, automation scripts, and its blocklist consensus algorithm, plus the email addresses of 83 users and details on 51 potential investors from 2020. CrowdSec states that its infrastructure and databases were not accessed and that no code was altered.

How did a former employee's account lead to the CrowdSec leak?

The employee had left, but his GitHub organization access was kept open so he could finish outstanding work. His laptop was compromised in the TanStack npm supply chain attack in May, which harvested his GitHub token. An attacker used that token on May 22 to clone the repositories. The account was removed on May 25.

Does the SolarWinds ARM flaw need immediate patching?

There is no reported exploitation and the attack vector is adjacent network rather than internet-facing, so this is not an emergency. It should still be scheduled promptly, because a hard-coded key is identical across every deployment and cannot be rotated by the customer once it becomes public.

What is the single highest-value action from this edition?

Run a report of every account and token in your code hosting platform that belongs to someone who has left. It takes one query, it is the exact failure that cost CrowdSec its source code, and it is almost certainly not clean in your environment either.

Related reading from the community

CISO Platform Breach Intelligence Team
Curated by Pritha Aash, Community Head, CISO Platform
Breach Watch is a daily briefing for senior security leaders. Every item is verified against at least two independent sources before publication, and threat-actor claims are labeled as claims.
Keep the briefing coming

Breach Watch is produced for the CISO Platform community, a vendor-agnostic peer network for senior security leaders. Joining is free.

Join the CISO Platform community (free)

Subscribe to the weekly newsletter · Visit the Breach Intelligence hub

Corrections and takedown requests: CISO Platform is committed to accuracy and fairness. If any detail in this briefing is inaccurate, or if you represent an affected organization and would like a correction or removal, please contact us at pritha.aash@cisoplatform.com and we will review your request promptly.

Votes: 0
E-mail me when people leave their comments –

You need to be a member of CISO Platform to add comments!

Join CISO Platform

Join The Community Discussion