CVE-2018-9426 is a high severity incorrect implementation that could produce weak RSA key pairs in the RSA key pair generator (RsaKeyPairGenerator::getNumberOfIterations in RSAKeyPairGenerator.java). NVD scores it 7.5. Google fixes it at security patch level 2018-07-05 or later. Install the device update that reaches that level.
What's affected
- Product: Android, in the RSA key pair generator (RsaKeyPairGenerator::getNumberOfIterations in RSAKeyPairGenerator.java).
- Releases listed by the bulletin: 7.0, 7.1.1, 7.1.2, 8.0 and 8.1. The NVD product list shows only some Android releases, so treat the bulletin as the fuller list.
- Fixed in: security patch level 2018-07-05 or later, according to the Pixel and Nexus Security Bulletin for July 2018.
- Impact in the record: a cryptographic weakness, rated as remote information disclosure with no privileges and no user interaction.
- Severity: NVD scores it 7.5 High (vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). The bulletin lists it as Moderate, type ID. Both ratings are given because they differ.
- Weakness classes: CWE-331 (Insufficient Entropy).
How to check if you're exposed
- On the device, open Settings and find the Android security patch level, usually under About phone. The exact path varies by manufacturer. A date earlier than 2018-07-05 means the fix is not present.
- With a USB debugging connection, run
adb shell getprop ro.build.version.security_patch. It prints the patch level as a date. You need 2018-07-05 or later. - For a fleet, export the patch level from your mobile device management console and filter for dates earlier than 2018-07-05.
- Match each device against the release list above. Devices on releases outside it are not named for this CVE, but check them against the other entries in the same bulletin.
What to do now
- Identify every Android device in scope and record its current security patch level.
- Roll out the manufacturer or carrier update that reaches 2018-07-05 or later. Google publishes the fixes, but each device maker decides when its devices receive them.
- For devices that no longer receive updates, plan replacement or limit what they can reach, such as corporate mail and internal apps.
- Write the update policy down, with a maximum patch age, and report exceptions.
Why it matters
The bulletin note in the record says the fix was designed to implement key generation correctly according to the FIPS standard. The practical question for teams is not only whether the device is patched, but whether any RSA keys were generated on a device before the patch and are still in use.
This is an insufficient entropy class weakness. The record names a function that decides a number of iterations, and says the fix makes generation follow the FIPS standard. A generator that departs from the standard can produce keys weaker than their length suggests. Weak keys do not fail loudly. They look normal until someone attacks them. The record's KEV flag is false, so CISA does not list it as exploited. That is the absence of a report in the sources read, not proof that no one has tried.
Quick check
Do I need to regenerate keys after patching?
The advisory text in the record describes a fix to the generator, not a key rotation procedure. Where RSA keys were created on an affected device and protect something valuable, plan a regeneration and confirm with your device vendor.
Which patch level should I look for?
The Pixel and Nexus Security Bulletin for July 2018 places this fix at 2018-07-05. Any date at or after 2018-07-05 includes it. Some makers ship it under a different update name, so check the date.
Sources
- Pixel and Nexus Security Bulletin for July 2018: Affected releases, severity, type and the patch level that carries the fix.
Last reviewed: 19 October 2026.
