Critical Flaws Expose eSIMs to Cloning and Mass Surveillance, Threatening Global Mobile Security
The research laboratory Security Explorations has unveiled the results of a months-long investigation exposing critical vulnerabilities at the core of eSIM technology. The focus of their analysis was a GSMA-certified eUICC card developed by Kigen, which employs a proprietary implementation of the Java Card virtual machine.
Despite boasting multilayered protection mechanisms—including EAL4+ certification, built-in memory isolation, and countermeasures against external attacks—the product proved susceptible to a successful exploit that not only compromised the integrity of the eSIM but also demonstrated a complete collapse of the trusted security model within the eUICC ecosystem.
The investigation revealed that vulnerabilities previously reported by Security Explorations in 2019—dismissed at the time as mere “concerns” by Oracle—were not only real but potentially devastating. Specifically, flaws such as type confusion between objects and arrays in the Java Card bytecode remained unaddressed in both Oracle’s reference implementation and independent products like Kigen’s eUICC.
Security Explorations successfully compromised the Kigen eUICC card, including its test profile TS.48, simulating the installation of a malicious Java applet via SMS-PP. The attack resulted in the extraction of a private ECC key uniquely identifying the GSMA-certified card. With this, the researchers gained unrestrained access to download and decrypt eSIM profiles from numerous mobile operators including AT&T, Vodafone, Orange, and T-Mobile. These profiles contained not only network configurations but also confidential OTA keys, subscriber identifiers, Java applets, and system parameters. In some cases, extracted applications could be modified and reinstalled without any detection by the operator.
One of the most striking demonstrations involved an attack on Orange’s network, where researchers successfully cloned an eSIM profile. Once installed on a second device, the duplicated profile allowed interception of incoming calls and SMS messages. While the rogue device remained active, the legitimate user received nothing, and the network falsely marked messages as delivered. This undermines not only user privacy but also the reliability of two-factor authentication services used by banks, email providers, and other critical systems.
Kigen acknowledged the vulnerability and began cooperating with the researchers. The company awarded $30,000 for the detailed technical report and agreed to a 90-day disclosure embargo. In response, Kigen attempted to mitigate the vulnerability by implementing type checks across all Java Card bytecodes. However, Security Explorations noted that the fix was superficial and ineffective: the system verified only the top of the stack, ignoring control flow paths, leaving dozens of exploitable conditions intact. In essence, the “universal check” proved nonfunctional, exposing over 100 potential attack vectors.
As a result, GSMA revised specification TS.48, disabling Java applet installation in test profiles. It also issued an advisory document urging tighter control over remote management keys. Nonetheless, the researchers criticized these measures as half-measures that failed to address the root cause—an architectural weakness in the Java Card virtual machine on which the entire eSIM ecosystem relies.
Notably, despite Kigen’s claimed independence from Oracle, their Java Card implementation replicated the same conceptual flaws found in Oracle’s reference version. The company also claimed ignorance of the vulnerabilities reported in 2019, although records show that Security Explorations attempted contact in November 2020 via a feedback form following a joint Kigen-Orange webinar.
The study also touched on other eUICC vendors. Using the Comprion service, researchers tested a chip from Giesecke+Devrient, which exhibited stronger resilience. Although arbitrary type casting was possible, critical memory zones were isolated, and array size fields remained decoupled from object data—suggesting that not all Java Card implementations are equally vulnerable. However, researchers lacked access to chips from vendors such as Thales and NXP due to closed distribution policies and restrictive NDAs.
Among the most troubling findings was the failure of Remote SIM Provisioning servers—including those operated by IDEMIA and Thales—to detect compromised eUICC certificates. This points to a systemic lack of validation and monitoring, enabling large-scale attacks to proceed unnoticed. Furthermore, the analysis revealed that many eSIMs do not implement full bytecode verification, despite explicit recommendations in the SGP.25 specification.
The tools developed by the researchers enabled not only the compromise and extraction of card content, but also automated checks for common Java Card vulnerabilities. These instruments scanned memory, stack behavior, local variables, and bytecode flows, and were used both for analyzing the Kigen eUICC and conducting tests in real-world networks.
A critical conclusion drawn from the research is the failure of existing certification regimes. Despite boasting EAL4/5 credentials and claims of hardware-based protection, the architecture itself permits adversaries to bypass all defense layers through flaws in the software implementation. Additionally, current standards do not mandate mandatory Java applet verification at the installation stage—creating an ideal window for trojanized payloads during provisioning.
Security Explorations underscores the urgent need to reevaluate the trust model in the telecommunications industry. Operators must no longer treat GSMA certificates as absolute assurances of security. A single compromised eUICC can jeopardize subscribers across any mobile operator. With applications installed on eSIMs remaining opaque to end users, they may well serve as silent vectors for state-sponsored espionage or organized cybercrime.
Despite the scale of the threat, Oracle declined to engage with the researchers or accept their pro bono technical remediation proposals. Kigen, in contrast, acknowledged the issue and coordinated a response through GSMA, directly notifying more than 100 organizations and hundreds more via a Coordinated Vulnerability Disclosure (CVD) program.
The authors emphasized that their work was conducted independently and self-funded, and that they would gladly provide their findings free of charge to all GSMA participants if given proper support. The purpose of the study, they concluded, is to highlight the indispensable value of independent security research and the critical importance of addressing details long neglected by the industry.
