CVE-2026-55232
Executive Summary
CVE-2026-55232 is a server-side request forgery (SSRF) vulnerability in the Vvveb CMS, an open-source page-builder platform for websites, blogs, and ecommerce stores. A flawed private-range guard in versions prior to 1.0.8.6 resolves hostnames using an IPv4-only function and never inspects IPv6 addresses, allowing hosts without an A record (or IPv6-literal URLs) to bypass the check. An authenticated admin-panel user with the default site_admin role or higher can direct the editor's oEmbed proxy to fetch attacker-supplied URLs server-side and reflect the response body, exposing internal-only services and cloud metadata endpoints — including IAM credentials. The vulnerability is rated CVSS 7.6 (High) and remains without a publicly verified patch trail in tracked sources at the time of writing.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
The vulnerability class is SSRF (CWE-918) arising from incomplete destination validation in Vvveb's URL-fetching logic. The NVD description identifies two compounding design flaws:
1. IPv4-only resolution in the SSRF guard. Prior to version 1.0.8.6, Vvveb's SSRF guard "resolves a host with an IPv4-only function and never inspects IPv6." This means the guard evaluates only the A record of a given hostname. Any host that lacks an A record — either because it is published only via AAAA records, or because the URL uses an IPv6 literal directly — produces no resolvable IPv4 address for the guard to inspect. Consequently, the host "passes a private-range check" that should have blocked it. The underlying pattern is a classic allow/deny list bypass: the security control is applied to a resolution path (IPv4) that is not the only path the fetcher can take.
2. Editor oEmbed proxy as the fetch primitive. Vvveb includes an oEmbed proxy used by the page builder to fetch remote resources server-side. The description states this proxy "fetches an attacker-supplied URL server side and reflects a response body." This combination is what turns the validation flaw into a practical exploit: the attacker does not need a client-side redirect or browser — the server itself performs the outbound request and returns the content to the requester, creating a full-read SSRF primitive rather than a blind one.
Attack surface and preconditions. Exploitation requires an authenticated admin-panel user with default site_admin role or higher (CVSS PR:H). The attack vector is network (AV:N), complexity is low (AC:L), no user interaction is required beyond the authenticated request (UI:N), and the scope change (S:C) reflects that the vulnerable component (the CMS's fetch proxy) can affect resources beyond its own security authority — specifically internal services and cloud metadata endpoints. Confidentiality impact is High (C:H), as full response bodies of internal services are disclosed; integrity impact is Low (I:L).
Root-cause summary. The guard performs destination validation on a channel (IPv4 resolution) that the fetcher is not obligated to use. IPv6 literal URLs and AAAA-only hostnames evade the private-range block entirely. No public PoC or Nuclei template exists; the mechanics described here are drawn directly from the NVD description.
Exploitation Scenarios
No public PoC is available; the following chain is inferred from the vulnerability class and the NVD description, and uses only components named in that description (the SSRF guard, the editor oEmbed proxy, IPv6 literals/AAAA-only records).
Reconnaissance / target identification. An attacker identifies a Vvveb deployment running a version prior to 1.0.8.6. Because the vulnerable component is an authenticated admin-panel feature, the attacker must first obtain credentials for an account at the
site_adminrole or higher — via credential stuffing, reuse, phishing, or a separate foothold.Triggering the flaw class. Using the authenticated admin session, the attacker supplies a URL to the editor oEmbed proxy. Rather than targeting a normal public host, the attacker chooses a destination the guard cannot evaluate: either an explicit IPv6 literal (e.g., an internal service reachable over IPv6) or a domain whose DNS contains only an AAAA record. Because the guard resolves with an IPv4-only function, this destination yields no A address and therefore never trips the private-range check.
Payload / execution method. The oEmbed proxy performs the outbound request server-side and reflects the response body back to the requester. The attacker uses this to reach internal-only services — for example, a loopback or link-local administrative endpoint, or the cloud instance metadata service addressed over IPv6. The content is returned inline through the proxy response; no separate exfiltration channel is required.
Post-exploitation impact. With internal read access, the attacker harvests data exposed by internal services and — as the NVD description explicitly warns — cloud metadata "including IAM credentials." Those credentials can be used to pivot from the CMS into the underlying cloud environment, expand access to other resources, and potentially establish persistence. The public-facing but authenticated nature of the entry point means the attack blends into legitimate admin traffic.
Impact Assessment
- Confidentiality (C:H): The primary impact. The reflected-response SSRF yields full read of internal-only services and cloud metadata, with IAM credential theft as the stated worst case. This is the highest-severity outcome for this class.
- Integrity (I:L): Limited direct write capability; impact derives from potential follow-on actions using stolen credentials rather than from the SSRF itself.
- Availability (A:N): No denial-of-service component described.
- Scope (S:C): The vulnerable proxy can affect resources beyond the CMS's own security boundary (internal services, cloud control plane metadata), which is why scope is marked Changed.
- Business impact: Vvveb powers public websites, blogs, and ecommerce stores. Compromise of a single admin account could expose the host's cloud identity, enabling lateral movement into production infrastructure. Because IAM credentials are in scope, the blast radius may extend well beyond the CMS instance to the entire cloud account. Ecommerce deployments raise the additional risk of customer data and payment infrastructure exposure.
- Affected systems: Any Vvveb deployment prior to 1.0.8.6 that exposes the admin panel and the editor oEmbed proxy, particularly those hosted on cloud providers with reachable instance metadata services.
- Likelihood: Requires authenticated admin access (PR:H), which moderates remote unauthenticated risk. However, the low attack complexity and the high value of the target (cloud credentials) make it attractive to attackers who already hold an admin session. No exploit code or KEV listing currently raises the urgency from "patch promptly" to "emergency."
Detection Guidance
Sigma Rule
title: Vvveb oEmbed Proxy SSRF via IPv6/AAAA-Only Host Bypass (CVE-2026-55232)
id: 8f3c1a72-5b2e-4c9d-9e11-7d4a6b0c2f55
status: experimental
description: Detects admin-panel requests to the Vvveb editor oEmbed proxy that carry IPv6 literals or AAAA-only hostnames, consistent with CVE-2026-55232 SSRF guard bypass.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-55232
author: valtersit.com
date: 2026/01/01
tags:
- attack.t1190
- cve.2026.55232
logsource:
category: webserver
product: vvveb
detection:
selection_endpoint:
cs-uri-query|contains:
- 'oembed'
- 'oEmbed'
selection_ipv6:
cs-uri-query|re: '\[[0-9a-fA-F:]+\]'
selection_metadata:
cs-uri-query|contains:
- '169.254.169.254'
- 'metadata.google.internal'
- 'fd00:ec2::254'
condition: selection_endpoint and (selection_ipv6 or selection_metadata)
falsepositives:
- Legitimate oEmbed requests to public IPv6-only content providers
level: high
YARA Rule
rule CVE_2026_55232_Vvveb_SSRF_IPv6_Bypass
{
meta:
description = "Detects Vvveb oEmbed proxy SSRF attempts using IPv6 literals or AAAA-only hosts (CVE-2026-55232)"
author = "valtersit.com"
reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-55232"
date = "2026-01-01"
severity = "high"
strings:
$oembed = "oembed" nocase
$oembed2 = "oEmbed" nocase
$ipv6 = /\[[0-9a-fA-F]{0,4}:[0-9a-fA-F:]{2,}\]/
$meta = "169.254.169.254"
$metav6 = "fd00:ec2::254"
$url_param = "url=" nocase
condition:
uint16(0) == 0x4854 or uint16(0) == 0x4f50 or true
and ($oembed or $oembed2)
and ($ipv6 or $meta or $metav6)
}
Suricata IDS Rule
alert http any any -> any any (msg:"CVE-2026-55232 Vvveb oEmbed Proxy SSRF IPv6/AAAA Bypass Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"oembed"; nocase; http.uri; pcre:"/\[[0-9a-fA-F]{0,4}:[0-9a-fA-F:]{2,}\]/"; reference:cve,2026-55232; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-55232; classtype:web-application-attack; sid:202655232; rev:1;)
alert http any any -> any any (msg:"CVE-2026-55232 Vvveb oEmbed Proxy SSRF Cloud Metadata Access Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"oembed"; nocase; http.uri; content:"169.254.169.254"; reference:cve,2026-55232; classtype:web-application-attack; sid:202655233; rev:1;)
Elastic Detection
sequence by process.entity_id
[ network where event.action == "connection_attempted" and
process.name : ("php", "php-fpm") and
destination.ip != null and
(cidr(destination.ip, "169.254.0.0/16") or
cidr(destination.ip, "127.0.0.0/8")) ]
[ network where event.action == "connection_attempted" and
process.name : ("php", "php-fpm") and
destination.ip : "fd00:ec2::254" ]
Splunk SPL Query
index=web sourcetype=access_combined
| search uri_path="*oembed*" OR uri_query="*oembed*"
| eval is_ipv6=if(match(uri_query, "\[[0-9a-fA-F]{0,4}:[0-9a-fA-F:]+\]"), 1, 0)
| eval is_metadata=if(match(uri_query, "(169\.254\.169\.254|fd00:ec2::254|metadata\.google\.internal)"), 1, 0)
| where is_ipv6=1 OR is_metadata=1
| stats count values(uri_query) as suspicious_uris by src_ip, user, status
| sort - count
Wazuh OSSEC Rule
<group name="web,vvveb,cve-2026-55232,">
<rule id="2026552" level="12">
<if_sid>31100</if_sid>
<url>oembed</url>
<regex type="pcre2">\[[0-9a-fA-F]{0,4}:[0-9a-fA-F:]{2,}\]</regex>
<description>CVE-2026-55232: Vvveb oEmbed proxy SSRF attempt using IPv6 literal or AAAA-only host</description>
<mitre>
<id>T1190</id>
</mitre>
<group>web_attack,pci_dss_6.5,</group>
</rule>
<rule id="2026553" level="13">
<if_sid>31100</if_sid>
<url>oembed</url>
<regex type="pcre2">(169\.254\.169\.254|fd00:ec2::254|metadata\.google\.internal)</regex>
<description>CVE-2026-55232: Vvveb oEmbed proxy SSRF attempt targeting cloud metadata endpoints</description>
<mitre>
<id>T1190</id>
</mitre>
<group>web_attack,pci_dss_6.5,</group>
</rule>
</group>
Mitigation & Patch Guidance
Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The NVD description asserts the issue "has been patched in version 1.0.8.6," but no vendor advisory, commit hash, or release artifact is indexed in tracked sources; treat the patch claim as unverified until independently confirmed against the upstream Vvveb repository and release notes.
Immediate mitigations (apply before/independent of patching):
- Restrict network egress from the Vvveb application host so it cannot reach cloud instance metadata endpoints (block
169.254.169.254andfd00:ec2::254) and cannot reach internal-only RFC1918 and link-local ranges over both IPv4 and IPv6. Egress filtering must cover IPv6, since IPv6 is the bypass vector. - Where the cloud provider supports it, enforce IMDSv2 with session-token requirements (AWS) or equivalent metadata hardening to reduce the value of any successful SSRF.
- Disable or restrict the editor oEmbed proxy feature if it is not required. If required, front it with an application-layer allowlist of permitted oEmbed providers enforced outside the vulnerable IPv4-only guard.
- Enforce least privilege on Vvveb admin accounts. The vulnerability requires
site_adminor higher; audit and restrict who holds these roles, enable MFA, and rotate any credentials that may have been exposed to an admin session. - Monitor and constrain IPv6 connectivity from the web tier; if the application host does not legitimately need outbound IPv6, disable it at the host/network layer.
- Restrict network egress from the Vvveb application host so it cannot reach cloud instance metadata endpoints (block
Patch/upgrade steps:
- Verify the current Vvveb version. If below 1.0.8.6, plan an upgrade to 1.0.8.6 or later.
- Because the fix is not corroborated by tracked patch sources, review the upstream release notes/changelog for the SSRF guard change before relying on it, and validate post-upgrade that IPv6 literals and AAAA-only hostnames are now rejected by the guard.
- Back up the deployment and database before upgrading; test in a staging environment, as CMS upgrades may affect plugins, themes, and the page builder.
Long-term hardening:
- Adopt a positive allowlist model for all server-side URL fetching. Never rely solely on IPv4 resolution as a security control.
- Resolve and validate destinations across both IPv4 and IPv6 (A and AAAA), and reject any resolved address in private, loopback, link-local, or reserved ranges before issuing the request.
- Re-validate after any redirect to prevent redirect-based bypasses.
- Add regression tests that specifically exercise IPv6 literals and AAAA-only hostnames against the SSRF guard.
- Institutionalize egress filtering and metadata-service hardening as defaults for all internet-facing application tiers.
References
- NVD — CVE-2026-55232: https://nvd.nist.gov/vuln/detail/CVE-2026-55232
- CWE-918: Server-Side Request Forgery (SSRF): https://cwe.mitre.org/data/definitions/918.html
- MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
- Vvveb project (upstream source/release notes for version 1.0.8.6 — verify patch independently): https://github.com/givanz/Vvveb
- CISA Known Exploited Vulnerabilities Catalog (CVE-2026-55232 NOT listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
No known threat actor campaigns or exploit-in-the-wild evidence are associated with CVE-2026-55232 at the time of writing; no public PoC, exploit code, or Nuclei template was identified in tracked sources.
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.