Bug Report: Unauthorized Subscription via UUID in Private List

[cpanti]

Version:
Listmonk: v4.1.0
Installation method: Docker (updated from 2.5)
Description of the bug and steps to reproduce:
Even with "All lists are private", "Enable public subscription page OFF", and "Enable public mailing list archive OFF", a malicious actor was able to subscribe an email to a double opt-in list by directly using the list's UUID.

The attacker sent a POST request to /subscription/form with the correct UUID of my list.
The system accepted the subscription request, despite the list being private.
The subscriber received a "Confirm Subscription" email, proving that the request was processed.
The UUID appears to have been from an older version.
Steps to Reproduce:
Set up Listmonk with:
All lists set to private
Public subscription page disabled
Double opt-in enabled

Make a POST request to /subscription/form using the UUID of the private list:
`Intrusion attempt - Data: POST /subscription/form HTTP/1.1
cf-ray:
x-forwarded-for: <Intrusion_ip>
Host: <your_listmonk_host>
CF-IPCountry: BG
accept-encoding: gzip
Upgrade-Insecure-Requests: 1
X-Forwarded-Proto: https
Content-Type: application/x-www-form-urlencoded
Cache-Control: max-age=0
CF-Visitor: {"scheme":"https"}
Accept-Language: en-US,en;q=0.9
Accept: /
CF-Connecting-IP: <Intrusion_ip>
cdn-loop: cloudflare; loops=1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Connection: Keep-Alive
Content-Length: 119
X-Forwarded-Host: <your_listmonk_host>
X-Forwarded-Proto: https
X-Forwarded-For:

email=[email protected]&l=<UUID_OF_PRIVATE_LIST>&name=Test&nonce=`

basically a POST /subscription/form HTTP/1.1
Host: <your_listmonk_host>
Content-Type: application/x-www-form-urlencoded
email=[email protected]&l=<UUID_OF_PRIVATE_LIST>&name=Test&nonce=

The email [email protected] will receive a confirmation email, even though the subscription page is disabled.

Expected Behavior:
If a list is private, the system should reject unauthorized subscription attempts.
API-based subscriptions should require authentication unless explicitly allowed.

Actual Behavior:
Subscriptions succeed if the attacker knows the UUID of the list.
Screenshots / Logs:
If needed, I can provide logs showing the unauthorized subscription attempt.

[cpanti]

Update to the Open Ticket: Unauthorized Subscription via UUID in Private Lists

I have implemented the following solution to mitigate the issue:

• Made the list public (changed its UUID for security reasons).
• Enabled "Public subscription page", but secured it with hCaptcha.
• The attacker can no longer bypass the subscription page due to hCaptcha validation.
• I now use /api/public/subscription to handle subscriptions from my website (WordPress).
• On my WordPress form, I have integrated reCAPTCHA v3 for additional protection.

Issues That Need to Be Fixed in Listmonk:
-A private list should not allow subscriptions via API without authentication.
Currently, knowing the UUID is enough to subscribe, even if the list is private.
-With "Enable public subscription page" OFF, /subscription/form should not accept new subscribers.
If the public subscription page is disabled, Listmonk should not process /subscription/form requests at all.