IT and AI security incidents, checked against the primary source

Tag: KEV

Chrome’s exploited V8 zero-day draws a September 18 federal deadline, and CISA filed it under Chromium
CISA added an actively exploited Chrome V8 type confusion bug to the Known Exploited Vulnerabilities catalog on September 4, 2026, with a federal remediation deadline of September 18 — and filed it under Chromium, which is a much larger surface than the browser.

What happened

Google shipped Chrome 152.0.7977.82/.83 for Windows and Mac, and 152.0.7977.82 for Linux, on Thursday, September 3, 2026. The release notes carry twelve security fixes and one sentence that changes how the rest of them read: “Google is aware that an exploit for CVE-2026-85046 exists in the wild.”

CVE-2026-85046 is a type confusion bug in V8, Chrome’s JavaScript and WebAssembly engine. NVD published the record at 8:17 p.m. UTC on September 3 and last modified it at 7:03 p.m. UTC on September 4. It carries CWE-843 and a CVSS v3.1 base score of 8.8, High, on the vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, scored by Google as the CNA. The description, in Google’s own words, is narrower than the headline number suggests: “Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.”

On September 4, CISA added it to the Known Exploited Vulnerabilities catalog. Read from NVD’s republication of CISA’s own fields rather than from any press report, the record states cisaExploitAdd of 2026-09-04 and cisaActionDue of 2026-09-18 — a fourteen-day federal clock, expiring Friday, September 18, 2026. The cisaVulnerabilityName is “Google Chromium V8 Type Confusion Vulnerability.”

The cisaRequiredAction string is the standard BOD 26-04 boilerplate, including its citation of “Forensics Triage Requirements.” That clause appears on fourteen-day entries as well as three-day ones and carries no per-entry information; this publication established that in August after briefly getting it wrong. It is not evidence of a band here, and it is not read as such.

The bug did not come from Google’s own threat hunters. The release note line reads, verbatim: “[$1,000][542403045] High CVE-2026-85046: Type confusion in V8. Reported by Salvatore Gulizia (nickname: Serotav) on 2026-08-04.” An outside researcher reported it through the Vulnerability Reward Program on August 4, 2026, and was paid $1,000. Google shipped the fix thirty days later. CISA listed it one day after that.

The Chromium bug tracker entry, issue 542403045, is marked Permissions Required. Google’s standing note applies: “Access to bug details and links may be kept restricted until a majority of users are updated with a fix.” Nobody outside Google can currently read the technical detail or the exploitation evidence.

Why it matters

Three things in this record do not line up, and each of them changes what an operator should do this week.

CISA named Chromium, not Chrome. The catalog entry is “Google Chromium V8 Type Confusion Vulnerability.” Google’s CVE description names Chrome and a Chrome version. Those are different scopes, and the catalog’s is the wider one. V8 is not a Chrome component that happens to be shared; it is the engine underneath Microsoft Edge, Brave, Opera, and Vivaldi, and underneath every application built on Electron or the Chromium Embedded Framework — chat clients, ticketing tools, code editors, vendor consoles, and the internal desktop app somebody wrapped around a web page years ago and has not touched since.

Chrome itself is close to a non-problem: it updates on relaunch, and most fleets will be current within days without anyone doing anything. Everything else in that list is a problem, because an Electron application ships its own copy of Chromium and updates on its vendor’s schedule, not Google’s. A federal remediation deadline attaches to the affected asset, not to the convenient one. An agency that reads “Chrome” and pushes a browser update has done the easy tenth of the work.

Google’s own fix is still rolling out. The release note says the new version “will roll out over the coming days/weeks.” That is Google’s normal staged-delivery language, and normally it is unremarkable. Against a fixed September 18 date it is not. Staged rollout means some machines will receive the update on Google’s timetable, which may land after the deadline. Waiting for automatic delivery is not a remediation plan here; forcing the update is. The distinction matters most for exactly the endpoints least likely to be checked — laptops that have not relaunched a browser in a fortnight.

The bug is described as staying inside the sandbox. Google’s description says the attacker executes arbitrary code “inside the sandbox.” A renderer-process compromise reaches everything the tab can reach, but on its own it does not reach the host. Getting there requires a second bug, a sandbox escape, that this record does not describe and Google has not disclosed. Coverage that flattens this to “remote code execution” is not wrong about the CVSS, which is 8.8 precisely because the scope is unchanged, but it is misleading about what an attacker gets. It does not lower the deadline, and it should not change anyone’s patching decision. It should change what a responder looks for.

Then there is the $1,000. Chrome’s reward amounts are set at triage and broadly reflect how exploitable the program judged a report to be. This one was assessed at the low end of the scale — the same release lists other high-severity bugs at “TBD” and Google-internal finds at “N/A” — and it is the one Google now says has an exploit in the wild. That is not a criticism of the triage; a reward tier is a judgment made in August about a bug report, not a prediction about attacker behavior in September. It is a caution about using severity proxies as a queue. The bounty figure, the CVSS score, and real-world exploitation are three different measurements, and here they disagree.

