~ / topics / Devices
$man devices-networking-and-iot

Devices: Networking and IoT

In brief: Home and office routers, network storage boxes, IP cameras, smart TVs and set-top boxes are mostly small Linux computers, many with 32-bit chips and software that is years out of date. If their clock goes past January 2038 they may crash, refuse logins, or reject every secure website because certificate dates look wrong. Newer firmware based on modern software (for example OpenWrt 22.03 or later) is fixed; older and abandoned devices are not.

Risk level High
Status Fixed in modern embedded stacks (musl ≥ 1.2, OpenWrt ≥ 22.03, Debian 13+ on most 32-bit ports); 32-bit Android and old vendor SDKs remain 32-bit; large unpatched installed base
Last reviewed 2026-10-21

2038 status at a glance

  • At risk ConfirmedTLS / X.509 certificate checks on 32-bit time_t (OpenSSL, GnuTLS, embedded TLS)Certificates already carry expiry dates past 2038. Validators on 32-bit time_t misread them, and failures have been seen in OpenSSL, GnuTLS and Tor.Do: Use 64-bit time_t builds and current libraries, and test with certificates expiring after 2038 and after 2050.
  • At risk ConfirmedHome and small-office routers (OpenWrt 21.02 and earlier, vendor uClibc SDKs)These are 32-bit MIPS/ARM systems with C libraries that have a 32-bit time_t.Do: Move to OpenWrt 22.03 or later, or vendor firmware built on musl 1.2+ or another time64 C library. Otherwise replace.
  • At risk ConfirmedPublic NTP servers running 32-bit operating systemsBitsight found that about 60% of public NTP servers revealing their OS ran old 32-bit systems. A wrong time from a server spreads to every client.Do: Use maintained time sources on 64-bit systems, and configure several independent servers.
  • At risk LikelyIP cameras, DVRs and NVRsThese typically use 32-bit SoCs with BusyBox and old embedded web servers such as Boa, and rarely get updates.Do: Check for firmware updates, or plan replacement.
  • At risk LikelyPayment terminals and transport ticket gatesThese have long-lived embedded firmware with certificate checks, and Kaspersky names them as an at-risk class.Do: Ask vendors for 2038 statements, and test certificate handling with post-2038 dates.
  • At risk LikelySmart TVs and set-top boxes with 32-bit softwareThese run 32-bit Android or vendor Linux, where bionic's 32-bit time_t will not be changed.Do: Use devices with 64-bit userspace, or plan replacement.
  • DependsEnterprise switches, routers and printersThese run vendor network operating systems or embedded RTOS/Linux, and exposure is vendor-specific.Do: Get a vendor statement, and check SNMP, syslog and certificate handling.
  • DependsNAS appliancesThese usually run Linux. They are exposed through old ext3, 128-byte-inode ext4 or non-bigtime XFS volumes, and NFSv3 to 2106.Do: Check kernel and C library versions and file-system settings, and reformat or convert old volumes.

Full risk register →Need help assessing your systems? →

Overview

Consumer and small-business network devices are the most numerous embedded systems on the internet. They are typically:

That makes them a prime target for the "trigger 2038 early" attacks described by Bitsight and the Epochalypse Project: coverage of their BruCON and Hack.lu talks lists routers, printers and smart TVs among the device classes at risk [1][2]. Bitsight's internet survey found that of roughly 200,000 public NTP services that revealed their OS, almost 60% ran old 32-bit operating systems [3]. It also counted about 500,000 reachable instances of the Boa web server, which has been unmaintained since 2005 and is widely embedded in devices, and projected around 1 billion smart TVs in use [3].

Technical details

Firmware platforms

Platform time_t on 32-bit Status for 2038
OpenWrt ≤ 21.02 32-bit Vulnerable on 32-bit targets
OpenWrt ≥ 22.03 64-bit (musl 1.2.x) Fixed; "a change of the musl libc ABI" that required recompiling all user space [4]
musl ≥ 1.2.0 (Feb 2020) 64-bit on all archs Fixed in libc; existing binaries still run, mixed builds can mismatch [5]
glibc ≥ 2.34 (2021) 32-bit default; 64-bit with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 Opt-in; needs Linux ≥ 5.1 for full support [6]
uClibc-ng 32-bit; time64 added 2024 Initially fully supported only on 32-bit ARM; big-endian targets needed extra work [7]
Android 32-bit (bionic) 32-bit, by design "will overflow in 2038"; no plan to add 64-bit time to the 32-bit libc [8]
Debian 13+ (armhf, armel, etc.) 64-bit Transition after Trixie, except i386 [9]
Linux kernel — ≥ 5.6 needed as base for 32-bit systems beyond 2038 [10]

Smart TVs and set-top boxes frequently run 32-bit Android or vendor Linux. Any device still running 32-bit Android userspace inherits bionic's 32-bit time_t [8].

Certificates and TLS

Certificate validation is the most likely way an otherwise-working device "loses the internet". If the device's clock is wrong, or if its date arithmetic overflows, every TLS connection can fail [11].

X.509 validity encoding (RFC 5280 §4.1.2.5) [12]:

