Resumen

• Vulnerability: Authenticated (Administrator) stored cross-site scripting (XSS).
• Affected software: AMP Enhancer — Compatibility Layer for Official AMP Plugin, versions ≤1.0.49.
• CVE: CVE-2026-2027
• Severity: Medium (maintainer rating CVSS 5.9). Real-world impact depends on attacker access to an admin account.
• Exploitation prerequisites: Administrator privileges on the site (or convincing an admin to save malicious CSS).
• Immediate mitigations: deactivate or remove the plugin; inspect and sanitize the stored setting in the database; restrict admin accounts; apply virtual patches / WAF rules to block malicious CSS payloads while preparing a full clean-up.
• Recovery: If compromise is suspected, isolate the site, rotate credentials, scan and remove injected content, and restore from a clean backup if necessary.

Why this stored XSS matters — even with admin-only requirements

Although exploitation requires an administrator to save the payload, the attack surface is still significant:

• Stolen or phished admin credentials allow a persistent foothold via stored XSS.
• Malicious contractors or insiders with admin access can intentionally inject payloads.
• Social engineering can trick an admin into pasting seemingly legitimate CSS that contains hidden payloads.

Possible consequences include session theft, site-wide redirects, SEO poisoning, backdoor script injection, and reputation damage. Because the payload is stored in a configuration and served site-wide, a single successful injection can affect every visitor and administrator who loads affected pages.

How the issue works (technical overview)

1. The plugin provides an “AMP Custom CSS” setting where administrators can enter CSS for AMP pages.
2. The setting is persisted in the database and later echoed into page markup for AMP output.
3. Insufficient sanitisation allows input that can be interpreted by the browser as executable or able to break out of the CSS context (for example, constructs that close a style block or introduce HTML).
4. Because the content is stored and output to visitors, the XSS is persistent (stored) and executes on subsequent page views.

Note: modern browsers and legacy quirks can turn unexpected sequences into executable actions when user-controlled data is output without safe encoding.

Escenarios de explotación realistas

• Stolen admin credentials: attacker logs in, pastes malicious content into AMP Custom CSS, and the payload is served to visitors.
• Social engineering: admin is convinced to paste “recommended CSS” from an untrusted source that contains obfuscated payloads.
• Malicious insider: an employee or contractor with admin access stores a payload to steal data or sabotage the site.

Signs you may already be affected

• Unexpected inline JavaScript or HTML fragments in page source or inside styles.
• Site pages redirecting to external domains.
• Unusual dashboard behavior or unexpected admin notifications.
• New or unknown admin users, edited posts/pages you didn’t make, suspicious cron tasks, or modified core/theme/plugin files.
• Search engine warnings, blacklisting, or unusual traffic patterns.

If you use an affected version of the plugin and notice these signs, assume potential compromise and follow containment steps immediately.

Immediate steps for site owners (ordered)

1. Put the site into maintenance mode or reduce exposure: temporarily restrict public access while investigating.
2. Deactivate the AMP Enhancer plugin: the simplest immediate mitigation is to deactivate or remove the plugin to stop it from serving stored content.
3. Inspect and clean the AMP Custom CSS setting:
   • Check the plugin option where custom CSS is stored (common keys might include amp_custom_css or plugin-specific option names).
   • If you find unexpected content, remove it or set the field to an empty string.
   • Example WP-CLI: wp option get amp_custom_css and to clear: wp option update amp_custom_css ''
   • SQL inspection example (always back up first):

   SELECT option_name, option_value FROM wp_options WHERE option_name LIKE '%amp%' OR option_value LIKE '%javascript:%' OR option_value LIKE '%<script%';

4. Rotate credentials and lock admin access:
   • Reset passwords for all administrator accounts and enforce strong, unique passwords.
   • Require two-factor authentication for all admins where possible.
   • Remove or downgrade unknown admin users.
5. Review recent admin activity: check audit logs (if available) to identify who changed settings; enable logging if absent.
6. Scan the site for other indicators: perform a full-site malware scan and inspect posts, options, theme files, and uploads for injected code.
7. Review backups: if you detect a compromise and cannot clean confidently, restore from a known-good backup taken prior to the injection.
8. Apply virtual patching / WAF rules as an interim measure: block suspicious payloads from being saved and prevent already-stored payloads from reaching clients (details below).
9. Monitor and re-scan regularly after cleanup to detect reinfection or repeated malicious changes.

