Hong Kong Security Alert BestWebSoft Columns XSS(CVE20263618)

Cross Site Scripting (XSS) in WordPress Columns by BestWebSoft Plugin
Plugin Name WordPress Columns by BestWebSoft
Type of Vulnerability Cross-Site Scripting (XSS)
CVE Number CVE-2026-3618
Urgency Low
CVE Publish Date 2026-04-08
Source URL CVE-2026-3618

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
Severity: Low (CVSS 6.5) — but actionable in many environments
Required privilege: Contributor (authenticated)
Vulnerability class: Stored Cross-Site Scripting (XSS) via the 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.


Executive summary

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 attribute.
  • 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 post_content.
  • 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)

  • Unexpected admin users or role changes.
  • Modified theme or plugin files with recent timestamps.
  • Suspicious entries in 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.


Immediate mitigation steps (what to do right now)

  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. Rotate credentials

    • 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. Check for persistence

    • 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. Back up

    • 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.

Virtual patching and WAF guidance (vendor-neutral)

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 where the id contains <, >, 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