Research

Paper

TESTING March 03, 2026

Exploiting PendingIntent Provenance Confusion to Spoof Android SDK Authentication

Authors

Ramanpreet Singh Khinda

Abstract

A single authentication bypass in a partner SDK grants attackers the identity of every partner in the ecosystem -- and millions of apps use SDKs with exactly this vulnerability. OWASP's 2024 Mobile Top 10 ranks Inadequate Supply Chain Security as the second most critical mobile risk, explicitly identifying third-party SDKs as a primary attack vector. Cross-app mobile SDKs -- where a partner application communicates with a platform provider's application via inter-process communication (IPC) -- mediate sensitive operations such as content publishing, payment initiation, and identity federation. Unlike embedded libraries that execute within a single app's process, cross-app SDKs require the provider's service to authenticate the calling application at runtime. A pattern sometimes used for this authentication relies on PendingIntent.getCreatorPackage() to verify sender identity. We demonstrate that this mechanism exhibits a fundamental provenance confusion vulnerability: a PendingIntent reliably identifies who created it but cannot attest who presents it -- and this distinction is fatal for authentication. An attacker app with notification access can steal a legitimate partner's PendingIntent via NotificationListenerService and replay it to impersonate that partner, bypassing authentication entirely. The attack succeeds against both mutable and immutable PendingIntents because immutability protects the token's contents, not its provenance. We systematically evaluate eight Android IPC authentication mechanisms against an SDK-specific threat model and present a defense architecture combining Bound Service IPC with kernel-level caller verification via Binder.getCallingUid(), supplemented by server-side certificate-hash validation. This provides authentication guarantees while remaining scalable across partner ecosystems.

Metadata

arXiv ID: 2603.02539
Provider: ARXIV
Primary Category: cs.CR
Published: 2026-03-03
Fetched: 2026-03-04 03:41

Related papers

Raw Data (Debug)
{
  "raw_xml": "<entry>\n    <id>http://arxiv.org/abs/2603.02539v1</id>\n    <title>Exploiting PendingIntent Provenance Confusion to Spoof Android SDK Authentication</title>\n    <updated>2026-03-03T02:53:17Z</updated>\n    <link href='https://arxiv.org/abs/2603.02539v1' rel='alternate' type='text/html'/>\n    <link href='https://arxiv.org/pdf/2603.02539v1' rel='related' title='pdf' type='application/pdf'/>\n    <summary>A single authentication bypass in a partner SDK grants attackers the identity of every partner in the ecosystem -- and millions of apps use SDKs with exactly this vulnerability. OWASP's 2024 Mobile Top 10 ranks Inadequate Supply Chain Security as the second most critical mobile risk, explicitly identifying third-party SDKs as a primary attack vector. Cross-app mobile SDKs -- where a partner application communicates with a platform provider's application via inter-process communication (IPC) -- mediate sensitive operations such as content publishing, payment initiation, and identity federation. Unlike embedded libraries that execute within a single app's process, cross-app SDKs require the provider's service to authenticate the calling application at runtime. A pattern sometimes used for this authentication relies on PendingIntent.getCreatorPackage() to verify sender identity. We demonstrate that this mechanism exhibits a fundamental provenance confusion vulnerability: a PendingIntent reliably identifies who created it but cannot attest who presents it -- and this distinction is fatal for authentication. An attacker app with notification access can steal a legitimate partner's PendingIntent via NotificationListenerService and replay it to impersonate that partner, bypassing authentication entirely. The attack succeeds against both mutable and immutable PendingIntents because immutability protects the token's contents, not its provenance. We systematically evaluate eight Android IPC authentication mechanisms against an SDK-specific threat model and present a defense architecture combining Bound Service IPC with kernel-level caller verification via Binder.getCallingUid(), supplemented by server-side certificate-hash validation. This provides authentication guarantees while remaining scalable across partner ecosystems.</summary>\n    <category scheme='http://arxiv.org/schemas/atom' term='cs.CR'/>\n    <published>2026-03-03T02:53:17Z</published>\n    <arxiv:comment>11 pages, 5 figures, 3 tables, 61 references</arxiv:comment>\n    <arxiv:primary_category term='cs.CR'/>\n    <author>\n      <name>Ramanpreet Singh Khinda</name>\n    </author>\n  </entry>"
}