Why does a malformed PAC script create a remote code execution risk on Android?

PAC scripts are executed as JavaScript inside a platform component that parses proxy decisions for the system. If the embedded V8 context is given an invalid allocator reference, attacker controlled script input can influence memory access during ArrayBuffer creation. That turns proxy configuration from a simple routing feature into an execution surface that can be reached through a malicious PAC URL.

How a malformed PAC script becomes executable attack surface

A Proxy Auto-Configuration file is supposed to return routing decisions, but on Android it is not treated as inert text. The script is parsed and executed inside a browser or system component, so a malformed payload can shift the failure mode from “bad proxy settings” to code execution when the runtime accepts attacker-controlled JavaScript in a privileged context.

That distinction matters because the attack surface is not the network proxy setting itself, but the JavaScript engine and its memory-handling path. If the parser, sandbox boundary, or embedded runtime makes unsafe assumptions about script validity, the PAC file becomes an input channel into code that can do far more than choose a proxy.

In practice, the risk emerges when the PAC handler trusts the file to be configuration data while the engine evaluates it as active code. A malicious PAC URL, a poisoned auto-discovery response, or a compromised configuration source can therefore deliver logic that reaches memory-unsafe behavior instead of merely producing a wrong proxy decision.

Why the allocator bug turns script parsing into memory corruption

The remote code execution risk comes from the interaction between JavaScript execution and memory allocation. When the embedded V8 context is given an invalid allocator reference, attacker-controlled input can influence how memory is handled during object creation, including ArrayBuffer operations. That is the moment a malformed script stops being a parsing problem and becomes a memory safety problem.

For a practitioner, the key point is that JavaScript engines are often hardened, but their integration points are not automatically safe. A bug in allocator wiring, object lifetime, or reference validation can let a crafted PAC script steer execution into corrupted memory state, which is why the issue is treated as code execution rather than simple script failure.

This pattern is similar to other cases where a small secret, key, or runtime integration mistake turns a routine control plane into an execution path. NHIMG’s ASP.NET machine keys RCE attack shows the same basic lesson: when a trusted mechanism is wired incorrectly, attackers can pivot from configuration to execution.

What makes malicious PAC delivery dangerous in real deployments

PAC handling is risky because it sits close to system networking, often with broad reach across applications and traffic flows. If the PAC source can be influenced, the attacker does not need to land code through a traditional app vulnerability first, they only need a path that makes the platform fetch and execute the script.

The dangerous part is the combination of reach and trust. Once the malicious PAC file is accepted, the code runs inside a component that may have visibility into traffic routing decisions and enough process privilege to matter. That means compromise can happen before user-space defenses see a conventional exploit chain.

For broader context on how runtime abuse and execution paths are treated in modern AI and tooling ecosystems, NHIMG’s Agentic AI Security Guide is useful because it frames the same control problem: trusted input plus tool-capable execution creates an attack surface that has to be bounded, not merely filtered.

External guidance on memory-safe controls and execution boundaries is also relevant here. The NIST SP 800-53 Rev 5 Security and Privacy Controls catalog provides the control language practitioners typically use when a configuration input can trigger an integrity failure in a privileged component.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	PAC scripts are untrusted input evaluated by a privileged runtime.
	SC-39 — Process Isolation	Separating the PAC engine limits damage if script execution is abused.
	CM-7 — Least Functionality	Proxy logic should expose only the minimum runtime surface needed to resolve routing.
Recommendation — Validate PAC inputs before execution and reject malformed or attacker-controlled script content. Isolate the PAC evaluator from higher-privilege processes and sensitive memory. Remove unnecessary script execution capabilities from proxy configuration handling.
OWASP ASVS	V15 — Secure Coding and Architecture	The issue is a runtime integration flaw that demands secure architecture and memory-safety review.
Recommendation — Review embedded engine integration for unsafe memory handling and object lifetime errors.
CIS Controls v8	CIS-16 — Application Software Security	Malformed PAC handling is a software security defect that needs secure build and review practices.
Recommendation — Test the PAC handling code path for memory corruption before deployment.

Practitioner Guidance

What to verify: Confirm whether PAC files are fetched from a source you control, whether auto-discovery can be redirected, and whether the Android build path still evaluates PAC content in a memory-unsafe embedded engine. If the answer is uncertain, treat the configuration path as internet-reachable attack surface, not as harmless proxy metadata.

Decision rule: If a PAC source can be influenced externally, assume the blast radius includes code execution and prioritize hardening the delivery path, code-path isolation, and update control before relying on proxy policy correctness. If you cannot prove the PAC source and runtime are trustworthy, do not treat the risk as theoretical.

Practitioner takeaway: The real control objective is not to validate that the PAC script “looks right”, but to ensure that the system never executes attacker-shaped proxy logic inside a privileged memory-sensitive runtime.