https://bugzilla.redhat.com/show_bug.cgi?id=2513048
Bug ID: 2513048
Summary: CVE-2026-60074 perl-Date-Manip: Date::Manip: Incorrect
date parsing leads to logic errors [fedora-all]
Product: Fedora
Version: rawhide
Status: NEW
Whiteboard: {"flaws": ["83e88e88-ce72-4289-9c20-fd726272c05c"]}
Component: perl-Date-Manip
Keywords: Security, SecurityTracking
Severity: medium
Priority: medium
Assignee: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
CC: [email protected], [email protected],
[email protected], [email protected],
[email protected]
Blocks: 2509488
Target Milestone: ---
Classification: Fedora
Disclaimer: Community trackers are created by Red Hat Product Security team on
a best effort basis. Package maintainers are required to ascertain if the flaw
indeed affects their package, before starting the update process.
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2513048
Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202513048%23c0
--
_______________________________________________
perl-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
