Apps bundling a known-vulnerable library (CVE)

What this finding means

Apps bundle third-party libraries, and some versions of those libraries have published security advisories. This category reports where a library version identified in an APK matches a CVE.

We have recorded this in 940 apps. The finding is a strong lead and is deliberately not treated as confirmation, for reasons worth being specific about.

Why this is the hardest detection to get right

Two things make dependency matching error-prone. The first is identifying the version at all: a shaded or minified library may carry no version string, and the string that is present may belong to something else entirely. The second is the advisory data, where affected ranges are often recorded loosely and a patch may land in a release the advisory does not name.

We got this wrong, at scale, and the shape of the error is instructive. A pattern intended to read okhttp's version also matched gRPC-Java's user-agent string, which embeds the word okhttp, and produced CVE findings against an okhttp3 version that has never existed, for 457 apps including several very well-known ones. The pattern is now anchored, a minimum-version floor rejects impossible results, and the 821 false rows were deleted rather than left in place.

The fix also required getting the ranges right. Querying OSV as the authoritative source established that one advisory is fixed in 4.9.2 rather than 4.9.0, so two further versions were affected that we had been clearing, and confirmed that a version we had doubts about genuinely is affected, so those findings stand. Two of three advisory entries we carried turned out to be dead code pointing at coordinates that do not exist.

How to act on one

• Confirm the version yourself from your dependency lock file, which is authoritative in a way that a string in a binary is not.
• Read the advisory and check whether your app uses the affected code path; a vulnerable version is not always a reachable vulnerability.
• Upgrade to the fixed version named in the advisory rather than to the next release, since those are not always the same.
• Check transitive dependencies, which is where most of these arrive and where nobody chose the version.
• Treat a dependency with no version information as unknown rather than safe.

How we detect it, and its limits

Library coordinates and versions are identified from compiled package paths, metadata and embedded version strings, then matched against advisory ranges. Findings map to the relevant CVE and to the MASVS control for dependency hygiene.

The honest limitation is that a reference is not reachability. We cannot see whether the vulnerable function is ever called, and we are matching a version we inferred from a binary rather than one you declared. That is why these are published as signals to verify against your build, not as confirmed vulnerabilities.