Otter Blocks EUVD-2026-108588

Exploitation requires a target site running Otter Blocks before 3.2.8 that actually uses the plugin's block visibility conditions to restrict content - gating blocks to specific roles, logged-in users, the post author, specific categories or tags, or (Pro tier) Stripe purchasers - and that restricted content must reside in a published post exposed via the WordPress REST API. No authentication is needed (PR:N), no user interaction, and default REST API exposure of published posts is sufficient. The key limiting factor is feature usage: sites that do not place sensitive content behind Otter's visibility conditions, or that restrict REST API access, are not meaningfully exposed; impact is bounded to disclosure of the gated block text (C:L), with no integrity or availability effect.

This is a moderate-severity information disclosure flaw (CVSS 5.3, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) whose signals point consistently toward low urgency rather than emergency patching. The CVSS vector confirms network, low-complexity, unauthenticated exploitation with no user interaction, but impact is limited to a partial confidentiality loss (C:L) with no integrity or availability effect - consistent with CWE-200. EPSS is only 0.15% (4th percentile), indicating very low modeled exploitation probability, and the vulnerability is not listed in CISA KEV, so there is no evidence of active exploitation. No public exploit code or PoC reference is shown in the provided data. The vuln.today decision label is 'this_month', which aligns with the low-EPSS/no-KEV picture: a real issue worth patching on a normal cadence, not a drop-everything priority. The signals are internally consistent - no conflicts between CVSS, EPSS, KEV, and the decision label. The main real-world caveat is that exploitability depends entirely on whether a site actually uses Otter Blocks' visibility conditions to gate sensitive content; the raw CVSS score does not capture that configuration dependency.

A site owner uses Otter Blocks to hide blocks containing sensitive text (e.g., member-only notes, author drafts, or Stripe-purchaser-only content) inside a published post. An unauthenticated attacker requests that post through the WordPress REST API, which renders the post without enforcing the block visibility conditions, returning the restricted block content in the response. No public exploit code is identified at time of analysis, though the technique is trivial (a single REST API GET request).