CVE-2026-12123: WordPress Video Gallery Plugin SSRF Flaw

CVE-2026-12123 Overview

CVE-2026-12123 is a Server-Side Request Forgery (SSRF) vulnerability affecting the All-in-One Video Gallery plugin for WordPress in all versions up to and including 4.8.5. The flaw exists in the handling of the vdl parameter, which the plugin uses to stream video content. Authenticated attackers holding Subscriber-level access or higher can force the WordPress server to issue arbitrary HTTP requests and receive the full response body. This exposes internal network services, cloud metadata endpoints, and loopback interfaces to remote querying. The vulnerability is tracked under CWE-918: Server-Side Request Forgery.

Critical Impact
Low-privileged users can pivot the WordPress host into internal network reconnaissance, potentially reaching cloud metadata services, admin panels, and non-public APIs reachable from the server.

Affected Products

All-in-One Video Gallery plugin for WordPress — all versions through 4.8.5
WordPress sites permitting Subscriber-level registration with the plugin installed
WordPress deployments with XML-RPC enabled and the vulnerable plugin active

Discovery Timeline

2026-07-10 - CVE-2026-12123 published to the National Vulnerability Database
2026-07-10 - Last updated in NVD database

Technical Details for CVE-2026-12123

Vulnerability Analysis

The vulnerability resides in the plugin's video download handler, which resolves the vdl query parameter to a post ID and streams the URL stored in that post's mp4 meta field. The handler does not validate whether the target URL points to an external, publicly routable resource. It also proxies the full response body back to the requesting client, turning the WordPress instance into an open request relay. Because the download endpoint itself is unauthenticated, any actor who can seed the mp4 post meta can later trigger the fetch anonymously.

The plugin's role configuration grants Subscriber-level accounts the capability to create aiovg_videos posts. Combined with WordPress's XML-RPC wp.newPost method, a Subscriber can programmatically create a video post and populate the mp4 meta field with an attacker-chosen URL. Requests to ?vdl=<post_id> then cause the server to fetch that URL server-side.

Root Cause

The root cause is missing validation of user-supplied URLs stored in the mp4 post meta before the plugin issues an outbound HTTP request on behalf of the client. The download handler treats the stored URL as trusted content and streams the response body without restricting the destination host, scheme, or address range. Subscriber-level users additionally have overly broad capabilities to create video posts and set arbitrary meta values.

Attack Vector

An attacker registers a Subscriber account on a WordPress site running a vulnerable version of the plugin. Using XML-RPC wp.newPost, the attacker creates an aiovg_videos post and sets its mp4 post meta to an internal or loopback URL such as http://127.0.0.1/wp-admin/, http://169.254.169.254/latest/meta-data/, or an internal service address. The attacker then issues an unauthenticated GET request to /?vdl=<post_id>. The WordPress server dereferences the stored URL, fetches the target, and returns the full response body to the attacker. This enables internal service enumeration, cloud metadata theft, and interaction with unauthenticated internal APIs. Technical details are available in the Wordfence Vulnerability Report and in the WordPress plugin source.

Detection Methods for CVE-2026-12123

Indicators of Compromise

Newly created aiovg_videos custom post entries authored by Subscriber-level accounts, particularly ones created via XML-RPC.
Outbound HTTP requests from the WordPress PHP process to RFC1918 addresses, 127.0.0.1, 169.254.169.254, or other internal service endpoints.
Web access log entries containing ?vdl= query parameters where the referenced post has an mp4 meta value pointing to non-public hosts.
POST requests to /xmlrpc.php from newly registered Subscriber accounts followed shortly by anonymous ?vdl= requests.

Detection Strategies

Correlate WordPress audit logs for Subscriber account creation with subsequent wp.newPost XML-RPC calls creating aiovg_videos posts.
Inspect the wp_postmeta table for mp4 meta values whose URLs resolve to private, loopback, or link-local address ranges.
Monitor egress traffic from the web server for HTTP requests originating outside of expected update or API destinations.

Monitoring Recommendations

Enable WordPress logging plugins or SIEM ingestion of PHP error_log and access logs to capture the vdl parameter and requestor IP.
Alert on any server-originated connections to cloud instance metadata endpoints such as 169.254.169.254 or GCP's metadata.google.internal.
Track XML-RPC usage volume per user and flag Subscriber-level accounts invoking wp.newPost.

How to Mitigate CVE-2026-12123

Immediate Actions Required

Update the All-in-One Video Gallery plugin to a version above 4.8.5 that contains the fix from WordPress changeset 3582575.
Audit existing aiovg_videos posts and remove entries whose mp4 meta references internal, loopback, or metadata-service URLs.
Review Subscriber-level accounts created recently and disable or delete accounts that show suspicious XML-RPC activity.

Patch Information

The vendor addressed the vulnerability in the release following version 4.8.5, tracked in WordPress plugin changeset 3582575. Site administrators should apply the update through the WordPress plugin manager or WP-CLI as soon as possible.

Workarounds

Disable the All-in-One Video Gallery plugin until the patched version is deployed.
Restrict or disable WordPress XML-RPC access by blocking /xmlrpc.php at the web server or WAF layer.
Close public user registration or restrict the Subscriber role from creating aiovg_videos posts by adjusting capabilities in includes/roles.php.
Enforce egress network controls that block the WordPress host from reaching RFC1918 ranges, 127.0.0.1, and cloud metadata IPs from the PHP process.

bash

# Configuration example: block xmlrpc.php in nginx and restrict egress
location = /xmlrpc.php {
    deny all;
    return 403;
}

# iptables egress restriction for the web server user
iptables -A OUTPUT -m owner --uid-owner www-data -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 192.168.0.0/16 -j REJECT