PNA in the Wild: Rare, but Often Broken
Analyzing the state of PNA adoption in 2025.
Introduction
Web browsers have quietly become a pivot point between the public internet and private infrastructure – a soft frontier where internal APIs, localhost services, and corporate portals all increasingly brush against the open web.
Historically, the “Same-Origin Policy” (SOP) shielded these local resources by restricting cross-origin access. But as browsers evolved into complex application platforms and usage of localhost APIs exploded (DevOps dashboards, agent UIs, IoT panels, internal admin tools), attackers found new ways to bridge that gap — abusing misconfigured CORS, DNS rebinding, and request smuggling to reach networks behind the firewall, with the browser as the hopping point.
In this post, we break down how PNA works, why it matters, and setting the stage for broader research into how widely (and securely) it’s being adopted in the wild.
Private Network Access (PNA)
What is PNA
PNA is the browsers response : a tightened permission and preflight model aimed at stopping “drive-by intranet access”. The core idea is simple — if a public website (Internet) wants to send requests to a more trusted target (e.g., 192.168.x.x, 127.0.0.1, RFC1918, RFC6598), the browser should first preflight and require the backend to explicitly opt-in via the Access-Control-Allow-Private-Network: true header.
Why PNA Matters
Without PNA, an attacker could embed malicious scripts in a public website and silently scan or exploit internal services reachable from the victim’s browser. PNA forces servers to explicitly acknowledge and allow these cross-network requests — effectively creating a new access boundary enforced at the browser level.
Valuable cases where these considerations matter include examples listed by Oligo Security in their blog “0.0.0.0 Day: Exploiting Localhost APIs From the Browser”, which shed light on real-world exploitation campaigns of local services and malicious browser fingerprinting.
Analyzing the state of PNA
While conversations about PNA seem to be more prevalent for browser adoption (client-side), its adoption and security implications on applications and services (server-side) have seemingly not received as much attention within the web security research community. CVE-2024-6221 may be the only known documented security issue where insecure PNA-related CORS headers have made an application intentionally vulnerable, thus bypassing browser protections (similar to traditional CORS issues we are familiar with).
This blog intends to set the stage for such research, provide some high-level insights into what the adoption of PNA headers on web servers looks like, and perhaps open up a can of worms for further research on what is intentional/unintentional.
How ?
For this research, AWS US East was used as the sample environment — it’s high-density, widely shared, and ideal for spotting patterns across diverse infrastructure. While enterprise networks with heavy private IP space usage would be ideal for this research, this environment provides a practical snapshot of real-world behavior.
This address space was probed with a GET request and the required CORS headers for PNA :
GET / HTTP/1.1
Host: targets
Origin: http://example.com
Access-Control-Request-Method: GET
Access-Control-Request-Private-Network: true
The headers parsed from the response were :
HTTP/1.1 [STATUS-CODE]
Server: [SERVER-TYPE]
Access-Control-Allow-Private-Network: [true/false]
Access-Control-Allow-Origin: [ORIGIN]
<title>[SERVICE-BANNNER]</title>
The tool of choice for this was NMAP, with a custom NSE script to capture these headers. The source code for this is linked below.
What ?
The results from this research would best be demonstrated with the graphic below.
Interpretation
Takeaway : PNA adoption is low — but misconfigurations are common where it is used.
Only a small portion of the scanned IP space responded with PNA-related headers. Among those, about one-third showed insecure configurations. This typically looked like:
Access-Control-Allow-Private-Network: trueAccess-Control-Allow-Origin: *or reflected origin.
Origin Server breakdown :
Response patterns (i.e. allow vs. deny) were fairly consistent across server types, but nginx led in raw numbers.
Title/Application Breakdown :
While most web server banners were missing (often returning a 404), no distinct patterns or common apps were found. However, these web services without HTML on the web root indicate a possibility that many may be APIs, which may be an area of interest for further research.
Checking your environment
Here’s a quick way you can use NMAP, with a custom script, to check for PNA behavior via preflight-like requests in your internal networks or localhost.
This script can be pulled from here : https://github.com/notnotnotveg/nse-http-pna-detect
This can be run as :
$ nmap -Pn -n --open --script http-pna-detect.nse -sV 127.0.0.1
Starting Nmap 7.80 ( https://nmap.org ) at 2025-01-01 01:00 UTC
Nmap scan report for 127.0.0.1
Host is up (0.0069s latency).
Not shown: 997 filtered ports, 1 closed port
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.7 (protocol 2.0)
80/tcp open http nginx
| http-pna-detect: VULNERABLE: Access-Control-Allow-Private-Network: true
| Server: nginx
| Origin: http://example.com
|_Title: Not found
Running this with the service detection (-sV) flag when scanning non-standard web ports is recommended.
Wrapping Up
Private Network Access is still emerging in the wild — but it’s already showing signs of the same misconfig pitfalls we’ve seen before with CORS. While adoption is low, early implementations suggest a need for better defaults and clearer guidance.
For anyone managing services in private or hybrid networks, it’s worth scanning your environment and tightening up access rules. Misconfigured PNA headers might not be widespread yet, but they’re already opening doors they shouldn’t.
Security teams should treat PNA like any other surface exposed to the web: validate origins, avoid wildcards, and monitor preflight behavior closely.