CVE-2026-49215: Symfony LiveComponent: CSRF bypass via safelisted header

GHSA-4m4j-hmqq-3gxm LOW
Published June 19, 2026
CISO Take

symfony/ux-live-component versions 2.22.0–2.35.x incorrectly relied on the CORS-safelisted Accept header as sole CSRF protection for server-side state-mutating LiveAction endpoints, allowing any malicious webpage to forge authenticated cross-origin requests against a victim's active session without triggering a browser preflight. With 5,435 downstream dependents, AI/ML web dashboards, model management consoles, and LLM-powered Symfony applications are exposed to unauthorized server-side mutations — triggering privileged actions, altering configurations, or initiating sensitive operations under a victim's identity. Exploitation risk is substantially mitigated in default Symfony deployments by SameSite=Lax cookie behavior, but applications using SameSite=None, permissive CORS policies, or reachable from a same-origin pivot remain fully vulnerable. Upgrade to symfony/ux-live-component 2.36.0 and immediately audit session cookie SameSite settings for any deployment where LiveComponent endpoints expose sensitive operations.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Low-to-medium risk overall, but strongly context-dependent. Default Symfony configurations with SameSite=Lax cookies reduce realistic exploitability to near-zero for most deployments; risk escalates sharply for applications that explicitly set SameSite=None or implement permissive CORS. No EPSS score is available, no public exploit code exists, and the CVE is absent from CISA KEV. However, the conceptual simplicity of CSRF exploitation — trivial to construct a malicious fetch() — and the breadth of 5,435 downstream dependents mean that non-default cookie configurations may be widespread in production. AI/ML applications using LiveComponent for interactive model interfaces, real-time inference UIs, or administrative dashboards face elevated risk if those endpoints expose privileged mutations.

How does the attack unfold?

Victim Lure
Attacker delivers a malicious webpage to an authenticated Symfony application user via phishing or drive-by redirection targeting AI system administrators.
AML.T0078
CSRF Header Bypass
Malicious page issues a cross-origin fetch() with the CORS-safelisted Accept: application/vnd.live-component+html header; browser appends session cookies and no preflight is triggered, bypassing the flawed CSRF check entirely.
AML.T0049
Unauthorized Action Execution
Symfony server processes the forged request as legitimate and executes the targeted #[LiveAction] method under the victim's identity, enabling unauthorized state mutation such as modifying AI pipeline configuration, triggering retraining jobs, or escalating privileges.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Anthropic Python composer >= 2.22.0, < 2.36.0 2.36.0
3.6K 5.4K dependents Pushed 9d ago 94% patched ~1d to patch Full package profile →

Do you use Anthropic Python? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

5 steps
  1. Patch immediately: upgrade symfony/ux-live-component to 2.36.0. The bundled Stimulus client already sends X-Requested-With on every LiveComponent request, so standard clients are unaffected post-patch.

  2. Audit SameSite settings: confirm all session cookies use SameSite=Lax (Symfony default) or SameSite=Strict — any deployment using SameSite=None is fully exposed until patched.

  3. Review LiveAction surface: audit all #[LiveAction]-annotated methods for sensitive operations (state mutations, privilege escalation, data access, pipeline triggers).

  4. Post-patch CORS: cross-origin callers that legitimately invoke LiveComponent endpoints must add X-Requested-With to their CORS Access-Control-Allow-Headers.

  5. Detection: inspect web server logs for cross-origin requests (Origin header differs from host) to LiveComponent endpoints lacking X-Requested-With during the vulnerable window (2.22.0–2.35.x).

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15(1) - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2 - Security and resilience of AI systems
NIST AI RMF
GOVERN-1.2 - Accountability and oversight structures for AI risk

Frequently Asked Questions

What is CVE-2026-49215?

symfony/ux-live-component versions 2.22.0–2.35.x incorrectly relied on the CORS-safelisted Accept header as sole CSRF protection for server-side state-mutating LiveAction endpoints, allowing any malicious webpage to forge authenticated cross-origin requests against a victim's active session without triggering a browser preflight. With 5,435 downstream dependents, AI/ML web dashboards, model management consoles, and LLM-powered Symfony applications are exposed to unauthorized server-side mutations — triggering privileged actions, altering configurations, or initiating sensitive operations under a victim's identity. Exploitation risk is substantially mitigated in default Symfony deployments by SameSite=Lax cookie behavior, but applications using SameSite=None, permissive CORS policies, or reachable from a same-origin pivot remain fully vulnerable. Upgrade to symfony/ux-live-component 2.36.0 and immediately audit session cookie SameSite settings for any deployment where LiveComponent endpoints expose sensitive operations.

