CVE-2026-61640 in Wallos
Summary
by MITRE • 09/01/2026
Wallos is an open-source, self-hostable personal subscription tracker. Prior to version 4.9.6, Admin-configured OIDC token_url and user_info_url in includes/oidc/handle_oidc_callback.php:18-49 are used directly in curl_init() with zero SSRF filtering. Unlike logo/webhook URLs which have validate_webhook_url_for_ssrf(), OIDC URLs bypass all protections. Admin sets URL to http://169.254.169.254/latest/meta-data/ for cloud metadata access or internal network pivoting. 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 the improper validation of user-supplied input within the OpenID Connect authentication flow. As an open-source, self-hostable personal subscription tracker, Wallos relies on external identity providers for secure access management. The specific defect resides in the file includes/oidc/handle_oidc_callback.php between lines 18 and 49, where administrative configurations for OIDC token_url and user_info_url are processed. Unlike other URL fields within the application, such as logo or webhook URLs which benefit from a dedicated validation function named validate_webhook_url_for_ssrf(), these specific authentication endpoints bypass all SSRF filtering mechanisms entirely. This inconsistency in input sanitization creates a significant security gap that attackers can exploit to compromise internal infrastructure.
From a technical perspective, the core issue is the direct injection of unvalidated administrative configuration values into PHP's curl_init() function without any preliminary checks for malicious patterns or restricted IP ranges. When an administrator configures these URLs during setup, the application trusts them implicitly and passes them directly to the cURL library for HTTP requests. Because there are no restrictions on protocol schemes such as file://, gopher://, or http/https targeting private IP spaces, a compromised administrative account or any entity with write access to the configuration can direct the server to make arbitrary network connections. This lack of validation allows the application to act as a proxy for internal reconnaissance and data exfiltration from services that are not exposed to the public internet but remain accessible within the local network environment.
The operational impact of this vulnerability is severe, particularly in cloud-native or containerized deployments where instance metadata services are commonly used for authentication and configuration retrieval. An attacker who gains administrative privileges can configure the token_url or user_info_url to point at http://169.254.169.254/latest/meta-data/, which is a standard endpoint for accessing cloud provider metadata on platforms like AWS, Azure, and Google Cloud Platform. By forcing Wallos to request data from this internal address, the attacker can retrieve sensitive credentials such as IAM role keys, SSH private keys, or instance identity documents without ever needing direct network access to those resources. This effectively bypasses perimeter security controls since the traffic originates from a trusted application server within the same virtual private cloud or subnet.
Beyond cloud metadata theft, this SSRF vulnerability facilitates broader internal network pivoting and lateral movement. An attacker can leverage Wallos as a foothold to scan internal ports, probe for vulnerable services running on localhost or other private IP addresses, and potentially exploit weaknesses in backend databases, API gateways, or management interfaces that are not directly accessible from the external internet. This transforms a seemingly low-impact configuration error into a high-severity threat vector capable of leading to full system compromise. The absence of similar protections for these specific fields compared to other URL inputs highlights an oversight in the application's security architecture where critical authentication pathways were left unprotected against SSRF attacks.
To mitigate this risk, organizations running Wallos versions prior to 4.9.6 must immediately upgrade to version 4.9.6 or later, which implements proper validation for these OIDC endpoints. For environments that cannot be upgraded instantly due to operational constraints, temporary mitigations should include restricting outbound network traffic from the server hosting Wallos using firewall rules or security groups. Specifically, egress filtering should block access to private IP ranges such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, with explicit exceptions only for legitimate external identity providers. Additionally, administrators should audit existing configurations to ensure no malicious URLs have been injected into the OIDC settings. Implementing strict input validation on all URL fields within the application codebase is also recommended to prevent similar oversights in future updates or custom integrations.
This vulnerability aligns with CWE-918, which defines Server-Side Request Forgery as a flaw where an attacker coerces a server into making requests to unintended destinations. It also maps to MITRE ATT&CK technique T1046, Network Service Discovery, and potentially T1552.004, Unsecured Credentials in Cloud Metadata API, depending on the specific exploitation path taken by the adversary. The failure to validate administrative input against SSRF patterns underscores the importance of applying defense-in-depth principles even within trusted configuration flows. Security teams should treat all user-controlled or admin-configured URLs with equal scrutiny regarding SSRF risks regardless of their functional purpose within the application logic.