Log date · Mon
GitHub Security Lab reports 24 Android vulnerabilities found with its open-source AI agent
On 2026-09-28 the GitHub Blog described auditing Android app source with an open-source taskflow agent, finding exported-component, deeplink and cookie-domain flaws.
What happened on 2026-09-28
On 2026-09-28, Kevin Stubbings of GitHub Security Lab published a GitHub Blog post on auditing Android app source repositories with the open-source GitHub Security Lab Taskflow Agent and its Android audit taskflows; the work found and reported 24 vulnerabilities. According to the post, the taskflows first identify entry points and then classify likely vulnerability types for each one. Every finding was reviewed by a researcher with mobile security experience and disclosed through GHSL advisories. Examples include an exported OsmAnd activity that accepted settings-import extras from any app, which could be used to overwrite map tile URLs, and a Wikipedia chain in which a deeplink hostname-parsing bug combined with two suffix-matching cookie-domain checks could lead to account takeover. Other classes included path traversal, cross-app scripting in WebViews and exposed JavaScript bridges. The post also lists limitations: false positives, misjudged severity, the need for human review, and the cost of runs.
What it means for Android developers
Most findings in the post sit where an app meets the outside world: exported components, intent extras, deeplinks, WebViews and cookie scoping. None of these has anything to do with obfuscation. Obfuscation does not make an exported activity that any app can invoke any safer. The post shows that AI-assisted auditing is lowering the cost of finding boundary flaws like these. Note that it analyzed source repositories, while an outside attacker usually works from the installed package. We cannot conclude that attackers would work at the same speed, but entry points are already public in the manifest, so boundary problems of this kind are not hard for anyone to locate. The limitations section matters just as much. The model reports unrealistic scenarios and misses mitigating factors, so the safer way for defenders to use such tools is to treat AI output as leads and have a person review them.
Checks to run on your own app
First, list every exported Activity, Service, Receiver and Provider in your manifest, confirm each one really needs to be exported, and validate incoming intent extras strictly. Second, use exact matching for deeplink and App Link host checks, never suffix or substring matching. Third, check whether any WebView loads untrusted content or exposes JavaScript interfaces to it, and scope cookie domains as narrowly as possible. Fourth, if you try AI audit tools on your own repository, treat the output as leads to verify, and have someone with mobile security experience review them and record the conclusions.
Your checklist
- Confirm each exported component is necessary and validate intent extras
- Switch deeplink host checks to exact matching
- Treat AI audit output as leads and have a person review them
Primary sources
- GitHub Blog: How we found 24 Android vulnerabilities using our open source AI security agent · Source date 2026-09-28 · Checked 2026-10-12