Remote Code Execution in “Custom css-js-php” WordPress Plugin (≤ 2.0.7) — What Site Owners Must Do Now

Resumen: A high-severity vulnerability (CVE-2026-6433) affecting the WordPress plugin “Custom css-js-php” (versions ≤ 2.0.7) enables an unauthenticated SQL injection that can be chained to remote code execution (RCE). Because the exploit requires no authentication and can result in full site compromise, every site running the affected plugin should treat this as an emergency. The guidance below, written from the perspective of a Hong Kong security expert, explains the risk, how the chain works at a high level, immediate containment steps, detection/response guidance, and recovery actions.

Nota: This article does not publish exploit proof-of-concept (PoC) code. The goal is to help site operators secure sites, detect compromise, and recover quickly.

Por qué esta vulnerabilidad es tan peligrosa

Two factors make this vulnerability extremely high-risk:

1. Acceso no autenticado — the vulnerable code is reachable without logging in to WordPress, removing common barriers such as account authentication or admin-only pages.
2. SQL injection chaining to RCE — the initial flaw is SQL injection (A3: Injection). When SQL injection can modify stored data that is later evaluated or written as code, attackers can achieve remote code execution, persistent backdoors, or full administrative takeover.

In short: an attacker who finds an unpatched site running Custom css-js-php ≤ 2.0.7 can potentially execute arbitrary code, create admin users, install persistent backdoors, exfiltrate data, and move laterally across infrastructure.

What we know (high-level technical overview)

• Affected software: WordPress plugin “Custom css-js-php”
• Vulnerable versions: versions up to and including 2.0.7
• Vulnerability class: SQL Injection (unauthenticated) that leads to Remote Code Execution (RCE)
• CVE: CVE-2026-6433
• Privilegios requeridos: Ninguno (No autenticado)
• Attack surface: Front-facing plugin endpoints that accept user-supplied input without proper sanitization or parameterization

Typical chain (no exploit details): an attacker finds a plugin endpoint or parameter passed into a SQL query without prepared statements. By injecting payloads that alter stored options or content, they can cause the application to later evaluate attacker-controlled data (for example via eval() or file writes that include attacker data). Once evaluated or included, arbitrary PHP can execute and provide full site compromise. Attackers may combine SQLi with WordPress behaviors (plugin settings storing executable snippets, option fields parsed as code) to create persistent vectors.

Escenarios de impacto en el mundo real

If exploited, consequences include (not exhaustive):

• Full administrative takeover of the WordPress site (creation of admin accounts, credential changes)
• Installation of PHP webshells or backdoors in uploads, theme, or plugin directories
• Data theft — exfiltration of user data, database tables, or secret keys in options
• Malware/SEO spam insertion and redirector pages
• Supply-chain abuse — using the compromised site to target other systems (emails, API integrations)
• Hosting compromise — lateral movement to the underlying hosting environment using stolen credentials or privilege escalation

Because the vulnerability is unauthenticated and leads to RCE, mass automated scanning and exploitation campaigns will likely appear quickly. Treat affected sites as high priority.

Immediate actions — an emergency checklist (what to do in the next 0–6 hours)

1. Identify affected sites immediately
   • Query your inventory and plugin lists for “Custom css-js-php” and confirm plugin version ≤ 2.0.7.
   • If you manage client sites, notify stakeholders and begin triage.
2. Contención
   • If a vendor patch is available: apply it immediately.
   • If no official fix is available for your installed version: deactivate and remove the plugin from every affected site. Removing the file prevents the vulnerable code from being executed.
   • If removal must wait (production constraints): block access to the plugin endpoints via webserver rules or firewall and restrict wp-admin to known IPs temporarily.
3. Virtual patching / rule-based blocking
   • Deploy rules to block requests to plugin endpoints that contain SQL metacharacters, suspicious payloads, or typical SQLi patterns.
   • Block or rate-limit unknown or suspicious POST requests, and treat unauthenticated writes to plugin endpoints as high risk.
4. Verifica signos de compromiso
   • Look for new admin users, modified files, newly created PHP files in uploads, unusual wp_options records, and suspicious scheduled tasks.
5. Rota credenciales y secretos
   • Reset WordPress admin passwords, API keys, application passwords, and hosting control panel credentials if compromise is suspected.
   • Revoke any suspicious OAuth tokens or API keys.
6. Preserve forensics snapshots
   • Preserve logs (webserver, PHP, database), copies of the site filesystem, and a database dump for analysis.
   • Work from read-only copies when investigating to avoid destroying artifacts.
7. Restaurar desde una copia de seguridad conocida si se confirma la violación
   • If backdoors or active compromise are present and you cannot fully verify a clean state, restore from a backup made before the compromise.
   • After restoring, ensure the plugin is removed or patched and verify integrity before reconnecting to production.

Indicators of Compromise (IoCs) and what to check