What the record does not say is whether the in-the-wild exploit is related to Gulizia’s report at all. Google’s wording — “is aware that an exploit…exists” — is the phrasing it uses whether the exploitation was found first or the bug was. The bug tracker is restricted, so the sequence is not publicly checkable. This is worth stating as unresolved rather than assuming the usual pattern, in which Google’s Threat Analysis Group finds an attack and works backward to the bug. As far as the public record shows, that is not what happened here.

One more detail from the same release is worth a line for anyone tracking how these bugs are being found. CVE-2026-85045, a separate race condition in V8 fixed in the same build, is credited to Brendan Dolan-Gavitt of XBOW, a company doing automated, model-driven vulnerability discovery. Two V8 bugs in one release, one from a human bounty hunter and one from an AI-assisted program, is a reasonable snapshot of where browser bug-finding currently sits.

What to do

Update to 152.0.7977.82 or later on Linux, and 152.0.7977.82/.83 or later on Windows and Mac. Check at chrome://settings/help, which also triggers the update. Do not wait for the staged rollout; push it.
- Force the relaunch. Downloading the update is not applying it. Chrome finishes the job on restart, and a browser left open for weeks is still vulnerable with the new binary sitting on disk. Enterprise fleets can use the RelaunchNotification and RelaunchNotificationPeriod policies to make the restart mandatory rather than a dismissible bubble.
- Check the other Chromium browsers. Edge, Brave, Opera, and Vivaldi each rebase on Chromium on their own cadence. Confirm the build in use is based on Chromium 152.0.7977.82 or later rather than assuming a recent-looking version number covers it.
- Inventory Electron and CEF applications. This is the part that will not be done by September 18 unless it starts now. Enumerate desktop applications that embed a browser engine, get the Chromium version each one bundles, and open tickets with the vendors that are behind. Internally built Electron apps need their own rebuild.
- Federal civilian agencies are on the clock to September 18, 2026, under BOD 26-04. Private-sector adoption is voluntary; CISA encourages it.
- For detection, the useful artifacts are renderer-process crashes and anomalous child processes from browser and Electron parents in the window before patching. Because the exploit is described as sandbox-contained, evidence of a successful follow-on escape is a separate hunt from evidence of the initial trigger.
Sourcing note

The KEV dates in this story come from NVD’s republication of CISA’s own fields at services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-85046, not from any press report: cisaExploitAdd 2026-09-04, cisaActionDue 2026-09-18, cisaVulnerabilityName “Google Chromium V8 Type Confusion Vulnerability.” The NVD record was published September 3, 2026 at 8:17 p.m. UTC and last modified September 4 at 7:03 p.m. UTC, with a status of Analyzed. CISA’s own catalog page and alert were not readable: cisa.gov returns HTTP 403 to automated fetching, and the two public KEV mirrors checked were both stale — the GitHub-hosted catalog copy still reported catalog version 2026.08.27, and a third-party KEV API returned nothing newer than the September 2 batch. The addition is confirmed here through NVD only.

The version numbers, CVE list, reward amount, reporter credit, report date, rollout language, and the exploitation sentence are quoted from Google’s Chrome Releases post of Thursday, September 3, 2026. Chromium issue 542403045 is marked Permissions Required and could not be read. Whether the in-the-wild exploit is connected to the August 4 bounty report is not stated by Google and remains unresolved. No independent confirmation of exploitation was found beyond Google’s own sentence, and no attribution is asserted. The claim that this bug is limited to the renderer sandbox is Google’s characterization in the CVE description, not an independent assessment.

Sources: Chrome Releases, September 3, 2026; NVD, CVE-2026-85046.
September 4, 2026
LiteLLM’s MCP endpoint answered a failed key check with an empty auth object, and CISA put it on a September 16 clock

When LiteLLM’s key validation failed on its MCP endpoint, the code substituted an empty authorization object and let the request through — CISA added it to the KEV catalog on September 2 with a September 16 deadline.

What happened

CISA added CVE-2026-59822 in LiteLLM to the Known Exploited Vulnerabilities catalog on September 2, 2026. NVD’s record carries the fields verbatim: cisaExploitAdd of 2026-09-02, cisaActionDue of 2026-09-16, and the catalog name “BerriAI LiteLLM Improper Authentication Vulnerability.”

LiteLLM is an AI gateway — a proxy that presents many model providers behind one OpenAI-compatible API, handles keys and budgets, and, increasingly, brokers Model Context Protocol tool calls on behalf of the applications in front of it. The flaw is in that last part. NVD’s description: “Prior to 1.84.0, LiteLLM’s MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization header to trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object, allowing requests to reach MCP tooling without a valid LiteLLM key.”

The project’s advisory, GHSA-7488-6r32-c95q, published June 30, 2026 and titled “MCP Authentication Bypass via OAuth2 Passthrough Fallback,” describes what that reaches: an attacker could “list and call configured MCP tools and access connected services exposed through MCP” with no valid credential. Affected versions are everything below 1.84.0. The fix is 1.84.0. The advisory credits a reporter it names as yaaras, and gives a workaround for anyone who cannot upgrade: disable the MCP routes, or block /mcp/ and related MCP resources at the reverse proxy or API gateway.

