CVE-2026-61640 Overview
CVE-2026-61640 is a Server-Side Request Forgery (SSRF) vulnerability in Wallos, an open-source self-hostable personal subscription tracker. The flaw exists in the OpenID Connect (OIDC) callback handler prior to version 4.9.6. Admin-configured token_url and user_info_url values in includes/oidc/handle_oidc_callback.php (lines 18-49) are passed directly to curl_init() without SSRF filtering. Unlike logo and webhook URLs that use validate_webhook_url_for_ssrf(), OIDC URLs bypass every protection. An authenticated administrator can point these URLs at cloud metadata endpoints or internal services to pivot into private networks [CWE-918].
Critical Impact
An admin can set OIDC URLs to http://169.254.169.254/latest/meta-data/ and retrieve cloud instance metadata, including IAM credentials, or reach internal-only services from the Wallos server.
Affected Products
- Wallos subscription tracker versions prior to 4.9.6
- The includes/oidc/handle_oidc_callback.php OIDC callback handler
- Self-hosted Wallos deployments in cloud environments (AWS, Azure, GCP)
Discovery Timeline
- 2026-08-31 - CVE-2026-61640 published to NVD
- 2026-09-02 - Last updated in NVD database
- Patched in Wallos v4.9.6 - See GitHub Release v4.9.6
Technical Details for CVE-2026-61640
Vulnerability Analysis
Wallos supports OIDC single sign-on, allowing an administrator to configure the identity provider's token_url and user_info_url. During the OIDC callback flow, the application performs server-side HTTP requests to those URLs using curl_init() to exchange the authorization code for a token and to retrieve user profile data.
The callback handler at includes/oidc/handle_oidc_callback.php:18-49 accepts the admin-configured URLs verbatim. It does not validate the scheme, resolve the hostname, or block access to private, loopback, or link-local address ranges. Other network-facing settings in Wallos, such as logo and webhook URLs, are routed through validate_webhook_url_for_ssrf(). The OIDC path was omitted from this control, creating an inconsistent trust boundary.
Because the server itself issues the outbound request, the attacker inherits the network position of the Wallos host. On cloud instances this includes access to the Instance Metadata Service (IMDS), which frequently exposes short-lived IAM credentials.
Root Cause
The root cause is missing URL validation on privileged administrator input before it is used in a server-side HTTP client. The pattern is a classic SSRF [CWE-918]: user-controlled URLs are consumed by curl_init() with no allowlist, denylist, or DNS rebinding protection. The existing helper validate_webhook_url_for_ssrf() was not applied to the OIDC configuration path.
Attack Vector
An attacker who already holds administrator credentials, or who compromises an admin account, updates the OIDC settings and points token_url or user_info_url at an internal target. Triggering the OIDC login flow then forces the Wallos backend to issue a request to that target and, in some cases, return the response body to the attacker's session. Typical targets include:
- http://169.254.169.254/latest/meta-data/ for AWS IMDSv1 credentials
- http://metadata.google.internal/ for GCP metadata
- Internal admin panels, databases, or CI systems reachable only from the Wallos host
// Patch excerpt: endpoints/admin/saveoidcsettings.php
// The fix introduces the SSRF helper on the OIDC settings save path.
require_once '../../includes/connect_endpoint.php';
require_once '../../includes/validate_endpoint_admin.php';
+require_once '../../includes/ssrf_helper.php';
$postData = file_get_contents("php://input");
$data = json_decode($postData, true);
Source: GitHub Commit b75f13d
Detection Methods for CVE-2026-61640
Indicators of Compromise
- Outbound HTTP requests from the Wallos container or host to 169.254.169.254, metadata.google.internal, or RFC1918 ranges originating from the PHP process.
- Modifications to the OIDC configuration table where token_url or user_info_url reference non-public hostnames or IP literals.
- Web server access logs showing OIDC callback traffic immediately preceded by admin edits to endpoints/admin/saveoidcsettings.php.
- Unexpected use of cloud IAM credentials tied to the Wallos instance role from external IPs.
Detection Strategies
- Inspect the Wallos database oidc_settings (or equivalent) for URLs whose host resolves to private, loopback, or link-local addresses.
- Enable egress logging on the Wallos host and alert on connections to metadata service addresses.
- Audit the application's PHP error and access logs for repeated curl_init failures against internal targets during OIDC flows.
Monitoring Recommendations
- Enforce IMDSv2 with hop-limit 1 on AWS instances to blunt SSRF against the metadata service.
- Deploy an egress proxy or network policy that restricts outbound traffic from the Wallos workload to known OIDC providers only.
- Alert on administrator configuration changes to OIDC endpoints and correlate with subsequent outbound network activity.
How to Mitigate CVE-2026-61640
Immediate Actions Required
- Upgrade Wallos to version 4.9.6 or later. See the GitHub Security Advisory GHSA-x9x5-gh69-q7cm.
- Review current OIDC settings and remove any token_url or user_info_url pointing to internal, loopback, or metadata addresses.
- Rotate any cloud IAM credentials associated with the Wallos instance if exposure is suspected.
- Restrict administrator access to Wallos and enforce strong authentication for admin accounts.
Patch Information
The fix is included in Wallos 4.9.6. The patch adds require_once '../../includes/ssrf_helper.php'; to the OIDC settings save endpoint and hardens OIDC state validation and session rotation. See GitHub Commit b75f13d and the associated pull request discussion for the full change set.
Workarounds
- Block outbound traffic from the Wallos container to 169.254.0.0/16, RFC1918 ranges, and localhost at the network layer.
- Run Wallos behind an egress proxy that allows only approved OIDC provider hostnames.
- Enforce AWS IMDSv2 with a hop limit of 1 to prevent containerized SSRF from reaching the metadata service.
# AWS: enforce IMDSv2 with hop limit of 1 on the Wallos instance
aws ec2 modify-instance-metadata-options \
--instance-id i-0123456789abcdef0 \
--http-tokens required \
--http-put-response-hop-limit 1 \
--http-endpoint enabled
# Docker: block metadata service egress from the Wallos container
iptables -I DOCKER-USER -m owner --uid-owner www-data \
-d 169.254.169.254 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.