The Plumbing Under Your Private AI Is Now on CISA's Exploited List

A lot of firms solved the confidentiality problem the same way over the past eighteen months. Rather than let attorneys paste client material into a public chatbot, the firm stood up its own gateway. Requests go through infrastructure the firm controls, keys live in one place, usage is logged, and matter content never touches a consumer product. It is a sound design and we have recommended versions of it.

That gateway is infrastructure. On September 2, some of the most common pieces of it landed on CISA's list of vulnerabilities that attackers are actively exploiting.

What was added

CISA added seven vulnerabilities to the Known Exploited Vulnerabilities catalog that day. Two are in SonicWall SMA1000 appliances, a server-side request forgery flaw and an OS command injection flaw. One is a SQL injection issue in Sangoma Switchvox. One is OS command injection in Kestra OSS.

The remaining three are worth naming individually, because of where they sit:

• CVE-2026-59822, an improper authentication flaw in BerriAI LiteLLM. LiteLLM is the proxy many teams put in front of model providers to normalize calls and manage keys. It is the gateway itself.
• CVE-2026-48710, HTTP request and response smuggling in Kludex Starlette, the framework underneath FastAPI. If your AI service was built in Python in the last three years, this is very likely running in it.
• CVE-2026-82329, improper authentication in JFrog Artifactory, where organizations store the build artifacts and model files that get deployed.

CISA's catalog is not a list of theoretical risks. Inclusion means the agency has evidence of active exploitation. The alert points to Binding Operational Directive 26-04 for federal agencies and encourages every organization to prioritize remediation on the same basis.

The LiteLLM entry is the one to read twice

Reporting from The Hacker News on September 3 fills in what attackers are doing with these. Reverse shells and cryptominers on the Kestra flaw. Admin tokens minted for enumeration through the Artifactory issue, which carries a 9.8 severity score and, in a default configuration, can let an unauthenticated attacker with network access reach administrative privileges. The Starlette smuggling flaw has been chained with a second vulnerability to reach remote code execution.

The LiteLLM activity is different in kind. On that one, attackers exploited the authentication weakness to harvest model configuration, upstream provider key material, provider endpoints, and the virtual keys the proxy itself issues.

Read that list against what your gateway was built to do. The reason it exists is to be the single place your firm's AI credentials live. Every model call the firm makes runs through it. The virtual keys it issues are how each practice group, or each application, gets its own scoped access. An attacker who takes that inventory has the provider keys, the map of what is connected to what, and the credentials your own systems use to talk to it.

The confidentiality architecture and the highest-value target became the same box. That is not a criticism of the design. Centralizing keys is better than scattering them. It does mean the box has to be maintained like the crown jewels it is, and in our experience it usually is not, because it was installed as a plumbing project by whoever was closest to the AI initiative.

The uncomfortable question for a law firm

Ask who patches it.

For the firm's document management system, the practice management platform, and the email tenant, there is an answer. Someone owns those, there is a maintenance window, and somebody would notice a missed update. For the AI gateway, the answer is frequently a name rather than a function: the person who set it up, who may be an associate with an interest in the technology, an outside developer engaged for a fixed project, or an MSP that treated the deployment as a one-time build.

None of those arrangements produce someone watching CISA's catalog on a Wednesday afternoon. And the components involved move fast. A model gateway is not enterprise software with a quarterly patch cycle; it is an open-source project that ships frequently, which is exactly why teams like it.

So the practical exposure is not that your firm chose badly. It is that a system holding the keys to every AI call the firm makes was installed without the operational ownership that the rest of your confidential infrastructure has.

What to do this week

Find out whether you are running any of it. Ask whoever built the AI capability for a straight inventory: is there a LiteLLM proxy, is the service built on FastAPI or Starlette, is Artifactory in the picture, and what versions. If nobody can answer within a day, you have learned the more important thing.

Check exposure before you check versions. A gateway reachable only from inside the firm's network is a different problem from one published to the internet so people can use it from home. The internet-facing ones come first, and the SonicWall flaws in the same batch are a reminder that the remote access path itself is under active attack.

Rotate the provider keys if LiteLLM was exposed. Patching closes the door. It does not un-harvest anything already taken. If an affected version was reachable, treat the upstream provider keys and the proxy-issued virtual keys as compromised and reissue them.

Give the thing an owner. Not a person who knows how it works. A role that is responsible for patching it, with a place in the same maintenance rhythm as everything else that holds client data. This is the fix that outlasts this particular batch of CVEs.

Your duty of confidentiality does not distinguish between the systems you think of as legal technology and the ones you think of as plumbing. Attackers do not either. They just found the pipe with the keys in it.

If you want help working out what your AI deployment actually consists of and who should be maintaining it, that is a conversation worth having.