GitHub’s Open-Source AI Security Agent Finds 24 Android Vulnerabilities

GitHub Security Lab has reported finding 24 vulnerabilities in Android applications using targeted AI security taskflows built around its open-source Security Lab Taskflow Agent.

The work demonstrates how security researchers can use large language models (LLMs) not simply to scan code, but to follow structured investigation workflows designed around specific vulnerability classes and Android attack surfaces.

GitHub says the taskflows have been used to identify vulnerabilities in mobile applications, including issues affecting the OsmAnd navigation app and the Wikipedia Android application.

The research also highlights an important limitation: while LLMs can identify complex vulnerabilities, they can struggle to determine their real-world severity and can produce false positives. GitHub therefore recommends that security researchers review AI-generated findings and validate them with application-specific testing.

What is the GitHub Security Lab Taskflow Agent?

GitHub Security Lab created the Security Lab Taskflow Agent as an open-source framework that allows security researchers to automate, package and share AI prompts and workflows for security research.

The approach is based on taskflows. Rather than asking an AI model to inspect an entire application with a single broad instruction, researchers can divide an investigation into smaller, targeted stages.

GitHub says custom taskflow prompts can guide an LLM through incremental research steps. This can help the model investigate complex vulnerability patterns that it might otherwise miss.

According to the announcement, the Android-focused work has already resulted in more than 20 reported vulnerabilities, with the total reaching 24 vulnerabilities at the time of publication.

How the Android audit taskflows work

Android applications have their own attack surfaces and vulnerability patterns, so GitHub adapted the existing security audit taskflows to focus more specifically on mobile applications.

One of the new taskflows, gather_mobile_entry_point_info.yaml, identifies application entry points and separates mobile entry points from non-mobile entry points.

This is important for repositories containing multiple types of applications. A single repository could contain Android applications alongside web servers, desktop applications or other components.

The taskflow helps the AI establish which parts of the code represent the relevant mobile attack surface.

GitHub also modified classify_application_local.yaml to provide the LLM with a list of vulnerability classes that should be considered for each entry point and component.

For example, when an Android intent-based entry point is identified, the taskflow can instruct the model to investigate vulnerabilities such as confused deputy issues and insecure broadcasts.

The research uses multiple runs with different prompts. GitHub describes this as combining a stricter approach for ensuring important vulnerability classes are checked with broader prompts that allow the AI to explore potential issues more creatively.

How to run the open-source taskflows

The taskflows are available as an open-source project and can be run against an application repository.

GitHub notes that running them requires a GitHub Copilot license and that the prompts use premium model requests. The process can also generate many tool calls and consume a substantial number of tokens.

The documented workflow is:

1. Open the seclab-taskflows repository and start a Codespace.

2. Wait for the Codespace to initialise.

3. Run ./scripts/audit/run_mobile.sh myorg/myrepo from the terminal.

4. After the audit completes, inspect the audit_results table in the SQLite viewer.

5. Look for results marked with a check in the has_vulnerability column.

GitHub says an audit can take one to two hours on a medium-sized repository, depending on the project.

A vulnerability involving OsmAnd

One of the examples in the research involves OsmAnd, an Android navigation application based on OpenStreetMap data.

GitHub investigated an exported Android activity called MapActivity. An exported activity can be launched by components outside the application itself.

The issue involved the way the application handled intent extras when importing settings files.

The application expected certain values to come from an AIDL service, but those values were accepted through intent extras. GitHub explains that any application can place arbitrary extras into an intent sent to an exported activity.

The relevant settings included controls for:

• Importing settings without a notification

• Replacing existing settings

• Importing selected settings without user confirmation

Because the exported activity accepted these attacker-controlled values, another application could send an intent containing manipulated settings.

GitHub demonstrated that this could be used to modify OsmAnd settings without an obvious indication to the user.

Location data exposure through modified map settings

The research went further by examining how OsmAnd handles map tiles.

GitHub describes how an attacker could replace the application's default tile URL with an attacker-controlled URL. When the application subsequently requested map tiles, information associated with the requested tiles could reach the attacker's server.

The researchers explain that this could expose the coordinates of map tiles loaded by the user.

The same vulnerability could also be used to obtain origin and destination information associated with routes processed by the application.

This makes the issue particularly significant from a privacy perspective because the affected data can reveal information about where a user has been navigating.

GitHub's example demonstrates how a vulnerability involving Android intents and application settings can ultimately reach a different security boundary: sensitive location information.

A Wikipedia Android account takeover chain

A second example involves the Wikipedia Android application.

The application registers a wikipedia:// deeplink that can be used to open Wikipedia content within the application.

GitHub identified a logic issue in the hostname validation process. The relevant check used an endsWith() condition, which allowed a hostname ending in the expected domain to pass the validation.

