Vulnerabilities

GitHub Security Lab published research on September 28 showing that its open source AI security agent has found and reported 24 vulnerabilities in Android apps. Researcher Kevin Stubbings built Android-specific "taskflows", staged audit scripts for the lab's Taskflow Agent, and ran them against open source apps. Two findings are now public: a flaw in the OsmAnd navigation app (more than 10 million Play Store downloads) that let any other app on the phone silently redirect its map traffic and track the user, and a deep link bug chain in the Wikipedia Android app that could hand an attacker a user's session after a single tapped link.

Both bugs sit in the parts of an Android app that other apps and links can reach: exported activities and deep link handlers. Mobile pentesters check that attack surface by hand, and the taskflows are free to run against your own repository today. If you ship an Android app, run them or repeat the same checks manually. If you use OsmAnd or the Wikipedia app, update both from your app store.

How the taskflows audit an app

Asking a large language model to "find bugs in this repo" gives noisy results. The GitHub team split the audit into stages instead. The first taskflow, gather_mobile_entry_point_info.yaml, walks the code and lists mobile entry points: exported activities, services and broadcast receivers, intent filters and deep links. It keeps these separate from other entry points so that multi-platform repositories do not blur the Android attack surface.

The second, classify_application_local.yaml, takes each entry point and tests it against a curated list of Android vulnerability classes. For an intent-based entry point, for example, it looks specifically for confused deputy problems (an app using its own privileges on behalf of an untrusted caller) and insecure broadcasts. GitHub says running both prompts across several runs gave the best coverage. A medium-sized repository takes an hour or two, needs a GitHub Copilot license, and uses a large number of premium model requests.

How the OsmAnd flaw works

An exported activity is a screen that components outside the app are allowed to launch. OsmAnd's MapActivity is exported because it handles opening settings files and deep links. It also accepted four intent extras, settings_version, silent_import, replace and export_type_list_key, that were meant to arrive only from OsmAnd's internal AIDL service (Android Interface Definition Language, the app's own inter-process channel).

Android gives an app no way to say "accept these extras only from my own service" on an exported activity. So any installed app, holding no permissions at all, could send MapActivity an intent with those extras and trigger a silent settings import. The imported settings could replace the map tile source with a URL template on an attacker's server.

From then on, each map tile the phone downloads is requested from the attacker, and the tile's zoom level and x and y coordinates in the URL say exactly which area the user is looking at. Logging those requests reconstructs where the user is and where they travel. GitHub adds that the same flaw also exposed the origin and destination of every route the user plans. The user sees no prompt or notice that anything changed.

How the Wikipedia account takeover works

The Wikipedia app registers the wikipedia:// deep link scheme and turns such links into https:// pages shown in its in-app WebView (an embedded browser the app trusts). Its handler checked that the link's host ended with wikipedia.org, using endsWith() rather than an exact domain match. A link such as wikipedia://evil-wikipedia.org/... passes that check and loads an attacker's page inside the app.

A second endsWith() check, in the app's SharedPreferenceCookieManager, decided which domains receive Wikimedia cookies. The lookalike domain passed that one too, so the attacker's server received the victim's cookies: username, a long-lived authentication token and session tokens that work across Wikipedia, Wikimedia Commons, Wikidata and Meta. One tap on a link was enough.

GitHub says both bugs "have already been disclosed" but does not give fixed version numbers. The Wikipedia app's public repository shows a change merged on March 31, 2026 titled "Properly limit cross-domain sharing of CentralAuth cookies", which matches the cookie half of the chain.

What the research does and does not show

GitHub has named only these two of the 24 findings. It has not published CVE IDs, CVSS scores or a full app list, so there is no wider set of apps to patch yet. The lab says new AI-found advisories will appear on its AI agents advisories page.

None of the sources report either bug being used against real users. GitHub is candid about the limits: the model was good at API behaviour and wrote proof-of-concept code that needed little editing, but it misjudged severity, kept flagging low-impact issues with unrealistic preconditions even when told not to, and missed mitigating factors. Stubbings says every finding needs review by a researcher who knows mobile apps.

What to do

For app teams and mobile pentesters

1. Inventory what is exported. In the merged AndroidManifest.xml (Android Studio's Merged Manifest tab, or apkanalyzer manifest print app.apk), list every activity, service, receiver and provider with android:exported="true" or an intent filter. Each one is input from any app on the device.
2. Treat every extra as hostile. If an exported component also serves an internal caller, split the internal path into a non-exported component, or protect it with a custom permission set to android:protectionLevel="signature". Flags such as "silent" or "replace" should never be honoured from an external intent.
3. Match hosts exactly: parse deep link and WebView URLs with Uri.parse() and compare the host against an allowlist with equality or a dot-prefixed suffix (host == "wikipedia.org" || host.endsWith(".wikipedia.org")). Plain endsWith("wikipedia.org") accepts evil-wikipedia.org. Apply the same rule wherever cookies or tokens are attached to requests.
4. Gate settings imports. Any feature that imports configuration, especially server URLs, should show the user what is changing and ask first.
5. Run the taskflows. GitHub's post gives the entry point: ./scripts/audit/run_mobile.sh myorg/myrepo from the open source seclab-taskflows repository. Budget an hour or two per medium app, and triage every finding by hand before filing it.

For users

Update OsmAnd and the Wikipedia app from Google Play or F-Droid. In OsmAnd, open the map source setting (Configure map, then Map source) and confirm it points to a source you chose. If you use the Wikipedia app while logged in and have tapped odd wikipedia:// links, log out and back in to replace your session tokens, and change your password if you see edits you did not make.

The wider lesson

Exported components and deep links are where an Android app takes input from other apps and from links. Both bugs here were a missing or loose check at that boundary, and both were found by an automated run that takes an hour or two per app, short enough to repeat before major releases. Most of the human effort now goes into triage: GitHub's own write-up shows the model overrating low-impact issues, so plan researcher time for reviewing each finding before anything is filed or fixed.

Our mobile penetration tests cover exported components, intent handling, deep links and WebView trust on Android and iOS, and our red team code review reads the source for the same patterns. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: GitHub Blog: How we found 24 Android vulnerabilities using our open source AI security agent, Help Net Security, GBHackers, Cyber Security News, Wikipedia Android app pull request 6469, GitHub Security Lab AI agent advisories, seclab-taskflows repository, OsmAnd raster maps documentation.