Some Android apps, especially those with native code, use local sockets, Unix domain sockets, for inter-process communication between their own components. It works, but there is a sharp edge most developers miss: Android's local sockets default to the abstract namespace, which has no filesystem permissions, so any app on the device that knows the socket name can connect to it. That turns what you intended as a private internal channel into one another app can reach, to send it data or read from it. If you put sensitive data or accept commands over such a socket, a malicious app can exploit it. Here is what local socket IPC is, where the exposure lies, and how to use it securely.
Short answer
Android local sockets are Unix domain sockets used for inter-process communication, and the key risk is that they default to the abstract namespace, which has no filesystem permissions, so any app that knows the socket name can connect to it. Per Android's guidance, an abstract local socket is not access-controlled, so it is an open channel to other apps: data sent over it can be read, and a socket that accepts commands or input can be reached by a malicious app. The fix is to avoid abstract-namespace sockets for sensitive IPC, prefer Android's higher-level IPC with permission models, use filesystem sockets in the app's private directory when you need a socket, authenticate the peer, and treat anything received as untrusted input. Do not expose sensitive IPC over an unauthenticated local socket.
What you should know
- Local sockets are Unix domain sockets for IPC: often used by native code.
- They default to the abstract namespace: which has no filesystem permissions.
- Any app that knows the name can connect: it is not access-controlled.
- Data and commands over it are exposed: readable and reachable by other apps.
- Prefer higher-level IPC or secure the socket: with permissions and peer checks.
What are local sockets, and what is the abstract-namespace risk?
They are an IPC channel that, in their default form on Android, lack access control. A Unix domain socket lets processes communicate locally, and Android apps, particularly ones with native components, sometimes use them, through the local-socket APIs or directly in native code, to pass data between their own processes. The catch is the namespace. A filesystem-based Unix domain socket lives at a path and is governed by filesystem permissions, so you can restrict who may connect. But Android's local sockets default to the abstract namespace, which is not tied to the filesystem and carries no permissions at all, so any process on the device, including another app, that knows or guesses the socket name can connect to it. That means an abstract local socket you created for your own internal IPC is, by default, reachable by other apps. So the risk is not the socket mechanism itself but the abstract namespace's lack of access control, which silently makes a channel you think is private into one that is open to the device.
Where is the exposure?
In what an unprivileged app can do once it connects. The table lists it.
| Aspect | Detail |
|---|---|
| Abstract namespace | No filesystem permissions; not access-controlled |
| Connectability | Any app knowing the name can connect |
| Data disclosure | Sensitive data sent over the socket can be read |
| Command injection | A socket accepting input or commands can be driven |
| No peer identity by default | You may not know who connected |
Once another app connects to your abstract local socket, the exposure depends on what the socket does. If it carries sensitive data, that data can be read by the connecting app. If it accepts input or commands, for example an internal control channel that triggers actions, a malicious app can send crafted input to it, making it both an untrusted-input surface and a potential way to invoke functionality you intended only for your own components. And by default you do not necessarily know who connected, so you cannot assume the peer is your own process. These are the same risks as any exposed IPC endpoint, but they are easy to overlook with local sockets precisely because the channel looks internal and the exposure comes from the default namespace rather than anything you did deliberately.
How do you use local IPC securely?
Prefer safer IPC, and if you use sockets, avoid the abstract namespace and authenticate. Where you can, use Android's higher-level IPC mechanisms, which come with permission models, rather than raw local sockets for communication that needs access control. If you genuinely need a Unix domain socket, do not use the abstract namespace for sensitive IPC; use a filesystem-based socket placed in your app's private directory, where filesystem permissions restrict access to your app, so other apps cannot connect. Authenticate the peer rather than trusting any connection: check the connecting process's credentials, its user identity, to confirm it is your own app before honoring the communication. Treat everything received over the socket as untrusted input and validate it, and do not expose sensitive operations or data over a local socket that other apps could reach. Apply least privilege to what the channel can do. The principle is that a local socket is an IPC endpoint whose default namespace gives it no access control, so you must add the access control yourself, through a private filesystem path and peer authentication, or avoid sockets in favor of IPC that is access-controlled by design.
What to watch out for
The first trap is using an abstract-namespace local socket for internal IPC and assuming it is private, when any app that knows the name can connect; use a private filesystem socket or higher-level IPC. The second is sending sensitive data or accepting commands over such a socket without authenticating the peer, exposing data or functionality to other apps. The third is trusting data from the socket rather than validating it as untrusted input. Local socket usage is in your app and native code, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled APK or AAB against OWASP MASVS, assesses your IPC and input handling, while securing the socket with a private path, peer checks, and validation is yours to implement.
What to take away
- Android local sockets are Unix domain sockets for IPC, and they default to the abstract namespace, which has no filesystem permissions, so any app knowing the name can connect.
- That makes an abstract local socket an open channel to other apps, exposing sensitive data sent over it and letting a malicious app drive a socket that accepts input or commands.
- Prefer higher-level access-controlled IPC, and if you use a socket, avoid the abstract namespace with a private filesystem path, authenticate the peer, and validate received data as untrusted input.
- Use a pre-submission scan such as PTKD.com to assess your IPC and input handling, and add access control to any local socket yourself.
