Passster CVE-2026-16602

Exploitation requires that the target WordPress site has Passster installed with a captcha provider actively configured - this is the specific condition that activates the vulnerable REST endpoint code path. Without captcha provider configuration, the vulnerable endpoint is not triggered. No authentication is required (CVSS PR:N), no user interaction is needed (UI:N), and the attack is executable over the network (AV:N). The primary limiting factor is the captcha configuration requirement; however, since captcha integration is Passster's primary value proposition, most active Passster deployments are likely configured this way. Additionally, the attacker must know or enumerate valid post IDs for non-public content, which may require some reconnaissance but is frequently achievable through sequential ID enumeration on WordPress sites.

The NVD CVSS score of 7.5 (High) reflects a network-accessible, unauthenticated, no-user-interaction vector with high confidentiality impact, which accurately describes the mechanics. However, real-world risk is modulated by several factors. First, exploitation requires that the target site have a captcha provider configured - this narrows the exploitable population to a subset of Passster users, though this subset is likely the majority of active deployments since captcha is the plugin's core use case. Second, the EPSS score of 0.16% at the 5th percentile contrasts sharply with the high CVSS score, indicating that, despite a publicly available proof-of-concept, mass automated exploitation is not currently observed. Third, the impact is limited to confidentiality (C:H, I:N, A:N) - an attacker cannot modify or delete data. The practical harm is leakage of unpublished content (drafts, private posts), which may include sensitive editorial content, unreleased announcements, or personal data depending on site configuration. This is a meaningful risk for content-sensitive sites (media, legal, medical) but low stakes for most general sites. Patch availability at version 4.3.6 and a low EPSS suggest this is a patch-and-move-on priority, not an emergency.

An attacker identifies a WordPress site running Passster with a captcha provider configured, which is discoverable via plugin enumeration. The attacker sends a crafted unauthenticated GET request to the Passster REST endpoint specifying the ID of a known or enumerated private or draft post. Because no post-status validation occurs, the endpoint returns the full post content in the response body. A publicly available proof-of-concept demonstrates this technique.