Follow the Map to Enterprise Risk: What’s Inside Popular Android Apps

Executive Summary

Maps are one of the most common features in mobile apps. From checking the weather to boarding a plane to navigating a new city — maps give context and convenience. But hidden inside some of today’s most popular Android apps is a library that quietly undermines security for millions of users.

That library is libmapbox-gl.so, once part of Mapbox GL Native (SDK v9 and below). Archived since August 2023, this library remains embedded in thousands of active apps — including airline, weather, and travel companions — and it comes with a dangerous surprise: it statically links to SQLite 3.24.0 (2018), a version riddled with critical vulnerabilities.

These vulnerabilities, unknowingly present in legitimate apps on employee’s devices, create significant enterprise risks, including credential and token hijacking, data theft and DoS risks.

Zimperium’s zLabs team, in the second half of the year analyzed the top-ranked apps across Google Play, APKMirror, and VirusTotal. The results are alarming:

• Thousands of Android apps still ship with libmapbox-gl.so.
• Among travel, weather, and airline apps reviewed, 40% ranked in the top 20 of their categories.
• Together, these apps account for hundreds of millions of installs, silently distributing vulnerable code.

For enterprises, this represents a BYOD nightmare: trusted apps installed by employees may introduce exploitable flaws. For developers, it’s a cautionary tale about how outdated dependencies become ticking time bombs.

Introduction: A Map With Hidden Roads

Mobile users rarely think about the libraries powering their apps. If the map loads quickly and looks beautiful, everything seems fine. But beauty can hide danger.

In 2023, Mapbox GL Native was officially deprecated and archived. Its replacement, Mapbox Maps SDK v10+, adopted new rendering backends and abandoned libmapbox-gl.so. But many developers chose not to migrate: API changes were disruptive, migrations required significant effort, and the old SDK still “worked.”

The cost of inaction, however, is that today millions of devices are running apps with a library that hasn’t been updated in years — and bundles a database engine with 19+ known CVEs.

Think of it as using an outdated paper map: the roads may still be there, but the bridges have collapsed, and attackers know exactly where the gaps are.

The Hidden Library: libmapbox-gl.so

At the heart of this risk is libmapbox-gl.so, a native library that powered Mapbox’s vector map rendering. It was widely adopted because it was:

• Fast: GPU-accelerated rendering.
• Beautiful: Smooth vector maps with offline support.
• Easy to integrate: Minimal developer effort.

Unfortunately, it also included a statically compiled version of SQLite 3.24.0 (2018). This means:

• Any vulnerabilities in that SQLite release are permanently compiled into the app.
• Updating SQLite elsewhere in the app does not fix the embedded version.
• Every app shipping this library is unknowingly distributing those vulnerabilities.

Despite Mapbox archiving the project in 2023, libmapbox-gl.so still lives on inside many apps, exposing their entire install base.

How Widespread is the Issue?

To measure the scale, Zimperium analyzed apps across APKMirror, VirusTotal, and the Google Play Store.

• Thousands of apps still bundle libmapbox-gl.so.
• Categories most affected: Airline apps (boarding, booking, flight tracking), Weather apps, Travel & tourism apps.
• Of 50 recently released apps analyzed in these categories, 40% ranked in the Play Store’s top 20.

This highlights two critical realities:

1. The risk is not theoretical. These are widely installed, mainstream apps.
2. Enterprise exposure is inevitable. In BYOD environments, some employees almost certainly have vulnerable apps installed.

The SQLite Time Bomb

SQLite is one of the most widely used databases in the world — but like any software, it requires updates. 

SQLite 3.24.0 was released in June 2018. Since then, at least 19 vulnerabilities have been discovered, several of which allow memory corruption, out-of-bounds reads, or even remote code execution. 

Below we have a selection of CVEs that could be exploited in the context of a mobile application and how they can be used in attack scenarios. 

Key CVEs impacting SQLite 3.24.0

CVE-2025-3277

Summary: An integer overflow in SQLite’s concat_ws() causes a truncated length to be used when allocating a buffer, then the full (untruncated) length is written, producing a huge (~4GB) heap buffer overflow and possible arbitrary code execution.