According to the research, this meant an attacker could construct a URL using a domain such as evil-wikipedia.org that satisfied the vulnerable validation logic while still being controlled by the attacker.

The application could then load the attacker-controlled page inside its WebView.

The research identified another related issue involving cookie handling.

GitHub explains that a second check also relied on an endsWith() comparison when determining whether cookies should be supplied to a page.

The researchers chained the two vulnerabilities. In their described scenario, a victim visits a malicious webpage containing a deeplink and activates it. The Wikipedia application then opens and loads the attacker-controlled page, potentially exposing long-lived Wikipedia-related cookies.

GitHub says the resulting chain could provide the attacker with access to account and session information across Wikimedia projects.

The example illustrates why individual security checks cannot always be assessed in isolation. A validation weakness may become significantly more consequential when combined with another weakness elsewhere in the application's architecture.

Where LLMs still struggle

The research does not present AI-powered security analysis as a replacement for human security researchers.

GitHub found that LLMs can identify vulnerabilities effectively, but they can also report issues that require unusual application states or conditions that may be difficult to reproduce in real-world scenarios.

The models also sometimes reported low-severity issues even when the researchers specifically instructed them not to do so.

More importantly, GitHub found that vulnerability severity can be difficult for an LLM to estimate accurately.

The actual impact of a vulnerability may depend on mitigating factors within the application. A seemingly serious code-level issue may have limited practical impact because of how other parts of the application process the affected data.

GitHub gives path traversal as an example. A path traversal affecting only external storage may have a different security impact from one that can influence sensitive internal application data.

The researchers also describe situations where an LLM could assume attacker-controlled external data would affect application behaviour even though internal storage data would take priority.

These situations can produce false positives.

To address such cases, GitHub says the model needs additional validation, such as debugging, proof-of-concept testing and closer examination of the original application code.

AI can understand security-relevant APIs

One area where the researchers reported strong results was the AI's understanding of common APIs and their security implications.

Security researchers who specialise in a particular programming language often learn which APIs and coding patterns are safe or unsafe.

GitHub says the LLM demonstrated a strong ability to understand the behaviour of security-relevant APIs across different programming languages, even without access to the source code of those languages.

The researchers also found that proof-of-concept code generated after identifying vulnerabilities often required relatively little modification before being used in their research.

What the 24 findings show

At the time of publication, GitHub Security Lab reported 24 Android vulnerabilities found in mobile applications using the taskflows.

The findings included relatively straightforward vulnerabilities as well as a number of critical issues.

GitHub says the vulnerabilities included security problems that security researchers would expect to encounter in Android applications, including cross-app scripting in WebViews and exposed JavaScript bridges.

The research therefore provides a practical example of where AI-assisted security research is currently useful.

The key approach is not simply giving an LLM source code and asking it to "find vulnerabilities". Instead, researchers can create structured workflows that define the attack surface, identify relevant components, check specific vulnerability classes and repeatedly examine the application from different perspectives.

At the same time, the findings show why human validation remains important. Identifying a suspicious code path is different from establishing exploitability, understanding application-specific mitigations and determining the actual security impact.

What this means for application security teams

The announcement highlights a broader industry shift toward using AI as part of security research workflows rather than treating AI as a standalone vulnerability scanner.

For application security teams, structured AI taskflows could provide another method for examining large codebases and investigating security-sensitive application components.

For Android developers specifically, the examples reinforce the importance of carefully reviewing exported components, intent handling, deeplinks, WebViews, cookie handling and data flows between application components.

The research also suggests that AI-assisted testing works best when paired with a clearly defined security methodology.

AI can help expand the number of potential issues researchers investigate, while human researchers can validate findings, reproduce behaviour and assess the practical impact.

Open-source taskflows for security research

GitHub has made the seclab-taskflow-agent available as an open-source project and says it is open to contributions involving new prompts, tools and mechanisms for AI-assisted vulnerability research.

The company says the approach can be applied beyond Android applications, including web, mobile and desktop applications.

For organisations experimenting with AI-assisted application security, the project provides a practical example of how LLMs can be integrated into repeatable security research workflows rather than used only as general-purpose coding assistants.

Key Takeaways

• GitHub Security Lab reports 24 Android vulnerabilities found using AI-powered security taskflows.

• The approach uses targeted prompts and multiple taskflows to analyse Android-specific attack surfaces.

• The research uncovered vulnerabilities involving Android intents, exported activities, deeplinks, WebViews and cookie handling.

• One OsmAnd issue could allow modified application settings to expose map and route-related location information.

• A combination of Wikipedia Android vulnerabilities could enable an account takeover scenario.

• GitHub found that LLMs can struggle with severity assessment and false positives.

• Human security researchers remain important for validation, proof-of-concept testing and impact assessment.

• The seclab-taskflow-agent is open source and can be used to build AI-assisted security research workflows.