CVE-2026-33399
Received Received - Intake
Incomplete SSRF Fix in Wallos Notification Save Endpoints

Publication date: 2026-03-24

Last updated on: 2026-03-26

Assigner: GitHub, Inc.

Description
Wallos is an open-source, self-hostable personal subscription tracker. Prior to version 4.7.0, the SSRF fix applied in version 4.6.2 for CVE-2026-30839 and CVE-2026-30840 is incomplete. The validate_webhook_url_for_ssrf() protection was added to the test* notification endpoints but not to the corresponding save* endpoints. An authenticated user can save an internal/private IP address as a notification URL, and when the cron job sendnotifications.php executes, the request is sent to the internal IP without any SSRF validation. This issue has been patched in version 4.7.0.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-24
Last Modified
2026-03-26
Generated
2026-05-27
AI Q&A
2026-03-24
EPSS Evaluated
2026-05-25
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
wallosapp wallos to 4.7.0 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-918 The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

[{'type': 'paragraph', 'content': "CVE-2026-33399 is a Server-Side Request Forgery (SSRF) vulnerability in Wallos, an open-source personal subscription tracker. Before version 4.7.0, the SSRF protections were incomplete because the validation function validate_webhook_url_for_ssrf() was only applied to test notification endpoints but not to the save notification endpoints. This allowed an authenticated user to save an internal or private IP address as a notification URL. When the system's cron job executed, it sent requests to these internal IPs without any SSRF validation, potentially allowing unauthorized internal network access."}, {'type': 'paragraph', 'content': 'The vulnerability was patched in version 4.7.0 by adding comprehensive SSRF protections across multiple endpoints, including validation of URL schemes, whitelist checks against private IP ranges, and controlled DNS resolution to prevent exploitation.'}] [1]


How can this vulnerability impact me? :

This SSRF vulnerability can allow an authenticated user to make the Wallos server send requests to internal or private IP addresses that are normally inaccessible from outside. This can lead to unauthorized access to internal network resources, potentially exposing sensitive data or enabling further attacks within the internal network.

Since the vulnerability allows bypassing network restrictions, it can be exploited to scan internal services, access internal APIs, or trigger actions on internal systems, which could compromise the confidentiality and security of the affected environment.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring for notification URLs saved via the save* endpoints that point to internal or private IP addresses. Since the vulnerability allows an authenticated user to save internal/private IP addresses as notification URLs, checking the database entries for such URLs is a key detection method.'}, {'type': 'paragraph', 'content': 'Additionally, observing the cron job sendnotifications.php making HTTP requests to internal IP addresses or cloud metadata endpoints (e.g., 169.254.169.254) can indicate exploitation attempts.'}, {'type': 'paragraph', 'content': 'Suggested commands include querying the database for notification URLs that resolve to private IP ranges or internal addresses. For example, if the notification URLs are stored in a database table, you can run SQL queries to find URLs containing private IP ranges such as 10.x.x.x, 172.16.x.x - 172.31.x.x, or 192.168.x.x.'}, {'type': 'list_item', 'content': "SQL example: SELECT * FROM notification_urls WHERE url LIKE 'http://10.%' OR url LIKE 'http://192.168.%' OR url LIKE 'http://172.16.%' OR url LIKE 'http://172.17.%' OR url LIKE 'http://172.18.%' OR url LIKE 'http://172.19.%' OR url LIKE 'http://172.20.%' OR url LIKE 'http://172.21.%' OR url LIKE 'http://172.22.%' OR url LIKE 'http://172.23.%' OR url LIKE 'http://172.24.%' OR url LIKE 'http://172.25.%' OR url LIKE 'http://172.26.%' OR url LIKE 'http://172.27.%' OR url LIKE 'http://172.28.%' OR url LIKE 'http://172.29.%' OR url LIKE 'http://172.30.%' OR url LIKE 'http://172.31.%';"}, {'type': 'list_item', 'content': 'Network monitoring commands such as tcpdump or Wireshark can be used to detect outgoing HTTP requests from the cron job to internal IP addresses.'}] [1]


What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation step is to upgrade Wallos to version 4.7.0 or later, where the SSRF fix has been fully applied to all save* notification endpoints.

If upgrading is not immediately possible, apply the validate_webhook_url_for_ssrf() function to all save* notification endpoints to ensure URLs are validated against private IP ranges before being saved.

Additionally, implement SSRF validation during the execution of sendnotifications.php as a defense-in-depth measure to prevent requests to internal IP addresses.

Restrict access to the save* endpoints to trusted authenticated users only, and audit existing notification URLs for any internal or private IP addresses.

Consider temporarily disabling the cron job sendnotifications.php or manually reviewing and cleaning notification URLs until the patch or mitigation is applied.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart