Putter WordPress Theme CVE-2025-69147

Target site must have the ThemeREX Putter WordPress theme installed and active at version 1.17 or earlier, and the vulnerable theme file/endpoint that takes a filename parameter must be reachable from the network (typical for any internet-facing WordPress site). No authentication and no user interaction are required (PR:N/UI:N), but CVSS AC:H indicates an additional non-default precondition the attacker must satisfy - likely knowledge of the specific parameter name and a payload that survives the theme's path handling. Escalation from arbitrary file read to full I:H/A:H realistically requires permissive PHP settings such as allow_url_include, accessible log/session files for inclusion, or available PHP stream wrappers (phar://, php://filter); hardened PHP installations reduce impact to file disclosure.

Signals are partially conflicting and warrant careful interpretation. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, 8.1 High) indicates a network-reachable, unauthenticated flaw with full CIA impact, but AC:H signals a non-trivial precondition (likely a specific parameter or request pattern that must be discovered or a race/encoding condition). The vulnerability is not listed in CISA KEV, no EPSS score was provided in the input, and no public exploit was identified at time of analysis, so this is not (yet) a mass-exploited target. That said, WordPress themes from ThemeREX have historically attracted scanner-based exploitation once a Patchstack advisory is indexed, so the risk shifts from theoretical to opportunistic quickly. The CWE-98 / I:H rating implies more than file read-write-side or RCE chains via PHP wrappers are plausible-so this should be treated as a near-term patch priority for any site running Putter ≤ 1.17.

An attacker enumerates WordPress sites running the Putter theme via wp-content/themes fingerprinting, then sends a crafted HTTP request to the vulnerable theme endpoint with a path parameter pointing to wp-config.php (or a php://filter convert.base64-encode wrapper) to exfiltrate database credentials and WordPress secret keys. With those credentials, the attacker pivots to admin takeover and, where PHP configuration permits, chains the LFI with log/session poisoning or phar:// deserialization to gain code execution as the web server user. No public PoC is identified at time of analysis, so the initial reconnaissance burden falls on the attacker.