Any authenticated user of a Chainlit deployment using the SQLAlchemy data layer—including trial accounts or compromised end-users—can pivot from the chatbot UI directly to your cloud metadata service and exfiltrate IAM credentials. Patch to 2.9.4 immediately; in cloud environments with IMDSv1 enabled, this is a one-request path to full account takeover. Until patched, enforce IMDSv2 and block outbound HTTP from the Chainlit process to RFC 1918 and link-local ranges.
Affected Systems
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| chainlit | pip | < 2.9.4 | 2.9.4 |
Do you use chainlit? You're affected.
Severity & Risk
Recommended Action
- 1. PATCH: Upgrade Chainlit to 2.9.4 immediately. Fix is in commit ffc3cce648b343b933e10e85ee5805c7e02ab3bf. 2. ENFORCE IMDSv2: On all cloud instances running Chainlit, disable IMDSv1 (AWS: aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1). 3. EGRESS FILTERING: Apply strict outbound firewall rules blocking Chainlit process HTTP to RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local (169.254.0.0/16). 4. PRINCIPLE OF LEAST PRIVILEGE: Audit and reduce IAM roles attached to Chainlit instances—assume credentials are already compromised if you cannot confirm patch status. 5. DETECT: Alert on outbound HTTP connections from Chainlit to internal IP ranges; review storage provider write logs for unexpected objects created by the Chainlit service identity. 6. WORKAROUND (pre-patch only): Block /project/element endpoint at WAF/reverse proxy layer, or disable the SQLAlchemy data layer if persistent chat is not required.
Classification
Compliance Impact
This CVE is relevant to:
Technical Details
NVD Description
Chainlit versions prior to 2.9.4 contain a server-side request forgery (SSRF) vulnerability in the /project/element update flow when configured with the SQLAlchemy data layer backend. An authenticated client can provide a user-controlled url value in an Element, which is fetched by the SQLAlchemy element creation logic using an outbound HTTP GET request. This allows an attacker to make arbitrary HTTP requests from the Chainlit server to internal network services or cloud metadata endpoints and store the retrieved responses via the configured storage provider.
Exploitation Scenario
An attacker obtains any authenticated session to a Chainlit application—via a legitimate trial account, phishing a registered user, or credential stuffing. They issue a crafted POST to the /project/element endpoint with a url field set to http://169.254.169.254/latest/meta-data/iam/security-credentials/my-role. The Chainlit server, running on an EC2 instance with an attached IAM role, fetches this URL server-side and stores the JSON response—containing a live AccessKeyId, SecretAccessKey, and SessionToken—into the configured S3 bucket. The attacker retrieves the object from storage and uses the credentials to authenticate to AWS. With the IAM role's permissions (commonly broad in AI development environments), they enumerate S3 buckets containing training data and model weights, access internal model APIs, or establish persistence via new IAM users. The entire attack chain requires only authenticated HTTP access and standard tooling.
Weaknesses (CWE)
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N References
- github.com/Chainlit/chainlit/commit/ffc3cce648b343b933e10e85ee5805c7e02ab3bf
- github.com/Chainlit/chainlit/releases/tag/2.9.4
- github.com/advisories/GHSA-2g59-m95p-pgfq
- nvd.nist.gov/vuln/detail/CVE-2026-22219
- vulncheck.com/advisories/chainlit-sqlalchemy-data-layer-ssrf-via-project-element
- zafran.io/resources/chainleak-critical-ai-framework-vulnerabilities-expose-data-enable-cloud-takeover