Request Smuggling: WebSockets

Overview

WebSocket smuggling abuses the HTTP upgrade process rather than classic Content-Length or Transfer-Encoding parser mismatches. The goal is to trick a front-end proxy into believing a connection has been upgraded to WebSocket, while the back-end still processes traffic as plain HTTP. Once that happens, the proxy may tunnel later bytes without inspection, letting you bypass frontend restrictions and reach protected backend paths.

Why WebSockets Matter

HTTP is request-response driven, so the client normally has to ask before the server can send anything back. That is awkward for real-time features such as notifications, chat, or live updates.

WebSockets solve this by creating a long-lived, full-duplex channel between browser and server.

Upgrade Handshake

WebSockets are designed to begin as HTTP. The client sends an HTTP request containing headers such as Upgrade: WebSocket, Connection: Upgrade, Sec-WebSocket-Key, and Sec-WebSocket-Version. If the server accepts the request, it replies with 101 Switching Protocols.

After that point, the connection is no longer treated as ordinary HTTP traffic.

What Proxies Often Do

Many proxies do not terminate WebSockets themselves. Instead, they forward the upgrade request to the backend and, if they think the upgrade succeeded, they switch into tunnel mode.

In tunnel mode, later traffic is relayed between client and server with little or no HTTP-aware inspection.

The Core Idea

The attack is to create disagreement about whether the upgrade really happened.

• the proxy believes the connection became a WebSocket tunnel,
• the backend does not actually switch protocols and still expects HTTP,
• the attacker then sends a second HTTP request through what the proxy now treats as opaque tunnel traffic.

Broken Upgrade with an Invalid Version

A practical way to trigger this is by sending an unsupported Sec-WebSocket-Version. Modern WebSocket implementations usually expect 13. If the version is invalid, the backend may reject the upgrade with 426 Upgrade Required.

If the proxy fails to verify that response and assumes the upgrade succeeded anyway, it may still start tunneling.

Classic Payload Shape

GET /socket HTTP/1.1
Host: target
Sec-WebSocket-Version: 777
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Key: nf6dB8Pb/BLinZ7UexUXHg==

GET /flag HTTP/1.1
Host: target

The first request tries and fails to upgrade. The second request is then forwarded through the tunnel if the proxy trusts the upgrade state more than the backend response.

Why This Works

• the client sends a WebSocket-looking request,
• the backend rejects it and stays in HTTP mode,
• the proxy assumes success and stops inspecting later bytes as HTTP,
• the backend receives the smuggled request as normal HTTP.

This usually lets you tunnel your own requests through the frontend rather than poison other users' backend connections.

Impact

The common use case is bypassing proxy-enforced restrictions. If the frontend blocks direct access to /flag, /admin, or an internal-only route, tunneling can still make the backend process that request.

That makes this a frontend ACL bypass problem more than a shared desync poisoning issue.

No Real WebSocket Endpoint Needed

Some proxies are so permissive that they do not even need the target path to be WebSocket-enabled. If the request simply looks enough like a WebSocket upgrade, the proxy may still switch into tunnel mode.

In those cases, even a request to / can be enough to trigger the behavior.

When the Proxy Is Smarter

More careful proxies, such as properly configured Nginx, verify that the backend actually returned 101 Switching Protocols before tunneling traffic. That blocks the invalid-version trick because a 426 response clearly means no upgrade happened.

Faking a Valid Upgrade with SSRF

If the application contains SSRF and can be made to fetch a URL you control, you may be able to feed the backend a fake 101 Switching Protocols response. That gives the proxy the success response it wants without creating a real WebSocket session.

At that point, the proxy thinks the connection is upgraded, while the backend still processes subsequent bytes as HTTP.

SSRF-Assisted Smuggling Flow

• find an SSRF endpoint that makes a backend request to an attacker-controlled server,
• return 101 Switching Protocols from that attacker-controlled server,
• wrap the SSRF request in WebSocket upgrade headers,
• append a second HTTP request for the protected resource.

Minimal 101 Server

import sys
from http.server import HTTPServer, BaseHTTPRequestHandler

class Redirect(BaseHTTPRequestHandler):
    def do_GET(self):
        self.protocol_version = "HTTP/1.1"
        self.send_response(101)
        self.end_headers()

HTTPServer(("", int(sys.argv[1])), Redirect).serve_forever()

A simple server like this is enough to fake the backend response if the SSRF can reach you.

Testing Notes

• Use Burp Repeater or raw TCP tooling so the payload is not rewritten.
• Disable automatic Content-Length updates in Burp when sending handcrafted requests.
• Preserve the exact blank lines between the upgrade request and the smuggled request.
• If tooling is inconsistent, sending the payload through nc can be more reliable.

What To Look For

• reverse proxies or caches in front of the target,
• WebSocket support or permissive upgrade handling,
• different error pages from proxy vs backend,
• frontend-denied paths that may still exist on the backend,
• SSRF that can influence backend responses.

Limitations

• This technique usually tunnels your own traffic rather than poisoning other users' requests.
• It depends heavily on proxy behavior and upgrade handling.
• Smarter proxies that validate backend 101 responses will block the simplest version.
• The SSRF-assisted variant only works when you can meaningfully influence the backend response path.

GitHub Link

• 0ang3el / websocket-smuggle: original research and reference material on WebSocket smuggling.

Mitigation

• Only tunnel traffic after confirming the backend actually returned 101 Switching Protocols.
• Harden proxy upgrade logic so invalid or partial handshakes never change connection state.
• Restrict or remove unnecessary WebSocket support on frontend infrastructure.
• Fix SSRF so attackers cannot inject arbitrary backend responses.
• Keep sensitive paths protected at the backend as well, not only at the proxy layer.

Key Takeaways

• WebSocket smuggling abuses disagreement about whether an HTTP upgrade succeeded.
• The proxy may tunnel traffic while the backend still speaks HTTP.
• The main practical impact is bypassing frontend restrictions and reaching backend-only paths.
• SSRF can be used to fake a 101 response when direct invalid-upgrade tricks fail.