The parse regexes capture year, month and day with the `\d` shorthand, which on a character string matches the whole Unicode decimal digit property `\p{Nd}` and not just `[0-9]`. Date::Manip::Base::check then validates the captured fields with numeric comparisons alone (`$y<1 || $y>9999`, `$m<1 || $m>12`, `$d<1 || $d>$days`), and _parse_check stores the numified fields (`$y+0`). Perl truncates a string at the first character that is not an ASCII digit, so a field whose leading characters are ASCII digits numifies to an in-range prefix and satisfies every test: a year field of three ASCII digits followed by U+0664 ARABIC-INDIC DIGIT FOUR numifies to 202, giving the year 0202, and one non-ASCII digit in the month or day field shifts those fields the same way. The hour, minute and second fields match explicit ASCII character classes (`0?[0-9]`, `[0-5][0-9]`) and do not shift, though a non-ASCII digit in a fractional hour or minute field truncates the fraction.
Any caller that passes an untrusted character string to ParseDate() or Date::Manip::Date->parse() can get back a date that differs from the string it parsed, with no parse error. Where the parsed date gates logic such as an expiry check or a retention window, the shift goes unnoticed.
Analysis
Analysis and contextual insights are available on OpenCVE Cloud.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| SBECK | Date::Manip | unaffected |
|
No data.
No data.
| Vendor | Product | Confidence | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Sbeck | Date::manip | 100% |
|
Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .
Vendor Workaround
No fixed release is available. Apply the patch, which spells the numeric field captures as `[0-9]` and requires the date fields to be ASCII digit strings, or reject untrusted date strings containing non-ASCII characters before parsing them.
Tracking
Sign in to view the affected projects.
No advisories yet.
Thu, 30 Jul 2026 15:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Sbeck
Sbeck date::manip |
|
| Vendors & Products |
Sbeck
Sbeck date::manip |
Thu, 30 Jul 2026 14:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Date::Manip versions through 6.99 for Perl return corrupted dates via non-ASCII decimal digits that pass the numeric range tests in check. The parse regexes capture year, month and day with the `\d` shorthand, which on a character string matches the whole Unicode decimal digit property `\p{Nd}` and not just `[0-9]`. Date::Manip::Base::check then validates the captured fields with numeric comparisons alone (`$y<1 || $y>9999`, `$m<1 || $m>12`, `$d<1 || $d>$days`), and _parse_check stores the numified fields (`$y+0`). Perl truncates a string at the first character that is not an ASCII digit, so a field whose leading characters are ASCII digits numifies to an in-range prefix and satisfies every test: a year field of three ASCII digits followed by U+0664 ARABIC-INDIC DIGIT FOUR numifies to 202, giving the year 0202, and one non-ASCII digit in the month or day field shifts those fields the same way. The hour, minute and second fields match explicit ASCII character classes (`0?[0-9]`, `[0-5][0-9]`) and do not shift, though a non-ASCII digit in a fractional hour or minute field truncates the fraction. Any caller that passes an untrusted character string to ParseDate() or Date::Manip::Date->parse() can get back a date that differs from the string it parsed, with no parse error. Where the parsed date gates logic such as an expiry check or a retention window, the shift goes unnoticed. | |
| Title | Date::Manip versions through 6.99 for Perl return corrupted dates via non-ASCII decimal digits that pass the numeric range tests in check | |
| Weaknesses | CWE-1289 | |
| References |
|
MITRE
Status: PUBLISHED
Assigner: CPANSec
Published:
Updated: 2026-07-30T13:42:03.068Z
Reserved: 2026-07-08T10:28:02.310Z
Link: CVE-2026-60074
Vulnrichment
No data.
NVD
No data.
Redhat
No data.
OpenCVE Enrichment
Updated: 2026-07-30T15:28:51Z
-
CWE-1289
Improper Validation of Unsafe Equivalence in Input