CVE-2026-54650: openhole Path Traversal Vulnerability

CVE-2026-54650 Overview

CVE-2026-54650 is a path traversal vulnerability [CWE-22] in openhole, a tunneling tool that exposes localhost services to the internet. In versions 0.1.1 and earlier, openhole-server forwards r.URL.Path instead of preserving the original request target with r.URL.EscapedPath(). This behavior allows percent-encoded dot segments (%2e) and separators (%2f) to reach tunneled local services as ../ and /, enabling directory traversal against backend services. The issue is fixed in version 0.1.2.

Critical Impact
Remote attackers can send crafted HTTP paths through an openhole tunnel to traverse directories and access unintended endpoints or files on the tunneled local service, with no authentication required.

Affected Products

openhole 0.1.1 and earlier versions
openhole-server component (internal/server/public_proxy.go)
openhole local proxy client (internal/client/local_proxy.go)

Discovery Timeline

2026-07-28 - CVE-2026-54650 published to NVD
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-54650

Vulnerability Analysis

openhole tunnels HTTP traffic from a public endpoint to a local service running behind a private network. The public-facing proxy in openhole-server accepts inbound HTTP requests and forwards the path component to the tunneled client. The forwarding logic reads r.URL.Path, which Go automatically decodes, collapsing %2e%2e%2f sequences into ../ before the value reaches downstream handlers.

When the tunneled local service receives the decoded path, it interprets the dot segments as directory traversal instructions. An attacker on the internet can reach files or endpoints outside the intended tunneled scope, bypassing any path-based access rules the local service implements.

Root Cause

The root cause is the use of r.URL.Path in internal/server/public_proxy.go instead of r.URL.EscapedPath(). Go's net/http package decodes percent-encoded characters when populating r.URL.Path, so the raw request target information is lost. Downstream code cannot distinguish between a literal / and an encoded %2f, nor between literal . characters and encoded %2e sequences. This loss of fidelity is the source of the traversal.

Attack Vector

An unauthenticated remote attacker sends an HTTP request to a public openhole tunnel URL containing percent-encoded traversal sequences such as /api/%2e%2e%2fadmin or /%2e%2e%2fetc%2fpasswd. The openhole-server decodes and forwards the path as /api/../admin or /../etc/passwd to the local service, allowing access outside the intended path scope.

// Vulnerable code in internal/server/public_proxy.go (pre-0.1.2)
-	path := r.URL.Path
-	if path == "" {
-		path = "/"
-	}
+	path := requestPath(r)

	reqMsg := protocol.RequestMessage{
		Type:       protocol.TypeRequest,

Source: GitHub Commit a28c27a

The patch introduces a requestPath(r) helper that preserves the escaped path, and the client side (internal/client/local_proxy.go) imports net/url to correctly reconstruct requests without decoding traversal sequences prematurely.

Detection Methods for CVE-2026-54650

Indicators of Compromise

HTTP request logs on tunneled local services showing decoded ../ sequences in the request path
Access log entries on openhole tunnels containing %2e, %2E, %2f, or %2F in the URL path
Unexpected 200 responses for paths outside the documented application surface of the tunneled service
Presence of openhole binary versions 0.1.1 or earlier on developer or CI hosts exposing local services

Detection Strategies

Inspect openhole-server access logs and downstream service logs for percent-encoded dot or slash sequences.
Enumerate running processes and binary versions across the environment to identify openhole instances below 0.1.2.
Correlate inbound tunnel traffic with backend responses to identify paths that would not exist under the intended application routing.

Monitoring Recommendations

Alert on any HTTP request reaching an openhole-tunneled service where the raw request target contains %2e or %2f.
Track outbound public URLs published by openhole and validate that only intended paths are being served.
Monitor for openhole process execution on production or sensitive systems, since the tool is generally intended for temporary developer use.

How to Mitigate CVE-2026-54650

Immediate Actions Required

Upgrade openhole to version 0.1.2 or later on all servers and clients running the tunnel.
Terminate any active openhole tunnels serving sensitive local services until the upgrade is complete.
Audit tunneled applications for evidence of directory traversal in historical HTTP logs.
Restrict use of openhole to non-production environments and require authentication on any tunneled service.

Patch Information

The fix is available in openhole 0.1.2, published as GitHub Release v0.1.2. The corresponding source change is documented in GitHub Commit a28c27a, and the coordinated disclosure is tracked in GHSA-fh2f-xfxc-q9cc. The patch replaces r.URL.Path with a helper that preserves the escaped request path so that percent-encoded traversal sequences are not silently decoded before forwarding.

Workarounds

Place a reverse proxy in front of the openhole tunnel that rejects requests containing %2e or %2f in the path.
Configure the tunneled local service to enforce strict path allowlists and canonicalize paths before authorization checks.
Avoid exposing services that rely on path-based access control through openhole until version 0.1.2 is deployed.

bash

# Upgrade openhole to the patched release
go install github.com/bablilayoub/openhole/cmd/openhole@v0.1.2

# Verify installed version
openhole --version