- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 0
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Replies within 5 days
- As the policy promises.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Response
-
Within 5 days
Expect acknowledgement within five days and a detailed response within ten.
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
13 assets you may test, 5 excluded.
Web 1
- https://github.com/nodejs/llhttp
Products and areas 12
- Chunked body decoding: chunk sizes, chunk extensions, trailers and the terminating sequence
- Connection semantics: keep-alive, the Connection header, pipelining and the boundary between one message and the next on a reused connection
- Content-Length and Transfer-Encoding handling, and every combination of the two, including repeated and conflicting instances of either
- Every lenient flag the parser exposes and precisely what each one relaxes
- Header parsing in full, covering header-name validation, value validation, whitespace handling, obs-fold continuation lines and duplicated headers
- Memory safety of the generated C under malformed and truncated input
- Request-line parsing: method handling, the request target in origin, absolute, authority and asterisk form, and the HTTP version
- The C API surface Node core binds against, and the assumptions it makes about caller behaviour
- The generated C parser and its state machine, plus the TypeScript generator that produces it, since a defect in the generator becomes a defect in the output
- The Node.js organisation security policy applies to this repository: reports go through hackerone.com/nodejs, with an escalation path to the OpenJS Foundation CNA. No boundary narrower than the parser is drawn
- The response parser, which Node's HTTP client uses, so a defect there is exploitable by a hostile server against an outbound request
- The upgrade path for WebSocket and CONNECT, and the point where the parser hands the remaining bytes back to the caller
Out of scope (5)
- Behaviour an application deliberately opted into by enabling a documented lenient flag, unless the flag is more permissive than it is documented to be
- Node.js core code outside the parser, including undici and the http module, unless the parser is what makes the issue reachable
- Other HTTP parsers, including the archived nodejs/http-parser that llhttp replaced
- Reverse proxies and front ends as products; the disagreement between them and llhttp is in scope on the parser's side
- Third-party npm modules, which belong to the separate ecosystem programme
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Report through hackerone.com/nodejs. The Node.js organisation policy governs this repository, and the platform is now purely a coordination channel with no reward attached
-
Expect acknowledgement within five days and a detailed response within ten. If nothing has arrived after six business days, escalate to the OpenJS Foundation CNA at the address on the policy page
-
Send the exact octets, including line endings, whitespace and any duplicated or folded framing headers. A parser finding is only convincing as bytes
-
Show what llhttp does with the input and what a common front end does with the same input, because the impact of a parser defect is the disagreement rather than the parse
-
Say whether the behaviour depends on any lenient flag being enabled, since Node exposes several of them and operators turn them on for compatibility
-
Do not file on hackerone.com/nodejs-ecosystem . That programme is for third-party modules and does not cover components the Node.js project maintains itself
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Latest advisories Loading the feed Overview llhttp is the HTTP/1.1 parser written in C that is vendored into every Node.js runtime, so it parses requests for Node servers, Electron applications, serverless JavaScript platforms and most CI tooling. Node.js alone accounts for 6.8 percent of all websites. A parser in that position is the desync half of every reverse-proxy pairing in front of a Node service, and its findings land as Node.js advisories rather than under its own name. Node's policy now states that the project no longer has a bug bounty program, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The Node.js organisation security policy applies to this repository: reports go through hackerone.com/nodejs, with an escalation path to the OpenJS Foundation CNA. No boundary narrower than the parser is drawn Request-line parsing: method handling, the request target in origin, absolute, authority and asterisk form, and the HTTP version Header parsing in full, covering header-name validation, value validation, whitespace handling, obs-fold continuation lines and duplicated headers Content-Length and Transfer-Encoding handling, and every combination of the two, including repeated and conflicting instances of either Chunked body decoding: chunk sizes, chunk extensions, trailers and the terminating sequence The response parser, which Node's HTTP client uses, so a defect there is exploitable by a hostile server against an outbound request Connection semantics: keep-alive, the Connection header, pipelining and the boundary between one message and the next on a reused connection The upgrade path for WebSocket and CONNECT, and the point where the parser hands the remaining bytes back to the caller Every lenient flag the parser exposes and precisely what each one relaxes The generated C parser and its state machine, plus the TypeScript generator that produces it, since a defect in the generator becomes a defect in the output Memory safety of the generated C under malformed and truncated input The C API surface Node core binds against, and the assumptions it makes about caller behaviour Out of scope Node.js core code outside the parser, including undici and the http module, unless the parser is what makes the issue reachable Third-party npm modules, which belong to the separate ecosystem programme Other HTTP parsers, including the archived nodejs/http-parser that llhttp replaced Reverse proxies and front ends as products; the disagreement between them and llhttp is in scope on the parser's side Behaviour an application deliberately opted into by enabling a documented lenient flag, unless the flag is more permissive than it is documented to be Most-valued findings Request smuggling and desync in any form: CL.TE, TE.CL, duplicated Transfer-Encoding, chunk-extension handling or line-ending tricks. This is where the parser's historical findings land and it is the reason the target is interesting at all Any input llhttp accepts that a mainstream front end rejects, or the reverse, because Node services sit behind nginx, HAProxy and cloud load balancers by default Header name or value validation gaps that let a header be injected into the parsed structure the JavaScript layer then reads as trustworthy Memory safety in the generated C under malformed input, since this is the first code in the runtime to touch untrusted bytes and it runs before any JavaScript does Parser state that survives a message boundary on a keep-alive connection and changes how the next request is read Lenient-flag behaviour that relaxes more than the documentation says, since operators enable those flags to accommodate legacy clients and assume a bounded cost Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report through hackerone.com/nodejs. The Node.js organisation policy governs this repository, and the platform is now purely a coordination channel with no reward attached Expect acknowledgement within five days and a detailed response within ten. If nothing has arrived after six business days, escalate to the OpenJS Foundation CNA at [email protected] Send the exact octets, including line endings, whitespace and any duplicated or folded framing headers. A parser finding is only convincing as bytes Show what llhttp does with the input and what a common front end does with the same input, because the impact of a parser defect is the disagreement rather than the parse Say whether the behaviour depends on any lenient flag being enabled, since Node exposes several of them and operators turn them on for compatibility Do not file on hackerone.com/nodejs-ecosystem . That programme is for third-party modules and does not cover components the Node.js project maintains itself There is no money here. The Node.js bounty is gone and no fund has replaced it Disclosure Run by the Node.js security team through HackerOne with a documented embargo and CVE process, and published on the Node.js security release schedule rather than on this repository. The repository itself has never published an advisory, so a finding here surfaces as a Node.js security release and a Node CVE, and the embargo runs to that release across every supported Node line at once. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability