Auto Upload Images EUVD-2026-82730

Requires an authenticated WordPress account with contributor-level capability or higher (PR:L) on a site running Auto Upload Images <= 3.3.2; no additional user interaction is needed (UI:N). Exploitation is triggered by embedding an <img> tag whose src points at an internal target in post content and submitting it so the plugin's downloadImage function processes it. The vulnerability is inherent to default behavior because the plugin uses wp_remote_get() (not wp_safe_remote_get()) and its validate() method only rejects the site's own hostname - no non-default configuration is required. The primary limiting factors are the contributor authentication gate and the 'Limited' nature of the SSRF (a GET-based image fetch with only low confidentiality impact); the highest-value outcome (cloud metadata credential theft via 169.254.169.254) is contingent on the site being hosted on a cloud provider that exposes an unprotected IMDS endpoint.

This is a genuine but bounded SSRF issue that sits in the medium-severity band, and the multi-source signals are internally consistent. The vendor CVSS 3.1 score of 6.4 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) reflects a network-reachable flaw with low attack complexity but a real authentication gate: PR:L means a contributor-level account is required, which meaningfully limits the attacker population to users who already have publishing/authoring rights on the WordPress site. There is no EPSS score, no CISA KEV listing, and no public exploit code referenced - only the Wordfence advisory and the trac source lines documenting the vulnerable code. So exploitation status is 'no public exploit identified at time of analysis.' The most important signal beyond the raw score is the impact ceiling: the vendor itself labels this 'Limited' SSRF (the plugin issues a GET via wp_remote_get() to fetch an image), and the CVSS confidentiality impact is only C:L, so this is not a full read-anything SSRF. The realistic priority driver is cloud-metadata exposure (169.254.169.254) - a contributor account on an AWS/GCP-hosted WordPress site could pivot to IMDS and potentially harvest instance credentials, which elevates practical risk on cloud deployments beyond what C:L suggests. On a self-hosted bare-metal site the impact is closer to internal port-scanning/host-discovery. Net: a real, patch-worthy issue but not an emergency - no evidence of active or automated exploitation, and the contributor prerequisite plus limited data exfiltration keep it out of the critical tier.

An attacker who holds (or has phished/registered into) a contributor-level WordPress account authors a post containing a crafted <img src="http://169.254.169.254/latest/meta-data/..."> tag and submits it for processing. The Auto Upload Images plugin's downloadImage function fetches that URL server-side with wp_remote_get(), and because validate() only blocks the site's own hostname, the request reaches the internal/loopback/link-local target. No public POC is referenced, but the technique is straightforward and the attack complexity is low (AC:L).