# AI Is Finding Bugs Faster Than You're Patching Them — What Website Owners Should Do Differently > Source: > Published: 2026-07-28 14:21:00+00:00 "As AI helps defenders discover more issues, customers will see a higher volume of security updates included in each security release." — Pavan Davuluri, Microsoft EVP, Windows + Devices, July 9, 2026 Five days later, Microsoft shipped patches for **570 security vulnerabilities** in a single Patch Tuesday — its largest release ever, and more than double the previous month's already-record count. That is not a sign that Windows got less secure. It is a sign that the way vulnerabilities are discovered has changed. AI tools are now scanning code at a scale and speed that human teams alone cannot match. More bugs found, more patches shipped, and a widening gap between when a vulnerability appears and when you actually fix it. If you maintain websites, web apps, or WordPress installations — and you think this is an enterprise-only concern — the data will change your mind. The July 2026 Patch Tuesday was the sharpest point of a trend that has been building all year: | Period | CVEs patched | Change | |---|---|---| | July 2025 | 137 | baseline | | June 2026 | ~200–206 | previous record | July 2026 | 570 | largest Patch Tuesday ever | | First 7 months of 2026 | 1,308 | nearly double the same period last year | Microsoft attributes the surge to AI-assisted vulnerability discovery through its internal **MDASH** (Multi-Model Agentic Scanning Harness) system. But the pattern extends well beyond Microsoft: **Mozilla + Anthropic:** Claude Mythos Preview, an unreleased frontier model restricted to a small group of organizations under Anthropic's Project Glasswing, identified **271 vulnerabilities** in Firefox in a single evaluation pass — all patched in Firefox 150. That's roughly 12× the number found by the previous model used in the same collaboration (Opus 4.6, which found 22 security-sensitive bugs in a two-week engagement, shipped in Firefox 148). Worth noting: Mozilla and outside commentators have pushed back on calling all 271 "zero-days" — most were bugs an elite human researcher could plausibly have found too; the real story is the speed, not exotic new bug classes. **Cisco:** Shifting to a **twice-monthly security disclosure schedule** (1st and 3rd Wednesdays) with seven days' advance notice of which product families are affected, explicitly citing AI-accelerated vulnerability discovery as the reason. **Oracle:** Its most recent quarterly update included **1,449 security patches**, which it also links to AI-assisted internal scanning. U.S. Executive Order 14409, "Promoting Advanced Artificial Intelligence Innovation and Security" (signed June 2, 2026), directs the Treasury Department, in consultation with the National Cyber Director, NSA, and CISA, to stand up an AI cybersecurity clearinghouse that coordinates vulnerability scanning, validation, and patch distribution across government and industry. The message from every major vendor is similar: AI finds bugs faster than before. That pace does not look like it's slowing down. One week before the July Patch Tuesday, the WordPress Security Team released an emergency patch for a vulnerability chain dubbed **wp2shell**. Two bugs in WordPress core — CVE-2026-63030 (a REST API batch-route confusion flaw) and CVE-2026-60137 (SQL injection in `WP_Query` ) — could be chained to let an unauthenticated attacker take complete control of a stock WordPress install. No plugins required. No login required. Just a crafted HTTP request. The chain was found by Adam Kues at Searchlight Cyber, who pointed **OpenAI's GPT-5.6 Sol Ultra** at a stripped-down copy of the WordPress source (with git history removed, so the model couldn't just trace old bug fixes) and let it search for a pre-auth-to-RCE path. The AI-assisted portion of the work took roughly **10 hours** and about $25 in API usage. It's worth being precise about what that means, though: Kues still defined the target, wrote the prompt, verified the SQL injection by hand against a live install, and then spent additional time afterward untangling the escalation chain the model produced. As Kues himself put it, the shift isn't that AI replaced the researcher — it's that the researcher's role moved up a level, from writing exploit code to steering and verifying it. Even accounting for that, a chain this complex against a target this hardened would very likely have taken a human team weeks, not a single working session. Then the timeline compressed: | Event | Time elapsed | |---|---| | Patch ships (7.0.2 / 6.9.5 / 6.8.6) | T+0 (Friday) | | First mitigation rules seeing exploit attempts | T+~90 minutes | | Public PoC exploit code | T+overnight | | Mass scanning + confirmed in-the-wild exploitation | T+1–2 days | At the time of disclosure, WordPress's own statistics showed **400+ million sites** running an affected version. That number doesn't reflect sites patched since — and here the actual news is more encouraging than it might sound: security consultant Daniel Card sampled roughly 3,500–4,200 WordPress sites and estimated that **fewer than 15% remained unpatched/vulnerable** days after disclosure, thanks largely to WordPress's forced auto-update mechanism and Cloudflare's WAF rules. That's the good news. The bad news is that even a small vulnerable percentage of a 400-million-site ecosystem is still on the order of **90 million exposed sites** — and that's the segment this article is really about: the sites where auto-update was disabled, delayed, or silently failed. The implication for developers and DevOps: the window between "patch available" and "attackers exploiting at scale" is now measured in hours, and being in the "small percentage that didn't auto-update" is no longer a safe place to be. For teams managing multiple sites or deployments, the gap between "patch ships" and "site is protected" is not just an awareness problem. It is a configuration problem: **Auto-update disabled** — many managed WordPress deployments disable core auto-updates for stability. The tradeoff: every emergency patch requires manual intervention. **No verification** — auto-update runs but no one confirms the version number post-update. wp2shell triggered forced auto-updates, but only for installations that hadn't opted out. **Plugin compatibility stalls** — "we'll update after we test plugin X" is a rational response that becomes a week-long exposure window. **No centralized version inventory** — teams running 10, 20, or 50 WordPress sites often have no dashboard showing which versions are live. **Hosting provider patching lag** — your site may be patched, but the server OS, PHP version, or database underneath may not be. ``` # Check WordPress auto-update settings wp option get auto_update_core wp option get auto_update_plugins wp option get auto_update_themes # Check current version across all sites wp core version ``` If auto-update is disabled, enable it for minor and security releases at minimum. Major-version auto-update is a separate risk decision, but security releases should never be deferred. After any WordPress update, automatically run something like: ``` wp core version | grep -q "7.0.2" && echo "PATCHED" || echo "VULNERABLE" ``` Fail the deploy if the version doesn't match the expected security release. For teams managing multiple WordPress instances, maintain a simple manifest: ``` [ { "site": "example.com", "wp_version": "7.0.2", "last_checked": "2026-07-25" }, { "site": "shop.example.com", "wp_version": "7.0.2", "last_checked": "2026-07-25" } ] ``` Automate it with a daily cron job that checks `wp core version` or queries the REST API: ``` curl -s https://example.com/wp-json/wp/v2/ | jq '.namespaces' # Or check the generator meta tag: curl -s https://example.com/ | grep -o 'content="[0-9.]*"' ``` External scans check SSL configuration, security headers, DNS records, email authentication, CMS version fingerprinting, and known technology exposures — 40+ categories. This is not a penetration test; it's a hygiene check that tells you your public exposure profile before an attacker does. Not a 30-page incident response plan. A literal checklist for the next critical disclosure: Repeat this sequence for every critical security release. It's worth more than any security product purchased after the fact. | Metric | Value | Source | |---|---|---| | Microsoft July 2026 CVEs | 570 (record) | Krebs on Security, BleepingComputer | | First 7 months of 2026 CVEs | 1,308 (~2× prior year) | Windows Latest | | Firefox vulnerabilities found by Mythos | 271 in one evaluation pass | Mozilla Blog | | WordPress sites on a vulnerable version | 400M+ (at disclosure) | WordPress.org, via TechCrunch | | Estimated share still vulnerable days later | <15% (≈90M sites) | Daniel Card, via TechCrunch | | wp2shell AI-assisted discovery time | ~10 hours (human-steered) | Searchlight Cyber / Dark Reading | | First exploit attempts after patch | ~90 minutes | Patchstack, via The Repository | AI-accelerated vulnerability discovery is not a future problem. It's the current operating environment. The bottleneck has shifted from finding bugs to patching and verifying them fast enough — and the wp2shell numbers actually cut both ways: most of the WordPress ecosystem patched quickly thanks to forced auto-updates, but the exposed minority is still tens of millions of sites, and the attackers only need one of them. For developers and DevOps teams: your patching pipeline, version verification, and configuration management are now first-class security controls, not just operational hygiene. The teams that handle the next wp2shell-level event best will be the ones that have already automated the verification step — not the ones relying on "we'll get to it this week." *Originally published on WardenBit — helping small businesses understand their security exposure before attackers do.*