CVSS: 6.9

Attack scenarios

• Attacker-controlled SQL input: If an app uses concat_ws() or exposes SQL execution on strings built from untrusted inputs (e.g., merging metadata fields from remote tiles, user-supplied data, or sync payloads), an attacker could craft arguments that cause the overflow.
• Malicious data files: An attacker delivers a malformed DB, map tiles, or session export (e.g., a downloaded GeoJSON or bundled tile) that triggers a concat_ws() path when Mapbox/SQLite processes text fields.
• Chained exploit (RCE): The heap overflow size (~4GB) allows attackers to corrupt heap metadata or function pointers; when combined with predictable memory layout (or with further driver/kernel bugs), this could be escalated to remote code execution or sandbox escape.

Risks to apps

• Remote or local RCE inside the app process, potentially enabling data exfiltration of local caches, stored credentials, or tokens.
• Sandbox escape if chained with GPU driver/firmware flaws or other native components that run with higher privileges.
• Large-scale impact: because map libraries run in widely used apps (airline, travel), a single exploit vector could affect millions of devices.

CVE-2023-7104 

Summary: A heap-based buffer overflow in the SQLite session extension (sessionReadRecord) can be triggered by specially crafted session data; affects SQLite up through 3.43.0.

CVSS: 5.5

Attack scenarios

• Sync/session manipulation: Apps that implement sync or session export/import using SQLite session extensions (e.g., offline sync of map tiles, route/session histories) may parse session records. An attacker who can inject or supply a crafted session blob (e.g., via a malicious sync server, crafted update package, or imported file) can trigger the overflow.
• Remote update channels: If the app pulls session-like state from a remote server (push updates, remote configuration, tile/session bundles), the server or CDN could be weaponized to deliver the payload.
• Chaining to sandbox escape: Overflow could corrupt memory structures and, when paired with other native code weaknesses or inadequate ASLR/hardening, be escalated to code execution.

Risks to apps

• Compromise of app runtime leading to arbitrary code execution or data theft (offline cached data, credentials).
• Supply-chain risk: CDNs or third-party servers that provide map/session content become high-impact attack vectors.
• Silent persistence: A compromised app can be used as a beachhead for lateral movement (local network scanning, leaking enterprise data).

CVE-2022-35737

Summary: Handling of extremely large string inputs (billions of bytes) could cause an array-bound overflow in certain SQLite builds prior to fixes; triggers when attacker-supplied string arguments to C API functions are uncontrolled.

CVSS: 7.5

Attack scenarios

• Huge payload injection: If an app processes very large strings from external sources (for example, large metadata fields, embedded GeoJSON, concatenated tile attributes, or untrusted user content) an attacker could craft payloads to trigger overflow.
• File-based attacks: An attacker supplies a large crafted file (map tiles, DB transfers, logs) that the app opens and parses, causing the overflow.
• Denial-of-Service or memory corruption: Even if RCE is not straightforward, such overflows commonly cause crashes (DoS) or unpredictable memory corruption exploitable under favorable conditions.

Risks to apps

• Crash/DoS affecting user experience and potentially taking down critical features (e.g., boarding passes, routing).
• Data corruption of local databases (broken caches, lost user data).
• If chained, potential code execution depending on heap layout and other memory safety mitigations in place.

CVE-2020-15358

Summary: A flaw in SQLite’s query flattening optimization in select.c mismanages certain query shapes and can lead to a multiSelectOrderBy heap overflow in older releases. 

CVSS: 5.5

Attack scenarios

• Crafted queries via exposed SQL: If an app composes SQL queries dynamically from untrusted components (filters, search queries, user-supplied fields) an adversary could craft parameters that create the problematic query shape that triggers the optimizer bug.
• Indirect exposure via imported data: An imported or synced dataset (e.g., search index entries, user bookmarks, offline POI lists) might produce SQL statements that, when executed, activate the buggy optimizer path.
• Exploit chain: Heap overflow opens possibility for memory corruption->RCE, or at minimum corrupt results and DB inconsistency.

Risks to apps

