Summary: A stored Cross-Site Scripting (XSS) vulnerability (CVE-2026-2300) affects BJ Lazy Load versions ≤ 1.0.9 and allows an authenticated user with Contributor privileges to inject persistent JavaScript into a site. Although the immediate risk is considered low-to-moderate (CVSS 6.5), stored XSS can be leveraged in targeted or supply-chain attacks. This post explains the vulnerability, real-world impact, detection steps, and concrete mitigation and remediation actions using practical hardening and WAF (virtual patching) strategies you can implement immediately.

TL;DR — Qué sucedió y por qué deberías preocuparte

• A stored XSS vulnerability exists in BJ Lazy Load (versions ≤ 1.0.9). An authenticated user with Contributor privileges can store JavaScript that is later rendered and executed in browsers.
• Attack complexity: requires an authenticated Contributor account; payloads are persistent and can be triggered repeatedly.
• Severity: CVSS 6.5 (medium). Stored XSS can still enable privilege escalation, account takeover, persistent site defacement, or delivery of secondary payloads.
• Immediate actions: restrict Contributor capabilities, audit recent content and media, apply virtual patches with a WAF or perimeter filter, and follow the remediation checklist below.

This guidance is written from the perspective of security practitioners based in Hong Kong, focused on fast, practical containment and recovery for site owners, hosts, and developers.

Background: what is stored XSS and why Contributor accounts matter

Cross-Site Scripting (XSS) happens when untrusted data is included in a page without proper validation or escaping, allowing attacker-supplied scripts to run in a victim’s browser.

Stored XSS (persistent XSS) occurs when the malicious payload is saved server-side (post content, media metadata, plugin settings, comments) and returned to clients later without sanitization. Every visitor — or a targeted admin — can trigger the payload when viewing a page or admin interface.

The WordPress Contributor role can create and edit posts and, depending on configuration, may upload files or fill fields that plugins render. If a plugin accepts Contributor input and outputs it unescaped, that opens the door to stored XSS.

What we know about this specific issue (high level)

• Affects: BJ Lazy Load plugin (versions ≤ 1.0.9)
• Tipo de vulnerabilidad: Cross-Site Scripting almacenado (XSS)
• Privilegio requerido: Contribuyente (autenticado)
• CVE: CVE-2026-2300
• Patch status at publication: No official plugin patch available — site owners must apply mitigations

Key risk: malicious Contributor accounts (or attackers who compromise Contributor accounts) can save payloads that render in the site or admin UI. Those payloads can act with admin-level contexts when triggered.

Attack scenarios — how an attacker might abuse this vulnerability

1. Malicious content in post metadata or lazy-load attributes

   A Contributor uploads an image or edits a field the plugin processes. The plugin records a crafted attribute or caption including script or event handlers, then outputs it without escaping. When editors or visitors load the page, the script executes.

2. Targeting admin users

   If payloads are visible in admin screens (media library, plugin settings), viewing the page as an admin can run injected scripts using the admin’s session to perform actions like changing options or creating users.

3. Amplificación de ingeniería social

   Stored payloads persist. Attackers can craft messages that lure admins to specific pages (for review), increasing the chances of execution.

4. Ataques encadenados

   Stored XSS can steal session cookies, create admin accounts, or deliver secondary payloads such as malware or redirects. Combined with other flaws, the impact escalates rapidly.

Why this is not just a “low severity” cosmetic issue

Even when scored as low/medium, stored XSS is attractive to attackers because it is persistent, can target admins, and can be used as an entry vector for supply-chain or mass campaigns. It can enable data theft, cryptomining, credential theft, or malware distribution. Treat stored XSS seriously and act promptly.

Immediate steps for site owners — containment (first 60–120 minutes)

1. Limit access: Put the site into maintenance mode or restrict admin access to reduce the chance an injected payload executes in a privileged session.
2. Restringir cuentas de Colaboradores: Change Contributor passwords and temporarily revoke Contributor privileges. If possible, disable the ‘upload_files’ capability for Contributors.
3. Disable or remove the vulnerable plugin: Deactivate BJ Lazy Load from the Plugins screen. If you cannot access the admin, rename the plugin folder via SFTP/SSH (e.g., wp-content/plugins/bj-lazy-load → bj-lazy-load.disabled) to force deactivation.
4. Apply perimeter filtering / virtual patching: Use your web application firewall (WAF) or reverse proxy to block requests that include script tags or suspicious payloads in areas the plugin writes to (postmeta, captions, lazy-load attributes). See the WAF guidance section for rule examples.
5. Audit recent content and media uploads: Search for suspicious posts, attachment metadata containing “
6. Rotate keys and secrets: Change admin passwords, rotate salts in wp-config.php if compromise is suspected, and force logout of all sessions.

How to detect if your site has been injected

Search the database for script tags and suspicious HTML attributes. Use WP‑CLI or direct SQL queries from a maintenance window.

Search posts and pages for script tags:

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%

wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_type = 'attachment' AND (post_excerpt LIKE '%

wp db query "SELECT option_id, option_name FROM wp_options WHERE option_value LIKE '%