### 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](https://github.com/symfony/ux/commit/d24d78fda6df2d5964312255943ebf3a217b79a2) 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](https://github.com/symfony/ux/commit/d24d78fda6df2d5964312255943ebf3a217b79a2) 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.
Update symfony/ux-live-component to 2.36.0; symfony/ux-live-component to 3.1.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanux-live-component: Format-less date LiveProps parsed with the permissive DateTime constructor affects symfony/ux-live-component (composer), symfony/ux-live-component (composer). Severity is medium. ### 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](https://github.com/symfony/ux/commit/d24d78fda6df2d5964312255943ebf3a217b79a2) 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.
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| symfony/ux-live-componentcomposer | >=2.8.0,<2.36.0 | 2.36.0 |
| symfony/ux-live-componentcomposer | >=3.0.0,<3.1.0 | 3.1.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate symfony/ux-live-component to 2.36.0; symfony/ux-live-component to 3.1.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanux-live-component: Format-less date LiveProps parsed with the permissive DateTime constructor affects symfony/ux-live-component (composer), symfony/ux-live-component (composer). Severity is medium. ### 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](https://github.com/symfony/ux/commit/d24d78fda6df2d5964312255943ebf3a217b79a2) 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.
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| symfony/ux-live-componentcomposer | >=2.8.0,<2.36.0 | 2.36.0 |
| symfony/ux-live-componentcomposer | >=3.0.0,<3.1.0 | 3.1.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard