Date::Manip versions through 6.99 for Perl return corrupted dates via non-ASCII decimal digits that pass…

Date::Manip is a venerable Perl date-parsing library (versions through 6.99 affected). Its parse regexes use Perl's \d shorthand, which matches not just [0-9] but the entire Unicode \p{Nd} property — over 660 decimal-digit codepoints from scripts like Arabic-Indic, Devanagari, Thai, etc. When a date string contains these non-ASCII digits, the regex happily captures them, and Date::Manip::Base::check validates the fields with numeric comparisons. Perl's numification silently truncates at the first non-ASCII byte, so a year field like 202٤ (three ASCII digits followed by U+0664) becomes 202, yielding the year 0202. The result is silently corrupted date objects — no error, no exception, just wrong data.

The vendor scored this HIGH 7.5 with an Availability impact vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). This overstates the real-world risk substantially. First, the CVSS vector claims unauthenticated network access, but Date::Manip is a *library* — it has no listening port. Exploitability depends entirely on whether the consuming application passes unsanitized Unicode date strings from network input into Date::Manip, which is a narrow subset of deployments. Second, the impact is data corruption (an integrity problem), not a crash or resource exhaustion that would constitute a true availability impact. Third, Date::Manip is a niche Perl library in a language whose enterprise footprint has been declining for over a decade. The vendor HIGH feels like a reflexive CVSS score that ignores how few real attack paths exist.

Why this verdict

• Library, not a service: Date::Manip has no network socket. The AV:N in the CVSS vector is aspirational — it assumes a consuming application blindly proxies Unicode input to the library. This alone invalidates the 7.5 base score.
• Impact ceiling is data corruption: The worst outcome is wrong dates in application output or storage. There is no path from corrupted dates to shell access, credential theft, or privilege escalation. The vendor's A:H (Availability:High) is a stretch — this is really I:L (Integrity:Low).
• Tiny exploitable population: Perl's share of enterprise web applications is small and shrinking. Within that set, only applications that (a) use Date::Manip specifically and (b) accept free-text Unicode date input from untrusted sources are vulnerable. This is a fraction of a fraction.
• Role multiplier: Date::Manip is a date-parsing utility library. It does not run on domain controllers, hypervisors, identity providers, backup servers, or network edge devices in any role-defining capacity. Even where Perl scripts run on high-value infrastructure (e.g., monitoring scripts on a DC), the Date::Manip bug yields bad date output, not host compromise. Blast radius: application-local. No floor override applies.
• No exploitation activity: Zero KEV listing, zero in-the-wild reports, EPSS at 0.00387, no public PoC that weaponizes the bug beyond trivial demonstration. The security community has correctly assessed this as uninteresting for attackers.

Why not higher?

The bug is real and the root cause is legitimate (Unicode equivalence bypass in input validation). If Date::Manip were used in a security-critical date comparison — say, certificate expiry validation or access token lifetime checks — corrupted dates could have higher impact. However, no such deployment pattern has been documented, and the library is overwhelmingly used for display formatting and scheduling, not security enforcement.

Why not lower?

The vulnerability does exist, is confirmed, and could cause silent data corruption in applications that hit the specific input conditions. An IGNORE verdict would be inappropriate because a Perl shop that does use Date::Manip for processing external input should still fix it — the corruption is silent and could cause subtle business logic errors that are hard to diagnose.

1. Sanitize date input to ASCII before passing to Date::Manip — Add a one-liner like $input =~ s/[^\x00-\x7F]//g or validate with /^[0-9\-\/\s:]+$/ before calling any Date::Manip parse function. This eliminates the attack surface entirely and takes minutes to deploy. As a LOW-severity finding, there is no noisgate mitigation SLA — treat as backlog hygiene.
2. Pin or patch Date::Manip locally — If your applications depend on Date::Manip, apply a local patch replacing \d with [0-9] in the parse regexes in Date::Manip::Base. This is a ~10-line change. Monitor CPAN for an upstream fix.
3. Audit Perl applications for Date::Manip usage with external input — Run grep -r 'Date::Manip' /path/to/apps and identify which applications pass user-controlled strings to parse functions. Prioritize those for the input sanitization fix above.

Run this on any host where Perl and Date::Manip are installed. No special privileges required. Invoke with: bash check_datemanip_cve2026_60074.sh

#!/usr/bin/env bash
# CVE-2026-60074 — Date::Manip Unicode digit corruption check
# Run on any host with Perl installed. No privileges required.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

# Check if Date::Manip is installed
if ! perl -MDate::Manip -e '1' 2>/dev/null; then
  echo "UNKNOWN — Date::Manip is not installed on this host."
  exit 2
fi

# Get installed version
VERSION=$(perl -MDate::Manip -e 'print $Date::Manip::VERSION')
echo "Date::Manip version: $VERSION"

# Functional test: feed a Unicode digit and see if it corrupts
RESULT=$(perl -MDate::Manip::Date -e '
  use utf8;
  my $d = new Date::Manip::Date;
  # U+0664 is ARABIC-INDIC DIGIT FOUR
  my $err = $d->parse("2026-07-3\x{0664}");
  if ($err) {
    print "REJECTED";
  } else {
    my $day = $d->printf("%d");
    if ($day eq "34" || $day ne "34" && $day ne "3\x{0664}") {
      # Parsed but gave wrong day — vulnerable
      print "CORRUPTED:$day";
    } else {
      print "OK";
    }
  }
' 2>/dev/null || echo "ERROR")

case "$RESULT" in
  REJECTED)
    echo "PATCHED — Date::Manip $VERSION rejects non-ASCII decimal digits."
    exit 0
    ;;
  CORRUPTED*)
    echo "VULNERABLE — Date::Manip $VERSION silently accepted non-ASCII digit and produced corrupted date (day=$RESULT)."
    exit 1
    ;;
  OK)
    echo "PATCHED — Date::Manip $VERSION handled Unicode digit correctly."
    exit 0
    ;;
  ERROR)
    echo "UNKNOWN — Could not run the functional test. Check Perl and Date::Manip installation."
    exit 2
    ;;
  *)
    echo "UNKNOWN — Unexpected result: $RESULT"
    exit 2
    ;;
esac

Sources

1. MITRE CWE-1289: Improper Validation of Unsafe Equivalence in Input
2. Date::Manip on MetaCPAN (latest version 6.99)
3. Date::Manip::DM6 documentation
4. Date::Manip changelog
5. oss-security mailing list
6. CPAN Security Advisory Database
7. Perl Toolchain Summit 2026 — Security Focus