Date::Manip versions through 7.00 improperly accept Unicode decimal digits when parsing year, month, or day fields, because the regex constructs use the \d shorthand which matches any Unicode decimal digit (\p{Nd}) rather than strictly [0-9]. The check routine then validates the captured fields with numeric comparisons alone and numifies them with Perl’s arithmetic conversion ($y+0). Oberly, a field beginning with ASCII digits and followed by a non‑ASCII digit is truncated to the ASCII prefix, satisfying the range tests and yielding an unintended date value. This flaw exemplifies CWE-1289 and CWE-681, where numeric inputs are not properly validated or correctly converted. An attacker providing an untrusted date string to ParseDate() or Date::Manip::Date->parse() can obtain a corrupted date that differs from the input, with no parse error. If that date is used to gate logic such as an expiry check or a retention window, the shift can allow the attacker to bypass limits or extend data retention undetected.

The vulnerability affects all releases of the SBECK Date::Manip Perl module up to and including 7.00. Any Perl application that uses this module to parse untrusted date strings in that version range is potentially vulnerable.

The EPSS score of <1% indicates a very low probability that this issue has already been exploited, but the CVSS score of 7.5 reflects a high severity impact on confidentiality, integrity and availability when the corrupted date feeds into critical logic. The vulnerability is not listed in the CISA KEV catalog. If an attacker can supply an untrusted date string to a vulnerable application, they may gain an exploitable logic bypass by leveraging the shifted timestamp. The described behavior provides a clear attack path, although the practical exploitation may require control over the input string and a scenario where the corrupted date matters for business logic.