CVE-2026-77351 in Wallos
Summary
by MITRE • 09/01/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in Wallos prior to version 5.0.0 represents a critical Server-Side Request Forgery (SSRF) flaw rooted in insufficient input validation within the application's email notification configuration module. As an open-source, self-hosted personal subscription tracker, Wallos allows authenticated users to configure SMTP settings for receiving notifications regarding their subscriptions. The core technical deficiency lies in the absence of server-side validation when storing or processing the SMTP host field. This oversight permits any authenticated user, regardless of privilege level, to inject arbitrary domain names or IP addresses into this configuration parameter. Specifically, attackers can target private internal network ranges and cloud metadata endpoints, which are typically inaccessible from external networks but fully reachable by the application server itself during outbound communication phases.
The operational mechanism of exploitation relies on the interaction between user input and the scheduled background tasks within the Wallos architecture. When a user submits their SMTP host configuration, the system stores this value without verifying whether it resolves to an internal or restricted address space. Subsequently, when the cron job responsible for sending email notifications executes, it retrieves the stored SMTP host and passes it directly to PHPMailer for connection establishment. This process triggers the Wallos server to initiate a new outbound TCP connection to the attacker-controlled destination. Because this action is performed by the application server rather than the client browser or external actor, the resulting network traffic originates from an internal IP address with potentially higher trust levels within the local network topology.
The impact of this vulnerability extends beyond simple connectivity testing. By leveraging this SSRF capability, a low-privileged attacker can perform reconnaissance against internal services that are not exposed to the public internet but may be vulnerable to other attacks or contain sensitive data. This includes probing database servers, administrative interfaces, API endpoints, and cloud metadata services such as AWS Instance Metadata Service (IMDS) or Azure Managed Identity endpoints. Accessing these metadata services could potentially allow an attacker to retrieve temporary security credentials for IAM roles attached to the server, thereby escalating privileges from a low-level application user to full control over associated cloud resources. This effectively bypasses network perimeter defenses that rely on source IP filtering to protect internal assets.
From a classification perspective, this vulnerability aligns with CWE-918, which addresses Server-Side Request Forgery (SSRF) flaws where the server makes requests based on unvalidated user input. It also maps closely to MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle or Lateral Movement via SSRF, as it enables an attacker to pivot through the compromised application host to reach other systems within the environment. The lack of validation against private IP ranges and cloud metadata endpoints is a common pattern in web applications that fail to implement strict allow-listing for outbound connections initiated by backend processes.
To mitigate this vulnerability, organizations running Wallos versions prior to 5.0.0 should immediately upgrade to version 5.0.0 or later, where the issue has been patched with proper input validation and restriction mechanisms. For environments unable to update immediately, defensive measures include implementing network-level controls such as egress filtering on the server hosting Wallos to block outbound connections to private IP ranges (RFC 1918) and cloud metadata endpoints unless explicitly required for legitimate business functions. Additionally, deploying a web application firewall with SSRF detection capabilities can help identify and block malicious requests attempting to access internal resources through the application interface. Ensuring that SMTP configurations are validated against an allow-list of known, trusted mail servers further reduces the attack surface associated with this configuration parameter.