Raw vector
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-22219 is a high-severity SSRF (CWE-918) vulnerability in Chainlit Chainlit. Its CVSS base score is 8.3 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked in the top 8% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to AC-4 (Information Flow Enforcement) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-22219 is a server-side request forgery (SSRF) vulnerability, classified under CWE-918, affecting Chainlit versions prior to 2.9.4 when configured with the SQLAlchemy data layer backend. The flaw exists in the /project/element update flow, where an authenticated client can supply a user-controlled URL value within an Element. This triggers the SQLAlchemy element creation logic to perform an outbound HTTP GET request to the specified URL.
An authenticated attacker with low privileges can exploit this vulnerability over the network with low complexity and no user interaction required. By controlling the URL, they can direct the Chainlit server to issue arbitrary HTTP requests to internal network services or cloud metadata endpoints, such as instance metadata services. The retrieved responses are then stored via the configured storage provider, enabling potential data exfiltration. The CVSS v3.1 base score is 7.7 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N), reflecting high confidentiality impact due to the changed scope.
The Chainlit project addresses this issue in version 2.9.4, as detailed in their GitHub release notes. Additional guidance appears in advisories from Vulncheck, which covers the SQLAlchemy data layer SSRF via project elements, and Zafran Security, discussing critical vulnerabilities in the AI framework including data exposure and cloud takeover risks.
This vulnerability impacts Chainlit, a framework used for building conversational AI applications, underscoring SSRF risks in AI/ML deployment environments particularly for internal network pivoting and metadata access.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-3347
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.3.6V1.5.3V5.3.2V10.4.7
Mitigating Controls (NIST 800-53 r5) AI
Information flow enforcement can restrict which destinations the server is allowed to contact on behalf of users.
Input validation directly stops untrusted URLs from being accepted and fetched without destination checks.
Boundary protection limits the network reach of server-initiated requests even if SSRF occurs.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure development practices directly include input validation and destination allow-listing that prevent SSRF.
Runtime monitoring of web applications and services can detect anomalous outbound requests indicative of SSRF.
Vulnerability identification processes can discover and record SSRF flaws in web applications.
Network segmentation and egress controls can limit the damage from successful SSRF requests.