https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 08:14:45 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-339077 EUVD-2026-339077 https://cve.radiocsirt.org/vuln/euvd-2026-339077 https://cve.radiocsirt.org/vuln/fkie_cve-2026-49208 <p>Symfony UX is a JavaScript ecosystem for Symfony. From 2.8.0 until 2.36.0 and 3.1.0, when a #[LiveProp] is typed as DateTimeInterface and no explicit format is configured, Symfony\UX\LiveComponent\LiveComponentHydrator::hydrateObjectValue() falls back to new $className($value), allowing client-supplied relative strings such as now, tomorrow, or +10 years to move a writable, format-less date prop past time-based business logic checks. This issue is fixed in versions 2.36.0 and 3.1.0.</p> <p>Symfony UX is a JavaScript ecosystem for Symfony. From 2.8.0 until 2.36.0 and 3.1.0, when a #[LiveProp] is typed as DateTimeInterface and no explicit format is configured, Symfony\UX\LiveComponent\LiveComponentHydrator::hydrateObjectValue() falls back to new $className($value), allowing client-supplied relative strings such as now, tomorrow, or +10 years to move a writable, format-less date prop past time-based business logic checks. This issue is fixed in versions 2.36.0 and 3.1.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-49208 https://cve.radiocsirt.org/vuln/ghsa-89g7-22c8-3j23 <p><strong>Affected:</strong> Packagist: symfony/ux-live-component</p> <p>### Description</p> <p>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 `&#34;now&#34;`, `&#34;tomorrow&#34;`, or `&#34;+10 years&#34;`, 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.</p> <p>### Resolution</p> <p>`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&#39;t valid RFC 3339 are now rejected, which is consistent with how a format-configured prop already behaved.</p> <p>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).</p> <p>### Credits</p> <p>Symfony would like to thank Pascal Cescon for reporting the issue and Hugo Alliaume for providing the fix.</p> <p><strong>Affected:</strong> Packagist: symfony/ux-live-component</p> <p>### Description</p> <p>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 `&#34;now&#34;`, `&#34;tomorrow&#34;`, or `&#34;+10 years&#34;`, 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.</p> <p>### Resolution</p> <p>`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&#39;t valid RFC 3339 are now rejected, which is consistent with how a format-configured prop already behaved.</p> <p>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).</p> <p>### Credits</p> <p>Symfony would like to thank Pascal Cescon for reporting the issue and Hugo Alliaume for providing the fix.</p> https://cve.radiocsirt.org/vuln/ghsa-89g7-22c8-3j23