Hi,

The following vulnerabilities were published for libdate-manip-perl.

CVE-2026-60074[0]:
| 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.


CVE-2026-60075[1]:
| Date::Manip versions through 6.99 for Perl allow CPU exhaustion via
| quadratic backtracking in the unanchored time substitution in
| _parse_time.  _parse_time removes a time from anywhere in the string
| with the unanchored substitution `s/$timerx/ /`, where $timerx is an
| auto-generated alternation of time patterns reached through a
| leading `(?:$atrx|^|\s+)`. The engine therefore retries the match at
| every position of an interior whitespace run: at each start position
| the leading `\s+` consumes the rest of the run greedily, the time
| alternation fails because the run holds no digits, and the engine
| backtracks a space at a time across the run before advancing the
| start position, which is quadratic in the length of the run. No time
| need be present in the string for this to happen, only a long run of
| whitespace, and the parse time rises about fourfold for each
| doubling of the run: a few kilobytes of whitespace costs seconds of
| CPU per parse and tens of kilobytes costs minutes.  Any caller that
| passes an untrusted string of unbounded length to ParseDate(),
| Date::Manip::Date->parse() or ->parse_time() can be made to spend
| unbounded CPU in a single parse, a denial of service.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-60074
https://www.cve.org/CVERecord?id=CVE-2026-60074
https://lists.security.metacpan.org/cve-announce/msg/42266594/
[1] https://security-tracker.debian.org/tracker/CVE-2026-60075
https://www.cve.org/CVERecord?id=CVE-2026-60075
https://lists.security.metacpan.org/cve-announce/msg/42266599/

Regards,
Salvatore

Hello,

Bug #1143125 in libdate-manip-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libdate-manip-perl/-/commit/3a85e719c9bf6447ca22c549fea94c4d5c655c81
------------------------------------------------------------------------
Add 2 patches from CPANSec.

- Date::Manip: restrict numeric date fields to ASCII digits
  CVE-2026-60074
- Date::Manip: cap the length of a string handed to the parsers
  CVE-2026-60075

Closes: #1143125
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1143125

We believe that the bug you reported is fixed in the latest version of
libdate-manip-perl, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1143125@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
gregor herrmann <gregoa@debian.org> (supplier of updated libdate-manip-perl package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 30 Jul 2026 21:41:01 +0200
Source: libdate-manip-perl
Architecture: source
Version: 6.99-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
Changed-By: gregor herrmann <gregoa@debian.org>
Closes: 1143125
Changes:
 libdate-manip-perl (6.99-2) unstable; urgency=medium
 .
   * Add 2 patches from CPANSec.
     - Date::Manip: restrict numeric date fields to ASCII digits
       CVE-2026-60074
     - Date::Manip: cap the length of a string handed to the parsers
       CVE-2026-60075
     (Closes: #1143125)
   * Declare compliance with Debian Policy 4.7.4.
Checksums-Sha1:
 4c767680cae1a096e92b8af4d4857bcb0134ce31 2461 libdate-manip-perl_6.99-2.dsc
 73b6d61a3b499ed77837fbfc2aacaa53ad975713 12212 libdate-manip-perl_6.99-2.debian.tar.xz
Checksums-Sha256:
 6d29e4ff7591ece11fdb570d9884c502ab02ff3fd4409e7fcffadb2ff4b1190b 2461 libdate-manip-perl_6.99-2.dsc
 f94b85052476e2488075957eb2393c1c006441ffe36a798c2faeef9be140e6cf 12212 libdate-manip-perl_6.99-2.debian.tar.xz
Files:
 18af6ffc86b816bd1d55fd56562a3137 2461 perl optional libdate-manip-perl_6.99-2.dsc
 a75cb81fbb63d2dda64344d18fdd9b4d 12212 perl optional libdate-manip-perl_6.99-2.debian.tar.xz
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmprqjZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYldQ//Y+CcwoltV/7H6bLw1J3PZSqxOsKrCNyv3aWxIbyjU80qochVCVwd2Q2s
8D0k9YMlIz6rhp8lWOy1q6Bem5ubGhhNvupwqvu5nbWLrQrylq9jUtw4h81DDGC7
Pm1sLM3lIT3pUGfrrHm5A5JO9OVdjWbe32aXQRp84XoqJ40251znYvi7d02mA0Oe
T7FLmD1izo7CFX60v/Tu5bPBD1GWRkVFDB+biBF6khqNeaAPvHFm+TB1iXSLv2mb
DhdBXa1TDMAUP/c+ryv1quuF71GIZIMeaEMLs46CR/HQ37L/iU8TaSgDGAR+S647
q5c2umiRN7gVREHUlYGXK1G5aJhdllWj2yeYT60PJ78Pq39WeOsMkfwYexprcaat
qfgRzC1C4DYnvkKHKioxjs5orrTtyax6wR97Vv0tD6Sw3q6ktpHclQ6Fn5rkR44E
svQ9dpx5SjfBdYjDJtgPjRVuO/xPDBx6rBDjVa6lcLruoKXj31WtEwNNgEPiaA+R
394gFYAUssSlmEcV9V1wUobZu9I+waPIiIOq0am7CqzXs2mpWGc2FsO79tTb/6So
nPdwD6mh1oezdspO8h7+E75SCXfLXlqnXN/E6bvRV3SxnxA7sGWSGfcTeMWF2Jzk
jPsBC2ApeyeLorJtJSYHKTyAZERwkdv3+EofN1wdqkyNet3KxNw=
=Jc2f
-----END PGP SIGNATURE-----