Chainlit on alert: two critical failures allow you to read files and cause SSRF to compromise cloud environments

Chainlit, a highly used open source tool to mount conversational interfaces and orchestrate IA components, has been the focus of a security alert that should turn on the alarms in organizations that have it exposed to the Internet. Zafran Labs researchers have identified two high-gravity failures that, combined, allow from reading any file accessible by the server to forcing outgoing requests to probe internal networks, opening the door to leaks of secrets and side movements in cloud environments. You can read the technical report of the discoverers in the publication of Zafran Labs: ChainLeak - Zafran Labs.

Before entering into technical details, it is appropriate to put in context the magnitude of the problem: Chainlit is a project with a remarkable use in Python, accumulating around 700,000 monthly downloads in PyPI and are often found in deployments of companies and academic environments that expose chat interfaces to users or integrate assistants in productive flows. Its nature as "front + backend" for chatbots and its integration with authentication, sessions and cloud deployment make it an attractive vector when it is poorly configured or vulnerable.

The two above-mentioned failures have received official identifiers in the NIST vulnerability base: the first, an arbitrary reading of files, appears as CVE-2026-22218, and the second, a SSRF-type vulnerability that allows the server to make requests to URLs controlled by the attacker, appears as CVE-2026-22219.

In practical terms, CVE-2026-22218 is exploited through an extension point for custom elements that Chainlit exposes in the route / project / element: an attacker can send an element with a 'path' field and cause the server to copy the file of that route to the attacker session, without the content going through sufficient checks. The effect is that a malicious actor can read files that the Chainlit process has access to, including API keys, cloud account credentials, source code, configuration files, local SQLite databases and authentication secrets.

For its part, CVE-2026-22219 affects installations that use the SQLAlchemy-based data layer. There the mechanism allows a custom element to include a 'url' field and force the server to make a GET request to that direction and store the answer. This ability to make outgoing requests is translated into a classic SSRF: from listing and consulting internal services and cloud metadata to bringing answers that can then be downloaded by the attacker from endpoints of elements.

The most worrying thing shown by Zafran Labs is that both failures can be chained up: SSRF, for example, allows access to infrastructure metadata or internal endpoints that return credentials, while arbitrary reading can extract critical files once the attacker has climbed information. In their demonstration, researchers describe a flow that culminates in full commitment and lateral movements in cloud environments, a critical scenario for any organization that depends on identities and secrets for resource orchestration.

The discoverers informed the Chainlit maintainers on 23 November 2025 and received a reply on 9 December 2025; the corrections were published on 24 December 2025 in the version 2.9.4. Since then, the branch has continued to receive maintenance and the most recent stable version is the 2.9.6. The immediate and priority recommendation for affected equipment is to update to 2.9.4 or, preferably, to the most recent version available.

If by compatibility restrictions it is not possible to apply the patch immediately, there are compensatory measures that reduce the risk: run Chainlit instances with strict file permissions and minimum confidence service accounts, block the outgoing traffic from the containers or machines that host Chainlit by network rules or output proxys, protect endpoints with strong authentication and WAF, disable or restrict the functionality that allows you to upload or record custom elements, and audit access and login in search of anomalous patterns. It is also crucial to rotate keys and secrets that could have been exposed and to review internal systems that can be consulted through SSRF.

Beyond immediate mitigation, this incident highlights security lessons that are applicable to any platform that exposes interfaces to run or process user-sent content. Strict validation of inputs, minimum privilege principles and egress controls (network output) must be part of the architecture when deploying software that supports extensions or elements defined by third parties. In addition, incorporating dynamic security tests and code reviews for points that treat file routes or URL fetting helps to identify similar fault classes before they reach production.

For incident response teams, it is appropriate to generate commitment indicators related to the above routes and endpoints, to review access log to / project / element and other endpoints of elements, to check whether sensitive files have been downloaded and to audit unusual outgoing traffic from the affected instances. If suspicious activity is detected, it is wise to isolate the instance, capture memory and file system for analysis and proceed to the rotation of credentials with possible impact on dependent services.

The security community and those responsible for cloud platforms should note how "friendly" infrastructure components for developers, such as IA chat frames, can become critical vectors if they are not properly isolated. In this regard, it is useful to review guidelines and good practices on SSRF mitigation and protection of secrets: resources such as CVE pages and technical reports provide verifiable context, for example in the NVD entry on these vulnerabilities and in the Zafran Labs technical note mentioned above.

Finally, for those who use Chainlit in production, the path is clear: update the parcheed version as soon as possible, check for potential exposure, rotate secrets and tighten network controls and permissions. The speed of applying these steps significantly reduces the exposure window against attackers who could exploit known and documented failures. Maintaining an up-to-date inventory of exposed software and its dependencies, and subscribing to an early notification process to internal maintainers and equipment, will help to address future vulnerabilities with less impact.