EUVD-2026-82567Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain editor/* admin account
-
DeliveryCraft url resolving to loopback/metadata IP
-
ExploitGET oEmbedProxy endpoint
-
ExecutionServer-side fetch bypasses validateUrl
-
ImpactRead metadata/credentials in response body
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V4 - API and Web Service URL allowlisting, SSRF prevention
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated Vvveb admin-panel account with editor/* permission - anonymous and storefront users cannot reach the endpoint (per description). The specific vulnerable path is GET /admin/index.php?module=editor/editor&action=oEmbedProxy with an attacker-controlled url parameter; because it is a GET request no CSRF token is required, enabling a CSRF-style trigger against a logged-in editor. Meaningful impact (credential theft) further depends on the server running where a private/loopback/link-local/reserved address hosts sensitive services - most notably a cloud instance-metadata endpoint (169.254.169.254). Exploitation is blocked entirely in 1.0.8.5+, which validates resolved IPs and pins curl to the vetted address with redirects disabled. |
| Impact | This is a genuine but access-gated SSRF (CWE-918). The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/SC:H/SI:H, 8.4) correctly captures the two decisive facts: it is remotely reachable with low complexity, but it REQUIRES an authenticated admin-panel account holding editor/* permission (PR:L) - storefront and anonymous users cannot invoke the endpoint. There is no EPSS score, no CISA KEV listing, and no public exploit code; the only linked GitHub artifact is the fix commit (bd280f5c), which reveals the mechanism (string-only hostname validation) but is not a weaponized POC. So this is not a mass-exploitation candidate. The realistic risk is concentrated: an environment where low-trust editors exist and where the server runs in a cloud instance with a reachable metadata endpoint (169.254.169.254) is high-impact because it can leak instance-role credentials. Because the action is a GET with no CSRF token, there is a secondary vector - a logged-in editor could be lured to a page that triggers the request - which partially softens the PR:L gate. The vendor's SI:H (subsequent-system integrity high) is slightly generous given the description limits impact to returning response bodies (read-oriented), so real integrity impact is closer to low. Net: real priority only where untrusted editor accounts + cloud metadata exposure coexist; otherwise moderate. |
| Exploit ScenarioDerived | A low-trust user with an editor/* role (or an attacker who has phished/compromised such an account) issues GET /admin/index.php?module=editor/editor&action=oEmbedProxy with url set to a hostname that resolves to 169.254.169.254 or an internal service. The server fetches the URL and returns the response body, disclosing cloud instance metadata and associated IAM credentials or internal API responses. No public exploit code exists, but the fix commit clearly documents the bypass (hostname string checked, resolved IP not). |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 17, 2026
Server-side request forgery in Vvveb CMS versions prior to 1.0.8.5 allows an authenticated admin-panel user holding editor/* permission to make the server issue HTTP or HTTPS requests to arbitrary internal addresses through the oEmbedProxy endpoint (GET /admin/index.php?module=editor/editor&action=oEmbedProxy?url=...), returning the fetched response body to the caller. Because the action is reached over GET, no CSRF token is required, so a logged-in editor can be induced to trigger the request cross-site, and the attacker can reach private, loopback, link-local, or reserved destinations - including cloud instance-metadata endpoints such as 169.254.169.254 - potentially disclosing internal service responses and associated credentials. Storefront visitors and anonymous users cannot reach the endpoint (authentication and editor-level privilege are prerequisites), and no public exploit code has been identified at time of analysis; the issue is resolved in 1.0.8.5, which validates resolved IP addresses and pins the outbound connection to the vetted address with redirects disabled.
RemediationAI
Vendor-released patch: upgrade to Vvveb 1.0.8.5 or later (https://github.com/givanz/Vvveb/releases/tag/1.0.8.5), which contains commit bd280f5ce136f6da22c873fb1eea9cad8741e623 and validates the resolved IP of the oEmbed URL, pins curl to that address with CURLOPT_RESOLVE, and disables redirect following. If immediate upgrade is not possible, apply compensating controls with their trade-offs in mind: restrict who holds editor/* admin-panel permission and treat every logged-in editor session as a potential SSRF pivot, acknowledging that this does not remove the exposure for legitimate editors; block the vulnerable route at the reverse proxy or WAF by denying requests matching module=editor/editor and action=oEmbedProxy (side effect: legitimate oEmbed embedding stops working in the editor); and enforce egress filtering so the web tier cannot reach RFC1918, loopback, link-local, and reserved ranges - which stops metadata theft but will also break any intentional fetching of internal resources. On cloud hosts, require IMDSv2 (token-based metadata access) on AWS or the equivalent hardened metadata mode on other providers, since this defeats unauthenticated GET-based metadata retrieval even if an SSRF slips through. Adding an explicit CSRF/same-origin check to the GET action would remove the cross-site trigger path but is only a partial mitigation against a malicious or compromised admin account, which is why the upstream upgrade remains the primary fix.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The defect is a classic Server-Side Request Forgery (CWE-918) rooted in hostname-string validation that never inspects the address a hostname actually resolves to. In the vulnerable code path, oEmbedProxy() in admin/controller/editor/editor.php takes the attacker-supplied url parameter and hands it to getUrl()/download() in system/functions.php, where validateUrl() performed only lexical checks: it rejected URLs containing a port, rejected hostnames without a dot, and rejected a host that was a literal IP via FILTER_VALIDATE_IP. Those checks are trivially bypassed by any hostname that looks like a domain but resolves to an internal address - for example dotted loopback and normalized forms (127.0.0.1.nip.io-style names, decimal/hex-encoded variants) that pass the 'has a dot' and 'not a literal IP' tests yet still resolve to 127.0.0.1, RFC1918, link-local (169.254.0.0/16), or reserved space. The upstream fix (commit bd280f5ce136f6da22c873fb1eea9cad8741e623) replaces the string checks with resolve-then-validate logic: parse_url() is used to require an http/https scheme and non-empty host, then gethostbynamel() resolves the host and every returned address is tested with filter_var(..., FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE), rejecting private, reserved, loopback, and link-local targets. Critically, the fix also binds curl to the validated address via CURLOPT_RESOLVE and sets CURLOPT_FOLLOWLOCATION to false, closing the DNS-rebinding and redirect-to-internal race that make resolve-then-fetch designs exploitable in practice.
Know when Vvveb gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N
Remote, low-complexity, but requires an authenticated editor/* account (PR:L); SSRF reaches other systems (S:C) and discloses metadata/credentials (C:H) with only limited request-issuing integrity impact (I:L).
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
2DescriptionCVE.org
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.
Technical POC Analysis
CWE-918 (Server-Side Request Forgery).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Vvveb CMS installations running versions earlier than 1.0.8.5 can be abused as a proxy into internal networks: an admin-panel user with editor-level permissions can make the server fetch responses from private, loopback, or cloud metadata addresses. Because those endpoints commonly return cloud credentials and tokens, a limited content-editing role can become a stepping stone toward broader cloud and internal infrastructure compromise. No public exploit identified at time of analysis, but any externally reachable Vvveb deployment with more than one privileged editor account should be treated as a high-priority exposure.
No vendor-released patch identified at time of analysis; the advisory indicates the issue is resolved in 1.0.8.5, so upgrade where that release is obtainable. Interim mitigations: enforce egress filtering from Vvveb application servers to loopback, link-local (including 169.254.169.254), and private/reserved address ranges; require IMDSv2 or equivalent metadata hardening on cloud instances so unauthenticated metadata retrieval fails; block or remove external access to the oEmbedProxy action (GET /admin/index.php?module=editor/editor&action=oEmbedProxy) at the WAF or reverse proxy; add Referer/Origin and CSRF-token validation so GET-based cross-site triggering cannot reach the endpoint; minimize and audit admin-panel accounts holding editor/* permissions; and alert on outbound requests to internal or metadata destinations originating from the CMS host.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.
Cross-Site Request Forgery exploits the automatic credential inclusion behavior of web browsers.
An issue in vvveb CMS v.1.0.6 allows a remote attacker to execute arbitrary code via the Plugin mechanism. Rated critica
A vulnerability was found in givanz Vvveb 1.0.5. Rated medium severity (CVSS 5.1), this vulnerability is remotely exploi
Arbitrary File Upload vulnerability in VvvebJs before version 1.7.5, allows unauthenticated remote attackers to execute
Reflected Cross-Site Scripting (XSS) vulnerability in VvvebJs before version 1.7.7, allows remote attackers to execute a
A security flaw has been discovered in givanz Vvveb up to 1.0.7.2. Rated medium severity (CVSS 5.5), this vulnerability
A security vulnerability has been detected in givanz Vvveb 1.0.7.2. Rated medium severity (CVSS 5.3), this vulnerability
Remote code execution in Vvveb CMS v1.0.8 allows authenticated administrators to execute arbitrary system commands as ww
Remote code execution in Vvveb CMS versions prior to 1.0.8.1 allows unauthenticated attackers to inject arbitrary PHP co
Hard-coded credentials in Vvveb's Docker deployment expose the entire application database to unauthenticated remote att
Stored cross-site scripting in Vvveb prior to 1.0.8.1 allows authenticated users with media upload and rename permission
Insecure Direct Object Reference in Vvveb CMS prior to 1.0.8.4 allows any authenticated low-privileged Vendor to read, d
Broken object-level authorization in Vvveb CMS prior to 1.0.8.4 allows an authenticated low-privilege Vendor to access,
Exploit-DB