CWE-927, Use of Implicit Intent for Sensitive Communication, hits Android apps that send sensitive data to other components through an implicit intent.
How it happens
An implicit intent does not name a receiver. Any app that declares a matching intent filter can process it. MITRE walks through the variations:
- Ordered broadcasts go to receivers by declared priority. A malicious receiver can claim a high priority, stop the broadcast from propagating, or change the data before passing it on. Downstream components cannot tell the data was altered.
- Sticky broadcasts stay available after the first send. Any receiver that registers later gets the old intent again, which raises the chance of information exposure over time. Permissions cannot protect sticky broadcasts.
- Any broadcast intent may carry a URI. The sender can grant the receiver read or write access to that URI, which the receiver would not normally have.
// Risky: any app with a matching filter may receive this
Intent i = new Intent("com.example.SYNC_DONE");
i.putExtra("token", token);
sendBroadcast(i);
// Safer: name the receiver
Intent j = new Intent(context, SyncReceiver.class);
j.putExtra("token", token);
sendBroadcast(j);
What an attacker gains
Confidentiality: untrusted apps can read data offered through the intent. Integrity: the app may handle responses from untrusted apps and take unexpected action.
How to find it
MITRE notes SAST can find some instances by tracing data flow. In review, search for sendBroadcast, startActivity and startService calls that carry extras but no explicit component. The observed example, CVE-2022-4903, involved a PendingIntent created without FLAG_IMMUTABLE.
How to fix it
If the app only needs to talk to its own components, the destination is always known, so use an explicit intent. Keep secrets out of intent extras where you can.
Quick check
What makes sticky broadcasts worse?
They remain accessible after the first send and are re-delivered to any later receiver, and permissions cannot protect them.
