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.

Just published a breakdown of RapperBot. Quick hits:

Uses DNS TXT records to hide rotating C2s.

Multi-arch payloads (MIPS, ARM, x86), stripped/encrypted, self-deleting.

Custom base56 + RC4-ish routine just to extract C2 IPs (decryptor included).

Infra shifts fast: scanners moving countries, repos/FTP/NFS hosting binaries.

Timeline lines up neatly with DOJ’s Operation PowerOFF takedown.

Full post: https://www.bitsight.com/blog/rapperbot-infection-ddos-split-second

Curious if anyone’s still seeing RapperBot traffic after the takedown, or if it’s really gone quiet.