CVE-2026-54507: Vvveb CMS: SSRF in oEmbed proxy leaks cloud metadata

HIGHPoC AVAILABLE
Published September 17, 2026
CISO Take

Vvveb CMS, a page-builder CMS, has a server-side request forgery flaw in its admin oEmbed proxy: the URL check validates only the hostname string, not the addresses it resolves to, so an authenticated admin with editor permission can make the server fetch loopback, private, or link-local addresses and return the response. The practical risk is theft of cloud instance metadata and credentials or probing of internal services, and because the action uses GET with no CSRF token, a logged-in admin could also be tricked into triggering it. Exploitation likelihood is currently low (EPSS 0.0045, 63rd percentile), it is not in CISA KEV, and CISA SSVC says TRACK. However, a public PoC exists and no scanner template is needed to reproduce it. This is a general-purpose CMS with only a tenuous AI/ML link, so treat it as a standard web-app patching item. Upgrade to Vvveb 1.0.8.5 or later, enforce IMDSv2 on cloud hosts, and restrict editor permissions.

Sources:NVDEPSSGitHub AdvisoryATLAS

What is the risk?

Moderate overall. Exploitation requires an authenticated admin-panel account with editor/* permission, which limits exposure. Impact can be high where the host runs in a cloud environment with IMDSv1 or over-permissive instance roles, because metadata credentials could be disclosed. EPSS is low (0.0045), there is no KEV listing, and SSVC is TRACK, but a public PoC lowers the skill needed. The AI/ML relevance is weak: the product is a general CMS (classified ml_ui by our tracker) and not a core AI component. CVSS is not yet scored.

How does the attack unfold?

Initial Access
Attacker obtains or phishes an admin account with editor/* permission, or lures a logged-in admin to a crafted GET link.
AML.T0012
Exploitation
Attacker calls the oEmbedProxy action with a hostname that passes the string check but resolves to a loopback or link-local address.
AML.T0049
Credential Access
The server fetches the cloud metadata endpoint and returns IAM credentials in the response.
AML.T0106
Impact
Stolen credentials are used to reach internal services and cloud resources, potentially including data stores or ML assets.
AML.T0025

What systems are affected?

PackageEcosystemVulnerable RangePatched
Vvveb——No patch

Do you use Vvveb? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.4%
chance of exploitation in 30 days
Higher than 39% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
○Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What should I do?

1 step
  1. 1) Upgrade Vvveb to 1.0.8.5 or later (fix commit bd280f5). 2) Restrict admin panel access by IP, VPN, or SSO, and limit who holds editor/* permissions. 3) Enforce IMDSv2 (or equivalent metadata hardening) and apply least-privilege instance roles. 4) Add egress filtering to block the web host from reaching loopback, link-local (169.254.169.254), and internal ranges. 5) Detect: review web logs for GET requests to /admin/index.php?module=editor/editor&action=oEmbedProxy with unusual url values, and review cloud logs for metadata credential use from unexpected sources.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2.6-AI system operation and monitoring
NIST AI RMF
MANAGE 2.3-Responses to identified AI risks are planned and documented
OWASP LLM Top 10
LLM03-Supply Chain

Frequently Asked Questions

What is CVE-2026-54507?

Vvveb CMS, a page-builder CMS, has a server-side request forgery flaw in its admin oEmbed proxy: the URL check validates only the hostname string, not the addresses it resolves to, so an authenticated admin with editor permission can make the server fetch loopback, private, or link-local addresses and return the response. The practical risk is theft of cloud instance metadata and credentials or probing of internal services, and because the action uses GET with no CSRF token, a logged-in admin could also be tricked into triggering it. Exploitation likelihood is currently low (EPSS 0.0045, 63rd percentile), it is not in CISA KEV, and CISA SSVC says TRACK. However, a public PoC exists and no scanner template is needed to reproduce it. This is a general-purpose CMS with only a tenuous AI/ML link, so treat it as a standard web-app patching item. Upgrade to Vvveb 1.0.8.5 or later, enforce IMDSv2 on cloud hosts, and restrict editor permissions.

Is CVE-2026-54507 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-54507, increasing the risk of exploitation.

How to fix CVE-2026-54507?

1) Upgrade Vvveb to 1.0.8.5 or later (fix commit bd280f5). 2) Restrict admin panel access by IP, VPN, or SSO, and limit who holds editor/* permissions. 3) Enforce IMDSv2 (or equivalent metadata hardening) and apply least-privilege instance roles. 4) Add egress filtering to block the web host from reaching loopback, link-local (169.254.169.254), and internal ranges. 5) Detect: review web logs for GET requests to /admin/index.php?module=editor/editor&action=oEmbedProxy with unusual url values, and review cloud logs for metadata credential use from unexpected sources.

What systems are affected by CVE-2026-54507?

This vulnerability affects the following AI/ML architecture patterns: Web application front-ends, CMS-hosted content portals, Cloud-hosted web workloads with instance metadata access.

What is the CVSS score for CVE-2026-54507?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

Web application front-endsCMS-hosted content portalsCloud-hosted web workloads with instance metadata access

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application
AML.T0075Cloud Service Discovery
AML.T0106Exploitation for Credential Access

Compliance Controls Affected

ISO 42001: A.6.2.6
NIST AI RMF: MANAGE 2.3
OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.5, the oEmbedProxy() handler in admin/controller/editor/editor.php accepts an attacker-controlled url parameter and passes it to getUrl(), while validateUrl() in system/functions.php checks only the hostname string and does not validate its resolved addresses. An authenticated admin-panel user with editor/* permission can invoke GET /admin/index.php?module=editor/editor&action=oEmbedProxy with a dotted hostname or normalized loopback form that resolves to a private, loopback, link-local, or reserved address, causing the server to issue an HTTP or HTTPS request and return the response body. Storefront users and anonymous visitors cannot invoke the endpoint, but no CSRF token is required because the action uses GET. This can disclose internal service responses or cloud instance metadata and associated credentials. This issue is fixed in version 1.0.8.5.

Exploitation Scenario

An attacker who has obtained or phished an editor-level admin account sends a GET request to the oEmbedProxy action with a url parameter using a dotted hostname or normalized loopback form that resolves to 169.254.169.254. The server fetches the cloud metadata endpoint and returns the response, exposing temporary IAM credentials. The attacker then uses those credentials to access cloud resources in the same account, which may include storage buckets holding datasets or model artifacts, or ML services. Alternatively, because no CSRF token is needed, the attacker lures a logged-in admin to a page that triggers the request.

Weaknesses (CWE)

CWE-918 — Server-Side Request Forgery: The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

  • [Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
  • [Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.

Timeline

Published
September 17, 2026
Last Modified
September 18, 2026
First Seen
September 18, 2026

Related Vulnerabilities