Skip to main content

Chainlit CVE-2026-22219

HIGH
Server-Side Request Forgery (SSRF) (CWE-918)
2026-01-20 disclosure@vulncheck.com GHSA-2g59-m95p-pgfq
8.3
CVSS 4.0 · Vendor: vulncheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Authenticate as low-privilege Chainlit user
  2. Delivery
    Submit Element with malicious internal URL
  3. Exploit
    SQLAlchemy layer performs server-side HTTP GET
  4. Execution
    Server fetches metadata/internal service
  5. Persist
    Response stored via storage provider
  6. Impact
    Retrieve stolen credentials or internal data

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V4 - API and Web Service URL allowlisting, SSRF prevention
MITRE ATT&CK

2 techniques across 2 tactics: Initial Access, Credential Access

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires that Chainlit is deployed with the SQLAlchemy data layer backend enabled for persistence (the vulnerable outbound-fetch code lives in the SQLAlchemy element-creation logic) and that the attacker holds an authenticated, low-privilege account (CVSS PR:L) able to create or update an Element through the /project/element flow. The concrete attacker-controlled input is the url value on an Element, which the server fetches via HTTP GET. Limiting factors: it is NOT exploitable against default deployments that do not enable the SQLAlchemy data layer, and it is NOT unauthenticated - a valid session is needed. Impact is maximized when the server has network reachability to sensitive internal services or a cloud metadata endpoint; environments with strict egress filtering or IMDSv2 enforcement meaningfully reduce the achievable impact.

Impact

The signals are mixed and should be read together. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, base 8.3) indicates a network-reachable, low-complexity attack requiring only low privileges (an authenticated app user) with high confidentiality impact and a subsequent-system confidentiality impact (SC:H), consistent with reaching internal/metadata endpoints. Publicly available exploit code raises practical risk, yet EPSS is very low (0.04%, 11th percentile) and the vulnerability is NOT in CISA KEV, so there is no evidence of active or widespread exploitation - the low EPSS despite a public POC suggests limited real-world targeting rather than mass scanning, plausibly because exploitation depends on a non-default configuration. Net: this is a genuine, credible priority for organizations that run Chainlit with the SQLAlchemy data layer and expose it to semi-trusted users (especially in cloud environments with reachable metadata services), but a lower priority for deployments not using that backend. Note the requirement of PR:L means it is authenticated, not an unauthenticated internet-wide risk; verify your data-layer configuration before triaging severity.

Exploit ScenarioDerived

An attacker with a valid low-privilege account on a Chainlit app (deployed with the SQLAlchemy data layer) creates or updates an Element whose url points at http://169.254.169.254/latest/meta-data/iam/security-credentials/. The Chainlit server issues an outbound GET to that URL and stores the returned cloud IAM credentials via the storage provider, where the attacker retrieves them - potentially enabling cloud account takeover. Public exploit code for this class of attack is available per the Zafran 'ChainLeak' writeup.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv3 – Jul 14, 2026

