CVE-2026-77352 in Wallos
Summary
by MITRE • 08/31/2026
Wallos is an open-source, self-hostable personal subscription tracker. From version 2.0.0 to before version 5.0.0, any authenticated Wallos user (no admin rights required) can make the server open arbitrary outbound SMTP connections to internal/link-local addresses, by setting the SMTP host of their personal email notifications to an internal IP. The per-user notification settings endpoint (endpoints/notifications/saveemailnotifications.php) performs no SSRF validation, and the notification cron (endpoints/cronjobs/sendnotifications.php) feeds that user-controlled host straight into PHPMailer ($mail->Host = $email['smtpAddress']). When the user's subscription notification fires, the server connects to the chosen host:port. This issue has been patched in version 5.0.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/31/2026
Wallos is an open-source, self-hostable application designed for tracking personal subscriptions and recurring expenses. A significant security vulnerability exists within versions ranging from 2.0.0 up to, but not including, version 5.0.0. This flaw allows any authenticated user, regardless of their privilege level or administrative rights, to manipulate the server into establishing arbitrary outbound connections via Simple Mail Transfer Protocol (SMTP). The core issue stems from a lack of input validation on the per-user notification settings endpoint located at endpoints/notifications/saveemailnotifications.php. When users configure their personal email notifications, they can specify an SMTP host value without any restriction or sanitization process to verify if the target is external or internal.
The technical mechanism behind this vulnerability involves how the application processes user-supplied data during automated tasks. The notification cron job script at endpoints/cronjobs/sendnotifications.php retrieves the stored SMTP address for each user and directly assigns it to the Host property of PHPMailer, a widely used email sending library in PHP applications. Specifically, the code executes $mail->Host = $email['smtpAddress']. Because there is no server-side validation to ensure that the provided hostname or IP address resolves to an external public network, the application blindly trusts user input. Consequently, when a subscription notification triggers this process, the Wallos server initiates a TCP connection to whatever host and port combination was specified by the authenticated attacker.
This behavior constitutes a Server-Side Request Forgery (SSRF) vulnerability of the outbound variety. From an industry standard perspective, this aligns with CWE-918, which describes Server-Side Request Forgery where the web server makes requests on behalf of the user to internal resources that are not intended to be accessible from outside. Furthermore, in the context of the MITRE ATT&CK framework, this technique falls under T1572, Protocol Tunneling, as it involves establishing a connection through an allowed protocol (SMTP) to reach unauthorized destinations. The lack of validation allows attackers to bypass network segmentation and firewall rules that typically protect internal infrastructure from external access, effectively turning the application into a proxy for accessing private networks.
The operational impact of this vulnerability is substantial in environments where Wallos is deployed behind firewalls or within isolated network segments. An attacker can leverage this flaw to scan internal ports, probe for vulnerable services running on local interfaces such as 127.0.0.1 or link-local addresses like 169.254.x.x, and potentially interact with other internal applications that expose administrative panels or sensitive data over HTTP, FTP, or database protocols via SMTP relay mechanisms if supported by the target service. In worst-case scenarios, this could facilitate further lateral movement within a network, leading to unauthorized access to critical systems, data exfiltration, or disruption of services. The severity is heightened because it requires only basic authentication, which many users possess simply for using their own subscription tracking features.
To mitigate this risk, organizations running Wallos versions prior to 5.0.0 should immediately upgrade to version 5.0.0 or later, where the developers have implemented proper validation checks to prevent internal IP addresses from being used as SMTP hosts. For environments that cannot be updated immediately due to compatibility constraints, network-level controls are recommended. These include configuring firewalls to block outbound SMTP traffic originating specifically from the Wallos server host unless it is destined for known and approved mail relay servers. Additionally, implementing egress filtering rules that restrict connections to non-standard ports or internal IP ranges can significantly reduce the attack surface. Application-layer mitigations could also involve modifying the source code to validate the SMTP host against a whitelist of allowed domains before saving user preferences, ensuring that only legitimate external email providers are accepted for notification delivery.