CVE-2026-65995: OsmAnd AIDL Authorization Bypass

OsmAnd 5.3.3 auto-approved unknown callers to an exported Android AIDL service, exposing location and file operations to any app already installed on the device. The public advisory confirms a fix but does not name the first fixed release or publish a CVSS score.

💡 Plain English Explainer (ELI5)

Imagine a building receptionist who is supposed to check a guest list but adds every new visitor to the approved list as soon as they arrive. OsmAnd’s service did the equivalent for apps on the same phone: it created unknown callers as enabled, then let them use the app’s integration interface. The fix must make approval explicit and bind it to the caller’s real Android identity.

Core Concepts & Subsystem Terms

AIDL: Android Interface Definition Language: a mechanism for one Android process to call methods exposed by another process through Binder IPC.
Exported service: An Android service that other apps can bind to. A permission or an equally strong caller-authorization check must protect sensitive methods.
Caller UID: The operating-system identity of the calling app process. A service should derive it from Binder rather than trust a package name supplied by the caller.
CWE-862: FlawOpen’s editorial classification for the shared missing-authorization boundary. GHSL lists CWE-862 among several weaknesses; the advisory does not publish a CVSS score.

Framework mappings

FlawOpen’s conceptual mapping to MITRE CWE; no vendor or CVE record assigned this weakness ID to this research demonstration. CWE-862

Root Cause Analysis

GitHub Security Lab tested OsmAnd 5.3.3 and found that the exported OsmandAidlServiceV2 had no Android permission and that OsmandAidlApi.isAppEnabled() created an unknown ConnectedApp with enabled=true. Because getApi() gated AIDL calls through this check, a newly encountered local app was added to the connected-app store as authorized instead of being denied pending user approval. GHSL reports that this exposed 97 AIDL methods, including methods returning location/navigation data and file operations with path-traversal weaknesses. The attacker must already have an app installed on the same device, but that app needs no Android location permission or additional user action. File effects described by GHSL are within OsmAnd’s storage sandbox, not arbitrary access to the whole device filesystem. GHSL confirmed the reported issues fixed on June 28, 2026, but its advisory does not state the first fixed release. It publishes no CVSS score; FlawOpen labels severity High editorially because the shared gate exposed sensitive location data and integrity-affecting operations. CWE-862 is FlawOpen’s primary editorial mapping, not Atlassian-style vendor scoring or a claim that GHSL assigned only one CWE.

Step-by-Step Attack Flow

Step 1

A local app reaches the exported service

The vulnerable service was exported without an Android permission. An app installed on the same device could bind to it without requesting OsmAnd’s location permission.

Step 2

The authorization check creates approval

For an unknown package, isAppEnabled() created a ConnectedApp with enabled=true and persisted it. The check therefore granted the access it was meant to verify.

Step 3

The shared gate exposes multiple capabilities

getApi() used that result to serve AIDL calls. GHSL says the path reached 97 methods, including getAppInfo() and file-copy operations; these represent distinct data and integrity impacts behind one authorization failure.

Step 4

The impact stays within documented prerequisites

A malicious app must already run on the device. GHSL documents location/navigation disclosure and file effects in OsmAnd’s storage sandbox; it does not establish whole-device file access or exploitation of customer devices in the wild.

Source Code: Flaw vs. Secure Implementation

The vulnerable excerpt is quoted from GHSL’s analysis of the tested 5.3.3 source. The lower snippet is a minimal fail-closed policy sketch, not OsmAnd’s patch or a complete authorization implementation: the approval flow must verify the calling UID, package signing identity, user consent, and the scopes needed by each method. A production service should enforce authorization at the Binder boundary and separately restrict sensitive methods. GHSL confirms a fix but does not publish the full fix diff or first fixed release; update to a supported release and verify the vendor’s current guidance. This code is instructional and contains no exploit or location/file payload.

Source excerpt: Method: isAppEnabled()

UNPATCHED FLAW

public boolean isAppEnabled(@NonNull String pack) {
    ConnectedApp connectedApp = connectedApps.get(pack);
    if (connectedApp == null) {
        connectedApp = new ConnectedApp(app, pack, true);
        connectedApps.put(pack, connectedApp);
        saveConnectedApps();
    }
    return connectedApp.isEnabled();
}

HARDENED SECURE PATCH

private final Set<Integer> approvedCallerUids = new HashSet<>();

private boolean isAppEnabled() {
    // Populate only after explicit user approval and identity verification.
    return approvedCallerUids.contains(Binder.getCallingUid());
}

Engineering & System Hardening Checklist

✓Update OsmAnd to a current supported release. GHSL confirms the issues were fixed but does not name the first fixed release; do not infer a patch floor from the advisory date alone.
✓For Android services, deny unknown Binder caller UIDs by default. Grant access only after explicit user approval and verification of the installed package’s signing identity.
✓Apply authorization at the exported service boundary and enforce least privilege per AIDL method; do not let a general integration grant automatically expose location, logs, or file operations.
✓Treat package names supplied as method arguments as untrusted. Derive caller identity from Binder.getCallingUid() and verify package-to-UID and signing-certificate bindings.
✓Constrain every file operation to a canonical app-owned root and reject paths that escape it; authorization checks do not replace path validation.
✓Review Android manifests for exported services without permissions, then test first-time callers, revoked approvals, app reinstall/signing changes, and every sensitive AIDL method.
✓The advisory reports a researcher proof of concept, not confirmed exploitation of customer devices. Investigate local indicators without treating the disclosure alone as evidence of compromise.