Community Alert Info Cards XSS Vulnerability(CVE20264120)

Cross Site Scripting (XSS) in WordPress Info Cards Plugin
Plugin Name Info Cards
Type of Vulnerability Cross-Site Scripting (XSS)
CVE Number CVE-2026-4120
Urgency Low
CVE Publish Date 2026-03-21
Source URL CVE-2026-4120

Authenticated Contributor Stored XSS in the Info Cards Plugin (≤ 2.0.7) — What WordPress Site Owners and Developers Must Do Now

Date: 19 Mar, 2026 — CVE-2026-4120 — CVSS: 6.5

As a Hong Kong security expert with frequent incident response experience across media and publishing sites, I treat this alert as an operational risk that requires immediate, pragmatic action. Info Cards versions 2.0.7 and earlier contain a stored Cross-Site Scripting (XSS) flaw that allows an authenticated user with Contributor privileges to persist JavaScript into Gutenberg block attributes. That content can execute later in the context of other users — including Editors or Administrators — when the post or block is viewed or edited.

This article explains, in plain technical terms: how the vulnerability works, attack scenarios and impact, immediate mitigations if you cannot patch instantly, practical WAF/virtual-patch patterns you can apply, developer fixes, and post-incident checks.


TL;DR — What to do right now

  1. Update the Info Cards plugin to 2.0.8 or later immediately — this is the official patch.
  2. If you cannot update immediately:
    • Deactivate the plugin temporarily.
    • Restrict Contributor accounts from creating or editing blocks registered by the plugin.
    • Enforce manual review of any content created by Contributors before publishing.
    • Apply WAF / virtual-patching rules (examples below) to block suspicious payloads targeting block attributes.
  3. Scan the site for malicious content and backdoors; rotate admin passwords and API keys if you detect suspicious activity.
  4. Enable stricter security headers and monitoring (Content Security Policy, X-Content-Type-Options, logging).

What is Stored XSS, and why is it dangerous here?

Stored Cross-Site Scripting (XSS) occurs when an attacker stores script content on the server that later executes in other users’ browsers. In this case, Info Cards accepts and saves Gutenberg block attributes without adequate server-side sanitization. A Contributor can craft attributes containing malicious payloads that execute when a privileged user opens the post in the editor or previews it. Because Contributors are common on multi-author sites, this is a realistic attack vector.

The attack combines a low-privilege authenticated user with a persistent payload that can run in a high-privileged user’s browser — enabling session theft, authenticated actions, or stealthy content injection. Even where no credentials are stolen, reputational and compliance damage can follow.

Vulnerability summary (technical)

  • Affected component: Info Cards WordPress plugin (Gutenberg block-based).
  • Vulnerable versions: ≤ 2.0.7.
  • Patched in: 2.0.8.
  • Type: Stored Cross-Site Scripting (XSS) via Gutenberg block attributes.
  • Required privilege: Contributor (authenticated).
  • CVE: CVE-2026-4120.
  • CVSS: 6.5 (medium/important — impact varies by site context).

Root cause (summary): Block attributes are accepted and persisted without sufficient server-side sanitization for fields that may be output as attributes or HTML. When those attributes are rendered in the editor or on the frontend without proper escaping, attacker-controlled payloads can execute.

How an attacker can abuse this (attack scenarios)

  1. A malicious Contributor creates a post or block using Info Cards and inserts a payload inside a block attribute.
  2. The payload is stored in the database (post_content or postmeta).
  3. An Editor or Admin opens the post in the editor (or previews it) and the attribute content is inserted into the DOM without proper escaping.
  4. The JavaScript executes in the privileged user’s browser, enabling:
    • cookie or session theft (if cookies are not properly protected),
    • authenticated requests performed via the user’s session,
    • further content injection or backdoor planting,
    • creation of new admin users via actions executed in the admin context.

Indicators of compromise (what to look for)

  • Posts edited or created by Contributor accounts containing unusual script-like attributes or encoded payloads inside block attributes.
  • Editor browser console errors when certain posts are opened.
  • Unexpected redirects, popups, or remote resource loads while previewing or loading pages with Info Cards blocks.
  • New users or changes to site settings that occurred without clear authorization.
  • Outbound admin-area network calls to suspicious domains.
  • Injected