CVE-2026-27479: Wallosapp Wallos SSRF Vulnerability

CVE-2026-27479 Overview

CVE-2026-27479 is a Server-Side Request Forgery (SSRF) vulnerability affecting Wallos, an open-source, self-hostable personal subscription tracker. The vulnerability exists in the subscription and payment logo/icon upload functionality, where improper handling of HTTP redirects allows attackers to bypass IP address validation and access internal resources, including cloud instance metadata endpoints.

Critical Impact

Authenticated attackers can exploit this SSRF vulnerability to access internal network resources, cloud metadata endpoints (such as AWS IMDSv1), and potentially exfiltrate sensitive credentials and configuration data from cloud environments.

Affected Products

• Wallos versions 4.6.0 and below
• Wallosapp Wallos (all installations prior to v4.6.1)
• Self-hosted Wallos instances with logo upload functionality enabled

Discovery Timeline

• 2026-02-21 - CVE-2026-27479 published to NVD
• 2026-02-24 - Last updated in NVD database

Technical Details for CVE-2026-27479

Vulnerability Analysis

This SSRF vulnerability occurs due to a Time-of-Check to Time-of-Use (TOCTOU) race condition in the URL validation logic. The getLogoFromUrl() function performs IP address validation on the initial URL by resolving the hostname and checking if the resulting IP falls within private or reserved ranges using PHP's FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE flags. However, after this validation passes, the subsequent cURL request is configured with CURLOPT_FOLLOWLOCATION = true and CURLOPT_MAXREDIRS = 3, allowing the request to follow HTTP redirects without re-validating the destination IP addresses.

An attacker can exploit this by providing a URL to an attacker-controlled server that initially resolves to a public IP address (passing the validation), but then issues an HTTP redirect (301/302) to an internal resource such as http://169.254.169.254/latest/meta-data/ (AWS metadata endpoint) or other internal network addresses.

Root Cause

The root cause is the absence of IP validation after HTTP redirects. While the application correctly validates the initial URL's resolved IP address against private and reserved ranges, it fails to perform the same validation on redirect destinations. The cURL configuration with CURLOPT_FOLLOWLOCATION = true automatically follows redirects, creating a bypass path for the security control.

Attack Vector

The attack is network-based and requires low-privilege authentication. An attacker with a valid user account can:

1. Set up an external server that returns HTTP 302 redirects to internal IP addresses
2. Submit this malicious URL through the subscription or payment logo upload functionality
3. The application validates the initial external URL (which passes)
4. cURL follows the redirect to an internal IP address without re-validation
5. The internal resource content is returned to the attacker

The following patch demonstrates how the vulnerability was addressed by implementing IP validation within a loop that checks each redirect destination:

 
function getLogoFromUrl($url, $uploadDir, $name, $settings, $i18n)
{
-    if (!filter_var($url, FILTER_VALIDATE_URL) || !preg_match('/^https?:\/\//i', $url)) {
-        $response = [
-            "success" => false,
-            "message" => "Invalid URL format."
-        ];
-        echo json_encode($response);
-        exit();
-    }
+    $maxRedirects = 3;
+    $currentUrl = $url;

-    $host = parse_url($url, PHP_URL_HOST);
-    $ip = gethostbyname($host);
-    if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) === false) {
-        $response = [
-            "success" => false,
-            "message" => "Invalid IP Address."
-        ];
-        echo json_encode($response);
-        exit();
-    }
+    for ($i = 0; $i <= $maxRedirects; $i++) {
+        if (!filter_var($currentUrl, FILTER_VALIDATE_URL) || !preg_match('/^https?:\/\//i', $currentUrl)) {
+            $response = ["success" => false, "message" => "Invalid URL format."];
+            echo json_encode($response);
+            exit();
+        }

Source: GitHub Commit Reference

Detection Methods for CVE-2026-27479

Indicators of Compromise

• Outbound HTTP requests from the Wallos application to cloud metadata endpoints (e.g., 169.254.169.254, fd00:ec2::254)
• Logo upload requests containing URLs that redirect to internal IP addresses or localhost
• Unusual patterns of HTTP 302/301 redirects in application logs preceding internal network access
• Access to sensitive internal endpoints from the web application server context

Detection Strategies

• Monitor application logs for logo upload attempts with URLs pointing to known redirect services or suspicious domains
• Implement network-level monitoring to detect requests from the web server to internal RFC 1918 addresses or cloud metadata endpoints
• Alert on HTTP requests to 169.254.169.254 or similar metadata service IPs originating from web application processes
• Review web server access logs for patterns consistent with SSRF exploitation attempts

Monitoring Recommendations

• Deploy network segmentation rules preventing web application servers from accessing cloud metadata endpoints directly
• Configure IDS/IPS rules to detect SSRF patterns targeting common internal services and metadata endpoints
• Implement logging and alerting on all outbound HTTP requests initiated by the getLogoFromUrl() function
• Monitor for unusual data exfiltration patterns from web application processes

How to Mitigate CVE-2026-27479

Immediate Actions Required

• Upgrade Wallos to version 4.6.1 or later immediately
• If unable to upgrade, disable the logo/icon upload from URL functionality temporarily
• Review logs for potential exploitation attempts prior to patching
• Audit any cloud credentials or metadata that may have been exposed

Patch Information

The vulnerability has been fixed in Wallos version 4.6.1. The patch modifies the getLogoFromUrl() function to validate IP addresses after each redirect, rather than only validating the initial URL. The fix implements a loop that manually follows redirects (up to 3) while performing IP validation at each step, effectively preventing the redirect-based bypass.

Patch details are available in the GitHub Security Advisory GHSA-fgmf-7g5v-jmjg and the fix can be downloaded from GitHub Release v4.6.1.

Workarounds

• Disable the URL-based logo upload functionality by modifying the application configuration until the patch can be applied
• Implement network-level controls to block outbound requests from the Wallos application server to internal IP ranges and cloud metadata endpoints
• Use a web application firewall (WAF) to inspect and block requests containing redirect payloads targeting internal resources
• If running in a cloud environment, enable IMDSv2 (for AWS) which requires session tokens and provides additional protection against SSRF

# Example: Block metadata endpoint access using iptables (Linux)
# Run on the server hosting Wallos to prevent SSRF to cloud metadata
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 169.254.0.0/16 -j DROP

# For AWS, enable IMDSv2 to require session tokens
aws ec2 modify-instance-metadata-options \
    --instance-id i-xxxxxxxxxxxx \
    --http-tokens required \
    --http-endpoint enabled