CVE-2026-54507: Vvveb oEmbedProxy vulnerable to server-side request forgery
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Vvvebto a version that resolves this vulnerability.Fixed in 1.0.8.5
Event History
Frequently Asked Questions
Which users can trigger the vulnerable request functionality?
An authenticated user who can access the admin panel and has editor/* permission can invoke the oEmbedProxy endpoint. Storefront users and anonymous visitors cannot invoke it directly.
Can this be exploited through an administrator's browser without a CSRF token?
Yes. The action uses GET and does not require a CSRF token, so an attacker may be able to cause a logged-in, permitted administrator's browser to request the endpoint.
What internal targets can be reached?
A permitted attacker can use hostname forms that resolve to private, loopback, link-local, or reserved addresses. The server can make HTTP or HTTPS requests and returns the response body, potentially exposing internal service data or cloud metadata credentials.
What should be done if an immediate upgrade is not possible?
Restrict admin-panel access and remove or limit editor/* permission for users who do not require it. Limiting the server's outbound access to private, loopback, link-local, reserved, and cloud metadata addresses can reduce exposure until version 1.0.8.5 is deployed.