Vvveb CMS CVE-2026-55232

Requires an authenticated admin-panel account with the default role site_admin or higher; this is the primary limiting factor and rules out unauthenticated attackers. The vulnerable path is the editor oEmbed proxy (the download/getUrl fetch in system/functions.php), which reflects the fetched response body back to the requester. Exploitation specifically requires supplying a host the IPv4-only validateUrl guard cannot resolve for private-range checking - namely a bare IPv6 literal or a domain that publishes only an AAAA record - so hosts with an A record are still blocked. Real-world impact further depends on the deployment having reachable internal services or a cloud metadata endpoint (e.g., a cloud-hosted instance exposing IAM credentials); an isolated on-prem install with no sensitive internal HTTP targets yields little. Affects Vvveb versions prior to 1.0.8.6.

This is a credible but access-gated server-side request forgery issue, not a wormable emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N, 7.6 High) correctly captures the dominant constraint: PR:H means exploitation requires an authenticated admin-panel account (default role site_admin or higher), so there is no path for an anonymous internet attacker. AC:L is appropriate because triggering the bypass is trivial once authenticated - supply an IPv6 literal or an AAAA-only hostname to the oEmbed proxy. The scope change (S:C) and C:H are justified because the flaw reaches beyond the application into internal-only services and cloud metadata (IAM credentials), which is the real prize. No EPSS score, KEV entry, or public POC was supplied in the input; the only exploit-adjacent artifact is the vendor patch commit, which demonstrates the root cause but is not weaponized exploit code. Net assessment: genuine priority for any Vvveb deployment running on a cloud instance with an exposed metadata endpoint, but the PR:H requirement keeps it out of the mass-exploitation tier. No conflicting signals were detected between the CVSS vector and the description - both agree on network vector plus privileged access.

An authenticated Vvveb user with site_admin (or higher) role opens the page-builder editor and submits an oEmbed URL pointing at an IPv6 literal or a domain carrying only an AAAA record, which the IPv4-only SSRF guard fails to inspect. The server-side proxy fetches the attacker's chosen internal target and reflects the response body back to the user, letting them read cloud metadata such as http://[fd00::...]/ or the metadata service to harvest IAM credentials. No public exploit was identified at time of analysis, though the patch commit publicly reveals the exact bypass mechanism.