• Remote logical exploitation where attackers use app features to inject query inputs.
• Data manipulation or exfiltration if the corruption allows reading arbitrary memory or altering DB state.
• Service reliability impact, especially for apps that rely on complex queries for UI flows.

CVE-2020-13434 / CVE-2020-13435

Summary: A set of issues in older SQLite releases (around 3.32.1) including integer overflows and read-access to NULL pointers in core functions such as printf.c and sqlite3ExprCodeTarget — leading to crashes or potential memory corruption. 

CVSS: 5.5

Attack scenarios

• Malicious SQL payloads: Carefully crafted SQL statements designed to hit printf-style formatting paths, FTS snippet functions, or expression code paths could cause crashes or exploitable conditions.
• WebSQL / exposed SQL engines: In contexts where SQL execution is exposed to web-like inputs (embedded WebViews, JS-to-native bridges), attackers can craft statements that trigger these bugs.
• Crash to exploit: Even if initial impact is Denial-of-Service, repeated attempts or combination with memory layout weaknesses may lead to further exploitation.

Risks to apps

• Denial-of-Service via malformed queries (bad UX, service disruption).
• Potential memory corruption / logic bugs that could be escalated on poorly hardened builds.
• Unexpected behavior of FTS / search features, degrading functionality.

CVE-2018-20346 & CVE-2018-20505 

Summary: FTS3/FTS4 extensions had integer overflow bugs (Magellan) enabling buffer overflows in certain shadow-table operations; malformed PRIMARY KEY handling could cause crashes/DoS. These were high-severity vulnerabilities discovered in 2018 and patched in later SQLite releases.

CVSS: 8.1/7.5

Attack scenarios

• FTS index poisoning: Attackers craft FTS shadow table changes or queries (e.g., via uploaded/remote data used to build search indexes) to trigger integer overflow and potential code execution — particularly impactful for apps that build search indexes from remote content.
  Malformed schema / DB files: If an attacker can supply or modify DB files (e.g., via shared storage, file import, or malicious update packages), malformed PRIMARY KEY records can be used to cause application crashes or manipulate DB behavior.
• Web/Browser contexts: In environments where JavaScript or WebSQL can execute arbitrary SQL (legacy or embedded engines), remote exploitation was a practical concern.

Risks to apps

• Remote code execution in contexts like WebSQL or when apps index untrusted content.
• Denial-of-Service and data integrity corruption.
• Silent compromise of search indexing and data retrieval features.

Cross-CVE chaining & enterprise-level risk scenarios

These individual CVEs are dangerous, but their risk is amplified when they are used as building blocks in a larger attack. We've outlined several high-impact scenarios below:

• Chaining with GPU / driver bugs: Map rendering libraries run near GPU/native code boundaries. If an attacker triggers a SQLite-based memory corruption and then can exploit a separate GPU driver vulnerability in the same process or kernel interface, that chain can lead to sandbox escape and device compromise. (This is a plausible escalation path—see industry GPU attack research and the Mapbox/GPU context noted in your draft.)
• Supply-chain & CDN vectors: Many apps load tiles, session blobs, or configuration from third-party CDNs. A compromised CDN or man-in-the-middle against an insecure endpoint can deliver crafted content that triggers one of these CVEs in many apps simultaneously.
• BYOD impact: A compromised consumer app on an employee device could expose enterprise credentials, cached tokens, VPN sessions, or SSO cookies — enabling lateral compromise of corporate resources.

While some of these bugs require specific conditions, attackers are creative. Combined with GPU driver flaws or firmware exploits, they could be chained into sandbox escapes or remote code execution on devices.

Why It’s Hard to Fix

If the risks are this serious, why haven’t developers updated?

• End of support: Mapbox GL Native is archived and read-only.
• Migration cost: Moving to v10+ or MapLibre requires code rewrites and API changes.
• False sense of safety: Apps still “work,” so the vulnerabilities remain invisible.
• Tech debt inertia: Updating dependencies rarely gets prioritized against feature development.

This creates the perfect storm: millions of users run vulnerable apps, while developers delay migrations, and attackers quietly research old CVEs.

Why This Matters for Enterprises

The presence of vulnerable libraries inside trusted apps is more than a developer inconvenience — it’s an enterprise risk vector.

