The 'any authenticated user' framing in this CVE obscures the real design failure: this plugin treats subscriber-level access as sufficient trust for arbitrary HTTP egress. That's not a permission slip — it's a capability modeling collapse. In WordPress, 'subscriber' is read-only access. The fact that a server-side HTTP requester with full method, header, and body control sits behind subscriber credentials tells you the developer never modeled this feature's trust boundary at all. They likely checked is_user_logged_in() or the equivalent and called it done — a pattern I encounter repeatedly where developers treat 'logged in' as a binary trust signal rather than a capability gradient.
The architectural question is why this endpoint was accessible at all below admin or editor roles. What was the intended use case — subscribers submitting URLs for something? If so, why not restrict methods, validate schemes, or block private IP ranges? The arbitrary method and header control signals this wasn't 'user submits a link' — it was a proxy left wide open. This points to either a development scaffold that bypassed capability checks, or scope creep where a debug feature became production code. The absence of a nonce compounds this: the CSRF check wasn't just missing, it was never wired, suggesting the developer didn't model this as a state-changing action requiring protection.
The CVSS 6.4 rating undersells this severely. Arbitrary HTTP egress from subscriber context against internal services — private IP ranges, cloud metadata endpoints, internal APIs — is functionally a pivot point. An attacker with this doesn't need a second vulnerability if the internal service trusts the source IP. AWS IMDS token extraction, internal admin panel access, database admin interfaces on adjacent hosts — the header control is the escalation vector because you can't GET an AWS metadata token without being able to send that exact request.
This fits a documented lineage of WordPress plugin SSRF: remote request utility exposed, no capability gate, no URL validation. WordPress core never provided a safe-by-default HTTP fetch mechanism that gates on capability AND validates against private IP ranges. Every developer reaching for wp_remote_request() invents their own security boundary from scratch — and this pattern keeps failing. The fix will likely add a capability check to this endpoint, but that closes one hole while the same flawed pattern may exist elsewhere in the codebase. The real question: what else has this developer forgotten to model?