eSIM Allows Reading Others' Messages and Intercepting Calls. This Has Already Been Proven.
A phone with an eSIM can turn into a spy against itself.
A phone with an eSIM can turn into a spy against itself.
The research lab Security Explorations has presented the results of a months-long investigation exposing vulnerabilities in the core technology of eSIM. The focus was on an eUICC card from Kigen, certified under GSMA standards and using a proprietary implementation of the Java Card virtual machine.
Despite claimed multi-layered security mechanisms—including EAL4+ certification, built-in memory isolation, and anti-tampering measures—the product was successfully compromised. The attack not only allowed control over the eSIM but also demonstrated a complete breakdown of the trust model in the eUICC ecosystem.
The research revealed that vulnerabilities reported by Security Explorations as early as 2019—which were dismissed at the time—are not only real but potentially devastating. Back then, Oracle labeled these issues as "concerns" and refused to acknowledge their severity. Today, it has become clear that ignored flaws in Java Card bytecode implementation, such as type confusion between objects and arrays, were never fixed—neither in Oracle’s reference implementation nor in independent products like Kigen eUICC.
Security Explorations successfully compromised Kigen’s eUICC card, including in the TS.48 test profile, by simulating the installation of a malicious Java application via SMS-PP. The attack extracted the ECC private key identifying the GSMA card, enabling the unrestricted download and decryption of eSIM profiles from multiple mobile operators, including AT&T, Vodafone, Orange, and T-Mobile. These profiles contained not only network settings but also confidential OTA keys, subscriber identifiers, Java applications, and service parameters. In some cases, extracted applications could be modified and reinstalled without the operator’s detection.
One striking demonstration was an attack on Orange’s network. Researchers showed that cloning an eSIM was possible: a duplicated profile installed on another device allowed intercepting incoming calls and SMS. While the malicious device was active, the legitimate user received no messages, yet the network marked them as delivered. This behavior threatens not only privacy but also the reliability of two-factor authentication (2FA) services used by banks, email providers, and other critical systems.
Kigen acknowledged the vulnerability and began collaborating with researchers. The company paid a $30,000 reward for a detailed technical report and agreed to a 90-day confidentiality period before disclosure. Post-analysis, attempts were made to patch the flaw by implementing type checks in Java Card bytecode. However, Security Explorations noted that the fix was superficial and ineffective—only the stack’s top was checked without tracking control flow, leaving dozens of attack vectors. In other words, the "universal check" was non-functional, leaving over 100 potential exploit points.
In response, GSMA revised the TS.48 specification, disabling Java app installation in test profiles. A guidance document was also issued, emphasizing the need for stricter Remote Application Management (RAM) key control. However, researchers consider these measures half-hearted, failing to address the root issue—the architectural weakness of the Java Card VM underpinning the entire eSIM ecosystem.
Interestingly, despite claiming independence from Oracle, Kigen’s VM reproduced the same conceptual flaws found in Oracle’s Java Card Reference Implementation. Kigen stated it was unaware of the 2019-reported vulnerabilities, though Security Explorations claims to have attempted contact via a feedback form after a joint Kigen-Orange webinar in November 2020.
Beyond Kigen, other eUICC vendors were examined. A Giesecke+Devrient chip tested via Comprion showed greater resilience: while type confusion was possible, critical memory regions were isolated, and array size fields did not overlap with object data. This confirms that not all Java Card implementations are equally vulnerable, though Security Explorations lacked access to chips from Thales and NXP due to restrictive distribution policies and NDAs.
A particularly alarming discovery was that Remote SIM Provisioning (RSP) servers—including those operated by IDEMIA and Thales—failed to detect compromised eUICC certificates. This systemic lack of validation and monitoring enables large-scale attacks without detection. Moreover, many eSIMs skip full Java Card bytecode verification despite SGP.25 specification recommendations.
The researchers’ toolkit not only breached cards and extracted data but also automated security checks for memory, stack, local variables, and bytecode analysis. This was used both for Kigen eUICC testing and real-world network experiments.
A key takeaway was the failure of existing certification mechanisms. Despite EAL4/5 certifications and claims of hardware security, architectural flaws allow attackers to bypass all protection layers via software vulnerabilities. Current standards also lack mandatory Java app verification during provisioning, creating ideal conditions for "Trojan" injections.
Security Explorations stresses the need to overhaul the telecom industry’s trust model. Operators must not treat GSMA certifications as absolute security guarantees. A single compromised eUICC can endanger subscribers of any carrier. Apps installed on eSIMs are invisible to users, making them potential attack vectors for state actors or cybercriminals.
Despite the scale of the threat, Oracle showed no interest in free technical fixes proposed by researchers. Kigen, however, acknowledged the issue and coordinated mitigation efforts via GSMA, notifying over 100 organizations directly and hundreds more through its CVD program.
The researchers funded the project independently, without external sponsorship, and offered to share findings freely with all GSMA members. Their goal: to highlight the value of independent security research and the dangers of ignoring critical details—a pattern the industry has repeated for years.
