A Proxy Auto-Configuration file is a JavaScript-based script used to decide how traffic should be routed through a proxy. In security research, a malformed or malicious PAC file can become dangerous if the parser or embedded runtime mishandles memory while executing the script.
What a Proxy Auto-Configuration file does
A Proxy Auto-Configuration file is a JavaScript-based decision script that tells a client how to route network requests. It acts as policy logic, not as a transport layer, so the file’s code determines whether traffic goes direct, through a proxy, or along different paths based on the request context.
That makes PAC files deceptively important in enterprise browsing and application egress design. A small script can influence large amounts of outbound traffic, which is why the file’s behaviour, hosting location, and update path matter as much as the proxy endpoint itself.
How PAC logic is evaluated
PAC evaluation is usually simple in concept but sensitive in execution. The browser or operating system supplies request details to helper functions in the PAC environment, and the script returns a routing decision such as a direct connection or a proxy host and port. The logic may branch on destination, scheme, host suffix, or other request attributes.
Because the script is JavaScript-based, the PAC file depends on the client’s parser and embedded runtime. That means the security boundary is not only the network proxy, but also the interpreter that reads and runs the file. A malformed script can fail closed, fail open, or expose implementation bugs if the runtime is weak.
Why PAC files matter for security and operations
PAC files are often used to centralise proxy behaviour, simplify exception handling, and adapt routing to different network zones. They can reduce manual configuration drift, but they also create a single decision point that can affect many users and devices at once.
When PAC logic is misconfigured, users may bypass inspection, break access to internal services, or send traffic through the wrong egress path. When the file is malicious or tampered with, it can redirect traffic in ways that support interception, data exposure, or covert access paths. In that sense, the PAC file is part configuration object and part control plane for web traffic.
Common failure modes and abuse cases
Two broad failure patterns matter most: unsafe content and unsafe interpretation. Unsafe content includes logic that routes sensitive destinations around the proxy, relies on brittle exceptions, or embeds hidden behaviour that changes traffic destinations unexpectedly. Unsafe interpretation includes parser defects, runtime crashes, and memory-handling problems when the PAC engine processes malformed input.
That second class is why PAC files show up in security research. If the parser or embedded runtime mishandles memory while executing the script, a file that is intended to steer traffic can instead become an attack surface. The risk is not just bad routing, but code execution, denial of service, or broader compromise depending on the implementation flaw.
Risk and Threat Considerations
PAC files concentrate routing trust into a script that is often updated centrally and consumed automatically by many clients. If an attacker can alter the file, poison its delivery path, or exploit a parsing bug, they may redirect traffic, bypass inspection, or trigger client-side crashes at scale.
Failure mechanism: A compromised or malformed PAC file can abuse the client’s parsing or JavaScript execution path, causing unsafe proxy decisions or implementation-level memory failures.
Impact: The result can be traffic redirection, loss of visibility, proxy bypass, denial of service, or in the worst case a foothold through a vulnerable PAC engine.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1090 — Proxy | PAC files directly control proxy routing, which maps to proxy-based traffic redirection mechanics. |
| Recommendation — Monitor for unexpected proxy routing and investigate traffic redirection patterns that alter normal egress paths. | ||
| NIST CSF 2.0 | PR.DS-02 — Data-in-Transit Is Protected | PAC routing decisions affect whether traffic is proxied and inspected in transit. |
| Recommendation — Verify that PAC logic preserves protected transit paths and does not bypass required inspection controls. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | PAC scripts should be limited to only the routing logic needed for approved proxy behaviour. |
| SI-10 — Information Input Validation | Malformed PAC content must be validated because the parser and runtime execute untrusted script input. | |
| SC-7 — Boundary Protection | PAC files influence boundary traversal by deciding when traffic crosses proxy controls. | |
| Recommendation — Restrict PAC script behaviour to approved routing logic and remove unnecessary branches or exceptions. Validate PAC file input and reject malformed content before the client runtime processes it. Use PAC policy to enforce approved boundary routing and prevent unintended direct outbound connections. | ||
Related resources from NHI Mgmt Group
- Who is accountable when an inherited proxy configuration remains exploitable?
- Should organisations separate file integrity monitoring from configuration management?
- What is the difference between automated file audit alerts and manual alert configuration?
- What do teams get wrong about repository and configuration file exposure?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
