EUVD-2026-45211
GHSA-89g7-22c8-3j23
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network endpoint accessible to any client; no authentication required by the vulnerability itself; integrity high due to business logic bypass; minor confidentiality impact from inferred internal temporal state.
Primary rating from Vendor (https://github.com/symfony/ux).
CVSS VectorVendor: https://github.com/symfony/ux
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
Business logic bypass in Symfony UX LiveComponent (symfony/ux-live-component) allows any client to manipulate writable #[LiveProp] date fields to arbitrary points in time by submitting relative PHP date strings such as '+10 years' or 'tomorrow' - inputs the application would never generate legitimately. Applications that gate time-sensitive features (trial periods, discount windows, scheduling logic, subscription expiry) on these date props are exposed to unauthorized temporal state manipulation. No public exploit has been identified and no CVSS has been assigned by the vendor, but the attack surface exists wherever writable format-less DateTimeInterface props are present in security-relevant components.
Technical ContextAI
Symfony UX LiveComponent (pkg:composer/symfony/ux-live-component) is a PHP library enabling reactive server-rendered UI components in Symfony applications. Component state is serialized ('dehydrated') to the frontend and deserialized ('hydrated') on each update request via LiveComponentHydrator. When a property is annotated #[LiveProp(writable: true)] and typed as DateTime or DateTimeImmutable without an explicit format string, the hydrateObjectValue() method previously fell back to new $className($value) - PHP's native DateTime constructor - which accepts not just ISO timestamps but also relative expressions like 'now', 'tomorrow', 'last monday', and '+10 years'. The root cause (CWE-20: Improper Input Validation) is that the hydrator did not enforce strict format parsing on the inbound path when no format was configured, even though dehydrateObjectValue() already emits values in RFC 3339 format. The patch commit d24d78fda6df2d5964312255943ebf3a217b79a2 unifies both paths to use DateTime::createFromFormat(DateTimeInterface::RFC3339, $value), making format-less props behave identically to explicitly format-configured props and rejecting all non-RFC-3339 inputs.
RemediationAI
Upgrade symfony/ux-live-component to version 2.36.0 for 2.x users or 3.1.0 for 3.x users; these are the vendor-confirmed fixed versions per GHSA-89g7-22c8-3j23, with the patch available at https://github.com/symfony/ux/commit/d24d78fda6df2d5964312255943ebf3a217b79a2. If immediate upgrade is not possible, the most targeted workaround is to add an explicit format parameter to all writable DateTimeInterface LiveProps (e.g., #[LiveProp(writable: true, format: DateTimeInterface::RFC3339)]), which already triggered strict parsing in the old code and exactly matches the serialized output format - making this a safe, non-breaking change. Alternatively, set writable: false on date props used in security-sensitive logic and handle updates through explicit server-side actions, which eliminates the attack surface entirely at the cost of requiring refactoring. Post-hydration validation of the date value (e.g., asserting it falls within an expected range) is a third option but introduces application-layer complexity.
Same weakness CWE-20 – Improper Input Validation
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today