How do you prevent CAPEC-502?

To limit one's exposure to this type of attack, developers should avoid exporting components unless the component is specifically designed to handle requests from untrusted applications. Developers should be aware that declaring an intent filter will automatically export the component, exposing it to public access. Critical, state-changing actions should not be placed in exported components. If a single component handles both inter- and intra-application requests, the developer should consider dividing that component into separate components. If a component must be exported (e.g., to receive system broadcasts), then the component should dynamically check the caller's identity prior to performing any operations. Requiring Signature or SignatureOrSystem permissions is an effective way of limiting a component's exposure to a set of trusted applications. Finally, the return values of exported components can also leak private data, so developers should check the caller's identity prior to returning sensitive values.

What weaknesses does CAPEC-502 target?

CAPEC-502 exploits 1 CWE weakness, including CWE-284 (Improper Access Control).

RadicalNotion.AI

Log in Start free

Log in

Log in Start free

Standard attack pattern

Draft

CAPEC-502: Intent Spoof

An adversary, through a previously installed malicious application, issues an intent directed toward a specific trusted application's component in an attempt to achieve a variety of different objectives including modification of data, information disclosure, and data injection. Components that have been unintentionally exported and made public are subject to this type of an attack. If the component trusts the intent's action without verififcation, then the target application performs the functionality at the adversary's request, helping the adversary achieve the desired negative technical impact.

Last updated June 1, 2026

Not rated

Typical severity

Per MITRE

Not rated

Likelihood of attack

Per MITRE

1

Related weaknesses

CWEs this targets

Standard

Abstraction

MITRE classification

Overview

CAPEC-502 (Intent Spoof) is a standard-level attack pattern catalogued by MITRE in the Common Attack Pattern Enumeration and Classification (CAPEC). It describes a recurring method attackers use to exploit software weaknesses.

What the attacker needs

Prerequisites

An adversary must be able install a purpose built malicious application onto the Android device and convince the user to execute it. The malicious application will be used to issue spoofed intents.

How to mitigate it

Defenses that reduce the risk of CAPEC-502.

To limit one's exposure to this type of attack, developers should avoid exporting components unless the component is specifically designed to handle requests from untrusted applications. Developers should be aware that declaring an intent filter will automatically export the component, exposing it to public access. Critical, state-changing actions should not be placed in exported components. If a single component handles both inter- and intra-application requests, the developer should consider dividing that component into separate components. If a component must be exported (e.g., to receive system broadcasts), then the component should dynamically check the caller's identity prior to performing any operations. Requiring Signature or SignatureOrSystem permissions is an effective way of limiting a component's exposure to a set of trusted applications. Finally, the return values of exported components can also leak private data, so developers should check the caller's identity prior to returning sensitive values.

Frequently asked questions

Common questions about CAPEC-502.

What is CAPEC-502?: An adversary, through a previously installed malicious application, issues an intent directed toward a specific trusted application's component in an attempt to achieve a variety of different objectives including modification of data, information disclosure, and data injection. Components that have been unintentionally exported and made public are subject to this type of an attack. If the component trusts the intent's action without verififcation, then the target application performs the functionality at the adversary's request, helping the adversary achieve the desired negative technical impact.
How do you prevent CAPEC-502?: To limit one's exposure to this type of attack, developers should avoid exporting components unless the component is specifically designed to handle requests from untrusted applications. Developers should be aware that declaring an intent filter will automatically export the component, exposing it to public access. Critical, state-changing actions should not be placed in exported components. If a single component handles both inter- and intra-application requests, the developer should consider dividing that component into separate components. If a component must be exported (e.g., to receive system broadcasts), then the component should dynamically check the caller's identity prior to performing any operations. Requiring Signature or SignatureOrSystem permissions is an effective way of limiting a component's exposure to a set of trusted applications. Finally, the return values of exported components can also leak private data, so developers should check the caller's identity prior to returning sensitive values.
What weaknesses does CAPEC-502 target?: CAPEC-502 exploits 1 CWE weakness, including CWE-284 (Improper Access Control).

References

Attack-pattern data is sourced from the MITRE CAPEC catalog (v3.9). Weakness associations link to the corresponding CWE entries on RadicalNotion.AI.

Defend against CAPEC-502

Track the CVEs and weaknesses attackers exploit with this technique, with AI-written analysis and remediation guidance.

Start free See pricing