Shared Files EUVD-2026-64834

Exploitation requires an authenticated WordPress session with at minimum the Contributor role (PR:L per CVSS). This means the attacker must have a valid WordPress account on the target site - unauthenticated exploitation is not supported by the available data. The vulnerability is triggered through a specific plugin feature that processes user-supplied URLs or remote resource references; sites that have Shared Files installed and active but where all user accounts with Contributor or higher roles are fully trusted have negligible practical risk from this path. What limits exploitation: the Contributor role requirement prevents anonymous exploitation; the C:L/I:L impact metrics indicate partial rather than full information disclosure; no scope change to the WordPress file system itself is implied. What enables more severe impact: cloud deployments with IMDSv1 enabled, flat internal networks reachable from the WordPress host, or internal APIs accepting requests from the server's IP without additional authentication.

The official CVSS 3.1 score of 6.4 (Medium) is calibrated by PR:L, meaning exploitation requires a valid WordPress account with at least Contributor privileges - a meaningful but not high bar on sites that allow open registration or have multiple contributors. The S:C (scope changed) metric is the most important signal: it confirms that impact extends beyond the WordPress application itself to backend infrastructure. C:L and I:L indicate limited but real data exposure and potential for interaction with internal services. EPSS data is not provided; KEV status is negative (not in CISA KEV); no POC is referenced. The combination of authenticated requirement (PR:L) and absence of public exploit code lowers immediate priority. However, sites running in cloud environments where IMDSv1 is reachable or with flat internal networks should treat this as a higher-priority remediation, since SSRF-to-credential-theft chains are well-documented and do not require sophisticated post-exploitation skills once the SSRF primitive is available.

An attacker who has obtained or registered a WordPress Contributor account on a vulnerable site crafts a request to the Shared Files plugin feature that accepts user-supplied URLs, substituting a target such as http://169.254.169.254/latest/meta-data/ (AWS IMDSv1 metadata endpoint). The server fetches the URL and returns internal cloud metadata - potentially including IAM role credentials - to the attacker. No public exploit code is known at time of analysis, but the SSRF primitive is well-understood and the exploitation pattern is documented widely in security literature.