ux-live-component: Format-less date LiveProps parsed with the permissive DateTime constructor
Description
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.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
1Patches
Vulnerability mechanics
Root cause
"Missing input validation in `LiveComponentHydrator::hydrateObjectValue()` allowed PHP's `DateTime` constructor to accept relative-time strings from the client."
Attack vector
An attacker sends a crafted frontend payload to a Symfony UX Live Component that has a writable `#[LiveProp]` typed as `DateTime` or `DateTimeImmutable` without an explicit `format` option. Because the old code passed the client-supplied string directly to `new $className($value)`, the attacker can use relative-time strings such as `"now"`, `"tomorrow"`, or `"+10 years"` to set the date prop to an arbitrary point in time [ref_id=2]. This allows bypassing time-based business logic that gates on that date prop. The attack requires no authentication beyond normal component access and is delivered over the network via the component's hydration endpoint.
Affected code
The vulnerability resides in `LiveComponentHydrator::hydrateObjectValue()` within `src/LiveComponent/src/LiveComponentHydrator.php`. When a `#[LiveProp]` is typed as `DateTimeInterface` and no explicit `format` is configured, the method fell back to `new $className($value)`, which allowed relative date strings like `"+10 years"` or `"tomorrow"` to be accepted from the client. The patch changes this to use `createFromFormat(DateTimeInterface::RFC3339, ...)` for format-less date props, matching the format already emitted by `dehydrateObjectValue()`.
What the fix does
The patch replaces the fallback `new $className($value)` with `$className::createFromFormat(DateTimeInterface::RFC3339, $value)` when no explicit format is configured [patch_id=6624352]. This enforces strict RFC 3339 parsing, so relative strings like `"+10 years"` or `"tomorrow"` now cause a `BadRequestHttpException` instead of being silently accepted. Normal round-trips are unaffected because `dehydrateObjectValue()` already emits RFC 3339 strings, and the new code matches that format exactly.
Preconditions
- configThe component must have a `#[LiveProp]` typed as `DateTime` or `DateTimeImmutable` with `writable: true` and no explicit `format` option.
- networkThe attacker must be able to send HTTP requests to the component's hydration endpoint (typically the frontend user).
Generated on Jun 19, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4News mentions
0No linked articles in our index yet.