Vvveb CVE-2026-34428

Requires authenticated access to Vvveb backend with privileges to use the editor module's oEmbedProxy action - specifically, the user account must have permission to access editor/editor endpoints. This is typically granted to content editors, administrators, or other trusted backend roles, not anonymous users. Default Vvveb installations grant editor access to authenticated users, making this exploitable in most deployments once authentication is obtained. Exploitation is NOT limited by specific Vvveb configuration settings or optional features - the vulnerable code path is active in all pre-1.0.8.1 installations. Attack complexity is low (AC:L): no race conditions, no need for specific timing, and response bodies are returned directly (not blind SSRF). Maximum impact requires deployment in environments with accessible internal network resources (cloud metadata endpoints, internal APIs, database admin interfaces) or sensitive local files readable by the web server process user (typically www-data or apache). Standalone Vvveb instances on isolated networks with restricted filesystem permissions face reduced but non-zero risk (local file disclosure still possible).

CVSS 7.7 (High) with vector AV:N/AC:L/PR:L/UI:N/S:C indicates network-exploitable attack requiring low-privilege authentication with no user interaction and scope change (internal network access beyond vulnerable component). The Confidentiality:High rating reflects ability to read sensitive files and internal service responses. However, real-world risk depends on multiple factors: (1) Requires authenticated backend access (PR:L), limiting attack surface to compromised accounts, malicious insiders, or chained exploitation after initial authentication bypass. (2) No CISA KEV listing suggests targeted rather than widespread exploitation. (3) Publicly available patch (GitHub commit 2d356844) since version 1.0.8.1 reduces window of exposure for maintained installations. (4) SSRF impact severity varies by deployment - cloud environments with metadata services (AWS EC2 169.254.169.254) or internal APIs face higher risk than isolated hosting. (5) Scope change (S:C) is significant: attackers can pivot from CMS compromise to internal network reconnaissance, reading cloud credentials, accessing internal documentation, or probing databases. Priority: High for internet-facing Vvveb installations in cloud/corporate networks with valuable internal resources; Medium for isolated hosting environments. Absence of EPSS score prevents exploitation probability assessment, but authentication requirement and lack of widespread exploitation reports suggest this is not yet a mass-exploitation target.

An attacker with valid backend credentials (potentially obtained via phishing, credential stuffing, or separate authentication bypass) logs into the Vvveb CMS administrator panel. Within the editor module, they craft a malicious oEmbedProxy request with url=file:///etc/passwd to read the server's password file, confirming local file access. Next, they iterate through url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS metadata endpoint) to extract temporary cloud credentials. Using these credentials, the attacker pivots to access the organization's S3 buckets or EC2 instances, escalating from CMS compromise to full cloud infrastructure breach. Publicly available exploit code exists (VulnCheck advisory provides technical details), lowering skill barrier for exploitation.