Look for the following signs that an attacker exploited the site:

• Archivos PHP nuevos o modificados en:
  • /wp-content/uploads/
  • /wp-content/plugins/
  • /wp-content/themes/
  • Unexpected .php files in otherwise static directories
• File modifications to core, theme, or plugin files where timestamps don’t match release times.
• Webshell patterns (strings often seen in webshells):
  • base64_decode( …
  • eval( gzinflate( …
  • assert( …
  • preg_replace( … /e ) patterns
  • system(, exec(, shell_exec( calls in files that shouldn’t have them
• New admin users or changes to existing admin accounts — cross-check user creation events in logs and review role/capability changes.
• Unusual scheduled tasks (wp_cron jobs) added for persistence.
• Suspicious database entries:
  • Unexpected options in wp_options that contain PHP code or large blobs.
  • New tables that store malicious payloads or links.
• Outbound connections to unfamiliar domains or IPs originating from the web server (check logs or host-level firewall/netstat).
• Large numbers of 4xx/5xx requests in a short timeframe, especially to plugin endpoints.
• Reputation and search-engine blacklisting: sudden drop in traffic, malware warnings in Google Search Console.

If you find evidence of compromise, follow a full incident response process: contain, eradicate, recover.

Detection strategies and useful quick checks (non-destructive)

Run these inspections immediately. They do not modify the site.

• List installed plugins and their versions:

  wp plugin list --format=table

• Search for recently modified PHP files (last 7 days):

  find /path/to/site -type f -name '*.php' -mtime -7 -ls

• Buscar archivos PHP en uploads:

  find /path/to/site/wp-content/uploads -type f -name '*.php' -ls

• Check for suspicious strings in the database (read-only):

  SELECT option_name, LENGTH(option_value) AS len FROM wp_options ORDER BY len DESC LIMIT 50;

  Export wp_options and review for serialized objects containing ‘eval’ or ‘base64’.

• Check user list for new admins:

  wp user list --role=administrador --format=tabla

• Search webserver access logs for requests to plugin URIs or unusual POSTs:

  grep -i 'custom-css-js-php' /var/log/apache2/access.log

• Check outbound network connections (if you have host access):

  netstat -plant

If anything suspicious is found, preserve evidence (copy files, logs, DB dump) and proceed to containment.

Virtual patching and rule recommendations

If you cannot remove or patch the plugin immediately, virtual patching via firewall/webserver rules is the fastest mitigation. Below are engineering-level recommendations for signatures, rate-limiting, and hardening. Test in staging before applying to production to avoid false positives.

1. Block or strictly filter requests to plugin endpoints
   • Deny unauthenticated requests to known plugin admin endpoints (AJAX endpoints or plugin-specific actions) from the public internet.
   • Example logic: If URI matches /wp-content/plugins/custom-css-js-php/* OR query parameter action equals the plugin action name AND request has no valid authenticated cookie/session, then block or return 403.
2. Patrones de inyección SQL
   • Block requests containing SQL metacharacters and patterns in parameters that are not expected to include such content:
   • Single quotes (‘), SQL comment sequences (–, /*, #), UNION SELECT, OR 1=1
   • Implement heuristic signatures (regex) that flag parameters containing SQL keywords and disruptive symbols.
3. Block suspicious payload sizes and encodings
   • Limit parameter lengths for fields that should be short.
   • Block base64 or long gibberish strings in parameters where not expected.
4. Prevent remote code patterns
   • Flag and block requests containing PHP evaluation patterns (base64_decode, gzinflate, eval) submitted through forms or endpoints.
5. Rate limiting and request reputation
   • Apply per-IP rate limits to POST requests and attempts to access plugin endpoints.
   • Use reputation lists or country-based blocking where appropriate.
6. Block known automated scanning and exploit traffic
   • Challenge high-probability automated traffic with CAPTCHA or JS challenges.
7. Whitelist admin access
   • If feasible, restrict wp-admin and plugin admin endpoints to management IPs via firewall or server config.
8. Virtual patch snippet (concept)

   IF URI CONTAINS /wp-content/plugins/custom-css-js-php/ 
   AND METHOD == POST 
   AND (PARAMETER CONTAINS SQL_KEYWORD_PATTERN OR PARAMETER CONTAINS base64_decode OR PARAMETER LENGTH > acceptable) 
   THEN BLOCK and LOG

Important: do not rely on a single signature. Attackers obfuscate payloads; combine heuristics, rate-limiting, and anomaly detection.

Incident response: containment → eradication → recovery (detailed playbook)

When you detect that a site was exploited (or likely exploited), follow a structured approach:

1. Contención

• Immediately block the vulnerable plugin from running (deactivate/remove).
• Isolate the site from the public internet if possible (maintenance mode + IP whitelist).
• Block malicious IPs and endpoints at firewall level.
• Preserve evidence (files, DB dump, logs). Snapshot storage volumes if available.

2. Eradication

• Identifique y elimine puertas traseras:
  • Search for PHP files in uploads or unexpected directories; remove any not part of known plugins/themes.
• Clean or replace modified core, plugin and theme files from trusted sources.
• Remove newly created admin users or suspicious accounts.
• Replace credentials and keys (DB, hosting, API, OAuth).
• Run reputable malware scanners and manual code reviews to find residual payloads.

3. Recovery

• Restore from a known-good backup if cleanup cannot provide full confidence.
• Harden configuration before returning to production:
  • Ensure the vulnerable plugin is removed or patched.
  • Deshabilitar la edición de archivos en wp-config.php:

    define('DISALLOW_FILE_EDIT', true);

  • Confirm WordPress core and all remaining plugins/themes are up to date.
• Recheck files, database, and logs to ensure no persistence remains.

4. Post-incident

• Rotate all credentials again after recovery.
• Conduct a root-cause analysis and document the timeline.
• Notify affected users if personal data was exfiltrated and follow local breach notification laws.
• Implement continuous monitoring and periodic integrity checks.

Hardening checklist — reduce the blast radius for future vulnerabilities

• Maintain an accurate inventory of plugins and versions across sites.
• Remove unused plugins and themes immediately.
• Enforce least privilege for admin accounts and use strong, unique credentials or SSO.
• Apply defense-in-depth: WAF + secure server configs + application hardening.
• Restringir el acceso de administrador por IP donde sea práctico.
• Disable PHP execution in /wp-content/uploads via .htaccess or server rules:

  
    Deny from all
  

• Keep a robust backup and recovery plan with offsite backups and periodic restore drills.
• Monitor logs and set up alerting on suspicious changes (new admin user, file changes).
• Use security headers (CSP, X-Frame-Options, HSTS) to harden the application.
• Regularly scan sites with automated tools and perform periodic manual security audits.

Example detection and response scenarios (walkthroughs)

Scenario A — Suspicious PHP in uploads

1. Take a snapshot of the server and preserve logs.
2. Move malicious files offline for analysis (do not execute).
3. Search for webshell indicators (strings like base64_decode, eval).
4. Use multiple malware scanners and manual inspection to identify malicious files.
5. Remove malicious files and replace any modified site files from verified clean sources (WordPress core, theme/plugin packages).
6. Rotate credentials and check for associated persistence in the database.

Scenario B — Unusual POST requests to a plugin endpoint

1. Block originating IPs and deploy a rule to challenge similar requests with CAPTCHA or JS validation.
2. Review request logs to identify payloads and time windows.
3. If payloads indicate SQLi, search the database for unexpected writes, new tables, or altered options.
4. Deactivate and remove the vulnerable plugin immediately.
5. If signs of exploitation exist, perform a deeper audit and follow eradication steps.

Consideraciones de comunicación y legales

• Notify clients and stakeholders: inform affected parties of the vulnerability, containment actions, and timelines.
• If sensitive user data was exposed, follow local notification laws and breach reporting requirements.
• Keep a clear incident log for compliance and auditing.

Preguntas frecuentes

Q: Can I leave the plugin installed but disable public access to it?

A: As an emergency measure you can block public access to the plugin’s endpoints via server rules or firewall and restrict admin to trusted IPs. However, the safest immediate action is to remove or update the plugin once a verified patch is available.

Q: Why not just rely on automatic updates?

A: Automatic updates are useful but many environments disable them for compatibility or testing reasons. Maintain an inventory, monitoring, and layered defenses in addition to update processes.

Q: Are there indicators specific to this plugin vulnerability?

A: Look for HTTP requests to plugin-specific endpoints, unusual POST payloads, and newly created or modified database rows associated with plugin options. Because exploits can be obfuscated, also search for generic indicators like new admin accounts and webshell-like file contents.

Lista de verificación final priorizada

1. Identify all sites running the affected plugin (≤ 2.0.7) immediately.
2. Deactivate and remove the plugin if you cannot confirm a vendor patch that fixes the issue.
3. Deploy rule-based blocking (virtual patch) to block plugin endpoints and SQLi-like patterns.
4. Scan for compromise: files, database anomalies, admin users, scheduled tasks.
5. Rotate credentials if compromise is suspected or confirmed.
6. Restore from a clean backup if you cannot reliably remove persistence.
7. Harden sites: disable file editing, restrict admin access, use security headers, maintain inventory, and keep plugins updated.
8. Implement continuous monitoring and periodic integrity checks to detect future incidents quickly.

If you require assistance triaging an incident or deploying virtual patching rapidly, engage an experienced incident response provider or an in-house security team. Prioritise containment and forensics preservation before any destructive remediation steps.

Stay safe, stay vigilant — treat unauthenticated RCE chains with the highest priority and move fast to contain and remediate.