symfony/ux-live-component

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

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, 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 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.

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.

Description

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

ChildComponentPartialRenderer now validates $childTag against a strict HTML tag-name regex before interpolating it, and rejects any value that doesn't match. Anything that wouldn't be a valid HTML tag is dropped before reaching the response.

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.

Description

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 (MAX_ACTIONS_PER_BATCH) 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.

Description

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 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.

Description