Wallos CVE-2026-41689

Exploitation requires: (1) authenticated access to Wallos (PR:L in CVSS vector) - attacker must have a valid user account, whether created through legitimate registration or by compromising an existing low-privilege account; (2) webhook notification feature must be enabled and configured by an administrator (non-default but likely in production instances using notifications); (3) administrator must have populated the webhook URL allowlist with at least one internal target address - if the allowlist is empty, no SSRF is possible; (4) allowlisted internal services must be network-reachable from the Wallos server (standard assumption in self-hosted scenarios). RCE downstream is conditional on the allowlisted service exposing executable APIs (deployment, orchestration, or scripting endpoints) and not enforcing strict authentication beyond IP-based checks. The AC:H complexity factor reflects these configuration and service-dependency constraints - exploitation is possible but not trivial across all Wallos deployments.

This vulnerability presents moderate real-world risk despite the 6.0 CVSS score. The CVSS vector (AV:N/AC:H/PR:L/UI:N/S:C) indicates network-accessible attack surface requiring low-privilege authentication (PR:L) and high attack complexity (AC:H), with cross-scope impact (S:C). The AC:H modifier is the primary limiting factor - it reflects that conditions must be right (e.g., specific Wallos configuration with a populated allowlist). The EPSS score and exploitation probability are not provided, limiting quantitative risk ranking. Critically, the vulnerability is conditional on downstream configuration: RCE is only possible if an allowlisted internal service exposes deployment or execution APIs - many internal services do not. However, the core SSRF risk is real for any Wallos instance with a non-empty allowlist, as authenticated users can perform reconnaissance and lateral movement. The lack of a vendor patch at publication time elevates risk for long-term deployments. Organizations running Wallos in air-gapped networks or with restrictive allowlists face lower risk; those with broad allowlists pointing to automation services (CI/CD, orchestration, IaC tools) face higher risk. The authentication requirement (PR:L) prevents unauthenticated exploitation but does not prevent insider threats or compromise of low-privilege accounts.

An attacker with low-privilege access to a Wallos instance (either a created account or compromised low-privilege user) navigates to the webhook configuration and creates a subscription notification that targets an internal CI/CD API allowlisted by the administrator, such as a GitLab Runner or Jenkins deployment endpoint. The attacker crafts webhook headers and body to mimic a legitimate deployment request, then triggers a subscription event to cause Wallos to send a forged server-side request to the internal service. If the downstream service lacks strict request authentication or validates only source IP (which now appears to be Wallos), the attacker achieves code execution on deployment infrastructure.