- 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.
- 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 |
- 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://listmonk.app
Products and areas 10
- Bounce and webhook processing, where a remote mail server or delivery provider supplies the input
- Campaign templating and message rendering, on both the HTML and plain-text paths
- Media upload and storage, covering the filesystem and object-storage backends and the URLs they hand back
- SMTP and messenger configuration handling, since the instance holds the credentials for whatever actually sends the mail
- Subscriber import and export, including file parsing on the way in and query handling on the way out
- The admin panel in full: authentication, session handling, every settings page and every action an operator can take from it
- The public-facing pages: subscription forms, the double opt-in confirmation flow, preference management and unsubscribe links, none of which need an account at all
- The published policy asks for security vulnerabilities in listmonk through GitHub security advisories, and pairs that with an explicit list of classes it has decided are not vulnerabilities. Everything inside the product and outside that list is fair game
- The user and role model, covering per-list permissions and what one non-superadmin account can reach of another's data
- The whole HTTP API, including the subscriber, list, campaign, template and media endpoints, and the API-key authentication in front of them
Out of scope (6)
- CSV formula injection in exports, ruled out by name
- Operator configuration, including an instance deliberately published without authentication in front of it
- Regular-expression denial of service in the templating engine, ruled out by name
- SQL injection through the subscriber-query feature, a deliberate capability the admin role is meant to have. The project rules it out by name
- Stored cross-site scripting delivered through SVG uploads, ruled out by name in the same published list
- Upstream Go libraries and Postgres itself, unless listmonk's own use of them is what makes the defect reachable
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 security advisories on knadh/listmonk
-
Read the project's what-not-to-report list before you start.
-
Say which role your finding needs.
-
Include the version.
Not accepted
-
SQL injection through the subscriber-query feature
-
Stored cross-site scripting delivered through SVG uploads
-
Regular-expression denial of service in the templating engine
-
CSV formula injection in exports
-
Discovering that it runs SQL is not a finding
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 5 Last 12 months Account takeover chains 40 % Access control 25 % Session management 20 % SQL injection 15 % Latest advisories Loading the feed Overview listmonk is a self-hosted newsletter and mailing-list manager written in Go on top of Postgres, and it has the largest audience of anything in its category. A running instance holds a subscriber database and the credentials for whatever relay actually sends the mail, with an admin panel and public subscription pages both reachable from the internet. CVE-2025-58430 is the reference point: a cross-site request forgery chained into stored scripting handed an attacker the admin account outright, rated critical. The project pays nothing for a report and publishes no reward terms of any kind, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy asks for security vulnerabilities in listmonk through GitHub security advisories, and pairs that with an explicit list of classes it has decided are not vulnerabilities. Everything inside the product and outside that list is fair game The admin panel in full: authentication, session handling, every settings page and every action an operator can take from it The whole HTTP API, including the subscriber, list, campaign, template and media endpoints, and the API-key authentication in front of them The public-facing pages: subscription forms, the double opt-in confirmation flow, preference management and unsubscribe links, none of which need an account at all The user and role model, covering per-list permissions and what one non-superadmin account can reach of another's data Campaign templating and message rendering, on both the HTML and plain-text paths Subscriber import and export, including file parsing on the way in and query handling on the way out Media upload and storage, covering the filesystem and object-storage backends and the URLs they hand back Bounce and webhook processing, where a remote mail server or delivery provider supplies the input SMTP and messenger configuration handling, since the instance holds the credentials for whatever actually sends the mail Out of scope SQL injection through the subscriber-query feature, a deliberate capability the admin role is meant to have. The project rules it out by name Stored cross-site scripting delivered through SVG uploads, ruled out by name in the same published list Regular-expression denial of service in the templating engine, ruled out by name CSV formula injection in exports, ruled out by name Upstream Go libraries and Postgres itself, unless listmonk's own use of them is what makes the defect reachable Operator configuration, including an instance deliberately published without authentication in front of it Most-valued findings Admin account takeover, which is what this project's record is actually made of. CVE-2025-58430 chained cross-site request forgery into stored scripting to get there and was rated critical; CVE-2026-21483 arrived at the same place through stored scripting alone Stored scripting anywhere the admin panel renders subscriber-controlled or campaign-controlled data, since that is the first link in the chain above. Note that the SVG path is explicitly out of scope Session lifecycle defects. CVE-2026-34828 left sessions valid after a password reset, meaning a compromised account stays compromised through the obvious remediation Permission-model bypass across lists and roles, the class CVE-2026-34584 landed in, and the one that matters most on instances shared between teams SQL injection anywhere outside the deliberate subscriber-query feature. CVE-2026-62361 sat in the subscriber export endpoint and bypassed table access control, which is a real finding in a way the query box is not Anything unauthenticated on the public subscription pages, since every instance exposes them by design Access to the configured SMTP or provider credentials, since an instance holds sending credentials for a domain other people trust 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 security advisories on knadh/listmonk ; the security page names that channel and private reporting is switched on Read the project's what-not-to-report list before you start. It rules out SQL injection through the subscriber-query feature, stored scripting via SVG, ReDoS in templating and CSV formula injection, all by name and all with argued reasoning The subscriber query box is a deliberate capability that runs SQL as the admin. Discovering that it runs SQL is not a finding Say which role your finding needs. listmonk has a permission model over lists and users, and a bypass of it is a different severity from something only a superadmin can reach Include the version. The project ships often and the recent record is dense enough that an old build produces duplicates There is no payment to negotiate: the project publishes no bounty and no reward terms Disclosure Coordinated through GitHub security advisories and published as GHSAs alongside a release. The maintainer runs a considered triage process, evidenced by a published list of classes the project has decided are not vulnerabilities, so expect a reasoned response rather than a form reply. No day count is published; the practical embargo runs to the release carrying the fix. 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