CVE-2026-49212

Symfony UX is a JavaScript ecosystem for Symfony. From 2.8.0 until 2.36.0 and 3.1.0, the HMAC computed by Symfony\UX\LiveComponent\LiveComponentHydrator covered only sorted prop key/value pairs and did not include the component name, the slot identifier (props vs propsFromParent), or request context, allowing a signed blob minted for one component or slot to be replayed in another and set a read-only prop on a target component. This issue is fixed in versions 2.36.0 and 3.1.0.

Symfony UX is a JavaScript ecosystem for Symfony. From 2.8.0 until 2.36.0 and 3.1.0, the HMAC computed by Symfony\UX\LiveComponent\LiveComponentHydrator covered only sorted prop key/value pairs and did not include the component name, the slot identifier (props vs propsFromParent), or request context, allowing a signed blob minted for one component or slot to be replayed in another and set a read-only prop on a target component. This issue is fixed in versions 2.36.0 and 3.1.0.

Description

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 target component to a value they were only ever allowed to choose as a writable prop on another component.

Resolution

The HMAC is now bound to its context: the component name and a slot identifier are included in the pre-image before hashing. Two constants (CHECKSUM_SLOT_PROPS and CHECKSUM_SLOT_PROPS_FROM_PARENT) name the two slots, and calculateChecksum(), verifyChecksum(), addChecksumToData(), and ChildComponentPartialRenderer thread these values through. Cross-component and cross-slot replays no longer verify.

The patch for this issue is available here 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.

Symfony UX is a JavaScript ecosystem for Symfony. From 2.8.0 until 2.36.0 and 3.1.0, the HMAC computed by Symfony\UX\LiveComponent\LiveComponentHydrator covered only sorted prop key/value pairs and did not include the component name, the slot identifier (props vs propsFromParent), or request context, allowing a signed blob minted for one component or slot to be replayed in another and set a read-only prop on a target component. This issue is fixed in versions 2.36.0 and 3.1.0.

Symfony UX is a JavaScript ecosystem for Symfony. From 2.8.0 until 2.36.0 and 3.1.0, the HMAC computed by Symfony\UX\LiveComponent\LiveComponentHydrator covered only sorted prop key/value pairs and did not include the component name, the slot identifier (props vs propsFromParent), or request context, allowing a signed blob minted for one component or slot to be replayed in another and set a read-only prop on a target component. This issue is fixed in versions 2.36.0 and 3.1.0.

Description

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 target component to a value they were only ever allowed to choose as a writable prop on another component.

Resolution

The HMAC is now bound to its context: the component name and a slot identifier are included in the pre-image before hashing. Two constants (CHECKSUM_SLOT_PROPS and CHECKSUM_SLOT_PROPS_FROM_PARENT) name the two slots, and calculateChecksum(), verifyChecksum(), addChecksumToData(), and ChildComponentPartialRenderer thread these values through. Cross-component and cross-slot replays no longer verify.

The patch for this issue is available here 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.