Description

Wallos is an open-source, self-hostable personal subscription tracker. Prior to version 5.0.0, Wallos lets any authenticated user store an arbitrary SMTP host — including private and cloud-metadata IP addresses — in their personal email notification settings, with no server-side SSRF validation. When the scheduled notification cron job runs, it passes the stored host directly to PHPMailer, causing the Wallos server to open an outbound TCP connection to whatever address the attacker specified. This gives a low-privileged attacker a reliable mechanism to probe internal network services from the server's perspective. This issue has been patched in version 5.0.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.5",
  "pubDate": "2026-08-31T22:17:20.467Z",
  "pubdate": "2026-08-31T22:17:20.467Z",
  "executiveSummary": "Wallos versions prior to 5.0.0 contain a Server-Side Request Forgery (SSRF) vulnerability originating from insecure handling of SMTP configuration parameters. The vulnerability allows an authenticated user to specify arbitrary hostnames or IP addresses, including those within internal networks or cloud provider metadata services, for email notification settings.\nThe root cause is a lack of server-side validation for user-supplied SMTP host configurations, which are subsequently processed by the PHPMailer library during scheduled cron job execution. By manipulating the SMTP host, a low-privileged attacker can force the Wallos server to initiate outbound TCP connections to internal infrastructure that would otherwise be inaccessible from the public internet.\nThis vulnerability poses a significant risk as it enables attackers to perform internal reconnaissance, port scanning, and potentially interact with internal services or APIs accessible from the host server. Successful exploitation requires an authenticated account, but no additional privileges are necessary to configure the notification settings. The issue has been addressed in version 5.0.0, and users are advised to upgrade immediately to mitigate potential post-exploitation threats against the host network.",
  "technicalDetails": "The vulnerability resides in the SMTP notification configuration module of Wallos. The application allows users to define custom SMTP server parameters, including the destination host address, to facilitate email notifications for subscription updates. The application fails to implement input sanitization or validation logic on the 'host' field before storing it in the database and passing it to the mailer utility.\nThe exploitation flow begins when an authenticated user updates their personal email notification settings with a malicious SMTP host string. This string can point to local services (e.g., 127.0.0.1), private network subnets (e.g., 10.x.x.x, 192.168.x.x), or cloud metadata endpoints (e.g., 169.254.169.254). Because the server-side code does not employ an allowlist or blocklist for destination addresses, the malicious configuration is accepted and saved.\nThe vulnerability is triggered during the execution of the scheduled cron job responsible for dispatching email notifications. When this background process executes, it retrieves the attacker-supplied SMTP host from the database and passes it to the PHPMailer object. The library, acting on behalf of the Wallos application, attempts to establish a TCP connection to the specified target to perform an SMTP handshake.\nEven if the SMTP handshake fails due to protocol mismatches, the initial TCP connection attempt allows an attacker to probe the internal environment. By analyzing server response times or error messages returned by the application (if leaked), an attacker can conduct port scanning or service discovery. In cloud environments, this may lead to the unauthorized retrieval of instance metadata or identity tokens if the application environment permits such access.\nThe technical impact is effectively a blind SSRF, where the server becomes a proxy for the attacker's network traffic. This bypasses typical perimeter defenses, as the connection originates from the trusted application server. The vulnerability is present in all versions prior to 5.0.0 and requires valid authentication as any user level to modify the SMTP configuration. The process does not require high-level administrative access, as the setting is scoped to personal notification preferences, significantly expanding the potential attack surface."
}