In a BYOD environment, an employee's “innocent” weather or airline app may:

• Contain exploitable vulnerabilities attackers can chain.
• Weaken device security, undermining compliance policies.
• Expose sensitive enterprise data if the device is compromised.

Blind trust in app store apps is no longer sufficient. Vulnerabilities don’t care whether an app is popular, free, or even preinstalled by airlines.

What Developers Can Do

The continued use of the deprecated libmapbox-gl.so library is a ticking time bomb. For any developer whose app still packages this library, migration is not optional—it's an essential security requirement. Here is how to audit your project and make the necessary switch:

1. Audit your APKs: Check lib/armeabi-v7a/, lib/arm64-v8a/, etc. for libmapbox-gl.so.
2. Check your Gradle builds: Look for com.mapbox.mapboxsdk:mapbox-android-sdk:9.x.x.
3. Migrate now: Move to Mapbox Maps SDK v10+ or MapLibre, which no longer bundles SQLite.
4. Verify SQLite versions: Ensure your app does not embed outdated, static builds.

How Zimperium Can Help

The libmapbox-gl.so vulnerability highlights a critical, ecosystem-wide visibility gap. It persists because both enterprises and developers are often blind to the risks buried in third-party code, which raises two fundamental questions:

• How can enterprises get visibility into the hidden dangers lurking inside legitimate apps on their employees' devices?
• How can developers get visibility into these inherited issues early and often in their CI/CD pipeline to avoid shipping costly security flaws in the first place?

Zimperium provides the solutions to answer both of these challenges.

For Enterprises

Mobile App Vetting answers the enterprise visibility challenge. It's a comprehensive solution that continuously scans and analyzes all mobile applications in your corporate environment, detecting specific, code-level vulnerabilities precisely like the hidden libmapbox-gl.so library. Security teams can:

• Gain visibility into hidden risks within trusted apps.
• Enforce app usage policies in BYOD environments.
• Reduce exposure to vulnerabilities outside of their direct control.

For Developers

For developers, the libmapbox-gl.so issue is a perfect example of how easily hidden risks can be inherited. Relying on third-party libraries is necessary to build modern apps quickly, but it also means you inherit all of their security flaws—even from libraries buried deep in a dependency tree.

Manually auditing every component is impossible. The real danger is that these vulnerabilities are often discovered after an app is released, forcing costly emergency patches, damaging user trust, and pulling teams away from feature development.

To solve this, developers need a way to find these issues "early and often." The most effective solution is an automated scanning platform that integrates directly into the CI/CD pipeline. This "shift-left" approach allows teams to find vulnerabilities—both in their own code and in third-party libraries—while they are still easy and cheap to fix, long before they ever reach production.

This is precisely the challenge zScan was built to solve. It is Zimperium's answer to the developer's need for early visibility. zScan integrates directly into your existing development workflow to:

• Detect outdated or vulnerable dependencies (like libmapbox-gl.so) before they are merged.
• Identify statically linked third-party libraries hiding old CVEs.
• Reduce tech debt and future risk by surfacing these issues early in the CI/CD pipeline.

By combining research-driven analysis with enterprise-scale tooling, Zimperium enables both sides of the mobile ecosystem to address these risks head-on.

Maps guide us to our destinations — but in the mobile world, they can also guide attackers if built on outdated foundations.

The persistence of libmapbox-gl.so inside today’s most popular Android apps demonstrates how tech debt becomes a security debt. Millions of users may already be carrying vulnerable apps in their pockets.

With Zimperium App Vetting and zScan, enterprises and developers gain the visibility, intelligence, and tools to spot these hidden risks before they become breaches.

Because in mobile security, it’s not enough for the map to look good — it has to be safe.

Google Commentary 

Through our participation in the App Defense Alliance (ADA), Zimperium collaborates directly with Google to improve security and help protect the Play Store. However, Google Play app developers are responsible for maintaining the security of their applications in accordance with Play policies, which do not allow code that introduces or exploits security vulnerabilities. Google provides a range of tools, resources, and best practices to help developers build and maintain secure apps. At the moment of writing this, there is no evidence that libmapx library was actively exploited.