Emergency: Stored XSS in “Columns by BestWebSoft” (≤ 1.0.3) — What WordPress Site Owners Must Do Now

Date : 8 April 2026
CVE : CVE-2026-3618
Gravité : Low (CVSS 6.5) — but actionable in many environments
Privilège requis : Contributeur (authentifié)
Classe de vulnérabilité : Cross-Site Scripting (XSS) stocké via le columns shortcode id attribute

This advisory is prepared by Hong Kong-based security experts for site owners, administrators, developers and hosting teams. If your WordPress site uses the “Columns by BestWebSoft” plugin (version 1.0.3 or earlier), read this entire advisory carefully. It explains the risk, how an attacker can abuse it, how to detect potential compromise, and immediate and longer-term remediation steps to reduce exposure.

Résumé exécutif

A stored Cross-Site Scripting (XSS) vulnerability exists in the “Columns by BestWebSoft” plugin (versions ≤ 1.0.3). An authenticated user with the Contributor role can submit a specially crafted [columns] shortcode using the id attribute that contains malicious payloads. The plugin fails to properly validate or escape that attribute before rendering. As a result, the payload can be stored in the WordPress database and executed in the browsers of anyone viewing the content where the shortcode is rendered — including administrators and editors who preview or edit the content.

Stored XSS can lead to session theft, privilege escalation (via chained attacks), content injection, SEO spam, and persistent backdoors. Although the public report lists this as low priority under certain assumptions, the real-world risk depends on site configuration and editorial workflows. Many incidents show that stored XSS introduced by lower-privilege accounts can escalate to full site compromise.

If you run this plugin on any site you manage, treat it as vulnerable until the vendor provides an official fixed release. Follow the remediation steps below immediately.

How this vulnerability works (high level, safe explanation)

• The plugin exposes a [columns] shortcode with an id attribut.
• Contributors creating or editing posts/pages may insert that shortcode into content for layout features.
• The plugin does not properly sanitize or escape the id attribute when outputting HTML. Instead of restricting the attribute to a safe identifier (e.g., integer or alphanumeric token), it permits characters that can close attributes or introduce scriptable content.
• A malicious Contributor can save content containing a crafted id value that, when rendered, results in injected JavaScript running in the browser of anyone viewing the post (front-end visitors, editors, admins viewing previews, etc.).
• Because the payload is stored in the database as post content, it will execute whenever the post is viewed. Stored XSS is persistent and therefore dangerous.

Important : This advisory does not publish exploit payloads. The intent is to explain the attack vector and defensive measures without providing details that would facilitate misuse.

Why this is a meaningful risk even with “Contributor” level access

• Contributors can create content that editors and administrators will preview and review. Privileged users frequently open drafts and previews, exposing them to injected scripts.
• Editorial workflows often allow Contributors to add shortcodes or custom HTML blocks; that content can be promoted or published later.
• Some sites permit Contributors to upload media or affect content in ways that influence admin workflows.

In short: allowing Contributors to insert complex shortcodes without strict validation is risky when stored XSS is possible. An attacker with a Contributor account can cause scripts to execute in editors’ and admins’ browsers, enabling cookie theft, CSRF-like chained actions, or lateral movement.

Potential impacts (examples)

• Session cookie theft (where cookies are not HttpOnly or attackers target non-cookie session tokens).
• Browser-based actions executed with admin privileges by chaining XSS to authenticated requests (modifying settings, creating admin users).
• Injection of spam/SEO content, malicious links or ads affecting visitors and reputation.
• Phishing or redirection campaigns targeted at privileged users.
• Planting persistent backdoors or malicious code via plugins/themes if an attacker can trick an admin into performing actions while their session is hijacked.

Detection: How to check your site now

Use a two-track approach: (A) scan for suspicious shortcode usage, and (B) look for signs of compromise.

A. Scan for suspicious [columns] shortcode instances

• Search the database for occurrences of the shortcode in post content. Example (read-only) SQL:

  SELECT ID, post_title, post_author, post_date FROM wp_posts WHERE post_content LIKE '%[columns%id=%';

• Inspect returned posts: note authors and dates. Pay particular attention to Contributors.
• Look for attribute values containing angle brackets (< or >), quotes, or strings such as script, onerror=, onload= — these are red flags.
• Search other storage locations: widget text, custom fields, term descriptions and post meta. Shortcodes and crafted attributes can be stored outside contenu_du_post.
• WP-CLI example grep-style check:

  wp db query "SELECT ID, post_title, post_author FROM wp_posts WHERE post_content REGEXP '\[columns[^\]]*id=[^\]]+'" 

