Insufficient HMAC context binding in Symfony UX LiveComponent enables cross-component state replay

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.

The affected package is symfony/ux-live-component in Symfony UX:

• 2.x branch: versions from 2.8.0 through versions before 2.36.0 are affected.
• 3.x branch: versions from 3.0.0 through versions before 3.1.0 are affected.
• The advisory confirms 2.36.0 as the fix for the 2.x branch and 3.1.0 as the fix for the 3.x branch.

The status of branches or versions outside these stated ranges should not be inferred from this advisory.

Symfony UX LiveComponent protects read-only props with an HMAC when component state is sent to the browser and returned to the server. In Symfony\UX\LiveComponent\LiveComponentHydrator, the HMAC input previously covered only sorted prop key/value pairs. It omitted the component name, the props or propsFromParent slot identifier, and request context, while one application-wide secret was used for every component.

This allows a signed blob minted for one component to be replayed to another when the relevant key names match, or to be moved between the two slots. An attacker can use a value that was valid as a writable prop in one component to set a read-only prop on a target component. The practical preconditions depend on whether the application uses the affected components, props, and slots; the reviewed fix description does not establish that request context is separately included in the checksum.

The vulnerability is reachable over the network. The attack characteristics supplied with the record describe exploitation without authentication or user interaction and with low complexity.

At a high level, an attacker needs a signed blob issued by the server and a compatible target component or slot in which to replay it. This is not a complete exploitation guide because the advisory does not disclose a payload, endpoint, or request sequence.

The supplied record does not establish exploitation in the wild or the availability of a public exploit. The reviewed advisory also does not identify a campaign, victim, or specific intrusion indicator.

The flaw allows a valid signed blob from one context to be accepted in another context, weakening verification of the data's origin and intended scope. The technical result is that a read-only prop on a target component may receive a value that the sender was only allowed to choose in another component.

The affected scope is limited to components and slots with data suitable for replay. Organisational consequences may include altered state or business decisions when the application relies on the prop to enforce workflow logic, but the advisory does not define a specific business outcome. The record does not identify an impact to data confidentiality or service availability.

• Integrity risk: The server may accept an attacker-selected value for a prop that the application treats as read-only.
• If that prop influences business decisions, session state, or workflow processing, application data or behavior may change outside the intended authorization model. The precise consequence depends on how the affected prop is used by the application.
• The record does not identify data disclosure or service interruption. The primary concern is loss of trust in the integrity of component state.

1. Upgrade symfony/ux-live-component to 2.36.0 when using the 2.x branch, or to 3.1.0 when using the 3.x branch. Use the fixed release matching the deployed branch and verify the resulting dependency lockfile.
2. After upgrading, reload pages that may still contain payloads signed before the upgrade. The fix changelog notes that previously signed payloads may no longer validate after the checksum calculation changes.
3. Review components with read-only props and child components using propsFromParent so that affected business flows receive post-upgrade validation.
4. The reviewed advisory documents the patch but no alternate mitigation. Renaming props or hiding endpoints should not be treated as a substitute for upgrading.

1. Inventory Composer dependencies and identify the deployed symfony/ux-live-component version in each application, container, and release artifact.
2. Review source code for LiveComponentHydrator, read-only #[LiveProp] properties, and child components that receive propsFromParent data.
3. Identify applications that accept signed component state from the browser, then prioritize components whose prop names or structures overlap with other components.
4. No product-specific IOC or log signature is documented in the advisory. Existing application telemetry can be reviewed for unusual replay patterns or hydration-verification failures as a precaution, but the absence of such logs does not prove safety.