Two scores sit on the record and neither is a dispute. GitHub’s advisory database supplies CVSS 4.0 at 8.8 High; [email protected] supplies CVSS 3.1 at 8.2 High on CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N. The CWE assignments are CWE-287 for improper authentication and CWE-306 for missing authentication for a critical function.

The exploitation evidence traces to one place. NVD’s reference list includes Wiz’s writeup of an AI infrastructure honeypot, and that writeup states that Wiz “observed exploitation of this vulnerability in our honeypots, with requests using single-character tokens to probe model enumeration endpoints.” The captured request is a single line: GET /v1/models HTTP/1.1 with Authorization: Bearer x.

Why it matters

Look closely at what the code did, because the shape of it is the story. This is not a missing authentication check. LiteLLM validated the key. The validation failed. And on that failure path, the OAuth2 passthrough fallback substituted an empty UserAPIKeyAuth() object — a successfully-constructed authorization result carrying no identity — and execution continued as though a caller had been identified.

This publication covered the identical shape yesterday in F5’s njs, where js_access control failed open when the JavaScript raised an exception. The lesson repeats because the mistake is structural: the error path of an authorization control is itself an authorization decision, and it is the path nobody writes a test for. A missing check gets caught in review, because the absence is visible. A check whose failure branch returns an empty success object looks, in a diff, like careful defensive coding.

The word “fallback” is doing the damage here. A fallback is what you write when the primary path might legitimately not apply — and OAuth2 passthrough is exactly such a case, since the point of it is that some upstream MCP servers do their own authorization. But “this request might be authorized by someone else” and “this request failed my authorization” are different conditions, and the code treated them as one.

Then there is what sits behind the endpoint. The instinct on reading “AI gateway breach” is to think about model access — someone burning your inference budget, or reading prompts. The MCP surface is a different thing. MCP tools are the gateway’s connections to real systems: databases, ticketing, source control, internal HTTP services, filesystems. Listing them tells an attacker what an organization has wired into its agents. Calling them is action taken against those systems, with whatever credentials the gateway holds for them, and the calls arrive from the gateway’s own network position and appear in downstream logs as the gateway. There is no user identity in any of it, because the authorization object was empty.

That is also why the CVSS 3.1 vector deserves a second look. It reads C:H/I:L/A:N — high confidentiality impact, low integrity impact, no availability impact. For an endpoint whose defining capability is calling tools that change state in other systems, low integrity is a defensible reading of the gateway itself and an understatement of the deployment. It is the same component-versus-deployment gap that showed up on the Starlette entry CISA added the same day.

The exploitation evidence needs to be stated at its real size, which is small. It is one vendor’s honeypot data, gathered over 90 days across AI and ML services. Wiz published no count of attempts, no dates within that window, no geography, and no figure for how many honeypots were hit. What it published is a pattern, and the pattern is informative even without a number: Authorization: Bearer x is a one-character token. Nobody sends that hoping it is the right key. It is a probe that asks whether any token gets through — the precise test for a fail-open bug, run indiscriminately. That is scanning behavior, and scanning behavior is what CISA’s exploitation determinations are usually built on.

One more thing for anyone running LiteLLM. It is on the list of downstream projects affected by BadHost, the Starlette Host header flaw that CISA added to the catalog the same day, on the same September 16 deadline. A LiteLLM operator therefore has two KEV entries due at once: one in the application and one in the web framework underneath it, both of them authentication bypasses, both reached over the same listening port.

The fix shipped June 30, 2026. The catalog listing came September 2 — 64 days. As with Kestra earlier in the same batch, the vendor did its part on time and the exposure being put on a clock is patch lag on self-hosted infrastructure that most organizations stood up quickly and have not yet folded into a normal patch cycle.

What to do

Get the running LiteLLM version. Anything below 1.84.0 is affected; 1.84.0 or later is fixed. Container deployments pinned to latest at build time are not evidence of anything — check the image that is actually running.

If an upgrade cannot happen inside the window, apply the project’s own workaround: disable MCP routes, or block /mcp/ and the related MCP resources at the reverse proxy. That closes the path without touching the gateway’s model-serving function.

Assume the endpoint was probed. Search access logs for requests to /mcp/ and to /v1/models carrying implausible bearer tokens — single characters, obvious test strings, repeated identical values from many addresses. Then check the tool side: MCP tool invocations that do not correlate to a known LiteLLM key or user, and activity in the connected systems arriving from the gateway’s address outside normal application hours. Because the bypass produced an empty authorization object rather than a borrowed one, an unauthenticated call will have no key attribution at all, which makes it findable if your logging records the key.

If you find calls you cannot account for, rotate the credentials the MCP servers hold for downstream systems, not just the LiteLLM keys. The LiteLLM key was never the thing that was used.

Federal agencies have until September 16, 2026. The required action carries CISA’s forensic triage clause and the discontinue-use provision where mitigations are unavailable, so the asset assessment is part of the obligation rather than a follow-up.

Sourcing note