B. Look for indicators of compromise (IOCs)

• Utilisateurs administrateurs ou changements de rôle inattendus.
• Modified theme or plugin files with recent timestamps.
• Entrées suspectes dans wp_options (site_url, active_plugins) or unknown cron jobs.
• Server logs showing unusual POST requests, traffic spikes, or connections from unfamiliar IPs.
• Outbound requests to unknown domains (check egress logs).
• Unusual authenticated session activity — attackers often act quickly after hijacking a session.

If you find suspicious signs, move to containment immediately. If you don’t find anything, still implement hardening and monitoring — stored XSS may be present but dormant.

Étapes d'atténuation immédiates (que faire dès maintenant)

1. Quick containment
   • Temporarily deactivate the vulnerable plugin on sites where it is not essential. Deactivation removes the rendering path for the stored XSS.
   • If the plugin cannot be disabled, restrict access to post editing and previewing: temporarily revoke Contributor privileges or require manual review of Contributor posts.
2. Review recent posts and content
   • Audit posts created/edited by Contributor accounts over the last 30–90 days for suspicious shortcodes (use the detection queries above).
   • If malicious shortcode usage is found, remove it and save a clean copy of the post.
3. Changer les identifiants
   • Reset passwords for accounts that may have been exposed, especially Editors and Admins.
   • Force session invalidation (expire cookies/sessions) to prevent reuse of hijacked sessions.
4. Vérifiez la persistance
   • Inspect plugin and theme directories for unexpected or modified files. Use file integrity tools if available.
   • Look for injected PHP files, modified wp-config.php, or unauthorized admin accounts.
5. Sauvegarder
   • Create a full backup (files + database) before making major changes. Preserve this snapshot for investigation, then take a clean backup after remediation.
6. Monitoring and logs
   • Enable verbose logging temporarily (server and application logs).
   • Begin real-time monitoring for suspicious admin actions and outbound connections.

Patching virtuel et conseils WAF (neutres vis-à-vis des fournisseurs)

If an official plugin update is not yet available or you cannot immediately disable the plugin, virtual patching via a Web Application Firewall (WAF) or equivalent request-filtering layer can reduce risk. Apply rules that detect and block suspicious id attribute patterns in [columns] shortcodes, and sanitize content where feasible.

Vendor-neutral defensive checks (high-level):