Field Encoding Rule Implication
notBefore / notAfter through 2049 UTCTime (YYMMDDHHMMSSZ) "CAs … MUST always encode certificate validity dates through the year 2049 as UTCTime" Two-digit year
Years 2050+ GeneralizedTime (YYYYMMDDHHMMSSZ) "validity dates in 2050 or later MUST be encoded as GeneralizedTime" Four-digit year
UTCTime interpretation — YY ≥ 50 → 19YY; YY < 50 → 20YY The "2050 rule": parsers that get this wrong misread 2050+
No expiry GeneralizedTime 99991231235959Z "SHOULD be assigned" for certificates with no well-defined expiration Year 9999 overflows any 32-bit time_t conversion

The X.509 encoding itself is fine until 9999. The 2038 problem appears when software converts the ASN.1 time into a 32-bit time_t. Documented cases include:

Long-lived device and CA certificates already have notAfter dates past 2038, so a 32-bit device can hit this today without its clock being wrong.

TLS 1.2 gmt_unix_time. RFC 5246 defines the first four bytes of the TLS 1.2 Random as uint32 gmt_unix_time, "seconds since the midnight starting Jan 1, 1970, UTC", while noting "Clocks are not required to be set correctly by the basic TLS protocol" [16]. As a 32-bit unsigned field it wraps in 2106. TLS 1.3 (RFC 8446) defines random as 32 bytes from a secure random number generator [17]. See File-Formats-and-Protocols.

Network management and time

NAS and storage

NAS devices combine all of the above with on-disk formats. A NAS formatted with ext4 using 128-byte inodes, or ext3, cannot store timestamps after 2038; XFS without bigtime is similar; and NFSv3 carries unsigned 32-bit seconds. See File-Systems.

Affected versions / products

Device class Typical stack Overflow Typical fix
Home/SMB routers (OpenWrt ≤ 21.02, vendor uClibc SDKs) 32-bit MIPS/ARM, 32-bit time_t 2038-01-19 OpenWrt ≥ 22.03 or vendor firmware on musl ≥ 1.2 / time64 libc
Enterprise switches/routers Vendor NOS; varies Vendor-specific Ask vendor; check SNMP/syslog/cert handling
NAS Linux + ext4/XFS/Btrfs, NFS/SMB 2038 (ext3, 128-byte ext4, non-bigtime XFS); 2106 (NFSv3) 64-bit kernel/libc; reformat or convert filesystems
IP cameras, DVR/NVR 32-bit SoC, BusyBox, embedded web servers such as Boa 2038 Firmware update or replacement
Smart TVs, set-top boxes 32-bit Android or vendor Linux 2038 64-bit userspace or replacement
Printers Embedded RTOS/Linux Vendor-specific Vendor statement
Any TLS client on 32-bit time_t OpenSSL/GnuTLS/mbed TLS with 32-bit conversion Certificates with dates ≥ 2038 64-bit time_t build; library update

The certificate behaviour of mbed TLS on 32-bit time_t was not verified for this page.

Risk & compliance notes

Detection & mitigation

See also

References

  1. The Y2K38 bug is a vulnerability, not just a date problem — SecurityWeek, 2025 — BruCON talk by Darley and Umbelino; device classes at risk (seen in search results; full page not retrievable).
  2. Umbelino & Darley, "2038 is gonna be epoch!" — Hack.lu 2025, 2025-10-23 — experiments on IoT, ICS/OT and embedded devices.
  3. Pedro Umbelino, "Forward to the Past: The Y2K38 Problem Ahead" — Bitsight, 2026-01-18 — NTP 32-bit share, Boa, smart TV figures.
  4. OpenWrt 22.03.0-rc6 release notes — OpenWrt, 2022-08-02 — musl 1.2.x and 64-bit time_t on 32-bit targets.
  5. musl time64 notes — musl libc — musl 1.2.0 ABI change and compatibility notes.
  6. GNU C Library 2.34 released — info-gnu, 2021-08 — _TIME_BITS=64 opt-in.
  7. uClibc-ng commit log for libc/misc/time — uClibc-ng cgit — time64 support, ARM-first.
  8. 32-bit ABI bugs — Android bionic docs — 32-bit Android time_t.
  9. Debian isn't waiting for 2038 to blow up — The Register, 2025-07-25 — Debian 64-bit time_t transition; TVs and routers still on 32-bit hardware.
  10. Arnd Bergmann, "[GIT PULL] y2038: core, driver and file system changes" — LKML, 2020-01-29 — Linux 5.6 baseline.
  11. Stan Kaminsky, "Epochalypse Now — or how to deal with Y2K38" — Kaspersky, 2026-01-19 — certificate verification failures on devices with wrong dates.
  12. RFC 5280 §4.1.2.5 Validity — IETF, 2008 — UTCTime/GeneralizedTime rules and 99991231235959Z.
  13. Netgate forum: OpenSSL certificate expiry after 2038 — OpenSSL 0.9.8 overflow; 1.0.0 time functions.
  14. GnuTLS issue #370 — GitLab — certtool 2038 problem on 32-bit architectures.
  15. Tor bug #20027, "Ed25519 certificate parsing does badly with expirations after 2038" — Tor Project, 2016 — 32-bit multiplication overflow in certificate expiry.
  16. RFC 5246 §7.4.1.2 — IETF, 2008 — TLS 1.2 gmt_unix_time.
  17. RFC 8446 §4.1.2 — IETF, 2018 — TLS 1.3 random is 32 bytes from a secure RNG.
  18. RFC 2579 — IETF, 1999 — SNMP DateAndTime (2-octet year) and TimeStamp wrap after ~497 days.