Description

Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to version 1.0.8.6, Vvveb's SSRF guard resolves a host with an IPv4-only function and never inspects IPv6, so any host that lacks an A record passes a private-range check. Editor oEmbed proxy fetches an attacker-supplied URL server side and reflects a response body, so an authenticated admin-panel user (default role site_admin or higher) can read internal-only services and cloud metadata, including IAM credentials, using an IPv6 literal or a domain that carries only an AAAA record. This issue has been patched in version 1.0.8.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.6",
  "pubDate": "2026-10-01T19:17:21.900Z",
  "pubdate": "2026-10-01T19:17:21.900Z",
  "executiveSummary": "Vvveb CMS is susceptible to a Server-Side Request Forgery (SSRF) vulnerability originating from an insufficient implementation of its internal network protection mechanism. The vulnerability exists within the oEmbed proxy functionality, which fails to properly validate IPv6 addresses or domains resolving exclusively to AAAA records. By bypassing the existing IPv4-centric security guard, an authenticated administrator can force the server to perform unauthorized requests against internal network resources.\nThe impact of this vulnerability is significant, as it permits the exfiltration of sensitive internal data, including cloud metadata service information and IAM credentials. This flaw enables an attacker to bridge the gap between a public-facing administration panel and restricted internal infrastructure. Successful exploitation requires an attacker to possess authenticated access to the administrative dashboard, specifically with a role of site_admin or higher. The vulnerability has been addressed in version 1.0.8.6, and immediate upgrade is required to mitigate risks associated with lateral movement and credential theft.",
  "technicalDetails": "The vulnerability resides in the SSRF protection mechanism utilized by the Vvveb CMS, specifically within the oEmbed proxy component. The root cause is an architectural flaw in the network validation logic, which relies exclusively on an IPv4-only resolution function to perform private-range checks on requested URLs. Because the system does not inspect or validate IPv6 address formats, it fails to evaluate the target host if it lacks an A record, effectively bypassing all perimeter security controls.\nThe attack flow proceeds as follows: An authenticated user with administrative privileges accesses the oEmbed proxy feature. The user provides a malicious URL crafted with either an IPv6 literal (e.g., [::1]) or a domain name configured only with an AAAA DNS record. When the proxy initiates the server-side request, the SSRF guard validates the destination based on its IPv4-focused logic. Since no A record exists for the provided input, the guard evaluates the check as benign and permits the request to proceed. The proxy then executes the HTTP request on behalf of the attacker, interacting with internal services that are not reachable from the public internet.\nBy targeting the server's local environment or internal cloud metadata endpoints (such as the AWS Instance Metadata Service at 169.254.169.254, mapped via IPv6 equivalents or equivalent internal network segments), the attacker can force the application to reflect the response body directly back to the administrative UI. This allows for the exfiltration of sensitive configuration data, internal service responses, and ephemeral cloud credentials.\nThis vulnerability affects Vvveb versions prior to 1.0.8.6. The requirement for 'site_admin' or higher privilege levels restricts the attack surface to authenticated users, but the potential for total infrastructure compromise—especially in cloud-hosted environments where IAM roles are attached to the instance—makes this a high-severity flaw. The exploitation is entirely server-side, meaning the target machine performs the malicious requests, masking the source of the traffic and potentially bypassing traditional network-based firewalls that focus on ingress traffic rather than egress-triggered SSRF."
}