Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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, 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…
Recommended action: Upgrade to 3.1.0 or 2.36.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In symfony/ux-live-component, a component's server-side state is exposed to the browser as a set of props (#[LiveProp]-annotated properties). Props marked writable: true can be freely changed by the client. Read-only props are round-tripped to the browser and back, and their integrity is protected by an HMAC so the client cannot tamper with them. Child components additionally receive a propsFromParent blob, also HMAC-signed. The HMAC computed by Symfony\UX\LiveComponent\LiveComponentHydrator covered only the sorted prop key/value pairs. It didn't include the component name, the slot identifier (props vs propsFromParent), or any request context, and a single application-wide secret is used for every component. A signed blob the server minted for component A is therefore a valid signature for component B if the key names happen to match, and a props blob can be replayed in the propsFromParent slot (or the reverse). An attacker can use this to set a read-only prop on a…
Recommended action: Upgrade to 3.1.0 or 2.36.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Symfony\UX\LiveComponent\Util\ChildComponentPartialRenderer::createHtml() interpolates the $childTag argument directly into the HTML output as a tag name, without escaping or validation. The value originates from client-controlled JSON (children[id].tag) parsed by LiveComponentSubscriber and propagated through InterceptChildComponentRenderSubscriber, so an attacker who can reach the Live Component endpoint can inject arbitrary HTML, including <script tags, on any re-render of a Live Component that contains at least one child component. In the default configuration, the Live Component endpoint is gated by an Accept: application/vnd.live-component+html request-header check that cannot be set cross-origin without a CORS preflight, so the issue is primarily a defense-in-depth gap. It becomes directly exploitable on applications that have relaxed CORS to allow this header from untrusted origins, or that have been pivoted from another same-origin XSS. Resolution…
Recommended action: Upgrade to 3.1.0 or 2.36.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Symfony\UX\LiveComponent\Controller\BatchActionController::invoke() iterates over the client-supplied actions array and issues a full HttpKernel sub-request for each entry (event subscribers, validators, Doctrine, rendering). The array size is never bounded, so an authenticated client can submit a single batch request containing thousands of actions and exhaust CPU, memory, and database connections on the application server. Resolution BatchActionController now enforces an upper bound of 50 actions per batch request (MAXACTIONSPERBATCH) and rejects larger payloads up front with a BadRequestHttpException. The matching JavaScript backend was also updated to split larger client-side batches into multiple requests so legitimate usage isn't affected. The patch for this issue is available here for branch 2.x (and forward-ported to 3.x). Credits Symfony would like to thank Pascal Cescon for reporting the issue and Hugo Alliaume for providing the fix.
Recommended action: Upgrade to 3.1.0 or 2.36.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a #[LiveProp] is typed as a DateTimeInterface and no explicit format is configured, Symfony\UX\LiveComponent\LiveComponentHydrator::hydrateObjectValue() falls back to new $className($value). The DateTime / DateTimeImmutable constructors accept relative strings such as "now", "tomorrow", or "+10 years", so a writable, format-less date prop can be pushed to an arbitrary point in time by the client. Components that rely on a date prop to gate time-based business logic can be moved past those checks by a frontend payload that no maintainer would consider a valid date. Resolution hydrateObjectValue() now parses format-less date props strictly with createFromFormat(DateTimeInterface::RFC3339, ...), matching the format already emitted by dehydrateObjectValue(). Normal round-trips are unaffected; only inputs that aren't valid RFC 3339 are now rejected, which is consistent with how a format-configured prop already behaved. The patch for this issue is available here for branch…
Recommended action: Upgrade to 3.1.0 or 2.36.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Rendering {{ attributes }} or using any method that returns a ComponentAttributes instance (e.g. only(), defaults(), without()) ouputs attribute values directly without escaping. If these values are unsafe (e.g. contain user input), this can lead to HTML attribute injection and XSS vulnerabilities. Patches The issue is fixed in version 2.25.1 of symfony/ux-twig-component by using Twig's EscaperRuntime to properly escape HTML attributes in ComponentAttributes. If you use symfony/ux-live-component, you must also update it to 2.25.1 to benefit from the fix, as it reuses the ComponentAttributes class internally. Workarounds Until you can upgrade, avoid rendering {{ attributes }} or derived objects directly if it may contain untrusted values. Instead, use {{ attributes.render('name') }} for safe output of individual attributes. References GitHub repository: symfony/ux
Recommended action: Upgrade to 2.25.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.