Finding the AMP Custom CSS entry (WP-CLI and SQL)

Examples to help locate suspect values (replace table prefix if not wp_):

# WP-CLI (if you know the option name)
wp option get amp_custom_css

# Scan options if unsure
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%amp%' OR option_value LIKE '%<script%' OR option_value LIKE '%javascript:%' LIMIT 200;"

# Direct SQL to inspect suspicious patterns
SELECT option_name, LEFT(option_value, 500) AS snippet
FROM wp_options
WHERE option_value LIKE '%<script%'
   OR option_value LIKE '%javascript:%'
   OR option_value LIKE '%onerror%'
   OR option_value LIKE '%expression(%'
LIMIT 500;

Always export suspicious content to a safe environment for analysis before removing it from production.

Safe remediation of the stored setting

• Review CSS for dangerous constructs:
  • url(javascript: patterns
  • expression(...) (legacy IE)
  • -moz-binding or behavior: properties
  • Embedded HTML fragments like </style>, <script>, or event handlers like onerror=
  • Data URIs with HTML or JavaScript (data:text/html;)
• If unsure, clear the field completely and re-enter only minimal, reviewed CSS.
• Prefer moving critical styling into theme files under version control and reviewed by a developer rather than relying on untrusted admin-entered CSS.

Developer guidance: how to fix the plugin correctly

Plugin maintainers should use both strict input validation and safe output encoding:

1. Validate input at save time:
   • Reject arbitrary HTML or constructs not valid in pure CSS fields.
   • Implement a strict whitelist of allowed CSS properties and value formats rather than relying on blacklists.
   • Block constructs such as url(javascript:...), expression(...), -moz-binding, behavior:, and data URIs that embed HTML.
2. Sanitize or escape on output:
   • When writing stored CSS into a page, ensure it cannot break out of a style context. Treat it as plain text and escape characters that could close the style block or start HTML.
   • Use server-side escaping functions appropriate for content placed in <style> bloques.
   • Always enforce capability checks (e.g., current_user_can('manage_options')) and nonces on admin forms and saves.
3. Use a vetted CSS sanitizer library or implement a strict whitelist approach and include unit tests to assert rejection of malicious sequences.
4. Add automated tests and fuzzing to continuous integration to detect regressions and common XSS mutation vectors.
5. Document how custom CSS is processed and warn administrators about pasting untrusted content.

WAF / virtual patching (generic guidance)

A Web Application Firewall (WAF) or response inspection layer is a valuable short-term mitigation while waiting for an official plugin update. Properly configured WAF rules can block attempts to save malicious CSS and prevent already-stored payloads from reaching clients.

Useful actions for a WAF or edge filter:

• Block POST requests that update the plugin’s custom CSS option when payloads contain clear malicious patterns (case-insensitive): url(javascript:, expression(, -moz-binding, <script, onerror=, or suspicious data URIs.
• Inspect outgoing responses and neutralise or strip suspicious sequences before they reach browsers.
• Rate-limit or block admin endpoints from unfamiliar IPs and alert on repeated attempts to change settings.
• Log the admin account and source IP when blocked requests occur to aid forensic analysis.

Example pseudo-regex patterns (for illustration only — test carefully to avoid false positives):

(?i)url\(\s*javascript:
(?i)expression\s*\(
(?i)-moz-binding
(?i)</?script\b
(?i)on\w+\s*=\s*["']?[^"'>]+["']?
(?i)data:\s*text/html

Rules should be tuned to avoid blocking legitimate CSS (for example, legitimate url() references to images). Focus on constructs that have no reasonable legitimate use in modern CSS.

Recovery checklist (if you suspect compromise)

1. Isolate the site (maintenance mode) to limit further damage.
2. Take a full backup (database + files) for forensic analysis.
3. Scan for malicious artifacts: options, posts, theme/plugin files, uploads, and cron entries.
4. Remove malicious content: clear the affected option, replace altered files with originals from trusted sources.
5. Rotate administrator passwords and reset API keys.
6. Audit user accounts and remove unknown or unused admin accounts.
7. Harden admin access: enable 2FA, apply IP restrictions where practical, and minimise admin accounts.
8. Restaura desde una copia de seguridad limpia si es necesario.
9. Monitor the site aggressively post-cleanup for signs of re-infection.

Long-term security best practices for WordPress site owners

• Minimise the number of administrator accounts and use least-privilege principles.
• Enforce strong, unique passwords and require two-factor authentication for admins.
• Keep WordPress core, themes, and plugins updated; test updates in staging before production.
• Remove unused plugins and themes; do not leave disabled plugins installed indefinitely.
• Vet plugins before installing: check recent updates, maintainers, and community feedback.
• Maintain frequent, verified backups stored off-site and regularly test restores.
• Use a WAF or response-inspection layer as part of layered defenses for zero-day scenarios.
• Enable logging and monitoring for administrative actions and review logs regularly.
• Implement Content Security Policy (CSP) to reduce the impact of XSS where compatible with your site/AMP requirements.
• Perform regular security audits and code reviews for custom code.

Recommended HTTP security headers

• Content-Security-Policy (CSP) — a strict CSP can limit where scripts/styles are loaded. Test carefully with AMP.
• X-Content-Type-Options: nosniff
• X-Frame-Options: SAMEORIGIN (o DENY where appropriate)
• Referrer-Policy: no-referrer-when-downgrade (or stricter)
• Strict-Transport-Security: max-age=31536000; includeSubDomains; preload (if using HTTPS)

Carefully test headers to avoid breaking site functionality or AMP constraints.

Detection queries and scans

Use these queries as starting points to search for suspicious stored CSS and XSS indicators (replace table prefix as needed):

SELECT option_name, option_value
FROM wp_options
WHERE option_value LIKE '%<script%'
   OR option_value LIKE '%javascript:%'
   OR option_value LIKE '%onerror=%'
   OR option_value LIKE '%expression(%'
   OR option_value LIKE '%-moz-binding%'
LIMIT 500;

SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%'
   OR post_content LIKE '%javascript:%';

Combine automated scanners with manual inspection; automated tools may miss obfuscated payloads or generate false positives.

Practical admin commands (copy-paste)

# Back up database and files first (always)

# Check the AMP custom CSS option via WP-CLI
wp option get amp_custom_css

# Clear the option
wp option update amp_custom_css ''

# Find suspicious options via SQL
wp db query "SELECT option_name, LEFT(option_value, 500) AS snippet FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%javascript:%' OR option_value LIKE '%onerror%' OR option_value LIKE '%expression(%' LIMIT 200;"

# Search posts for injected scripts
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' LIMIT 200;"

Always take a backup before running update or delete operations on the database.

Final checklist (actionable)

• Temporarily deactivate or remove the AMP Enhancer plugin (≤1.0.49).
• Back up the site (files + database).
• Inspect and, if needed, clear the AMP Custom CSS setting from the database.
• Reset admin passwords and require 2FA for all admins.
• Scan site for injected scripts, modified files, and suspicious scheduled tasks.
• Apply WAF/virtual patch rules blocking dangerous CSS constructs and outbound injection patterns.
• Monitor blocked events and audit logs for recurring attempts.
• Update the plugin immediately when a fixed version is released and test it in staging first.
• Harden admin access (IP restriction, strong passwords, fewer admin accounts).
• Consider moving critical CSS to theme files under version control after code review and QA.

Reflexiones finales

Stored XSS in administrator-facing features like a “custom CSS” field demonstrates how convenience can introduce risk. The right approach is layered: remove or limit the vulnerable plugin, clean and secure the site, and use response-inspection or WAF rules as an interim control while a permanent fix is applied.

If you manage multiple sites or cannot tolerate downtime while cleaning, consider engaging a qualified security professional to implement virtual patching, perform a tailored cleanup, and prepare a remediation plan.

If you’d like a tailored remediation plan (step-by-step commands, a search-and-clean script, and a recommended WAF rule set tuned to your environment), reply with whether you host on shared hosting, managed WordPress, or have root/server access, and I will prepare one.

— Experto en Seguridad de Hong Kong