• Block requests that submit post content containing [columns où le id contient , script, or common event-handler attributes (e.g., onerror=).
• Inspect POST payloads for post creation/edit endpoints (e.g. wp-admin/post.php and relevant admin-ajax endpoints) and quarantine requests with suspicious shortcode attributes.
• Sanitize content rendered in admin previews and the front-end: remove <script> tags and disallow javascript : URIs where possible.

Note: tune WAF rules to your site’s normal traffic patterns to avoid false positives. Do not copy exploit payloads from public advisories into rules directly; instead use conservative patterns that match clearly malicious attribute content (angle brackets, event handlers, obvious script strings).

Long-term fixes and best practices

1. Principe du moindre privilège

   Re-evaluate whether Contributors need to insert shortcodes. Move layout responsibilities to Editors or require approved workflows for shortcode usage.

2. Content review workflow

   Require shortcode-containing content from untrusted users to be reviewed in a sandbox or by an editor before publishing. Use scheduled publishing and editorial checks.

3. Enforce escaping and sanitization

   Plugins and themes must validate every attribute they accept and escape output on render. For shortcodes, treat attributes as strings or identifiers and sanitize using WordPress APIs (e.g., sanitize_text_field, intval, wp_kses with an allowlist).

4. Politique de sécurité du contenu (CSP)

   Implement a strict CSP that forbids inline scripts and restricts script sources. CSP can mitigate many XSS attacks, but test in staging because it may break legitimate inline behaviour.

5. HttpOnly, Secure & SameSite cookies

   Ensure auth cookies use HttpOnly, Sécurisé, et approprié SameSite flags where possible to reduce the impact of cookie theft.

6. Automated scanning and code review

   Include plugin audits and dependency scanning in maintenance workflows. Use file integrity checks and regular malware scanning.

Developer guidance: how to patch plugin code

If you are the plugin author or a code maintainer, address the issue by validating and escaping the id attribute and adding tests:

• Validate the id on the server:
  • If numeric: cast with intval() and reject non-numeric values.
  • If an alphanumeric token: validate with a whitelist, e.g. preg_match('/^[a-zA-Z0-9_-]+$/').
• Échapper la sortie : utiliser esc_attr() when injecting attribute values into HTML.
• Use WordPress sanitization APIs: sanitize_text_field(), wp_kses() ou wp_kses_post() with a strict allowlist if HTML must be accepted.
• Add unit tests that submit attributes containing quotes, angle brackets and event handler attributes to ensure the plugin rejects or safely escapes them.
• Perform a security review and add regression tests for shortcode rendering.

If you suspect your site is already compromised

1. Containment and triage
   • Take the site offline or place it in maintenance mode if possible.
   • Revoke active sessions (force password reset for all users).
   • Change database credentials and update wp-config.php if you suspect persistent access.
2. Instantané d'analyse
   • Create a full snapshot (files + DB) before changing anything. Preserve this for investigation or external responders.
3. Nettoyage
   • Remove malicious shortcodes or content from posts.
   • Replace modified or injected PHP files with clean copies from trusted backups.
   • Scan for known malware signatures and remove any backdoors.
4. Restaurez à partir d'une sauvegarde propre
   • If you have a clean snapshot from before the compromise, consider restoration and then apply containment, credential rotation and hardening steps.
5. Renforcement post-incident
   • Review what allowed the attack (editorial workflows, insufficient validation, missing virtual patching, delayed patches) and apply the fixes above.

If you need professional incident response assistance, engage a trusted security consultant or your hosting provider’s security team promptly.

Practical checklist — step-by-step for site owners (quick reference)

1. Identify: Search for [columns occurrences in content and metadata.
2. Contain: Deactivate the Columns plugin where possible. If you cannot deactivate, restrict Contributor privileges or require manual review.
3. Clean: Remove or sanitize suspicious id attributes from posts and custom fields.
4. Harden: Apply virtual patching rules on your WAF or request-filtering layer to block suspicious id values and strip <script> tags from rendered content.
5. Rotate: Reset admin/editor passwords, revoke sessions, and enable MFA where possible.
6. Back up: Take a clean backup after remediation.
7. Monitor: Increase logging and watch for suspicious actions; scan for new malicious content.
8. Patch: Update the plugin to a vendor-fixed release as soon as one is available.

Developer note: audit your shortcode handling

If your plugins accept shortcode attributes, run these checks now:

• Are attributes validated against expected patterns or types?
• Are attributes escaped with esc_attr() or otherwise safely rendered?
• Are any attributes injected into attribute contexts without quoting or escaping?
• Do unit tests include attempts to pass values containing >, <, quotes or event handlers?

Example: safe sanitization patterns (developer guidance)

Use strict allowlists. Examples:

// Numeric id
$id = isset($atts['id']) ? intval($atts['id']) : 0;

// Alphanumeric token
if ( isset($atts['id']) && preg_match('/^[A-Za-z0-9_-]{1,64}$/', $atts['id']) ) {
    $id = $atts['id'];
} else {
    $id = '';
}

// Always escape when outputting
echo '<div id="' . esc_attr( $id ) . '">...</div>';

Si un HTML limité est requis, utiliser wp_kses() with a minimal allowlist.

Réflexions finales

Stored XSS via a shortcode attribute can appear low-risk on paper, yet it frequently becomes the first step in a larger compromise. The difference between a contained incident and a full breach is often quick detection, a responsible update process, and layered protections such as carefully tuned request filtering, strict editorial workflows, and strong sanitization practices.

From the perspective of Hong Kong site operators and administrators: act promptly. Search your content for suspicious shortcodes, harden contributor workflows, deploy virtual patching where available, and engage a qualified security professional if you need hands-on containment or recovery assistance.

Restez en sécurité,
Hong Kong-based Security Experts

Appendix: Useful commands and queries (safe, read-only or descriptive)

• Search posts for suspicious columns shortcode (adjust table prefix if not wp_):

  SELECT ID, post_title, post_author, post_date FROM wp_posts WHERE post_content LIKE '%[columns%id=%';

• Export posts with the shortcode for manual review via WP-CLI (modify for your needs):

  wp post list --post_type=post --format=csv --fields=ID,post_title,post_author --post_status=publish,draft

• If unsure what to do next: take a backup and consult a security professional before making intrusive changes.