CVE-2026-61638 in Wallos
Summary
by MITRE • 09/01/2026
Wallos is an open-source, self-hostable personal subscription tracker. Prior to version 4.9.6, POST /endpoints/notifications/testemailnotifications.php accepts smtpaddress and smtpport from POST body with zero SSRF validation. PHPMailer connects to attacker-supplied host:port. Every other notification endpoint uses ssrf_helper.php but email was missed. Any authenticated user can probe internal network, cloud metadata. This issue has been patched in version 4.9.6.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in Wallos prior to version 4.9.6 represents a critical Server-Side Request Forgery (SSRF) flaw rooted in insufficient input validation within the application's notification subsystem. Wallos is an open-source, self-hosted personal subscription tracker that allows users to manage recurring expenses and services. The specific weakness resides in the POST /endpoints/notifications/testemailnotifications.php endpoint, which accepts smtpaddress and smtpport parameters directly from the HTTP request body without implementing any validation mechanisms to restrict these values to legitimate mail servers or internal network ranges. This oversight stands in stark contrast to other notification endpoints within the same application, which correctly utilize a dedicated ssrf_helper.php module designed to mitigate such risks by enforcing strict allowlists or blocking private IP addresses and cloud metadata service IPs.
From a technical perspective, the flaw exploits the behavior of PHPMailer, the library used for sending emails. When an authenticated user submits a request containing maliciously crafted smtpaddress and smtpport values, PHPMailer attempts to establish a connection with the specified host and port on behalf of the server. Because there is no SSRF protection in place for this specific endpoint, attackers can direct the application to connect to arbitrary destinations. This capability allows the attacker to probe internal network services that are not exposed to the public internet, such as database servers, administrative interfaces, or IoT devices within the local area network. Furthermore, it enables access to cloud provider metadata endpoints, which often contain sensitive credentials and configuration details for running instances.
The operational impact of this vulnerability is significant due to its potential for lateral movement and information disclosure. An authenticated attacker can leverage this SSRF vector to map out the internal network topology by scanning common ports on various IP addresses returned from successful connections or timeouts. In cloud environments, accessing metadata services like those found at 169.254.169.254 for AWS or similar endpoints in Azure and GCP can lead to the compromise of instance credentials, potentially granting full control over cloud resources. This vulnerability effectively bypasses network perimeter defenses because the requests originate from a trusted internal server IP address, making them appear legitimate to firewalls and intrusion detection systems that rely on source IP reputation rather than payload inspection for this specific traffic type.
This issue aligns with CWE-918, which defines Server-Side Request Forgery (SSRF) flaws where a web application fetches a remote resource without validating the user-supplied URL or host. Additionally, it maps to MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle or Lateral Tool Transfer scenarios where SSRF is used as a pivot point for further exploitation. The root cause is identified as CWE-20, Improper Input Validation, resulting from inconsistent security implementation across different modules of the application. While most endpoints were secured with ssrf_helper.php, the email notification endpoint was inadvertently excluded during development or refactoring processes, creating an asymmetric defense posture that attackers can easily exploit by targeting the unprotected path.
Mitigation strategies primarily involve upgrading to Wallos version 4.9.6 or later, where this vulnerability has been patched by integrating proper SSRF validation into the email notification workflow. For organizations unable to upgrade immediately due to operational constraints, temporary mitigations include placing a reverse proxy in front of the application that inspects outbound connections from the web server and blocks requests destined for private IP ranges (RFC 1918) or cloud metadata IPs. Additionally, implementing network segmentation to isolate the Wallos instance from critical internal services can reduce the blast radius if an attacker successfully exploits this flaw. It is also recommended to enforce strict authentication controls and monitor logs for unusual outbound connection patterns originating from the application server to detect potential abuse of this SSRF vector in real-time.