Websocket Case-Study from bug bounty reports

Published on: 2026-01-08

Status code 1001 to go look at Websockets. …〆(･ω･。)

Intro and TLDR

This is part 0 of my WS Research methodology. It covers a case study which I was inspired by from gregxsunday.

His case studies cover a vulnerability-class, which he then proceeds to gather a lot of data from via bug bounty reports. This is basically the bad knockoff version - I highly recommend his works!

What you’ll find in this post:

• Some background // Lots of blabbering here. If you don’t like idiot rambling you should skip this part.
• Methodology
• Tools and resources I made
• Vulns
• Takeaway (With a dr pepper, please)

Background

I promise I won’t be this talkative (typeative?) in subsequent posts, but I need to blurt out my passion somewhere. :D (And hey it’s my blog i’ll go wild who cares)

I’m not going to blurt the same thing I’ve read about websockets on 10000 other blogs. These string bytes are precious. Or the AI scraper tokens are a bit happier. Anyway, if you don’t know what a Websocket is, an amazing intro can be found on websocket.org

Protocols have always intrigued me. I remember how mindblown I was by looking in Wireshark and looking at packet breakdowns of TCP when getting into tech stuff at 18. Good times… :D

Naturally, this made “weird” protocols intriguing. A protocol that’s not HTTP in the browser - crazy bro!!!

And then, one cold evening while I was walking home from work, genuinely feeling useless, I started listening to the CTBB podcast. And they had the guest MonkeHack just really briefly mentioning WebSocket weirdness. And I just started running home and wanted to look at websockets, really craving to dig into it.

Overcoming anxiety, On new years, I even wrote to him, and got the most awesome response (and a response at all!!) about what he had looked at.

And thats how I decided to start cookin’, i guess. I want to dissect a lot about Websockets, and the layers on them. This might bleed over into other protocols later, like the promising WebTransfer which I will dig into once my WebSocket pipeline is a bit more complete.

Methodology

As a starter, I followed what Gregxsunday does, but I wrote a rust wrapper for the initial data gathering. I queried pentester.land as well as some manual searches, packed it all into a fat json blob, then I used my rust tool to sort it and return a nice notion table.

You can find the final table here: https://www.notion.so/27b1ca9ac80d803fa5a8e0551d7be808?v=27b1ca9ac80d81308fdd000c65b509e4&source=copy_link

Then I manually went through all reports, removing dead ones, and classifying by vulnerability. This gave a general gist of the most common WS reported, which primarily was CSWH, which is a rant I’ll cover later.

Other than that, there was injection vulnerabilities, and on for example electron apps, some spicy RCEs that were really really cool!

As you can see there are some non-started at the bottom, these are vulns I think deserve another approach and love, so I am going to cover such issues in another post.

Back to CSWH though, it is a bug that, while seemingly the posterchild for Websocket vulns, is gradually falling irrellevant. This is due to default browser security headers, such as the Total Cookie Protection. Of course, there will still be caveats, but it does explain why there are so few CSWH vuln reports 2024-2025 for standard webapps. This doesn’t necessarily apply to client-side apps or anything bypassing these browser protections though! It just typically won’t show up how most labs portray it nowadays.

Tools

WebSockets have been getting some love lately, particularly on the side of BurpSuite with WebSocket Turbo intruder, and Backslash powered scanner getting WS Support. (I dont have burp pro tho so cant try that atm :D ), and well, the Montoya API in general has let skilled people write good extensions.

But the first step is finding what sites use them. Sure, as soon as I see a RTE or a chat, I’ll open devtools to see if it uses WS - but I felt I needed a larger pool of targets for this one. So I spaghettied up some golang tool for doing this: https://github.com/etum-dev/webZR its really bad and a WIP because I didn’t set out to make a good program - it’s literally just ugly hacks - please no bully

The tool started off being based on STEWs, which was probably the first genuine attempt on implementing a testing methodology/collection of WebSocket vulns. The primary means of obtaining a WebSocket endpoint here was to fuzz for endpoints or subdomains. This is probably great for large-scale research, but I wanted to target slightly less - using domain lists from bug bounty target repos.

I decided to have the tool try finding WS targets by starting gentle scans and gradually going more agressive. At the time of writing, I’m working on adding a config file to decide on enumeration methods in a more fine-grained manner. It checks in the following order: CSP -> JS crawl -> Common endpoints -> Subdomains

JS Crawl is currently just looking for the wss:// url scheme, so it will have troubles with most typical JS-blobs.

Honestly, CSP Headers and JS was a “good enough” approach that returned plenty test data, so I haven’t optimized too much on the other modules.

Another really neat tool i found was https://github.com/law-chain-hot/websocket-devtools to help inspecting and scripting traffic.

Websocat is also feature-rich. I underrestimated how much one can do with it. I recommend you run websocat —help and/or read https://github.com/vi/websocat/blob/master/doc.md

In addition to that, the coolest vulns reported in my opinion was the apps. So I took home a few client apps and reversed, to see if they used WS.

I also wrote one or two CTF challenges with WS you can test these tools on, but these are to be used in some competitions first. I’ll release them here on my /projects page later.

In the wild

So while I initially just wanted to release this Notion table as some fun initial start, I were so curious. Was I bullshitting this table? Do these sort of vulnerabilities still occur? What sites even use websockets? What for?

So that’s why I made that crappy go tool. After having some hosts, it was time to do the fun stuff.

In addition to random VDP or BB hosts I had a list of, I also took a few open source projects I enjoy.

GraphQL over WS

I noticed multiple hosts using GraphQL over WebSockets. Fittingly, one host on my first hackalong had WebSockets. After learning about the GraphQL over websockets I discovered an IDOR on this host. IDORs over GQL does make sense — authentication works a bit differently. Albeit, in this case, I would not say the impact was large. Perhaps more used as a gadget. So I didn’t bother reporting it yet.

A lot was also for analytic purposes/user behavior. Interesting to look at for seeing how and what data is tied to you.

Another trend I saw was that companies have the WSS connections go to AWS iot endpoints. I have not followed the IOT trend for a while, but a gut feeling is telling me IOT is still not really secure. Source: I have 0 iot skills, but it feels like just poking it a little in the wrong way always returns some secrets or keys. With that in mind, it seems like a promising way to possibly send injections.

I could also often use it as an error oracle — something sometimes underrestimated. It often does require the WS request to have valid data. I (assume) the WS Server does not bother parsing it otherwise - likely returning error 1007 (Unsupported payload).

In another research, there are multiple more WebSocket quirks I wish to look at, but this blogpost was simply getting more familiar with how the protocol is used today. Anyway, this is just the apéterif for me. I’m working on deeper research next! There are at least 3 layers I have not even scratched the surface on.

If you managed to read through my annoying ass, I am both surprised and thankful for your time. Lets be friends!!!!!!!! If you want to (〃ω〃) ﾎﾟｯ