Hide My WP Ghost CVE-2026-81806

No authentication is required per the CVSS PR:N designation, and network access alone (AV:N/AC:L) is sufficient - no special configuration of the plugin beyond its presence and activation on a WordPress site is stated in the available data. The exploit is limited in direct impact to C:L/I:L with no availability impact; the attacker cannot directly execute code on the WordPress host through this vector alone, but can probe and interact with internal systems reachable by the server. Exploitation requires that the WordPress site is internet-accessible and running Hide My WP Ghost version 7.0.09 or earlier. If the vulnerable code path is behind a WordPress nonce or login check not reflected in the CVSS PR:N rating, unauthenticated exploitation would be limited - this cannot be confirmed without Patchstack's full technical disclosure.

The CVSS 7.2 score is driven by AV:N/AC:L/PR:N/UI:N - unauthenticated, low-complexity, network-reachable exploitation requiring no user interaction - combined with a scope change that amplifies potential blast radius beyond the WordPress host. EPSS data is not provided; given that no KEV listing and no public PoC have been identified, immediate mass exploitation is not confirmed, though the broad attack surface (any internet-facing WordPress site running the plugin) makes this a priority for operators to patch promptly. SSRF with scope change can serve as a stepping stone for internal network reconnaissance, cloud metadata credential theft, or interaction with unauthenticated internal APIs, meaning even a mid-sized municipal IT team in leszno managing WordPress-hosted public services should treat this as urgent if the plugin is deployed. The primary uncertainty is whether PR:N is confirmed - Patchstack's advisory is the sole reference, and the exact exploitable endpoint is not described publicly; if the vulnerable code path is only reachable post-login, the real-world risk would be materially lower than the CVSS implies.

An unauthenticated attacker sends a crafted HTTP request to the vulnerable WordPress endpoint, supplying an attacker-controlled internal URL as the target - for instance, the AWS EC2 metadata service at 169.254.169.254. The WordPress server fetches the URL and returns enough of the response (directly or via error messages) for the attacker to harvest IAM credentials or map internal services. No public PoC has been confirmed, but the technique is well-documented for SSRF vulnerabilities of this class.