Published October 23, 2026. Based on public CVE records available on that date; details may change.

Otter Blocks versions before 3.2.8 are affected by four CVEs published on October 23, 2026: two stored cross-site scripting (XSS) flaws and two ways to read restricted content through the WordPress REST API. Three of the four can be used without logging in. Update Otter Blocks to 3.2.8, then review contributor accounts, restricted blocks, and, on WooCommerce sites, coupon codes.

What happened

The four records describe separate problems in the same plugin, all fixed in 3.2.8.

CVE-2026-109933: stored XSS via block styling (contributor and above)

Otter Blocks writes block styling values into an inline stylesheet. According to the CVE record, it did not properly sanitize and escape those values, so a user with contributor-level access or higher could inject script that runs when any visitor, including an administrator, views the affected post. Affected: all versions before 3.2.8.

CVE-2026-109934: non-public content through the REST API (unauthenticated)

A REST API endpoint in the plugin treated any post with the "published" status as public. The record says this let unauthenticated users read manual excerpts of password-protected posts, the content and titles of non-public post types, and, on WooCommerce sites, coupon codes and their descriptions. Affected: versions 3.1.1 up to, but not including, 3.2.8.

CVE-2026-109935: block visibility conditions not enforced over REST (unauthenticated)

Otter lets site owners show a block only to certain visitors. The record says those visibility conditions were not enforced when a published post was rendered through the WordPress REST API. Unauthenticated users could read block content restricted to specific roles, logged-in users, the post author, categories or tags, or, on the Pro tier, Stripe purchasers. Affected: all versions before 3.2.8.

CVE-2026-109936: stored XSS via dynamic content tokens (unauthenticated)

Otter rewrites dynamic-content tokens while rendering blocks. The record says the pattern it uses was not correctly bounded, so it could consume the quote that closes an HTML attribute and pull nearby unescaped data into the markup as new attributes. This allows unauthenticated users to achieve stored XSS that runs in the browser of any visitor, including a logged-in administrator. Affected: all versions before 3.2.8.

None of the four CVE records includes a CVSS score. The records reviewed for this article do not mention exploitation in the wild. The 3.2.8 changelog on WordPress.org, dated October 19, 2026, lists "Enhanced security" without naming these issues.

Who is affected

Any site running Otter Blocks before 3.2.8 is affected by at least three of these issues, and sites on 3.1.1 or later are affected by all four. Otter Blocks has 300,000+ active installations on WordPress.org as of October 23, 2026.

The practical risk depends on how you use the plugin:

  • Sites with contributor accounts (guest writers, agencies, membership sites) should pay attention to CVE-2026-109933.
  • Sites using Otter's visibility conditions to hide blocks from some visitors should assume that content was readable through the REST API on affected versions (CVE-2026-109935).
  • WooCommerce sites should treat coupon codes as possibly exposed (CVE-2026-109934), along with excerpts of password-protected posts.
  • Every site on an affected version is exposed to CVE-2026-109936, which needs no account.

How to check your site

Check the version first. In the dashboard, open Plugins and find Otter Blocks. With WP-CLI, run wp plugin list --name=otter-blocks from the WordPress directory.

Then check the people and content involved:

  1. List contributors and above with wp user list --role=contributor, and repeat for author, editor, and administrator. Confirm every account belongs to someone you know. Our guide to finding hidden WordPress admin users helps with accounts that are hard to spot.
  2. Review posts that contain Otter blocks and were created or edited recently by lower-privileged users. Look for odd styling values or markup that looks like code.
  3. List pages that rely on Otter visibility conditions, and note what content they hide.
  4. On WooCommerce sites, list active coupons under Marketing, Coupons and note which ones should not be public.

Watch for signs that script ran in an administrator's browser: new admin accounts, changed settings, or edited plugin and theme files. The checklist in signs a WordPress site is hacked covers the common symptoms.

What to do now

Update Otter Blocks to 3.2.8 or later through Dashboard, Updates, the Plugins screen, or wp plugin update otter-blocks. If you also run Otter Pro, keep it current through its own update path; the CVE records list Otter Blocks as the affected product.

After the update:

  • Clear page and CDN caches so pages rendered on the old version are rebuilt.
  • Replace WooCommerce coupon codes that were not meant to be public, especially high-value or single-use ones.
  • If visibility conditions protected content that matters (pricing, member material, purchased content), treat it as possibly read and decide whether anything needs to change.
  • Remove contributor and higher accounts that are no longer needed.

Updating stops further exposure, but it does not undo content that was already read or script that already ran. If you find signs of tampering, preserve a backup first, then work through a structured cleanup. Our guide on how to fix a hacked WordPress site lays out the order.

When to get help

Get help if you find unexplained admin accounts or file changes, or if restricted content and coupons on your site carry real business value and you need to know what was exposed. WordPress malware removal is the right start for a suspected compromise, and a security audit can review user roles, REST API exposure, and plugin configuration.

Sources