Vulnerability ManagementAI SecurityThreat Intelligence
The Known Exploited Vulnerabilities catalog is a boring document by design. It is a list of things that are being used against people right now, maintained by CISA, with a date by which US federal agencies have to fix them. It does not editorialise. It does not have a theme.
This week it accidentally had one.
On September 2 and 3, 2026, CISA added seven flaws to KEV. Three of them are not applications in the way the catalog usually means the word. They are the plumbing that AI systems run on.
| CVE | CVSS | Product | Class |
|---|---|---|---|
| CVE-2026-83548 | 10.0 | SonicWall SMA 1000 | Server-side request forgery |
| CVE-2026-49869 | 10.0 | Kestra OSS | OS command injection |
| CVE-2026-82329 | 9.8 | JFrog Artifactory | Improper authentication |
| CVE-2026-9586 | 9.3 | Sangoma Switchvox | SQL injection |
| CVE-2026-59822 | 8.8 | Berri LiteLLM | Improper authentication |
| CVE-2026-83549 | 7.8 | SonicWall SMA 1000 | OS command injection |
| CVE-2026-48710 | 6.5 | Kludex Starlette | HTTP request smuggling |
Federal agencies had until September 5 to remediate everything except Starlette and LiteLLM, which carry a September 16 deadline. Reported post-exploitation activity across the SonicWall, Switchvox, JFrog and Kestra entries is the usual mixture: reverse shells, credential harvesting, persistence, and coin miners for whatever capacity is left over.
Read the list again with a different filter. LiteLLM is an LLM proxy — for many organisations, the LLM proxy, the single service every internal application calls so that provider keys live in one place. Kestra is a workflow orchestrator increasingly used to schedule data and model pipelines. Starlette is the ASGI framework underneath FastAPI, which is what a very large share of internal AI services — inference wrappers, RAG endpoints, guardrail services — are actually written in.
None of these are AI products in the marketing sense. Nobody buys them. They are the layer under the thing you bought.
CVE-2026-82329 was already familiar. When we wrote about the Artifactory pre-auth admin bypass on September 2, the point of the piece was the gap between exploitation and cataloguing: watchTowr had reported attackers minting admin tokens on September 1, and the CVE was not in KEV.
It is now. The gap was roughly one day, which is fast, and it still means that anyone whose patch prioritisation waits for a KEV listing spent a day with an actively exploited pre-auth admin bypass on their artifact registry.
That is the useful thing about KEV, stated honestly: it is an excellent confirmation and a poor alarm.
The clearest read on attacker intent this week does not come from the catalog at all. It comes from what is happening to Langflow, the low-code builder used to assemble AI agents and pipelines.
CVE-2026-0768 (CVSS 9.8) is unauthenticated remote code execution as root. The validate endpoint of the custom component editor takes a code parameter and passes it to Python's exec() without sanitisation. ZDI published it as a zero-day advisory (ZDI-26-034) in January; every release up to 1.4.2 is affected.
Mass exploitation began on August 29, 2026. VulnCheck recorded more than 50 detections on August 30, rising to 360 by September 1, from roughly 20 source IPs across more than six countries, with observed targets in Singapore, Israel and the UK. SecurityWeek reported the same campaign.
What the attackers did once they had root is the part worth sitting with. They did not encrypt anything. They read environment variables — specifically LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS* and AWS_SECRET* — pulled the Langflow secret_key, and went looking for .env files, SSH keys and shell history. VulnCheck characterised the activity as reconnaissance and credential harvesting.
This is the twelfth Langflow CVE observed under exploitation, alongside CVE-2026-0769, CVE-2025-3248 and CVE-2026-5027, across more than 15,000 recorded attempts. Twelve is not a run of bad luck. It is a product category that attackers have decided is worth systematic attention.
Running in parallel, and worth patching for the same reason: CVE-2026-66066 — "KindaRails2Shell", CVSS 9.5 — an unauthenticated arbitrary file read in Ruby on Rails arising from a mismatch between how Active Storage and libvips handle image uploads. It leaks Rails secrets, database passwords, cloud credentials and API tokens, with over 7,100 vulnerable instances identified in early August.
Different stack, identical objective. Read files, take secrets.
A year of AI security discussion has been about the model — whether it can be jailbroken, persuaded, poisoned, or talked into calling a tool it should not. Almost none of this week's activity involves a model at all.
The attackers are going after AI infrastructure for a reason that has nothing to do with intelligence and everything to do with architecture. Building AI systems concentrates credentials in ways that older systems did not.
Consider what a typical internal AI service holds in its process environment:
secret_key, which decrypts every other credential the platform has stored.That is a richer haul than a typical web application, sitting in a service that is often newer, deployed faster, owned by a data or platform team rather than an application team, and less likely to appear in the CMDB. The LiteLLM entry makes the concentration explicit: the whole point of a gateway is that every provider key lives there, so an authentication bypass on it is worth more than an authentication bypass on almost anything else in the estate.
And the LiteLLM bypass is a good illustration of how these fail. Prior to version 1.84.0, the MCP Streamable HTTP endpoint supported OAuth2 passthrough for upstream MCP servers. On the fallback path, a failed LiteLLM key validation could be replaced with an empty UserAPIKeyAuth() object — so a request carrying a fabricated Authorization header reached MCP tooling with no valid key at all, able to list and call configured tools and the services behind them. Not a model failure. An error-handling branch that returned an empty object instead of a refusal.
There are three questions worth answering before Monday:
Most organisations can answer the first question with effort, the second with a lot of effort, and the third not at all.
The honest framing first, because this article is partly about a compromised LLM gateway and Obiguard operates one. A gateway is software, and software has CVEs. No architecture makes an authentication bypass impossible, and any vendor claiming otherwise is describing marketing rather than engineering. LiteLLM's fix is version 1.84.0 and it should be applied today.
What architecture does change is the value of what an attacker gets. The reason the Langflow campaign is profitable is that the credentials it harvests are bearer credentials: possession is authorisation, they work from anywhere, they are scoped to an organisation rather than a job, and nothing records what they were used for.
Obiguard Governance AI is built to break each of those properties.
Credentials are issued as scoped grants, not bearer secrets. Allow-lists operate at four levels — models, tools, external domains and users — and follow the credential rather than the caller. A key issued to a retrieval service that is approved for one model ID cannot be used to call a different one; a key with no registered tools cannot invoke MCP tooling at all, which is precisely the capability CVE-2026-59822 handed to an unauthenticated attacker. A key lifted out of a container's environment arrives at the gateway carrying its own restrictions, and a call outside the approved list is refused before the request leaves.
Inspection is synchronous and in-path, not a log processor reading after the fact. Every prompt, response and tool-call is evaluated against the Policy Set bound to that agent — including a validated allow-list check on tool invocations, with out-of-scope calls blocked and logged with full context. Mass credential exfiltration through a hijacked AI service is not a subtle pattern; it is only invisible when nothing sits in the path to see it.
Registration makes the inventory question answerable. AI Use Cases and Agents are registered objects with an owner, a policy set and a credential, which is what turns question 1 above from an all-hands Slack thread into a query. The failure mode across the whole Langflow story is not that these platforms were unpatched — it is that in many organisations nobody had a list of where they were running.
The Audit Ledger answers question 3. An append-only, immutable record of every call — prompt, response, tool invocations, the model, the agent ID, the initiating user or service account, timestamped — streaming to Splunk, Sumo Logic, Datadog or any SIEM by webhook or S3. It is written outside the service that might be compromised, which is the only property that matters after an incident. The difference between what could that key have done and what did that key do is the difference between a six-week investigation and an afternoon.
This is the server-side counterpart to the argument we made about credential theft on developer laptops. There, the collection target was a config file in a home directory. Here it is an environment variable in a container. The remedy is the same in both cases and it is not better secret storage — it is making sure that possessing the secret is not the same thing as being authorised.
The AI platforms being exploited this week are, for the most part, doing exactly what they were designed to do. Langflow's validate endpoint executes code because executing user-authored components is the product. LiteLLM holds every provider key because centralising them is the product. These are not neglected legacy systems; they are the newest, fastest-moving, most enthusiastically adopted software in the organisation.
That is the problem. They were adopted at the speed of a demo and are being attacked at the speed of a KEV listing, and the gap between those two speeds is where the API keys live.
Twelve exploited CVEs in one AI framework, an LLM gateway in KEV, and an orchestrator at CVSS 10.0 — inside a single week. The attackers have finished deciding whether AI infrastructure is worth targeting.
Explore Obiguard Governance AI or talk to us about which AI services in your estate are holding a long-lived provider credential right now — and what you could say about its activity if it were read tomorrow.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →