What happens when an attacker controls the PAC file URL on Android?

How a hostile PAC file URL turns into system-level execution risk

A PAC file is more than a connectivity hint: the system proxy service treats it as executable logic and evaluates it to decide where traffic should go. If an attacker controls the PAC URL, they can make the device fetch attacker-supplied proxy logic at the point where the system trusts it most, which is why a parsing or allocator weakness in that path becomes a security boundary failure rather than a normal browser issue.

On Android, that matters because the proxy path can sit below the app layer. The bug is exercised by the system service, so the impact is not limited to the app that first triggered the fetch. When a malicious PAC script reaches a memory safety flaw, the result can move from crash behaviour into broader process compromise if the attacker can shape execution enough to corrupt memory reliably.

Older platform behaviour widens the blast radius. If applications can change system proxy settings directly, then a compromise or abuse in one app, configuration channel, or managed environment can become a device-wide traffic redirection problem. That makes PAC control an access problem as much as a parsing problem, because whoever controls the URL can control the logic that the network stack later trusts.

Where the failure mode actually sits

The critical failure is not simply “bad proxy settings,” it is the combination of external input, privileged evaluation, and unsafe parsing. A PAC file URL is attacker-controlled content delivery. The system proxy service is the trusted execution point. The allocator bug is the memory-safety weakness that turns content handling into a potential exploit path.

If the attacker can influence both the PAC URL and the conditions under which the system evaluates the script, they may get a crash first and then attempt code execution through memory corruption. The practical significance is that a network configuration feature becomes an attack surface for the underlying service, so defenders need to treat proxy configuration as a security-sensitive input channel, not a convenience setting.

For background on real-world identity and access abuse patterns that often combine exposed configuration, stolen credentials, and downstream exploitation, see The 52 NHI Breaches Report. While this Android issue is not an identity breach by itself, the same operational lesson applies: configuration control can become a privilege boundary when trusted services execute attacker-controlled inputs.

Why older Android versions are materially riskier

Older Android versions are riskier because they may allow broader proxy-setting changes from applications, which lowers the bar from “system-level compromise” to “app-level influence over a system trust path.” That does not make exploitation automatic, but it does increase the number of ways an attacker can plant or replace the PAC URL, especially in environments where device management, enterprise profiles, or legacy permissions are weakly constrained.

In practice, the vulnerability window is larger when proxy changes are not tightly governed and when proxy evaluation happens in a long-lived system process. A defect in that process becomes more serious when many apps depend on it and when user actions, enterprise tooling, or malicious code can repeatedly force evaluation of attacker-controlled PAC content.

For threat context, the general pattern of adversaries abusing trusted control planes is well documented in current reporting such as CISA cyber threat advisories. The specific Android issue is a smaller mechanism, but it fits the broader model of attackers turning legitimate control surfaces into execution paths.

Practitioner Guidance

What to prioritise: Treat PAC URL governance as part of the device's attack surface. Verify who can set proxy configuration, where the PAC URL is sourced from, and whether the platform version still allows application influence over system proxy state.

What to verify: Confirm that proxy settings are centrally managed, that PAC content is delivered from trusted infrastructure, and that the system proxy service is patched against the relevant allocator flaw. If legacy devices remain in use, assume the exposure is higher until proven otherwise.

Decision rule: If an untrusted app, user-controlled channel, or third-party service can change the PAC URL, treat that as a security defect, not an acceptable configuration shortcut. The safest response is to remove the path to attacker-controlled PAC retrieval before relying on detection or incident response.

Practitioner takeaway: The real risk is not the PAC file itself, but the trust placed in the service that fetches and executes it, so control the URL source as tightly as you would any other privilege-bearing configuration input.

Related resources from NHI Mgmt Group

• What happens when an attacker combines a hidden bug with exposed code or weak cloud controls?
• What happens when an attacker can combine SSRF with virtual file or image-processing formats?
• What happens when an attacker gains access in a hybrid cloud environment without segmentation controls?
• What happens when a malicious file hash is blocked before the attacker finishes deploying malware?