Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-31T22:17:20.607Z",
  "pubdate": "2026-08-31T22:17:20.607Z",
  "executiveSummary": "Wallos versions 2.0.0 through 4.x are vulnerable to a Server-Side Request Forgery (SSRF) vulnerability due to improper validation of SMTP server configurations. This flaw allows any authenticated user to force the application server to initiate outbound SMTP connections to arbitrary network destinations, including internal and link-local addresses. By manipulating the notification settings, an attacker can leverage the server's network context to perform service discovery, interact with internal APIs, or probe restricted network segments that are otherwise inaccessible from the public internet. The risk is significant in containerized or internal network environments where the application server acts as a proxy for internal service interaction. Exploitation requires authenticated access to a user account, but does not necessitate administrative privileges. The vulnerability has been remediated in version 5.0.0.",
  "technicalDetails": "The vulnerability resides in the way Wallos processes user-defined SMTP notification settings. Specifically, the script located at endpoints/notifications/saveemailnotifications.php accepts user-provided SMTP host configurations without performing any verification or allow-listing of the destination IP addresses or hostnames. This lack of input validation permits the configuration of sensitive internal addresses, such as those within the 127.0.0.0/8 range, 169.254.0.0/16 (link-local), or private RFC 1918 address spaces.\nThe attack flow initiates when an authenticated user modifies their profile's email notification settings, setting the 'smtpAddress' to an internal target. When the notification cron job executes via endpoints/cronjobs/sendnotifications.php, the application retrieves the user-controlled host and directly assigns it to the PHPMailer object instance: $mail->Host = $email['smtpAddress']. When the subscription notification logic triggers, PHPMailer attempts to establish a TCP connection to the attacker-supplied host and port.\nBecause the server-side code performs no sanitization or restriction on the '$mail->Host' property before instantiation, the underlying system makes an outbound socket request. This capability enables an attacker to perform internal port scanning, fingerprint internal services by observing response behavior, or potentially exploit non-SMTP services if they are capable of responding to the initial connection handshake or malformed SMTP commands sent by the PHPMailer library.\nThe impact of this SSRF is elevated by the application's environment; if the Wallos instance is deployed within a cloud environment or a restricted VPC, the attacker can leverage the server as a pivot point to interact with metadata services or internal microservices that assume implicit trust from internal traffic. The vulnerability is confirmed in versions 2.0.0 through before 5.0.0. Exploitation is limited to authenticated users; however, since Wallos is a self-hosted application where user registration is often open or easily attainable, the barrier to exploitation is low. The issue is fundamentally a lack of architectural separation between user-controlled data and network-level configurations in the application's notification subsystem."
}