Listmonk Vulnerability Disclosure

generated: '2026-08-13'
method: searched
source: >-
  https://listmonk.app/docs/security-reports/ ,
  https://github.com/knadh/listmonk/blob/master/SECURITY.md , and
  https://github.com/knadh/listmonk/security/policy (HTTP 200, probed 2026-08-13)
description: >-
  listmonk publishes a real, deliberate vulnerability disclosure policy. It is
  not served at /.well-known/security.txt — that path 404s on every listmonk host
  (see well-known/listmonk-well-known.yml) — but it exists in two places the
  project controls: a SECURITY.md in the repository root, which GitHub renders as
  the repo's security policy, and a dedicated /docs/security-reports/ page on
  listmonk.app. The docs page is unusually specific: rather than only saying how
  to report, it enumerates five classes of finding the project has decided are
  NOT vulnerabilities, with a written rationale for each. That is a stronger
  disclosure posture than most self-hosted projects publish, and it is what the
  `Security` pointer in apis.yml points at.
program:
  type: coordinated-disclosure
  bug_bounty: false
  paid: false
  platform: github-security-advisories
  intake_url: https://github.com/knadh/listmonk/security/advisories
  policy_url: https://listmonk.app/docs/security-reports/
  repo_policy_url: https://github.com/knadh/listmonk/blob/master/SECURITY.md
  security_txt: false
  safe_harbor_published: false
  response_sla: null
  scope_note: >-
    Reporters are asked to read the acceptable-risk list first. Reports falling
    into those classes are explicitly unwanted.
out_of_scope:
  - id: sql-injection-via-subscriber-query
    title: SQL injection via the subscriber `query` parameter
    rationale: >-
      Arbitrary read-only SQL expressions are a deliberate segmentation feature
      gated behind the `subscribers:sql_query` permission. Postgres offers no
      practical way to allow/deny specific functions, so the mitigation is
      permission hygiene, documented at /docs/roles-and-permissions/.
  - id: stored-xss-via-svg
    title: Stored XSS via uploaded SVG / HTML / JS
    rationale: >-
      listmonk stores uploaded files untransformed by design. Administrators
      choose permitted file types under Admin -> Settings -> Media.
  - id: stored-xss-in-campaign-html
    title: Stored XSS in campaign HTML
    rationale: >-
      listmonk is a full HTML CMS; arbitrary <script> in a published archive page
      is expected behaviour. Previews are iframe-sandboxed in the admin.
  - id: redos-dos-in-templating
    title: ReDoS / DoS in Go templating
    rationale: >-
      Templates expose the full Go template language plus Sprig functions and are
      Turing-complete by design; grant template permissions only to trusted users.
  - id: csv-formula-injection
    title: CSV formula injection in subscriber export
    rationale: >-
      Cited as difficult to mitigate and commonly excluded from bounty programs
      (OWASP). listmonk will not restrict leading formula characters in names.
track_record:
  advisories_url: https://github.com/knadh/listmonk/security/advisories
  known_cves:
    - id: CVE-2025-58430
      fixed_in: v5.1.0
      fixed_date: '2025-09-09'
      summary: CSRF prevention. Disclosed and fixed in a versioned release.
  security_releases:
    - version: v6.2.0
      date: '2026-06-26'
      summary: Fixes for multiple campaign/list permission validation issues in multi-user environments.
    - version: v6.1.0
      date: '2026-03-29'
      summary: Fixes for multiple campaign/list permission validation issues in multi-user environments.
  note: >-
    Security fixes are announced in the release notes under their own "Security"
    heading, so a self-hosting operator watching releases sees them.
gaps:
  - No /.well-known/security.txt on listmonk.app or demo.listmonk.app (RFC 9116).
  - No published response-time commitment or safe-harbour statement.
  - No bug bounty; disclosure is unpaid and volunteer-triaged.