I believe Y2K38 isn’t a future problem, it’s exploitable today in any vulnerable system synchronizing time in a way that can be exploitable by an attacker.

Bitsight published an overview of the Year 2038 problem and its security impact: https://www.bitsight.com/blog/what-is-y2k38-problem (Full disclosure: I’m the author)

Many 32-bit systems accept externally influenced time (NTP, GPS, RTC sync, management APIs).

Forcing time near / past the overflow boundary can break authentication, cert validation, logging, TTLs, replay protection.

Embedded / OT / IoT devices are especially exposed:

Long-lived, rarely patched 32-bit Linux / RTOS is common Often internet-reachable Failures range from silent logic errors to crashes.

This makes Y2K38 less a “future date bug” and more a latent vulnerability class affecting real systems today.

I'm interested in how others are:

Treating this issue. Have you heard about it before? Are you (or did you) testing for Y2K38 exposure, in your code and in your installed infrastructure and its dependencies? How do you treat time handling in threat models for embedded / OT environments / critical infrastructure?

If you are interested in time security and want to know more or share your experiences, there is. Time Security SIG over at FIRST that you can consider joining.