WordPress RCE CVE-2026-119977 Added to CISA KEV — 13,095 Attacks in 24 Hours

What to do in the next 24 hours

1. Patch WordPress core to the fixed version from wordpress.org/news/category/security. Auto-updates handle most hosted sites; confirm the core version on every site you own with wp core version.
2. Patch bundled plugins. Many successful exploitations against WordPress CVEs go through a plugin that re-exposes a core primitive. Run wp plugin update --all on each site; disable plugins you cannot immediately update.
3. Rotate anything stored in wp-config.php or the admin console: DB credentials, authentication keys / salts, API keys that WordPress holds for third-party integrations, OAuth client secrets, SMTP passwords.
4. Force password reset for all admin / editor users. Invalidate existing sessions (wp user session destroy --all).
5. Hunt for webshells in wp-content/uploads/, wp-content/plugins/, and theme directories. File-integrity scans like WPScan, Wordfence, or the TigerGate container-image scanner catch most. Oversized .php files with high-entropy contents are the usual tell.
6. Audit scheduled jobs. Check wp cron event list for events you did not create, especially ones that execute shell commands or hit unfamiliar URLs.
7. Check admin user list. Attackers commonly create a second administrator with an innocuous name.

If you operate many WordPress sites

Agencies and managed-hosting providers typically run dozens to thousands of WordPress sites. The exploit is being sprayed at scale, so the right posture is fleet-wide:

• Push the core update via your fleet management (WP-CLI over SSH, ManageWP, MainWP, Kinsta/WP Engine bulk-update API).
• Add a WAF virtual-patch rule for the known exploit shapes (your WAF vendor likely has signatures live already).
• Sweep file systems for recent writes to .php files in upload or plugin directories across the whole fleet; prioritize sites with hits.
• Snapshot and preserve logs. Breach-notification clocks may apply if customer data flows through affected sites.

The broader WordPress attack-surface problem

WordPress is still the single most common CMS on the public internet, which makes any core RCE a volume event the moment a public exploit lands. The CISA listing plus the Wordfence volume tells you this one is already there. The broader lesson stays the same: WordPress estates benefit from a continuous testing posture rather than a once-a-year audit — see our longer guide on continuous VAPT vs annual pentest, and the WordPress pentest checklist for the specific coverage TigerStrike tests.

How TigerGate helps

• Attack Surface Management enumerates every WordPress site your organisation operates, including the long tail of marketing microsites, campaign landing pages, and acquired-company estates that never make the core inventory.
• VAPT AI Engine checks each discovered WordPress site for CVE-2026-119977 and the usual plugin-side exposure, with reproducible payloads for fix verification.
• Container Security flags WordPress-based container images with the vulnerable core or plugin versions before they reach your registry.
• eBPF runtime detection watches for the exploitation side-effects: anomalous child processes spawned by php-fpm or apache, new writes to wp-content/uploads/, outbound connections from webserver processes to unfamiliar IPs.
• Compliance evidence maps the patch action to SOC 2 CC7.1, PCI DSS 6.3.3 (critical patch within 30 days) and BOD 22-01 timing — the audit trail your next auditor will ask for.

Sources

• BleepingComputer: CISA flags WordPress RCE flaw as actively exploited in attacks
• CISA Known Exploited Vulnerabilities Catalog — CVE-2026-119977 entry, 3 November 2026
• Wordfence blog — 24-hour attack telemetry, 3–4 November 2026