AI Autopsy: ChainLeak Creates a New Attack Surface Out of Traditional Flaws

Two new vulnerabilities in the open source AI framework Chainlit are a reminder that AI security is still security. The bugs – dubbed “ChainLeak” by researchers – are not prompt tricks or model weirdness. They are familiar web vulnerability classes: arbitrary file read and server-side request forgery (SSRF).

The twist is context. AI apps built with frameworks like Chainlit often sit close to sensitive data, integrate with internal services, and run with cloud permissions. So a straightforward flaw can become a multi-system compromise.

Zafran estimates that Chainlit averages around 700,000 downloads per month and has had more than five million downloads over the past year. In enterprise terms, that translates into a simple risk pattern: quick prototypes become real services, demos get left running, and internal tools quietly inherit production credentials. The frameworks that make AI adoption easier can also inadvertently create a new attack surface.

What is ChainLeak?

Zafran identified two vulnerabilities affecting Chainlit versions before 2.9.4. CVE-2026-22218 enables arbitrary file read through an element update flow, allowing an attacker to retrieve files the Chainlit process can access. CVE-2026-22219 enables SSRF, in which the server can be coerced to make outbound HTTP requests to internal services that an external attacker could not normally reach. Responses may be retrievable, depending on the configuration. In its disclosure, Zafran flags higher impact when the SQLAlchemy data layer is used, because attacker-controlled element URLs can trigger server-side fetches.

“Most severe risks come from traditional vulnerabilities in the framework and server, rather than the model” Gal Zaban

The bottom line is that exploitation could enable an attacker to access sensitive data, including cloud API keys, and move through a victim’s broader cloud environment.

The researchers say the issues can be triggered with no user interaction and are present in internet-facing enterprise deployments. The fixes landed in Chainlit 2.9.4, but that is only half the story. Organisations also need to ask where Chainlit has been deployed, what it can reach, and what secrets it carries. Zafran launched Project DarkSide alongside the disclosure, positioning it as a wider effort to test the building blocks of AI applications rather than focusing only on models.

From framework bug to cloud compromise

File read and SSRF are longstanding issues, but they become more dangerous when the affected system acts as a broker between users, cloud services, and internal data. With file read, the prize is often secrets – local databases, tokens, signing keys, and especially “environment variables” where cloud credentials and API keys still tend to live. With SSRF, the prize is reach – internal services, administrative interfaces, and in some environments, cloud metadata endpoints used to issue temporary credentials.

Alexander Feick, VP of labs at eSentire Labs, says the core issue is that AI frameworks like Chainlit are built to turn AI output into action. “Model responses are not just displayed; they are routed into tool calls, data retrieval, file handling, and external services,” he tells Assured Intelligence. “That execution model is powerful, but it also flattens trust.”

In other words, compromise the framework, and you can inherit the application’s authority. That is why a vulnerability in an “AI UI framework” can appear like a cloud incident. The framework sits in the middle of a permissions graph, and those permissions are often broader than anyone remembers approving.

Time to take action

Gal Zaban, research team lead at Zafran, warns that the risks associated with exploiting CVE-2026-22218 and CVE-2026-22219 are “elevated when combined, leading to a potential compromise of cloud resources.” This should make prompt patching the first port of call for CISOs.

“Chainlit’s execution model is powerful, but it also flattens trust” Alexander Feick

But this should be the baseline. Because the exploitation path is designed to expose secrets, organisations should assume that credentials will be exposed in any internet-facing or broadly accessible deployment and respond accordingly.

ESentire’s Feick says security teams should treat this like a secrets incident, not just a version bump. “Organisations should immediately rotate their API keys, invalidate tokens, and review the cloud roles or service accounts the application relies upon,” he explains. Then they should restrict what the Chainlit app can do, even when it is behaving “normally”. That means stripping IAM permissions to least privilege and removing access to anything it does not strictly need to connect to.

Next, CISOs should contain the blast radius. SSRF is significantly less useful to attackers when workloads cannot communicate freely with internal admin surfaces or metadata endpoints. Putting Chainlit behind authentication, restricting outbound access, and segmenting it like any other internet-facing service will help to reduce risk. If an AI app does not need to interact with a service, it should not be able to talk to it.

Finally, network defenders should consider threat hunting. Feick explains that actions performed with stolen credentials can appear legitimate because they are executed using the application’s own identity. That makes cloud audit logs, request tracing, and baselining of which internal services the application normally calls all useful tactics.

The bigger picture

ChainLeak is a useful counterweight to the industry’s model-first security narrative. Prompt injection, jailbreaks, and tool abuse matter, but the fastest way into an AI system may still be the same vulnerability classes we have dealt with for decades. The consequences of these traditional exploits can be more severe because AI systems are designed to integrate with everything.

Zafran’s Zaban makes that point directly. “Most severe risks come from traditional security vulnerabilities in the framework and server themselves, rather than the model being used,” she tells Assured Intelligence.

Gregor Stewart, chief AI officer at SentinelOne, argues that AI ecosystems amplify those traditional risks because frameworks become high-leverage control points. Agent harnesses are “a nexus … for a model to do certain things”, he tells Assured Intelligence. And because models can act at speed and scale, vulnerabilities in that nexus can become “incredibly bad”. He adds a line CISOs should tape above their desks: “You can’t automate accountability.”

“You can’t automate accountability” Gregor Stewart

That is the strategic message. AI security strategy cannot be limited to “new AI risks” or only “old software risks”. It must be both, because modern AI applications combine both, and the surrounding plumbing often has the clearest exploitation paths.

Shadow AI and adversarial validation

Chainlit also highlights how shadow AI becomes operational risk. Zaban describes a common pattern. Employees deploy Chainlit instances “to quickly test new solutions or create a demo” – but these instances are “rarely patched and often hold production API keys”. This is a perfect storm – a service with real credentials, deployed outside normal review, and sometimes exposed far more widely than intended.

For eSentire’s Feick, shadow AI is structural, not moral. “Shadow AI is the default outcome when decision authority grows faster than security visibility and ownership,” he argues. If teams cannot ship quickly through sanctioned platforms, they will ship quickly through unsanctioned ones.

CISOs need two parallel responses, according to Feick and Zaban. One is governance: bringing AI frameworks into the same SDLC and vulnerability management processes as everything else. Inventories, dependency tracking, patching SLAs, secrets scanning, and pre-deployment reviews should all be standard practice for AI projects.

The other response is technical validation. Security teams must validate new tooling under adversarial conditions before it gains production privileges. Threat-model the framework, test abuse cases, probe for SSRF and data-leakage paths, and treat “demos” as hostile by default.

Feick puts it neatly: “You do not trust a system because it never fails. You trust it because you understand how it fails, and how far those failures can spread.”

Chainlit will be patched, and the CVEs will fade. The pattern will not. AI frameworks are rapidly becoming infrastructure. CISOs who treat them like infrastructure – by inventorying, containing, and testing them under pressure – will spend less time reading future autopsies about their own systems.