CVE-2026-82290: Chainlit IDOR lets users tamper

CISO Take

Chainlit, the widely used Python framework for building LLM chat interfaces, fails to verify that a feedback record actually belongs to the requesting user before honoring PUT and DELETE calls on it — any authenticated user can overwrite or delete another user's human-rating feedback simply by supplying a different feedback identifier. This isn't remote code execution or data theft, but it quietly corrupts the human-in-the-loop signal that teams rely on to evaluate and tune their deployed LLM applications, a harder failure to detect than an outage because the data just looks wrong rather than missing. The attack needs only a low-privilege authenticated account and no user interaction (CVSS 5.3, AC:H/PR:L/UI:N/C:N/I:H/A:N), there is no public exploit or scanner template, and it is not in CISA KEV, so this is not an emergency but is a genuine data-integrity risk for any multi-tenant Chainlit deployment using feedback for evaluation or RLHF-style loops. Upgrade Chainlit past 2.12.0 once a patched release is available, and in the meantime add server-side ownership checks (or a reverse-proxy rule scoping feedback endpoint access to the record's original author) and audit feedback tables for edits/deletes whose author doesn't match the session that created the record.

Sources:NVDGitHub AdvisoryATLASvulncheck.com

What is the risk?

Medium overall risk. The CVSS 5.3 score reflects high attack complexity and the need for an authenticated (even low-privilege) account, which limits opportunistic exploitation — this is not a pre-auth, wormable, or trivially scannable bug, there is no public PoC or Nuclei template, and it is absent from CISA KEV/SSVC, so active exploitation is unlikely in the near term. However, the confidentiality and availability impact of 'none' understate the real business risk: the integrity impact (I:H) means an insider or any signed-up user of a multi-tenant Chainlit deployment can silently corrupt human-rating data used to judge and improve an AI system, which is a slow-burn trust and model-quality risk rather than an immediate breach. Risk rises sharply for any deployment where feedback data feeds automated retraining, RLHF pipelines, or compliance/quality dashboards without independent validation.

How does the attack unfold?

Initial Access

Attacker registers or uses an existing low-privilege authenticated account on a multi-tenant Chainlit deployment.

AML.T0012

Discovery

Attacker observes or enumerates feedback record identifiers via the application's API traffic or predictable ID patterns.

Exploitation

Attacker sends PUT or DELETE requests to the feedback endpoints using arbitrary feedback IDs, which the server processes without verifying record ownership.

Impact

Other users' feedback/ratings are silently modified or deleted, corrupting the human-rating data used for model evaluation and quality decisions.

AML.T0059

Initial Access

Attacker registers or uses an existing low-privilege authenticated account on a multi-tenant Chainlit deployment.

AML.T0012

Discovery

Attacker observes or enumerates feedback record identifiers via the application's API traffic or predictable ID patterns.

Exploitation

Attacker sends PUT or DELETE requests to the feedback endpoints using arbitrary feedback IDs, which the server processes without verifying record ownership.

Impact

Other users' feedback/ratings are silently modified or deleted, corrupting the human-rating data used for model evaluation and quality decisions.

AML.T0059

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Chainlit	pip	—	No patch
12.5K41 dependentsPushed 1mo ago63% patched~74d to patchFull package profile →

Do you use Chainlit? You're affected.

How severe is it?

CVSS 3.1

5.3 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 27% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

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

What is the attack surface?

AVNetwork

ACHigh

PRLow

UINone

SUnchanged

CNone

IHigh

ANone

What should I do?

1 step

1) Patch: upgrade Chainlit beyond the affected 2.12.0 line as soon as a fixed release is published (track https://github.com/Chainlit/chainlit/issues/2975 and the VulnCheck advisory for the fix version). 2) Workaround: if you cannot patch immediately, add an authorization check in front of the feedback PUT/DELETE routes (reverse proxy rule or middleware) that confirms feedback.user_id == session.user_id before forwarding the request, or disable feedback editing/deletion entirely for non-admin roles. 3) Detection: audit the feedback/rating table for records whose updated_at/updated_by (or equivalent) doesn't match the original submitting user's session, and watch access logs for PUT/DELETE calls to /feedback/{id} referencing IDs the caller never created. 4) Data hygiene: if feedback data feeds retraining or compliance evidence, snapshot and diff it periodically until patched, and treat any pre-patch feedback history as potentially tampered when using it for model evaluation claims.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableNo

Technical Impactpartial

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

How is it classified?

Auth BypassFrameworkTraining DataAML.T0012- Valid Accounts AML.T0059- Erode Dataset Integrity

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.4 / A.9.3-Data for AI systems / AI system monitoring and evaluation

NIST AI RMF

MEASURE 2.5-AI system performance is monitored and evaluated using validated metrics

Frequently Asked Questions

What is CVE-2026-82290?

Chainlit, the widely used Python framework for building LLM chat interfaces, fails to verify that a feedback record actually belongs to the requesting user before honoring PUT and DELETE calls on it — any authenticated user can overwrite or delete another user's human-rating feedback simply by supplying a different feedback identifier. This isn't remote code execution or data theft, but it quietly corrupts the human-in-the-loop signal that teams rely on to evaluate and tune their deployed LLM applications, a harder failure to detect than an outage because the data just looks wrong rather than missing. The attack needs only a low-privilege authenticated account and no user interaction (CVSS 5.3, AC:H/PR:L/UI:N/C:N/I:H/A:N), there is no public exploit or scanner template, and it is not in CISA KEV, so this is not an emergency but is a genuine data-integrity risk for any multi-tenant Chainlit deployment using feedback for evaluation or RLHF-style loops. Upgrade Chainlit past 2.12.0 once a patched release is available, and in the meantime add server-side ownership checks (or a reverse-proxy rule scoping feedback endpoint access to the record's original author) and audit feedback tables for edits/deletes whose author doesn't match the session that created the record.

Is CVE-2026-82290 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-82290, increasing the risk of exploitation.

How to fix CVE-2026-82290?

1) Patch: upgrade Chainlit beyond the affected 2.12.0 line as soon as a fixed release is published (track https://github.com/Chainlit/chainlit/issues/2975 and the VulnCheck advisory for the fix version). 2) Workaround: if you cannot patch immediately, add an authorization check in front of the feedback PUT/DELETE routes (reverse proxy rule or middleware) that confirms `feedback.user_id == session.user_id` before forwarding the request, or disable feedback editing/deletion entirely for non-admin roles. 3) Detection: audit the feedback/rating table for records whose `updated_at`/`updated_by` (or equivalent) doesn't match the original submitting user's session, and watch access logs for PUT/DELETE calls to `/feedback/{id}` referencing IDs the caller never created. 4) Data hygiene: if feedback data feeds retraining or compliance evidence, snapshot and diff it periodically until patched, and treat any pre-patch feedback history as potentially tampered when using it for model evaluation claims.

What systems are affected by CVE-2026-82290?

This vulnerability affects the following AI/ML architecture patterns: LLM chat/UI frameworks, human feedback / RLHF pipelines, model evaluation pipelines.

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

CVE-2026-82290 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.34%.

What is the AI security impact?

Affected AI Architectures

LLM chat/UI frameworkshuman feedback / RLHF pipelinesmodel evaluation pipelines

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0059Erode Dataset Integrity

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.4 / A.9.3

NIST AI RMF: MEASURE 2.5

What are the technical details?

Original Advisory

Chainlit through 2.12.0 fails to validate ownership of feedback records in PUT and DELETE endpoints. Authenticated attackers can delete or modify other users' feedback by supplying arbitrary feedback identifiers, corrupting human-rating data used for model evaluation.

Exploitation Scenario

An organization deploys a Chainlit-based internal LLM assistant where any employee can sign up and rate responses via thumbs-up/down to help the ML team track model quality. A disgruntled or curious low-privilege employee authenticates normally, then inspects the feedback API calls made by the Chainlit front-end and notices the feedback ID is a simple, guessable identifier. They script a loop issuing PUT and DELETE requests against a range of feedback IDs, overwriting positive ratings from other users with negative ones (or deleting them outright) to make a competing team's RAG configuration look worse, or to erase evidence of a model regression before an internal review. Because the ML team trusts the feedback table as ground truth for their evaluation dashboard and potential RLHF fine-tuning pipeline, the tampering skews model comparisons and quality metrics without triggering any alert, since no authentication was bypassed and no system availability was affected.

Weaknesses (CWE)

CWE-639Authorization Bypass Through User-Controlled KeyPrimary CWE-639Authorization Bypass Through User-Controlled Key

CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

[Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
[Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Source: MITRE CWE corpus.