- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 11
- 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 3 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 3 days
Expect an acknowledgement inside 72 hours.
- 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
11 assets you may test, 6 excluded.
Web 1
- https://github.com/haraka/Haraka
Products and areas 10
- Any HTTP or management interface an operator can enable, along with the authentication in front of it
- AUTH handling and the relay decision: who may send mail through this server, and to where
- Message parsing in full, covering headers, MIME structure, encoded words, RFC 2231 parameter handling and the body decoders that run over attacker-supplied content
- Outbound queuing and delivery, including retry handling and anything a remote server's response can influence
- Resource limits across connection handling, since a single session able to pin a worker takes the server down for everyone else on it
- The JavaScript object model where it meets untrusted input: header names and structured fields that become object keys, the surface CVE-2026-34752 sat in
- The plugin API and the plugins that ship with the server, including the authentication backends and the sender-validation checks
- The published policy asks for confidential reports through GitHub private vulnerability reporting and publishes a threat model naming the SMTP listener and the message content it parses. Nothing narrower is carved out
- The SMTP command state machine: the full sequence from connection through EHLO, MAIL, RCPT and DATA, including pipelining and every transition between states
- TLS and STARTTLS handling, together with the point at which a connection is treated as secure
Out of scope (6)
- Node.js runtime defects and npm dependency CVEs, unless Haraka's own use of them is what makes the defect reachable
- Operator configuration: an open relay someone configured deliberately is a decision rather than a defect
- Public GitHub issues for security matters, since the policy asks for the confidential channel instead
- The policy publishes no exclusions list, so what follows is ordinary out-of-scope territory rather than a stated policy position
- Third-party plugins written outside the Haraka organisation
- Volumetric denial of service. A single crafted session that pins a worker is the interesting case; sending a million messages is not
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Submit through sorona.xyz.
-
Report through GitHub private vulnerability reporting on haraka/Haraka , the channel the policy names and one that is confirmed switched on
-
Read the published threat model first.
-
Say whether your finding needs authentication.
-
Separate core from plugin.
Not accepted
-
Third-party plugins written outside the Haraka organisation
-
Node.js runtime defects and npm dependency CVEs, unless Haraka's own use of them is what makes the defect reachable
-
Operator configuration: an open relay someone configured deliberately is a decision rather than a defect
-
Volumetric denial of service
-
Public GitHub issues for security matters
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 CVE history 2 Last 12 months Denial of service 50 % Parsing/validation 25 % Prototype pollution 15 % Auth and relay 10 % Latest advisories Loading the feed Overview Haraka is an SMTP server written in Node.js and built as a plugin host, so operators bolt their own filtering and routing directly onto the mail path. It runs as the inbound edge for mail providers and for products that need to accept SMTP at volume, meaning it takes connections from anyone on the internet and parses their commands and message bodies before authentication happens at all. CVE-2026-34752 shows what that costs: an email header named proto was enough to take the server down. The project publishes a real disclosure policy and no money whatsoever, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy asks for confidential reports through GitHub private vulnerability reporting and publishes a threat model naming the SMTP listener and the message content it parses. Nothing narrower is carved out The SMTP command state machine: the full sequence from connection through EHLO, MAIL, RCPT and DATA, including pipelining and every transition between states Message parsing in full, covering headers, MIME structure, encoded words, RFC 2231 parameter handling and the body decoders that run over attacker-supplied content The plugin API and the plugins that ship with the server, including the authentication backends and the sender-validation checks TLS and STARTTLS handling, together with the point at which a connection is treated as secure AUTH handling and the relay decision: who may send mail through this server, and to where Outbound queuing and delivery, including retry handling and anything a remote server's response can influence The JavaScript object model where it meets untrusted input: header names and structured fields that become object keys, the surface CVE-2026-34752 sat in Resource limits across connection handling, since a single session able to pin a worker takes the server down for everyone else on it Any HTTP or management interface an operator can enable, along with the authentication in front of it Out of scope The policy publishes no exclusions list, so what follows is ordinary out-of-scope territory rather than a stated policy position Third-party plugins written outside the Haraka organisation Node.js runtime defects and npm dependency CVEs, unless Haraka's own use of them is what makes the defect reachable Operator configuration: an open relay someone configured deliberately is a decision rather than a defect Volumetric denial of service. A single crafted session that pins a worker is the interesting case; sending a million messages is not Public GitHub issues for security matters, since the policy asks for the confidential channel instead Most-valued findings Anything reachable before authentication. Both of the past year's advisories are available to anyone who can open an SMTP connection, and that is the shape this project keeps producing Algorithmic complexity in the parsers. GHSA-6f4j-gpc2-6p2g was quadratic behaviour in _parse_rfc2231 that blocked the SMTP worker outright, and the MIME and header parsers are full of comparable loops Prototype pollution driven by message data. CVE-2026-34752 needed nothing more than a header named proto , so every place a header name becomes an object key is the same bug waiting to be found Anything turning a parsing defect into memory corruption or code execution rather than a stall, since that would be a step change on this project's record Relay-decision bypass: getting the server to accept and deliver mail for a domain it does not serve, or as a sender it should refuse Authentication bypass through the AUTH plugins, where a credential check returns success on input it should reject Protocol confusion between what Haraka accepts as end-of-data and what the next hop accepts, since two implementations disagreeing is how message boundaries get forged 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 GitHub private vulnerability reporting on haraka/Haraka , the channel the policy names and one that is confirmed switched on Expect an acknowledgement inside 72 hours. The policy commits to that and points at CERT coordinated vulnerability disclosure for the process that follows Read the published threat model first. It states plainly that the server accepts connections from strangers and parses their SMTP commands and message content, which sets the bar for what counts as interesting Say whether your finding needs authentication. Both advisories from the past year are reachable by anyone who can open an SMTP session, and that is the class the maintainers care about most Separate core from plugin. Haraka is a plugin host, and a defect in a bundled plugin is a different report from one in the SMTP engine Advisory credit is guaranteed by the policy; there is no payment to negotiate Disclosure Coordinated through GitHub private vulnerability reporting against a 72-hour acknowledgement target, then published as a GitHub Security Advisory alongside a release. The policy points at the CERT coordinated vulnerability disclosure model rather than publishing its own day count, and it promises credit to the reporter in writing. Both advisories from the past year shipped that way, so the process is exercised rather than theoretical. 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