CVE-2026-60074: CWE-1289 Improper Validation of Unsafe Equivalence in Input
Date::Manip versions through 7.00 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.
AI Analysis
Technical Summary
Date::Manip versions through 6.99 for Perl use regexes that match Unicode decimal digits (\p{Nd}) instead of strictly ASCII digits ([0-9]) when parsing year, month, and day fields. The numeric validation checks only numeric ranges after Perl numifies the strings, which truncates at the first non-ASCII digit. This allows crafted inputs with non-ASCII decimal digits to pass validation but produce corrupted dates. Time fields are not affected due to explicit ASCII digit matching. The flaw can cause callers passing untrusted strings to ParseDate() or Date::Manip::Date->parse() to receive dates that differ from the input without parse errors, potentially bypassing date-based logic.
Potential Impact
An attacker or malformed input can cause Date::Manip to return incorrect date values without triggering parse errors. This silent corruption can affect any logic relying on accurate date parsing, such as expiry checks or retention windows, potentially leading to incorrect application behavior or security bypasses. There is no direct confidentiality or integrity impact stated, but availability impact is high due to possible logic failures.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, avoid passing untrusted input containing non-ASCII decimal digits to Date::Manip parsing functions or implement input validation to restrict date strings to ASCII digits only.
CVE-2026-60074: CWE-1289 Improper Validation of Unsafe Equivalence in Input
Description
Date::Manip versions through 7.00 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.
CVSS v3.1
Score 7.5high
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Date::Manip versions through 6.99 for Perl use regexes that match Unicode decimal digits (\p{Nd}) instead of strictly ASCII digits ([0-9]) when parsing year, month, and day fields. The numeric validation checks only numeric ranges after Perl numifies the strings, which truncates at the first non-ASCII digit. This allows crafted inputs with non-ASCII decimal digits to pass validation but produce corrupted dates. Time fields are not affected due to explicit ASCII digit matching. The flaw can cause callers passing untrusted strings to ParseDate() or Date::Manip::Date->parse() to receive dates that differ from the input without parse errors, potentially bypassing date-based logic.
Potential Impact
An attacker or malformed input can cause Date::Manip to return incorrect date values without triggering parse errors. This silent corruption can affect any logic relying on accurate date parsing, such as expiry checks or retention windows, potentially leading to incorrect application behavior or security bypasses. There is no direct confidentiality or integrity impact stated, but availability impact is high due to possible logic failures.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, avoid passing untrusted input containing non-ASCII decimal digits to Date::Manip parsing functions or implement input validation to restrict date strings to ASCII digits only.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- CPANSec
- Date Reserved
- 2026-07-08T10:28:02.310Z
- State
- PUBLISHED
Threat ID: 6a6b5ad09c2644c7f82c5446
Added to database: 07/30/2026, 14:08:16 UTC
Last enriched: 08/06/2026, 16:39:11 UTC
Last updated: 09/12/2026, 10:01:32 UTC
Views: 66
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.