Various software builds for the AT&T Calypso, Nokia C100, Nokia C200, and BLU View 3 devices leak the device IMEI to a system property that can be accessed by any local app on the device without any permissions or special privileges. Google restricted third-party apps from directly obtaining non-resettable device identifiers in Android 10 and higher, but in these instances they are leaked by a high-privilege process and can be obtained indirectly. The software build fingerprints for each confirmed vulnerable device are as follows: AT&T Calypso (ATT/U318AA/U318AA:10/QP1A.190711.020/1632369780:user/release-keys); Nokia C100 (Nokia/DrakeLite02US/DKT:12/SP1A.210812.016/02US1190:user/release-keys and Nokia/DrakeLite02US/DKT:12/SP1A.210812.016/02US1270:user/release-keys); Nokia C200 (Nokia/Drake02US/DRK:12/SP1A.210812.016/02US1080:user/release-keys); and BLU View 3 (BLU/B140DL/B140DL:11/RP1A.200720.011/1628014629:user/release-keys, BLU/B140DL/B140DL:11/RP1A.200720.011/1632535579:user/release-keys, BLU/B140DL/B140DL:11/RP1A.200720.011/1637325978:user/release-keys, BLU/B140DL/B140DL:11/RP1A.200720.011/1650073052:user/release-keys, BLU/B140DL/B140DL:11/RP1A.200720.011/1657087912:user/release-keys, BLU/B140DL/B140DL:11/RP1A.200720.011/1666316280:user/release-keys, and BLU/B140DL/B140DL:11/RP1A.200720.011/1672371162:user/release-keys). This malicious app reads from the "persist.sys.imei1" system property to indirectly obtain the device IMEI.

Sat, 21 Mar 2026 19:00:13 +0100, Solar Designer wrote: On Sat, Mar 21, 2026 at 01:13:47PM -0400, kf503bla () k com wrote: why assign cve to something irrelvent? I guess because (ir)relevance isn't among criteria for (not) assigning a CVE, and because there may be value in having a non-ambiguous way to refer to historical vulnerabilities for illustration of how the current ones fit in historical context. Beyond the historical context, there is an argument to be made for being aware of known defects in legacy codebases which have been resurrected for use on modern resource-constrained hardware.

For example, the RetroBSD [1] project provides a port of 2.11BSD intended for PIC32 (MIPS) targets. There's also an actively maintained RetroBSD fork, called DiscoBSD [2], which adds support for STM32F4 (ARM Cortex-M4) targets and had its last release [3] last month.

And then there's Serge Vakulenko's LiteBSD [4], a 4.4BSD port to PIC32.

And who knows where Robert Nordier's port of UNIX V7, v7/x86 [5], may be running?

While these projects might modernize parts of the kernel and/or userland, there's always the possibility of bug-ridden code (and bug-ridden assumptions) being inherited from their respective BSD and/or Research UNIX lineage - as we've all seen with BSD derived telnet server and client implementations recently.

Regards, Justin

--- Links ---

[1] https://retrobsd.org [2] http://discobsd.org [3] https://github.com/chettrick/discobsd/releases/tag/DISCOBSD26 [4] https://github.com/sergev/LiteBSD [5] https://www.nordier.com/#v7x86

Solar Designer <solar () openwall com> writes: I guess because (ir)relevance isn't among criteria for (not) assigning a CVE, and because there may be value in having a non-ambiguous way to refer to historical vulnerabilities for illustration of how the current ones fit in historical context. ... and because it was a bit of fun. Not everything has to be serious, it was nice to see the CISA folks have a sense of humour :-). The 2025 in this CVE is almost certainly wrong, but I understand that no one had the resources to figure out the year it was first discovered. They were unable to assign a 1973 CVE so used 2025, the year it was (re-)discovered, instead.

Peter.