Known 2038 Incidents
In brief: The Year 2038 problem has already caused real failures, years ahead of the date itself. Most of them happened because software worked with a date in the future that was past January 2038, such as a long timeout or a long-lived certificate. Others were found when testers or attackers moved a clock forward. Every item below has a published source. Some widely repeated stories could not be verified, and the section on unverified claims lists them.
| Risk level | n/a (historical record) |
| Status | Ongoing: new 2038 CVEs were published in 2025–2026 |
| Last reviewed | 2026-10-21 |
2038 status at a glance
- At risk ConfirmedWAGO controllers, firmware before 4.10.0 (CVE-2025-0101)CERT@VDE advisory VDE-2025-007. A low-privileged user can set the date past the 32-bit limit, and functions may misbehave or stop.Do: Update to firmware 4.10.0 (FW32).
- At risk Confirmed32-bit editions of Windows (including Windows 10)A 2024 demonstration showed core functions breaking when the clock was set to 2038.Do: Move to 64-bit Windows.
- At risk ConfirmedWAGO managed switches, all firmware (CVE-2025-1235)CERT@VDE advisory VDE-2025-020. Setting the date to 2038-01-19 resets system time to 1970 and corrupts log timestamps. The advisory states no fix.Do: Restrict who can set the time, and follow the vendor advisory for updates.
- At risk ConfirmedOracle Access Manager 10.1.4.3 (Windows)This already failed in March 2022. A cookie set about 500 million seconds ahead pushed dates past 2038, and some searches threw exceptions. This is reported by a secondary source only.Do: Apply Oracle patch 33983548.
Overview
There are three ways a 2038 bug shows up before 2038:
- Future arithmetic:
now + long_durationoverflows. Examples are timeouts, cookie lifetimes and certificate validity. - Future-clock testing or manipulation: someone sets the clock to 2037–2038, for testing or as an attack.
- Same-shaped overflows: a non-time value, such as a date-shaped version number, overflows a signed 32-bit integer in the same way.
The entries are grouped by these classes. They count as "verified" when a primary source (vendor, CERT, bug tracker, mailing list) or a reputable news outlet documents them.
Technical details: incident register
A. Future arithmetic
| Date | System | What happened | Source |
|---|---|---|---|
| 2006-05-12/13 | AOLserver (web server), with an Oracle driver | A workaround set database connection timeouts (MaxOpen/MaxIdle) to 1,000,000,000 seconds to mean "infinite". Once now + 10⁹ exceeded 2³¹−1, servers hung. On Solaris the symptom was EINVAL from a timed condition wait. Justin Mason described it as the first known Y2038 bug. Wikipedia dates the onset to 01:27:28 UTC on 2006-05-13, which is exactly 10⁹ seconds before the rollover. Operators fixed it by lowering the timeout in configuration. |
[1][2] |
| 2009–2022 (open) | Python http.cookiejar / LWPCookieJar on 32-bit |
Saving cookies that expire in 2038 or later raised ValueError: timestamp out of range for platform time_t. A partial fix in 2011 still failed on 32-bit Raspberry Pi in 2020. The issue was still open when it migrated to GitHub in 2022. |
[3] |
| 2010 (reported 2024) | Private CA and VPN appliances at a US retailer | The CA's ten-year validity calculation overflowed 32-bit time, producing a certificate valid from 2037 to 1910. Together with an NTP signed/unsigned bug that made clocks jump by about 2³² seconds, CRL churn grew past a 512 KiB limit. VPNs at about 100 sites failed. | [4] |
| 2012 | Ruby OpenSSL on 32-bit Windows (i386-mingw32) |
Time.mktime could not set a certificate not_after later than 2038-01-19. This was split into a separate bug. |
[5] |
| 2021 | OpenSSH ssh-keygen |
Certificate validity dates beyond 2³¹ were displayed as 2038-01-19T03:14:07 because the formatting code clamped the value to INT_MAX. The reporter saw it on x86-64, Windows and armv7. |
[6] |
| 2022-03-17 | Oracle Access Manager 10.1.4.3 (Windows) | The Identity Console set a cookie about 500,000,000 seconds in the future. After 02:20:48 UTC on 17 March 2022 that date lay past 2038, so gmtime_r() failed and some searches threw exceptions. Oracle issued patch 33983548 on 2022-04-06. Secondary source only; the Oracle forum post was not fetched. |
[2] |
B. Found by setting the clock forward (testing or attack)
| Date | System | What happened | Source |
|---|---|---|---|
| Undated (QEMU history) | QEMU emulated RTC | QEMU's RTC test sets a date in 2080 "to ensure there is no year-2038 overflow". The test exposed an overflow in mktimegm: Linux ignored the century byte, so a 1980 date became 2080. The fix moved the calculation to 64-bit arithmetic, and a later commit skips the test on hosts with 32-bit time_t. |
[7] |
| 2024-03 | 32-bit Windows 10 | Developer "Enderman" showed that setting the clock to 2038 on 32-bit Windows, including Windows 10, breaks core functions. He advised users to run 64-bit Windows. | [8] |
| 2025-04-15 | WAGO controllers (CERT@VDE VDE-2025-007, CVE-2025-0101, CVSS 6.5) | A low-privileged user can set the date to 2038-01-19 and push the clock past the 32-bit limit. Functions may misbehave or stop, both at runtime and after a restart. The fix is firmware 4.10.0 (FW32). | [9] |
| 2025-06-02 | WAGO managed switches (VDE-2025-020, CVE-2025-1235, CVSS 4.3) | Setting the date to 2038-01-19 resets system time to 1970 and corrupts log timestamps. All firmware versions are listed as affected. | [10] |
| 2025-08 | PDP-11/73 at The National Museum of Computing (UK) | Volunteers moved the clock forward. At 2036 everything worked, but at the start of 2037 any program calling the time function crashed. They also found that local time went back to 1970 rather than 1901. The system is not Unix, but it does have a 1982 C compiler. | [11] |
| 2025-09-18 | Dover Fueling Solutions ProGauge MagLink LX4/LX Plus/LX Ultimate (CISA ICSA-25-261-07, CVE-2025-55068, CVSS v3 8.2) | The devices fail to handle Unix time values beyond a certain point. Changing the system time causes authentication errors and denial of service. Fixed in 4.20.3 / 5.20.3. Pedro Umbelino of Bitsight reported it. | [12] |
| 2025-10-23 | Veeder-Root TLS4B automatic tank gauge (CISA ICSA-25-296-03, CVE-2025-55067, CVSS 7.1) | At 2038-01-19 the clock "resets to December 13, 1901". This causes authentication failures and disrupts login, history and leak-detection termination. The issue can be triggered early by time manipulation. A fix was planned but not yet released at publication. | [13] |
C. Same-shaped signed 32-bit overflows (not time_t, but the same bug)
| Date | System | What happened | Source |
|---|---|---|---|
| 2022-01-01 | Microsoft Exchange Server 2016/2019 (on-premises) | The FIP-FS malware engine's date-shaped version number (for example 2201010001) no longer fit a signed 32-bit long. The engine failed to load ("Can't convert "2201010001" to long") and mail stuck in transport queues. Microsoft said it was "not a security related issue" and shipped a reset script. |
[14][15] |
Related precursor: the 2001 "billennium"
On 2001-09-09 01:46:40 UTC, Unix time reached 1,000,000,000. Systems that stored it as a nine-digit string, or sorted timestamps as text, had trouble. Problems were not widespread [16]. This is not an overflow of 32 bits, but it shows that "harmless" limits do get reached.
Affected versions / products
| Product | Affected | Fixed |
|---|---|---|
| WAGO controllers (VDE-2025-007) | firmware < 4.10.0 | 4.10.0 (FW32) [9] |
| WAGO managed switches (VDE-2025-020) | all firmware | no fix stated [10] |
| Dover ProGauge LX4 / LX Plus | < 4.20.3 | 4.20.3 [12] |
| Dover ProGauge LX Ultimate | < 5.20.3 | 5.20.3 [12] |
| Veeder-Root TLS4B (CVE-2025-55067) | listed in advisory | fix pending at publication [13] |
| Oracle Access Manager 10.1.4.3 (Windows) | 10.1.4.3 | patch 33983548 [2] |
| Exchange Server 2016/2019 FIP-FS | engine 2201010001 | Microsoft reset script [14] |
Not verified (do not cite as incidents)
- Pension and mortgage calculation failures. These are widely mentioned as examples. Hackaday (2025) says software projecting 30-year mortgages is already affected [17]. However, as of 2026-10-21, this review found no primary report of a specific pension or mortgage system failing for this reason. Treat such stories as plausible risk scenarios, not incidents.
- IBM Japan ATM failures on 2004-01-10 (2³⁰ seconds). This appears only in an informal blog found via search. (unverified)
- Hikvision camera and MikroTik clock limits. These come from user forum anecdotes only. (unverified)
- Exposure counts. Bitsight's figures, such as about 500,000 Boa servers [18], are survey estimates of exposure, not failures.
Risk & compliance notes
The pattern is clear. Since 2025, 2038 bugs have been disclosed as CVEs with CWE-190 classification. They can be triggered early wherever an attacker or user can change the clock. Include clock-manipulation scenarios in OT threat models, and track these CVEs like any other vulnerability. Use Risk-Assessment-Checklist for triage.
Detection & mitigation
Most of these bugs would have been caught by two cheap tests: running with a fake 2038+ clock, and inserting future-dated data. See Testing-and-Detection. For fixes, and for why the "infinite = 10⁹ seconds" pattern is dangerous, see Remediation-Guide.
See also
- Year-2038-Problem · Y2K-Incidents · Related-Date-Bugs
- GPS-Week-Rollover · NTP-Era-2036
- Devices-Industrial-and-Infrastructure · OS-Windows · Lang-Python
- Articles-and-Sources
References
- Justin Mason, linklog entry on the AOLserver Y2038 bug — jmason.ie, 2006-07-20 — quotes the AOLserver list (Scheffers, Rogers, Piskorski); 10⁹-second timeout.
- Year 2038 problem — Wikipedia — AOLserver onset time and fix; Oracle Access Manager incident and patch (citing Oracle Communities).
- Issue 5537: LWPCookieJar cannot handle cookies with expirations of 2038 or greater on 32-bit platforms — bugs.python.org — opened 2009-03-22; history to 2022.
- Curious tale of broken VPNs, the Year 2038, and certs that expired 100 years ago — The Register, Thomas Claburn, 2024-02-09 — 2010 retail VPN outage.
- Bug #6122: OpenSSL::PKCS7 verify — Ruby issue tracker, 2012-03-07 —
not_aftercapped at 2038 on i386-mingw32. - Bug 3329: Certificate validity dates greater than 32bit are truncated to 2038-01-19T03:14:07 — openssh-bugs, 2021-07-02 — display clamping in ssh-keygen.
- rtc-test: skip year-2038 overflow check in case time_t is 32bit only — QEMU commit and rtc: implement century byte — QEMU commit — 2080 test and mktimegm overflow (seen in search results).
- Y2K38 "Epochalypse": Das Jahr-2000-Problem kehrt zurück — WinFuture, 2024-03-06 — 32-bit Windows 10 breaks at 2038.
- VDE-2025-007 WAGO: Year 2038 problem — CERT@VDE, 2025-04-15 (rev. 2026-08-07) — CVE-2025-0101.
- VDE-2025-020 WAGO: Switches affected by year 2k38 problem — CERT@VDE, 2025-06-02 — CVE-2025-1235.
- The Unix Epochalypse might be sooner than you think — The Register, Richard Speed, 2025-08-23 — TNMOC PDP-11/73.
- ICSA-25-261-07 Dover Fueling Solutions ProGauge MagLink LX4 Devices — CISA, 2025-09-18 — CVE-2025-55068.
- ICSA-25-296-03 Veeder-Root TLS4B Automatic Tank Gauge System — CISA, 2025-10-23 — CVE-2025-55067.
- Email Stuck in Exchange On-premises Transport Queues — Microsoft Exchange Team blog, 2022-01-01 — official Microsoft post (title confirmed; date and error text from secondary coverage).
- Exchange Server – Email Trapped in Transport Queues — SANS ISC diary, Guy Bruneau, 2022-01-02 — independent confirmation; "not a security related issue".
- Time formatting and storage bugs — Wikipedia — 2001 billennium (citing Wired, "Unix Tick Tocks to a Billion").
- The Epochalypse: It's Y2K, But 38 Years Later — Hackaday, 2025-07-22 — mortgage example (no specific incident cited).
- Forward to the Past: The Y2K38 Problem Ahead — Bitsight, 2026-01-18 — exposure estimates.