CVE-2026-12106: Auto Upload Images <= 3.3.2 - Authenticated (Contributor+) Server-Side Request Forgery via 'src' Attribute of <img> Tags
The Auto Upload Images plugin for WordPress is vulnerable to Limited Server-Side Request Forgery in all versions up to, and including, 3.3.2 via the downloadImage function. This makes it possible for authenticated attackers, with contributor-level access and above, to make web requests to arbitrary locations originating from the web application. The plugin uses wpremoteget() rather than wpsaferemoteget(), and the validate() method only rejects URLs whose host matches the site's own hostname, failing to block requests to private, loopback, or link-local addresses (e.g., 127.0.0.1, 10.0.0.0/8, 169.254.169.254). Attackers can trigger this by embedding a crafted <img> tag with a src attribute pointing to internal network hosts in post content and submitting it for processing.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
wordpress/plugins/auto-upload-imagesto a version that resolves this vulnerability.Fixed in 3.3.2 - Configuration
Update the plugin’s URL validation logic so that validate() rejects URLs targeting private, loopback, and link-local addresses rather than only blocking the site’s own hostname. This is required to prevent SSRF via <img src=...> processing.
WordPress Auto Upload Images plugin validate() host check = reject private, loopback, and link-local IP ranges (e.g., 127.0.0.1, 10.0.0.0/8, 169.254.169.254) - Configuration
Change the plugin’s downloadImage function to use wp_safe_remote_get() (not wp_remote_get()) to leverage WordPress SSRF protections during server-side fetches.
WordPress Auto Upload Images plugin HTTP request function = use wp_safe_remote_get() instead of wp_remote_get()
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs an authenticated WordPress account with Contributor-level permissions or higher. They must be able to submit post content containing a crafted img tag.
What can an attacker request through the vulnerable site?
The attacker can cause the WordPress application to make requests to arbitrary locations, including private, loopback, and link-local addresses. Examples identified include 127.0.0.1, addresses in 10.0.0.0/8, and 169.254.169.254.
Does the hostname validation prevent access to internal services?
No. The validation only rejects URLs whose host matches the site's own hostname, so it does not block private, loopback, or link-local destination addresses.
How is exploitation triggered?
The attacker embeds an img tag whose src attribute points to an internal or other target location in post content, then submits that content for processing by the plugin.