LSPosed/LSPromise

What it is

The page is the author's own writeup of the InCallController logic bug (CVE-2026-49881), giving the exact vulnerable code and the reflection-based pivot technique, none of which appear in the existing summary.

How it works

Android 17's InCallController.java calls serviceClassExists(), which builds a package context with Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY for an arbitrary (attacker-controlled) package and calls packageContext.getClassLoader(). Although Class.forName(name, false, classLoader) is called with initialize=false to avoid running static initializers, an attacker can still declare a custom AppComponentFactory in their APK, which the classloader invokes merely by being loaded — giving arbitrary Java code execution inside system_server (since com.android.server.telecom runs with sharedUserId="android.uid.system" and process="system").

From there, because system_server hosts ActivityManager, the exploit uses Java reflection to read ActivityManager's internal map of IApplicationThread handles for every running process. This lets the attacker command com.android.networkstack (which is allowed to load native code and has SELinux privileges system_server lacks) to load attacker native code, bridging into the DirtyFrag kernel exploit chain already covered by the summary. The author notes this same ActivityManager-reflection pivot was used previously in their exploit for CVE-2026-0091.

Preconditions / Affected

Introduced in Android 17; the attacker app needs no special permissions, just the ability to declare a service with a custom AppComponentFactory and the android.telecom.CLASS_EXISTENCE_CHECK metadata flag to trigger the vulnerable path.

What to do

Reported to the Android Security Team on 2026-07-23 but initially dismissed as a duplicate. Fixed in the September 2026 bulletin via "Remove serviceClassExists logic to address security vulnerability" — i.e., the check was deleted outright rather than hardened. The page attributes the delayed fix partly to Google's move from monthly to quarterly security bulletins.

Caveats

The page states AOSP and Pixel devices (outside beta QPR builds) remained vulnerable at time of writing despite the kernel 1-day being disclosed three months earlier. The author also calls out, without elaboration, that the fix date vs. Android 17's release left roughly a three-month exposure window attributable to the bulletin cadence change.