CVE-2026-22218: Chainlit arbitrary file read

CISO Take

Chainlit, the open-source UI framework used to front LLM chat and agent apps, ships an arbitrary file read flaw in versions before 2.9.4: an authenticated user can submit a custom Element with a manipulated path, forcing the server to copy any file it can read into the attacker's own session, then pull the raw bytes back via a predictable /project/file/<chainlitKey> endpoint. This matters because Chainlit sits in front of production LLM deployments where the service account routinely has read access to .env files, API keys for the LLM provider, RAG source documents, and internal config — exactly the kind of data this bug hands over with nothing more than a valid login. With 40 known downstream dependents and an EPSS score placing it in the top 5% of CVEs by predicted exploitation likelihood, this is not a theoretical bug, even though it's absent from CISA KEV and no public exploit or Nuclei template has surfaced yet. Patch to Chainlit 2.9.4 or later immediately; until then, restrict who can create authenticated sessions, audit what the Chainlit process account can read on disk (secrets, credentials, source), and monitor for anomalous requests to /project/element and /project/file/ endpoints referencing paths outside the expected project directory.

Sources: NVD EPSS GitHub Advisory ATLAS zafran.io vulncheck.com

What is the risk?

High severity, low-complexity path traversal (CWE-22) requiring only an authenticated session — no admin privileges or user interaction beyond normal app use. EPSS at 0.088 places it in the top 5% of CVEs ranked by real-world exploitation probability, indicating meaningful attacker interest in this class of flaw despite no confirmed active exploitation (not in CISA KEV, no SSVC decision, no public PoC or Nuclei template yet). The combination of trivial exploitability post-auth, broad blast radius (40 dependents), and a public technical writeup (Zafran's "ChainLeak" research) that documents the exact request flow raises the practical risk above what the EPSS score alone suggests — expect weaponization to follow disclosure research on a matter of weeks, not months.

How does the attack unfold?

Initial Access

Attacker obtains or already holds a valid authenticated session on a public-facing Chainlit deployment.

AML.T0049

Exploitation

Attacker sends a crafted request to /project/element with a user-controlled path pointing to a sensitive server-side file, causing Chainlit to copy it into the session.

AML.T0037

Exfiltration

Attacker retrieves the copied file's raw contents via the returned chainlitKey using the /project/file/<chainlitKey> endpoint.

AML.T0025

Impact

Disclosed credentials, API keys, or source code enable follow-on abuse of the LLM provider account or broader infrastructure compromise.

AML.T0055

Initial Access

Attacker obtains or already holds a valid authenticated session on a public-facing Chainlit deployment.

AML.T0049

Exploitation

Attacker sends a crafted request to /project/element with a user-controlled path pointing to a sensitive server-side file, causing Chainlit to copy it into the session.

AML.T0037

Exfiltration

Attacker retrieves the copied file's raw contents via the returned chainlitKey using the /project/file/<chainlitKey> endpoint.

AML.T0025

Impact

Disclosed credentials, API keys, or source code enable follow-on abuse of the LLM provider account or broader infrastructure compromise.

AML.T0055

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Chainlit	pip	—	No patch
12.5K 41 dependents Pushed 2d ago 50% patched ~45d to patch Full package profile →

Do you use Chainlit? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

10.3%

chance of exploitation in 30 days

Higher than 95% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ EPSS exploit prediction: 10%

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What should I do?

1 step

Upgrade to Chainlit 2.9.4 or later immediately — this is the vendor-confirmed fix (see the 2.9.4 release notes). Where immediate upgrade isn't possible, restrict Chainlit deployments so the service account runs with least-privilege file system access (no read access to .env, credential stores, or unrelated project directories), and place the app behind additional authentication/network controls to reduce the pool of users who can reach /project/element. Detection: monitor logs for /project/element requests containing path traversal sequences (../, absolute paths, or references outside the expected project root) and for unusual volumes of /project/file/<chainlitKey> retrievals shortly after an element update — both are strong indicators of exploitation attempts.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Leakage Privacy Violation Framework AML.T0025 - Exfiltration via Cyber Means AML.T0037 - Data from Local System AML.T0049 - Exploit Public-Facing Application AML.T0055 - Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.3 - AI system security

NIST AI RMF

MEASURE 2.7 - AI system security and resilience evaluation

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-22218?

Chainlit, the open-source UI framework used to front LLM chat and agent apps, ships an arbitrary file read flaw in versions before 2.9.4: an authenticated user can submit a custom Element with a manipulated path, forcing the server to copy any file it can read into the attacker's own session, then pull the raw bytes back via a predictable /project/file/<chainlitKey> endpoint. This matters because Chainlit sits in front of production LLM deployments where the service account routinely has read access to .env files, API keys for the LLM provider, RAG source documents, and internal config — exactly the kind of data this bug hands over with nothing more than a valid login. With 40 known downstream dependents and an EPSS score placing it in the top 5% of CVEs by predicted exploitation likelihood, this is not a theoretical bug, even though it's absent from CISA KEV and no public exploit or Nuclei template has surfaced yet. Patch to Chainlit 2.9.4 or later immediately; until then, restrict who can create authenticated sessions, audit what the Chainlit process account can read on disk (secrets, credentials, source), and monitor for anomalous requests to /project/element and /project/file/ endpoints referencing paths outside the expected project directory.

Is CVE-2026-22218 actively exploited?

No confirmed active exploitation of CVE-2026-22218 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-22218?

Upgrade to Chainlit 2.9.4 or later immediately — this is the vendor-confirmed fix (see the 2.9.4 release notes). Where immediate upgrade isn't possible, restrict Chainlit deployments so the service account runs with least-privilege file system access (no read access to .env, credential stores, or unrelated project directories), and place the app behind additional authentication/network controls to reduce the pool of users who can reach /project/element. Detection: monitor logs for /project/element requests containing path traversal sequences (../, absolute paths, or references outside the expected project root) and for unusual volumes of /project/file/<chainlitKey> retrievals shortly after an element update — both are strong indicators of exploitation attempts.

What systems are affected by CVE-2026-22218?

This vulnerability affects the following AI/ML architecture patterns: LLM chat/agent UI serving layer, RAG pipelines (Chainlit-fronted), agent frameworks with Chainlit UI.

What is the CVSS score for CVE-2026-22218?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

LLM chat/agent UI serving layerRAG pipelines (Chainlit-fronted)agent frameworks with Chainlit UI

MITRE ATLAS Techniques

AML.T0025 Exfiltration via Cyber Means

AML.T0037 Data from Local System

AML.T0049 Exploit Public-Facing Application

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.3

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

Chainlit versions prior to 2.9.4 contain an arbitrary file read vulnerability in the /project/element update flow. An authenticated client can send a custom Element with a user-controlled path value, causing the server to copy the referenced file into the attacker’s session. The resulting element identifier (chainlitKey) can then be used to retrieve the file contents via /project/file/<chainlitKey>, allowing disclosure of any file readable by the Chainlit service.

Exploitation Scenario

An adversary signs up for or otherwise obtains a low-privilege authenticated account on a public-facing Chainlit-powered AI assistant. They open a chat session and, instead of using the normal UI, craft a direct request to the /project/element update endpoint with a custom Element whose path parameter points to a sensitive file on the server — for example the application's .env file or a config file holding the LLM provider's API key. The server copies that file into the attacker's session and returns a chainlitKey identifier. The attacker then requests /project/file/<chainlitKey> and receives the full file contents. With the leaked API keys or credentials, the attacker can pivot to abuse the underlying LLM provider account (cost harvesting, data exfiltration via the inference API) or gain further foothold in connected infrastructure.

Weaknesses (CWE)

CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.