KEV dates, the catalog vulnerability name, the required action text, the description, both CVSS entries with their assigners, and the CWE assignments come from NVD’s API record for CVE-2026-59822, which republishes CISA’s fields verbatim. The advisory title, affected and fixed versions, the description of what MCP access reaches, the workaround, and the reporter credit come from LiteLLM’s own GitHub Security Advisory GHSA-7488-6r32-c95q, published June 30, 2026.

The exploitation observation is single-vendor: Wiz’s AI infrastructure honeypot writeup, referenced from the CVE record. It reports a 90-day observation window and gives the probe pattern, but publishes no count of attempts, no dates within the window, no geographic breakdown, and no number of honeypots involved. We asked for those figures and they are not in the source. Nothing here should be read as a measure of how widely the flaw has been exploited.

CISA’s alert page and KEV catalog feed both return HTTP 403 to automated requests, so the catalog was reached through NVD — NIST republishing CISA, a government primary source, but one that lags the catalog and is not the catalog itself. Unresolved: whether the exploitation CISA relied on is the same activity Wiz observed or separate reporting, and whether any successful MCP tool calls, as opposed to enumeration probes, have been documented against a live deployment.

September 3, 2026
Starlette’s BadHost is KEV-listed at CVSS 6.5, and CISA filed the FastAPI dependency under a bug class it is not

Three independent scorers rate CVE-2026-48710 a 6.5 medium, CISA’s catalog calls it request smuggling, and the researchers who found it call it an authentication bypass — it is now on a federal clock either way.

What happened

CISA added CVE-2026-48710 to the Known Exploited Vulnerabilities catalog on September 2, 2026. NVD’s record carries the fields verbatim: cisaExploitAdd of 2026-09-02, cisaActionDue of 2026-09-16. That is the 14-day band, not the three-day one.

The catalog names it “Kludex Starlette HTTP Request/Response Smuggling Vulnerability.” The flaw is in Starlette, the lightweight ASGI framework that FastAPI is built on. NVD’s description: “Prior to version 1.0.1, the HTTP Host request header was not validated before being used to reconstruct request.url. Because the routing algorithm relies on the raw HTTP path while request.url is rebuilt from the Host header, a malformed header could make request.url.path differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on request.url (rather than the raw scope path) could therefore be bypassed.”

The researchers call it BadHost. X41 D-Sec found it in January 2026 during a source-code audit of vLLM that OSTIF managed and the Alpha-Omega Project sponsored; the downstream notification work was sponsored in part by Amazon Web Services. X41’s advisory X41-2026-002 gives the timeline: identified January 27, 2026; proof of concept built and vendor notified February 4; patch released May 21; advisory published May 22.

The mechanism, in X41’s words, is that Starlette builds a URL as "{scheme}://{host_header}{path}" without rejecting characters the Host header is not allowed to contain. Send Host: example.com/abc?bar= against a request for /foo, and the reconstructed URL parses as path /abc with the real path swallowed into the query string. Routing still dispatches to /foo, because routing uses the raw scope path. Any middleware that made its decision from request.url.path made it about a different request than the one that ran.

Affected versions are 0.8.3 through 1.0.0. Version 1.0.1 validates the Host header against the grammar of RFC 9112 §3.2 and RFC 3986 §3.2.2 and falls back to scope["server"] for malformed values.

Why it matters

Start with the score, because it is the part that will cause the most trouble. Three separate entries on the NVD record — GitHub’s advisory database as Secondary, [email protected] as Primary, and a third secondary source — all land on 6.5 medium, on the identical vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. Low confidentiality impact, low integrity impact, no availability impact, unchanged scope. X41, the only party that had built a working proof of concept, rated it High at 7.0.

The scorers are not wrong about Starlette. A Host header parsing inconsistency, considered as a property of a framework, really does have low direct impact; the framework itself does not lose anything. The impact belongs entirely to whatever the application built on top of it decided to protect with that value. CVSS scores the component. Exploitation happens to the deployment. This CVE is a clean demonstration that those are different questions, and that a 6.5 is not a statement that nobody is being attacked through it.

Any organization whose vulnerability program suppresses medium-severity findings in transitive Python dependencies has been correctly following its own policy and is now on a federal deadline anyway.

Then there is the classification. CISA’s catalog title says HTTP request/response smuggling, which follows the record’s CWE-444. The record also carries CWE-1289, improper validation of unsafe equivalence in input, which is much closer to what happened. X41’s own advisory classifies it as CWE-436, interpretation conflict. Three classifications, three genuinely different mental models: a smuggling bug is about a proxy and an origin disagreeing on where a request ends; an interpretation conflict is about two parsers reading the same bytes differently; an equivalence bug is about a check treating unequal things as equal. The last two describe this. The first is the one that will appear in most dashboards.

This matters for the same reason it mattered on the Kestra entry CISA added the same day: the catalog is increasingly an input to automated triage rather than a page a human reads. An engineer told to check for request smuggling looks at load balancers, reverse proxies, and CDN configuration. Nothing in that search finds a Python web framework three levels down a requirements file.

Which raises the harder problem. Starlette is not a product. It is not in anyone’s asset inventory, it has no license entry, and almost nobody installed it deliberately — it arrives as a dependency of FastAPI, and FastAPI arrives as a dependency of whatever the team actually chose. The KEV entry identifies the vendor as “Kludex,” which is the GitHub username of the framework’s maintainer. That is CISA doing the only sensible thing available, and it is also a fair picture of where federal remediation deadlines now point: at a single-maintainer open-source library, named by handle.

