ux-live-component: Format-less date LiveProps parsed with the permissive DateTime constructor
Impact
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.
Source excerpt · OSVAffected packages
Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.
| Affected range | Recorded fix |
|---|---|
| From 2.8.0 before 2.36.0Ecosystem versions | 2.36.0 |
| From 3.0.0 before 3.1.0Ecosystem versions | 3.1.0 |
Version evidence: OSV · GHSA-89g7-22c8-3j23
View original version evidence (48 explicit versions)
Original source 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.
References
- Security advisory github.com/symfony/ux/security/advisories/GHSA-89g7-22c8-3j23
- Patch github.com/symfony/ux/commit/d24d78fda6df2d5964312255943ebf3a217b79a2
- Security advisory github.com/FriendsOfPHP/security-advisories/blob/master/symfony/ux-live-component/CVE-2026-49208.yaml
- Source reference github.com/symfony/ux