CVE-2026-33399: Wallosapp Wallos SSRF Vulnerability

CVE-2026-33399 Overview

CVE-2026-33399 is a Server-Side Request Forgery (SSRF) vulnerability affecting Wallos, an open-source, self-hostable personal subscription tracker. This vulnerability exists due to an incomplete fix for previously identified SSRF issues (CVE-2026-30839 and CVE-2026-30840) that were addressed in version 4.6.2. The validate_webhook_url_for_ssrf() protection was added to the test notification endpoints but was not applied to the corresponding save endpoints, allowing authenticated attackers to bypass SSRF protections and access internal network resources.

Critical Impact

Authenticated users can exploit this SSRF bypass to access internal services, potentially exposing sensitive data from systems that should not be publicly accessible.

Affected Products

• Wallos versions prior to 4.7.0
• wallosapp wallos (all versions before security patch)
• Self-hosted Wallos instances with notification functionality enabled

Discovery Timeline

• 2026-03-24 - CVE CVE-2026-33399 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33399

Vulnerability Analysis

This SSRF vulnerability stems from an inconsistent application of security controls across related code paths. When the Wallos development team addressed CVE-2026-30839 and CVE-2026-30840 in version 4.6.2, they implemented the validate_webhook_url_for_ssrf() function to prevent users from specifying internal or private IP addresses as notification webhook URLs. However, this validation was only applied to the test notification endpoints (test* endpoints) and not to the save notification endpoints (save* endpoints).

This oversight creates a time-of-check time-of-use (TOCTOU) style bypass. An attacker can directly save an internal IP address as a notification URL without triggering SSRF validation. When the cron job sendnotifications.php executes to deliver scheduled notifications, it processes the saved notification URL without re-validating it, sending requests to internal network addresses.

Root Cause

The root cause is incomplete patch coverage where SSRF validation was selectively applied to testing endpoints but omitted from the corresponding save endpoints. This indicates a gap in the secure development lifecycle where all code paths handling user-supplied URLs were not comprehensively reviewed and hardened. The save endpoints bypass the validation entirely, allowing persistence of malicious internal URLs in the application's configuration.

Attack Vector

The attack is network-based and requires low-privilege authentication. An authenticated user can exploit this vulnerability by:

1. Authenticating to the Wallos application with a valid user account
2. Navigating to notification configuration settings
3. Submitting a save request directly to the save endpoint with an internal/private IP address (e.g., http://192.168.1.1/, http://10.0.0.1/, or http://169.254.169.254/ for cloud metadata services)
4. Waiting for the sendnotifications.php cron job to execute, which sends the request to the internal IP without SSRF validation

The attack allows reading responses from internal services, potentially exposing cloud metadata, internal APIs, or other sensitive network resources. For detailed technical analysis, refer to the GitHub Security Advisory GHSA-mfjc-3258-cq3j.

Detection Methods for CVE-2026-33399

Indicators of Compromise

• Notification configurations containing private IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x)
• Webhook URLs pointing to localhost (127.0.0.1) or cloud metadata endpoints (169.254.169.254)
• Unusual outbound requests from the Wallos server to internal network segments during cron execution
• Audit log entries showing notification URL changes to non-public IP addresses

Detection Strategies

• Implement network monitoring to detect outbound connections from the Wallos server to RFC 1918 private address spaces
• Configure web application firewall (WAF) rules to alert on SSRF patterns in notification-related POST requests
• Monitor database tables storing notification configurations for internal IP address patterns
• Review sendnotifications.php execution logs for requests to internal resources

Monitoring Recommendations

• Enable comprehensive logging for all notification endpoint interactions including both test and save operations
• Set up alerts for any outbound requests from the application server to private IP ranges or cloud metadata endpoints
• Implement periodic audits of stored notification URLs in the database for compliance with allowed URL policies
• Monitor cron job execution for unexpected network behavior or latency indicative of internal scanning

How to Mitigate CVE-2026-33399

Immediate Actions Required

• Upgrade Wallos to version 4.7.0 or later immediately
• Audit existing notification configurations for any stored internal/private IP addresses
• Remove or update any suspicious notification URLs found during the audit
• Restrict network egress from the Wallos server to only necessary external destinations

Patch Information

The vulnerability has been patched in Wallos version 4.7.0. The fix ensures that validate_webhook_url_for_ssrf() is consistently applied to both test and save notification endpoints, preventing storage of internal URLs. The patch can be reviewed in the official GitHub commit.

Workarounds

• Implement network-level controls to block outbound requests from the Wallos server to private IP ranges
• Use a reverse proxy or WAF to validate and filter notification URL submissions before they reach the application
• Restrict user permissions to minimize the number of accounts that can configure notifications
• Disable notification functionality entirely if not required until patching is complete

# Example: Block outbound traffic to private IPs using iptables
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -d 169.254.0.0/16 -j DROP