The blast radius is visible in the record’s own reference list. Red Hat alone has issued more than twenty separate RHSA errata for this one CVE, which is a reasonable proxy for how many distinct shipped products contain the library. OSTIF’s disclosure names the downstream projects the researchers checked: FastAPI, LiteLLM, vLLM, text generation inference projects, OpenAI shim proxies, MCP servers, and agent harnesses. Their summary is that it “hits very large and prominent projects.” They did not publish a count, and we are not going to invent one.

That list is worth reading twice, because it is almost entirely AI-serving infrastructure — which is not a coincidence. The bug was found during an audit of vLLM. And it is not the only AI-stack entry in the September 2 batch: CISA added LiteLLM’s CVE-2026-59822 the same day, on the same September 16 deadline, and LiteLLM appears on the BadHost list of affected downstreams. Both records cite the same piece of research, Wiz’s AI infrastructure honeypot writeup. The pattern in this batch is not one framework. It is that the layer organizations stood up over the past two years to serve models has become a place attackers now look first, and that layer is Python web plumbing with a lot of hand-rolled path-based authorization in front of it.

What to do

Resolve Starlette’s version, not FastAPI’s. pip show starlette, or check the lockfile — anything from 0.8.3 through 1.0.0 is affected, and 1.0.1 or later is fixed. Pinning FastAPI without repinning the transitive dependency does nothing.

If you cannot upgrade immediately, the code-level mitigation is to stop deriving authorization from the reconstructed URL. Middleware that reads request.url.path should read request.scope["path"] instead, which is the raw path the ASGI server received and the same value routing uses. A Host allowlist at the proxy, or Starlette’s own TrustedHostMiddleware, also cuts off the injection, and is the faster change in most deployments.

Search your own code for the pattern rather than only checking versions. Any place that makes a security decision from request.url, str(request.url), or request.url.path — path prefix checks for admin routes, internal-only route guards, tenant scoping — is the vulnerable shape, and it stays a fragile shape after the upgrade.

Federal agencies have until September 16, 2026. The required action includes CISA’s forensic triage clause and a discontinue-use provision where mitigations are unavailable, so the deliverable is not only a dependency bump. For AI gateways and model-serving endpoints specifically, check access logs for Host headers containing /, ?, or #; those characters are not legal in a Host header, so any request carrying them was malformed on purpose.

Sourcing note

KEV dates, the catalog vulnerability name, the required action text, the description, the CWE assignments, the three CVSS metric entries with their source identifiers, vulnStatus, and the reference list all come from NVD’s API record for CVE-2026-48710, which republishes CISA’s fields verbatim. The disclosure timeline, the 7.0 High rating, the CWE-436 classification, and the Host header example come from X41 D-Sec’s advisory X41-2026-002. The audit sponsorship and the list of affected downstream projects come from OSTIF’s own disclosure post.

CISA’s alert page and KEV catalog feed both return HTTP 403 to automated requests, so the catalog was reached through NVD rather than directly. Note that NVD’s record for this CVE was still marked “Undergoing Analysis” with a lastModified of September 2, 2026 at 6:19 p.m. UTC when we retrieved it, roughly a day and a half after the addition.

The Red Hat errata count is a count of URLs on NVD’s reference list for this CVE, not a Red Hat statement about product coverage. We did not independently verify exploitation; the exploitation determination is CISA’s, and CISA does not publish its evidence in the catalog. Unresolved: what exploitation CISA observed and against which downstream project, and whether the researchers’ 7.0 or the three concurring 6.5 scores better reflects the bug as deployed.

September 3, 2026
Kestra is on a three-day federal clock for a command injection CVE whose actual flaw is a filter calling endsWith

CISA catalogs CVE-2026-49869 as an OS command injection flaw, but what an attacker actually exploits is a filter that checks whether a request path ends with the word configs.

What happened

CISA added CVE-2026-49869 in the Kestra orchestration platform to the Known Exploited Vulnerabilities catalog on September 2, 2026. NVD’s record carries CISA’s fields verbatim: cisaExploitAdd of 2026-09-02 and cisaActionDue of 2026-09-05. Federal agencies have three days.

The catalog entry is titled “Kestra OSS OS Command Injection Vulnerability.” That is where the flaw ends up. It is not where it starts. NVD’s description states the mechanism plainly: “Prior to 1.0.45 and 1.3.21, AuthenticationFilter uses request.getPath().endsWith(\"/configs\") to whitelist the public configuration endpoint from Basic Auth. Because the check is a suffix match rather than an exact path match, any API path whose last segment is configs bypasses authentication entirely.”

The whole vulnerability is endsWith where equals was intended. Kestra wanted one endpoint — the public configuration endpoint — to be reachable without credentials, and expressed that intent as a shape rather than an identity. Every other route in the API inherits the exemption for free, provided the attacker appends the right five characters.

Kestra’s own advisory, GHSA-5vc5-wxxq-3fjx, published June 3, 2026, is titled “Unauthenticated Remote Code Execution via Authentication Bypass in AuthenticationFilter” and scores it 10.0 on CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. It explains what the bypass reaches. An unauthenticated caller can create and execute workflows, and Kestra ships its script plugins — Shell, Python, Node — enabled by default. Workflow creation is therefore code execution, running as root inside worker containers. The advisory also notes that the Pebble template engine’s http() function is unfiltered, which turns the same access into server-side request forgery against internal services and cloud metadata endpoints.

Affected versions are 1.3.20 and below. Patched releases are 1.0.45 and 1.3.21.

Trade coverage of the September 2 catalog additions reports that unknown actors have used the flaw to establish reverse shells and deploy cryptocurrency miners. CISA does not publish exploitation detail in the catalog itself, and we have not confirmed the payloads against a primary source; they are consistent with the shape of the bug but should be read as reported rather than established.

One record detail is worth noting. NVD lists the CVE’s vulnStatus as “Analyzed,” but the only CVSS metric on the record comes from [email protected] as a Secondary source. There is no [email protected] Primary score. The 10.0 that will appear in every dashboard is the project’s own self-assessment, republished. It looks correct here. It is still not an independent one.

Why it matters

The gap between the catalog name and the mechanism is not pedantry, because of how remediation actually gets triaged. An organization that receives the September 2 KEV batch and sorts it by vulnerability class is looking for command injection in its orchestration tooling. What it needs to look for is an authentication filter that uses suffix matching. Those are different searches, and only one of them finds anything.

The CVE record’s own classification shows the strain. It carries four CWEs: CWE-78 for the command injection, CWE-287 for the improper authentication, CWE-918 for the request forgery, and CWE-184 — incomplete list of disallowed inputs — for the filter logic itself. CWE-184 is the honest one. Every other entry describes an outcome. Only that one describes the decision that made the outcome possible: a security control that enumerated what it would allow by pattern instead of by name.

CISA had to pick one title, and picking the endpoint of the chain is defensible. But the effect is that the catalog, which is increasingly the input to automated compliance work rather than something a human reads, files this under a class that will not match the thing an engineer greps for.

The second point is about what Kestra is. Orchestration platforms are credential concentrators by design. Kestra exists to run jobs against databases, object stores, message queues, cloud APIs, and internal services, which means it holds — or can mint — access to most of them. Unauthenticated root execution inside its workers is not a compromise of one application. It is a compromise of the credential set for everything that application was built to reach. The unfiltered http() function makes that concrete: cloud instance metadata is one templated request away, and instance metadata is how container root becomes cloud role.

Third, the timing. The fix shipped June 3, 2026. The KEV listing came September 2 — 91 days later. This is not a vendor failure; Kestra disclosed and patched cleanly, with a named advisory and a clear description. The exposure that CISA is now putting on a three-day clock is entirely operator-side patch lag on a self-hosted, open-source component.

The branch split is part of why that lag persists. The advisory names two fixed releases, 1.0.45 and 1.3.21, and lists everything at or below 1.3.20 as affected. An operator running 1.1.x or 1.2.x will not find a fixed release on their own line. There isn’t one. They have to move to 1.3.21, which is a minor-version jump on a platform whose configuration surface changes between minors, and that is a materially harder change to schedule than a point release. Three days is not much time to discover that the fix is a migration.

Finally, the payloads. Reverse shells and coin miners are commodity outcomes, and commodity outcomes come from indiscriminate scanning rather than from targeting. A 10.0 unauthenticated path in an internet-reachable open-source platform gets found by everyone, not by someone. Any Kestra instance that has been reachable from the internet on a vulnerable build since June should be treated as having been tried.

What to do

Check the running version, not the chart or manifest version. Anything at or below 1.3.20 is affected. Move to 1.3.21, or to 1.0.45 if you are genuinely on the 1.0 line. If you are on 1.1.x or 1.2.x, plan the jump to 1.3.21 now rather than looking for a backport that does not exist.

If you cannot upgrade inside the window, the immediate mitigation is network placement. Kestra’s API should not be reachable from the internet, and a reverse proxy in front of it can reject any request path whose last segment is configs other than the single legitimate configuration endpoint. That is a stopgap that mirrors the bug rather than fixing it, and it should be treated as buying days, not as remediation.

Assume you need to look, not just to patch. In the Kestra UI and database, list flows and executions created since early June and reconcile them against what your team actually authored — an injected flow will typically be a single script task with no history. On the hosts, check worker containers for outbound connections to addresses you do not recognize and for requests to 169.254.169.254. If instance metadata was reachable from a worker, rotate the role credentials that metadata endpoint would have handed out, on the assumption that they were taken.

Federal agencies should read the required action in full. It says to “Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s ‘Forensics Triage Requirements’ (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable.” The forensic obligation and the discontinue-use clause are both in there, and neither is satisfied by an upgrade.

Sourcing note

The KEV dates, required action text, description, CWE list, CVSS metric sourcing, and vulnStatus come from NVD’s API record for CVE-2026-49869, which republishes CISA’s fields verbatim. The advisory title, affected and patched version numbers, the default-enabled script plugins, and the unfiltered Pebble http() function come from Kestra’s own GitHub Security Advisory GHSA-5vc5-wxxq-3fjx, published June 3, 2026.

CISA’s alert page and its KEV catalog feed both return HTTP 403 to automated requests, so the catalog was reached through NVD — NIST republishing CISA, a government primary source, but one that lags the catalog by hours and is not the catalog itself. The reverse-shell and cryptocurrency-miner payloads are from trade coverage of the September 2 batch and are not confirmed against a primary source.

Unresolved: when exploitation began, which CISA does not publish and Kestra has not stated; whether any 1.1.x or 1.2.x backport exists that the advisory does not name; and why a record marked “Analyzed” by NVD carries no NVD Primary CVSS score.

September 3, 2026
SonicWall’s third SMA1000 zero-day pair draws a September 5 federal deadline, and its own CVE records name no fixed version

CISA added both SMA1000 flaws to the Known Exploited Vulnerabilities catalog on September 2, 2026 with a September 5 remediation deadline, and the CVE records SonicWall assigned itself list affected builds without naming a fixed one.

What happened

SonicWall published two CVEs for its SMA1000 secure access appliances on September 1, 2026, and CISA added both to the Known Exploited Vulnerabilities catalog the following day. NVD’s records carry CISA’s own fields verbatim: cisaExploitAdd of 2026-09-02 and cisaActionDue of 2026-09-05 on each. That is a three-day federal clock, and it expires this Saturday.

The first, CVE-2026-83548, is scored 10.0. SonicWall’s own description is short: “A Pre-authentication SSRF vulnerability exists in the SMA1000 Appliance Work Place interface due to an unintended alternate access path.” The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — network reachable, no privileges, no user interaction, and a changed scope, which is what carries it to a perfect ten. The record is classified CWE-918 for the request forgery and CWE-441, confused deputy, for the access path itself. CISA catalogs it as “SonicWall SMA1000 Appliances Server-Side Request Forgery Vulnerability.” The finder credited on the record is Adam Babis of SonicWall PSIRT.

The second, CVE-2026-83549, is scored 7.8 and sits in the Appliance Management Console rather than the user-facing Work Place. SonicWall describes it as a “Post-authentication Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) vulnerability … which in specific conditions could potentially enable a remote authenticated attacker as administrator to execute arbitrary OS commands, resulting in remote code execution.”

Read on its own, that second record does not look like a three-day emergency. Its vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. AV:L means local attack vector. PR:L means low privileges required. But the prose in the same record says “remote” and says “as administrator.” The vendor’s sentence and the vendor’s vector, on one record, describe two different attacks. Neither NVD nor CISA reconciles them; both simply republish what the CNA supplied.

The two records together do resolve into something coherent. A pre-authentication request forgery with a changed scope in the Work Place interface is a way to reach things the appliance can reach but you cannot. An administrator-context command injection in the management console is a way to run code once you are there. That is a chain, and CISA’s decision to add both on the same day under the same deadline is consistent with the pair being used together rather than each being used alone.

The remediation action CISA attached to both is its current standard text: “Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk guidance and CISA’s ‘Forensics Triage Requirements’.” That last clause is not decoration. BOD 26-04’s three-day band includes entries that carry an additional obligation, and the directive states it plainly: “The text ‘& forensic triage’ means that the agency must complete remediation or mitigation action within the timeline (three days) and carry out a forensic triage of the asset to assess whether the system is compromised.” Patching is half of what is being asked here.

Why it matters

The version ranges are the part worth sitting with. SonicWall’s CNA record lists the affected builds for the September pair as “12.4.3-03453 (platform-hotfix) and older” and “12.5.0-02835 (platform-hotfix) and older.” In July, the same appliance line took a nearly identical pair: CVE-2026-15409, also a pre-authentication SSRF in the Work Place interface, also scored 10.0 on an identical vector, added to KEV on July 14, 2026 with a cisaActionDue of 2026-07-17 — also three days. That record’s affected ranges topped out at 12.4.3-03434 and 12.5.0-02800.

Compare the ceilings. July’s affected range ended at build 03434. September’s affected range includes everything up to and including 03453. An administrator who did exactly what the July advisory asked — moved past 03434 onto a later build — landed inside the range that the September advisory now calls vulnerable. The remediation was real and the exposure returned anyway, in the same interface, with the same root class of flaw, seven weeks later.

This is the third round in nine months for this product line. It is worth being precise about what is and is not established across those rounds. The July pair was attributed by Volexity to an actor it tracks as UTA0533, with a named malware set; that attribution belongs to July and to Volexity, and nothing published so far ties the September pair to the same actor. Trade coverage of the September round also reports that attackers in the earlier intrusions extracted TOTP seed material, and that SonicWall’s guidance advised log review and reimaging rather than patching alone. We could not read SonicWall’s advisory page to confirm that language, and we are not treating it as confirmed. The reason to mention it is that it explains why CISA’s forensic-triage clause is attached rather than a bare patch instruction: on an appliance that terminates remote access, the question of whether the box was already used is separate from the question of whether the hole is closed.

The second thing worth noting is where the fixed build number lives. Both NVD records point at one authoritative vendor source, SNWLID-2026-0016 on SonicWall’s PSIRT portal. That page returns a document containing a title and no advisory body; the content is assembled by JavaScript after load. Automated tooling — and any reader without a browser — gets nothing from it. SonicWall’s own CVE records, which are machine-readable and which the company controls, list the affected versions and carry no fixed-version field at all. The result is that the build numbers an administrator needs on a three-day clock reach them through third-party transcription. Beazley Security’s advisory gives them as 12.4.3-03526 and 12.5.0-02952. That is very probably right. It is also a security firm reading a vendor’s rendered web page on the vendor’s behalf, which is not where a remediation deadline should get its version numbers.

Correction, September 3, 2026, 4:10 p.m. CT: The paragraph above is wrong on its central point. SonicWall does publish the fixed builds in a document a non-browser client can read — a product notice carrying the same SNWLID-2026-0016 identifier at sonicwall.com/support/notices/, distinct from the psirt.global.sonicwall.com page the CVE records name as the authoritative reference. That notice, dated September 1, 2026, lists 12.4.3-03526 and 12.5.0-02952 as the remediation builds. The build numbers therefore do not reach administrators only through third-party transcription, and Beazley Security’s advisory agrees with the vendor rather than standing in for it. What remains accurate: SonicWall’s CVE records still carry no fixed-version field, and the reference those records point to is the page that does not render. The same notice also confirms in SonicWall’s own words the guidance this story treated as unverified trade coverage: “Contact SonicWall Technical Support for assistance reviewing the system for indicators of compromise (IoCs). If IoCs are detected: Re-image (hardware) or re-deploy (virtual) appliances. Change all user and administrator passwords. Reset TOTP tokens.”

This publication has now seen the same shape three times in a week: HPE’s Aruba bulletin, whose fixed-version page did not render; Amelia’s changelog, which described a critical fix as routine; and now a vendor whose structured record omits the one field that closes the deadline. The fix keeps arriving before the record of it does.

What to do

Identify SMA1000 6210, 7210, and 8200v appliances and read the platform-hotfix build, not the marketing version. If it is at or below 12.4.3-03453 or 12.5.0-02835, it is in the affected range on SonicWall’s own record. Move to 12.4.3-03526 or 12.5.0-02952. [Corrected September 3, 2026: these builds are confirmed against SonicWall’s own product notice for SNWLID-2026-0016 at sonicwall.com/support/notices/. The original sentence here told readers to verify them in a browser because we believed only a third-party transcription existed. That was wrong.]

Federal agencies are past the point where patching alone satisfies the requirement. The required action names forensic triage; plan for the asset assessment alongside the upgrade, not after it.

Everyone else should treat the appliance as a candidate for review rather than a box that is now fine. Pull Work Place and management console logs back through June and look for requests that reached internal addresses the appliance should never have contacted, and for administrative sessions that do not match a known change. If you find evidence of pre-patch access, reissue MFA enrollment rather than resetting passwords: a rotated password invalidates a stolen password, and neither invalidates a stolen seed.

Sourcing note

KEV dates for CVE-2026-83548, CVE-2026-83549, and CVE-2026-15409 were taken from NVD’s API records, which republish CISA’s cisaExploitAdd, cisaActionDue, cisaVulnerabilityName, and cisaRequiredAction fields verbatim. Affected version ranges, CVSS vectors, descriptions, and the finder credit come from SonicWall’s CNA records retrieved from the CVE Program API — SonicWall is the assigner for all of these, so that is the vendor’s own text.

[Corrected September 3, 2026: we could not read the psirt.global.sonicwall.com vulnerability-detail page for SNWLID-2026-0016, which returns no advisory body without JavaScript execution and which this newsroom does not execute scripts for. We did not find, and should have found, SonicWall’s product notice for the same advisory ID on sonicwall.com, which renders as static HTML and carries the fixed builds, the CVSS scores, and the IoC and TOTP guidance. It was retrieved twice on September 3, 2026 with different prompts and returned the same values both times. The original text of this paragraph follows.] We could not read SNWLID-2026-0016 directly. The page returns no advisory body without JavaScript execution, and this newsroom does not execute page scripts. CISA’s own alert page and KEV catalog feed both return HTTP 403 to automated requests, so the catalog was reached through NVD rather than directly; that is NIST republishing CISA and is a government primary source, but it lags the catalog by hours and is not the catalog itself. The fixed build numbers 12.4.3-03526 and 12.5.0-02952 are transcribed from Beazley Security’s advisory BSL-A1201 and are not confirmed against a SonicWall document we could read.

The July attribution to UTA0533 is Volexity’s, reported through trade coverage, and applies to the July pair only. The TOTP seed extraction and the reimaging guidance are from trade coverage and are unconfirmed against a primary source; they are reported here as claims and were not used to establish any fact about the September pair. Unresolved: whether the internal conflict on CVE-2026-83549 between “remote … as administrator” in the description and AV:L/PR:L in the vector reflects an error in the vector or an imprecise description, and whether builds between 12.4.3-03434 and 12.4.3-03453 were ever a complete remediation for the July pair.

September 3, 2026