Is CVE-2026-49215 actively exploited?

No confirmed active exploitation of CVE-2026-49215 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-49215?

1. Patch immediately: upgrade symfony/ux-live-component to 2.36.0. The bundled Stimulus client already sends X-Requested-With on every LiveComponent request, so standard clients are unaffected post-patch. 2. Audit SameSite settings: confirm all session cookies use SameSite=Lax (Symfony default) or SameSite=Strict — any deployment using SameSite=None is fully exposed until patched. 3. Review LiveAction surface: audit all #[LiveAction]-annotated methods for sensitive operations (state mutations, privilege escalation, data access, pipeline triggers). 4. Post-patch CORS: cross-origin callers that legitimately invoke LiveComponent endpoints must add X-Requested-With to their CORS Access-Control-Allow-Headers. 5. Detection: inspect web server logs for cross-origin requests (Origin header differs from host) to LiveComponent endpoints lacking X-Requested-With during the vulnerable window (2.22.0–2.35.x).

What systems are affected by CVE-2026-49215?

This vulnerability affects the following AI/ML architecture patterns: Web-based AI model management dashboards, Symfony-based ML pipeline control panels, LLM-powered interactive web applications, AI data annotation and labeling tools.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

Web-based AI model management dashboardsSymfony-based ML pipeline control panelsLLM-powered interactive web applicationsAI data annotation and labeling tools

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application
AML.T0078 Drive-by Compromise

Compliance Controls Affected

EU AI Act: Article 15(1)
ISO 42001: A.6.2
NIST AI RMF: GOVERN-1.2

What are the technical details?

Original Advisory

### Description When using `symfony/ux-live-component`, methods annotated with `#[LiveAction]` are invokable from the browser and mutate server-side state via AJAX. `Symfony\UX\LiveComponent\EventListener\LiveComponentSubscriber::isLiveComponentRequest()` gated these invocations on the presence of `Accept: application/vnd.live-component+html`, with a code comment stating that this acted as a CSRF protection. The `Accept` header is a [CORS-safelisted request header](https://fetch.spec.whatwg.org/#cors-safelisted-request-header), so a cross-origin `fetch()` can set it without triggering a preflight. The header therefore provided no CSRF protection. Any `#[LiveAction]` could be forged cross-origin against a victim's session. In practice the attack is mitigated by `SameSite=Lax` session cookies (Symfony's default), but applications using `SameSite=None`, `credentials: 'include'` with a permissive cookie policy, or that have been pivoted from another same-origin vector remained exposed. ### Resolution `isLiveComponentRequest()` now additionally requires the request header `X-Requested-With: XMLHttpRequest`. This header is **not** CORS-safelisted, so the browser issues a preflight `OPTIONS` request for any cross-origin attempt; Symfony does not advertise CORS for LiveComponent endpoints, the preflight fails, and the real request is blocked before it reaches the application. The bundled Stimulus client already sends `X-Requested-With` on every LiveComponent request (`RequestBuilder.ts`), so standard usage is unaffected. Cross-origin callers must add `X-Requested-With` to their CORS `Access-Control-Allow-Headers` allow-list. The patch for this issue is available [here](https://github.com/symfony/ux/commit/aed7493db2b4b7bf1f9c79b33cda544f06904b27) for branch 2.x (and forward-ported to 3.x). ### Credits Symfony would like to thank Anthropic (via Project Glasswing) for reporting the issue and Hugo Alliaume for providing the fix.

Exploitation Scenario

An attacker targeting an organization with a Symfony-based AI model management dashboard creates a malicious webpage and delivers it to an authenticated administrator via spearphishing. When the admin visits the page, JavaScript silently issues a cross-origin fetch() to the Symfony application with the Accept: application/vnd.live-component+html header — CORS-safelisted, so no preflight is triggered. The browser automatically appends the victim's session cookies. The Symfony server, finding the Accept header and lacking X-Requested-With validation in the vulnerable version, treats the request as legitimate and executes the targeted #[LiveAction] method — for example, triggering a model retraining job, elevating a user to admin, or modifying AI pipeline configuration — entirely under the victim's identity and without their awareness.

Weaknesses (CWE)

CWE-352 — Cross-Site Request Forgery (CSRF): The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.

  • [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330] Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]
  • [Implementation] Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.

Source: MITRE CWE corpus.

Timeline

Published
June 19, 2026
Last Modified
June 19, 2026
First Seen
June 19, 2026

Related Vulnerabilities