Is this #curl security report AI slop or not? hackerone.com/reports/3303765
curl disclosed on HackerOne: WebSocket Fragmentation DoS on Curl...
### Summary A malicious WebSocket server can send a fragmented message (FIN=0) followed by a flood of continuation frames, causing the client (curl) to continuously allocate memory while waiting...HackerOne
- slop (73%, 328 votes)
- not slop (26%, 119 votes)
Stéphane Bortzmeyer
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Stéphane Bortzmeyer • • •Eicar Arlettaz
in reply to daniel:// stenberg:// • • •Sensitive content
Mx. Moriarty 🏳️⚧️
in reply to daniel:// stenberg:// • • •Techassi
in reply to daniel:// stenberg:// • • •Philip Johansson 🏴☠️💜
in reply to daniel:// stenberg:// • • •I haven't seen an AI take a screenshot of their terminal yet. And Kali on WSL does seem like something an overambitious script kiddy would use. On the other hand, the user definetly types like an LLM, and not answering the direct question is hella suspicious 🤔
Maybe it's a kid who's just asking ChatGPT what to do and say?
Conny Duck
in reply to daniel:// stenberg:// • • •Wolf480pl
in reply to daniel:// stenberg:// • • •does the form require the Mitigation Recommendations and Impact sections, and does itbsuggest 3 bullet points for each? If not, then definitely slop, whether human or AI.
Also, the mitigation recommendations seem very generic and don't demonstrate a beyond-surface-level understanding of the usecase.
Wolf480pl
in reply to Wolf480pl • • •like, why do websockets allow fragmentation? Possibly to allow processing messages of unbounded size in a streaming fashion, while allocating only enough memory to hold one fragment.
Which I'm guessing is what curl is already doing.
But the fix suggestions don't mention that possibility.
daniel:// stenberg://
in reply to Wolf480pl • • •Wolf480pl
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Wolf480pl • • •pitch R.
in reply to daniel:// stenberg:// • • •Not necessarily genAI. but definitively slop.
Could be there was actually a bug/glitch in the Kali WSL/potential Microsoft "curl"/hacking some webserver stack.
I would not consider this environment reliable in any possible sense.
It can be expected to at least spin up a clean VM and test your claims against a more simple/basic stack. Clearly that was not done.
o_andras
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to o_andras • • •Jeff Clough
in reply to daniel:// stenberg:// • • •ben
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to ben • • •daniel:// stenberg://
in reply to daniel:// stenberg:// • • •Jeff Clough
in reply to daniel:// stenberg:// • • •Bredroll
in reply to daniel:// stenberg:// • • •maunzCache
in reply to daniel:// stenberg:// • • •F4GRX Sébastien
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to F4GRX Sébastien • • •F4GRX Sébastien
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to F4GRX Sébastien • • •F4GRX Sébastien
in reply to daniel:// stenberg:// • • •Apollo
in reply to daniel:// stenberg:// • • •John Deters
in reply to daniel:// stenberg:// • • •sre4ever
in reply to daniel:// stenberg:// • • •I voted “not slop” for the benefit of doubt. At least that report was reasonably concise.
Maybe you could require security issue reporters to provide a minimal Dockerfile demonstrating the issue and a screenshot of the output highlighting the failure? (and require output lines to be timestamped in that screenshot)
KasTas
in reply to daniel:// stenberg:// • • •first thing which weirded me out - long and detailed, from the looks, text. But no mentions of the specific environment (including the version of curl) "used" to "reproduce". Which should be one of the most important details, I suppose.
But yeah. Tricky as heck.
Ondřej Surý
in reply to daniel:// stenberg:// • • •I originally voted for 'not slop', but then no Debian/Ubuntu/Kali release has curl 8.13.0, so I am not sure anymore. It is probably AI-assisted thing.
curl 8.15.0-3 was in Kali rolling between 2025-05-08 and 2025-06-12;
I've tried building 8.13.0-5 package in Debian Trixie to match that one of the reporter and the memory is stable. So ... probably AI was involved.
akop
in reply to daniel:// stenberg:// • • •I voted for "No slop" because I was falsely reported (more than once) for writing AI stackoverflow answers ... 🤣
Brett Nash
in reply to daniel:// stenberg:// • • •doragasu
in reply to daniel:// stenberg:// • • •Kaito
in reply to daniel:// stenberg:// • • •hisold
in reply to daniel:// stenberg:// • • •I would assume someone would read the docs before writing such a report.
aspragg
in reply to daniel:// stenberg:// • • •Lando
in reply to daniel:// stenberg:// • • •Pretty confident an LLM was at least used to create the text. However I think this is a rare case of the user actually bothering to trim the output down so it’s readable.
If the problem were real that would be it, but you mentioned even the version they cited in the comment doesn’t exhibit the problem. For that reason I have to lean toward slop.