Server-side request forgery in Chainlit before 2.9.4 lets an authenticated user coerce the server into fetching an attacker-supplied URL, exposing internal network services and cloud metadata endpoints. The flaw lives in the /project/element update flow specifically when Chainlit is deployed with the SQLAlchemy data layer backend, whose element-creation logic issues an outbound HTTP GET against a user-controlled url field and persists the response through the configured storage provider. Publicly available exploit code exists (documented in Zafran's 'ChainLeak' research), though the flaw is not listed in CISA KEV and its EPSS probability is low at 0.04%.

Earlier versions of this analysis (2)
v2 Jul 14, 2026 - 17:06 cvss changed CVSS 8.3

Server-side request forgery in Chainlit (the open-source Python framework for building conversational AI/LLM apps) before 2.9.4 lets an authenticated user coerce the server into fetching an attacker-supplied URL. When the app is deployed with the SQLAlchemy data layer, a user-controlled url in an Element is retrieved by an outbound HTTP GET and the response is written to the configured storage provider, exposing internal services and cloud metadata (e.g. 169.254.169.254). Publicly available exploit code exists (VulnCheck/Zafran 'ChainLeak' research); it is not on CISA KEV and EPSS is low (0.04%).

v1 Mar 12, 2026 - 21:54 CVSS 7.7

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. [CVSS 7.7 HIGH]

RemediationAI

Vendor-released patch: 2.9.4 - upgrade Chainlit to 2.9.4 or later, which adds sanitization for custom thread element updates (PR #2737). Note the 2.9.4 upgrade includes a breaking persistence change: if you use persistence you must run the migration ALTER TABLE steps ADD COLUMN IF NOT EXISTS modes JSONB; before or during rollout, so schedule a maintenance window. If you cannot patch immediately, reduce exposure by restricting who can authenticate to the Chainlit application (the attack requires an authenticated client), and place the server behind egress controls: block outbound requests from the Chainlit host to internal RFC1918 ranges, localhost, and especially the cloud metadata endpoint 169.254.169.254 (on AWS, enforce IMDSv2 to require a session token) - the trade-off is that legitimate server-side fetches to those ranges will also break. Where feasible, temporarily disabling the SQLAlchemy data layer element persistence removes the vulnerable path but also disables element storage functionality. Refer to the VulnCheck advisory and the 2.9.4 release notes for authoritative details.

Affected Packages

pypi chainlit fix: 2.9.4

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in pypi

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Chainlit is an open-source Python framework for building conversational and LLM/agent chat applications, offering an optional persistence layer to store threads, steps, and Elements (file/media attachments). When operators enable the SQLAlchemy data layer, the element-creation code path dereferences a client-supplied url attribute on an Element and performs a server-originated HTTP GET to retrieve its contents before saving them via the storage provider. This is a textbook CWE-918 (Server-Side Request Forgery): the server trusts a user-supplied URL as a fetch target without validating scheme, host, or destination, so requests to RFC1918 addresses, localhost, or cloud metadata services (e.g. 169.254.169.254) are honored. The single affected package is cpe:2.3:a:chainlit:chainlit, with the vulnerable behavior gated on the SQLAlchemy backend configuration rather than being present in all deployments.

Know when Chainlit gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (vulncheck) PRIMARY 8.3 HIGH
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N
vuln.today AI 7.7 HIGH

Network-reachable and low-complexity but needs an authenticated user (PR:L); SSRF reaching internal/metadata services crosses a trust boundary (S:C) with confidentiality-only impact (C:H, I/A:N).

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

Primary rating from Vendor (vulncheck).

CVSS VectorVendor: vulncheck

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
Low
User Interaction
None
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
None
Vulnerable system: Availability
None
Subsequent system: Confidentiality
High
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

6
Analysis Updated
Jul 14, 2026 - 17:08 vuln.today
v3 - CVSS changed
Analysis Updated
Jul 14, 2026 - 17:06 vuln.today
v2 - CVSS changed
CVSS changed
Jul 14, 2026 - 16:22 NVD
7.7 (HIGH) 8.3 (HIGH)
Patch released
Mar 31, 2026 - 21:13 nvd
Patch available
PoC Detected
Feb 02, 2026 - 20:56 vuln.today
Public exploit code
CVE Published
Jan 20, 2026 - 00:15 nvd
HIGH 7.7

DescriptionCVE.org

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.

Executive ViewAI

Why It Matters

Chainlit versions before 2.9.4 contain a server-side request forgery vulnerability in the /project/element update flow that allows authenticated users to coerce the server into fetching attacker-supplied URLs, potentially exposing internal network services and cloud metadata endpoints. Publicly available exploit code exists, and organizations using SQLAlchemy backends face heightened risk of lateral movement and credential exposure through metadata endpoint access.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.0%
Top 89% exploitable
Prevalence
Medium
popular open-source framework for building LLM/agent chat apps
Exploit
POC
Public exploit code exists
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC Yes
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
Poc
System Exposure· derived
Open
Automatable· derived
No
Human Impact
High

Priority Score

62
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +42
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.

Affected Products (CPE)CVE.org

cpe:2.3:a:chainlit:chainlit:*:*:*:*:*:*:*:*

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy