AI Is Finding Bugs Faster Than You're Patching Them — What Website Owners Should Do Differently

"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, July 9, 2026

Five days later, Microsoft released patches for 570 security vulnerabilities in a single Patch Tuesday — a record that nearly tripled the previous month's already-record-breaking count.

That is not a typo. And it is not a sign that Windows suddenly became less secure. It is a sign that the way vulnerabilities are found has fundamentally changed. AI tools are now scanning code at a scale and speed that human researchers alone never could. The result: more bugs found, more patches shipped, and a growing gap between when a vulnerability appears and when you actually fix it.

If you run a website, an online shop, or a WordPress installation — and you think this is an enterprise problem that doesn't affect you — the next section will change your mind.

The numbers behind the acceleration

The July 2026 Patch Tuesday was not an isolated event. It was the sharpest point of a trend that has been building for months:

Microsoft's own EVP publicly attributed the surge to AI-assisted vulnerability discovery. The company now uses an internal system called MDASH (multi-model agentic scanning harness) to scan critical binaries and validate candidates across the Windows codebase at a rate human teams could not match — a scanner pipeline flags issues, and a separate "prove" pipeline filters out false positives before anything reaches an engineer.

But Microsoft is not alone. The same pattern is playing out across the software industry:

• Mozilla + Anthropic: An early version of Claude Mythos Preview found 271 zero-day vulnerabilities in Firefox in a single evaluation pass. For context, the previous phase of the collaboration, using Opus 4.6, found 22 confirmed security-sensitive bugs over two weeks — fixes for both rounds shipped in Firefox 150 (and Firefox 148 for the earlier batch). Mozilla noted it hadn't seen any bug that an elite human researcher couldn't eventually have found — the difference is that no human team could have found this many, this fast.
• Cisco: Announced a shift to a scheduled, twice-monthly security disclosure model (the first and third Wednesday of each month) with seven days' advance notice of which technologies each release will cover, explicitly citing AI-accelerated vulnerability discovery as the reason the old ad-hoc model no longer scales.
• The White House / CISA: A June 2, 2026 executive order on AI security directed CISA, the NSA, and the Treasury Department to stand up a national clearinghouse for AI-assisted vulnerability scanning, validation, and patch distribution — and CISA followed on June 10 with Binding Operational Directive 26-04, which replaces older CVSS-based patch deadlines with a risk-based model and requires the most critical federal vulnerabilities to be fixed within three days.

The message from every major vendor is the same: AI finds bugs faster, and that pace is not slowing down.

Why this is your problem, not just Microsoft's

When people hear "570 vulnerabilities," they picture server rooms and enterprise IT teams. But the vulnerabilities AI discovers do not stay inside Microsoft's ecosystem. They ripple outward into every product, plugin, and platform that sits on top of the same technology stack.

Consider what happened just one week before the Patch Tuesday:

On July 17, 2026, the WordPress Security Team released an emergency patch for a vulnerability chain dubbed wp2shell. The chain — two bugs in WordPress core itself, CVE-2026-63030 and CVE-2026-60137 — allowed unauthenticated attackers to take complete control of any affected WordPress site. No plugins required. No login required. Just an HTTP request.

Here is the part that makes this an AI story:

The wp2shell chain was discovered by Adam Kues, a researcher on the Assetnote team at Searchlight Cyber, using OpenAI's GPT-5.6 Sol Ultra — in just over 10 hours of largely autonomous analysis (with a human designing the test, verifying results, and handling responsible disclosure). A task that would traditionally have taken a human research team weeks — WordPress core hasn't had a meaningful pre-auth vulnerability in a decade — was completed in a single working session, for roughly $25 in API costs.

And then the timeline compressed further:

Tens to hundreds of millions of WordPress sites were running a vulnerable version when the patch dropped. Security researcher Daniel Card estimated that less than 15% of a sample of 3,500 sites had been patched days after the fix was available — meaning the vast majority were still exposed.

That is the new reality: AI finds the bug, the patch ships, and attackers weaponise the PoC before most site owners even know the vulnerability exists.

The patch gap is where the real risk lives

The traditional security model assumed a comfortable window: a vendor finds a bug, writes a patch, publishes it, and you have days or weeks to apply it. That window is now measured in hours.

This creates what security researchers call the exploitation gap — the time between a patch becoming available and a site actually applying it. In the WordPress case, that gap was wide enough for attackers to scan the internet, identify unpatched sites, and begin compromising them within a day of disclosure.

For small businesses, this gap is often much wider than for enterprises:

• No dedicated security team monitoring vendor disclosures
• No automated patching pipeline to push updates across systems
• No one checking whether auto-update actually ran successfully
• Plugin and theme compatibility fears that delay updates "until the weekend"
• Multiple sites to manage with no centralised view of versions

The wp2shell incident exposed exactly this problem. The patch was available immediately. Forced auto-updates were enabled. Yet most sites remained vulnerable because someone, somewhere, had disabled auto-updates, was running a custom deployment, or simply did not know the update existed.

What "AI finding bugs faster" means for your website

If AI can find 271 zero-days in Firefox in one pass, or discover a WordPress core RCE chain in 10 hours for the cost of a takeout order, the implication is straightforward: the supply of discoverable vulnerabilities is growing faster than most organizations' ability to patch them.

This does not mean your website is doomed. It means the security playbook has to change from periodic checks to continuous practice.

The old model

1. Install security software
2. Run a scan occasionally
3. Fix what the scan finds
4. Assume you are safe until the next scan

What actually works now

1. Enable auto-updates — and verify they run. WordPress, plugins, themes, your server OS, your CMS. Auto-update is no longer optional. After a security release, log in and confirm the version number. The wp2shell forced auto-update saved millions of sites, but only for those that had not disabled it.

2. Know your exposure within hours, not weeks. A free external scan checks your site's SSL, security headers, DNS configuration, email authentication, CMS version, and known technology fingerprints — 40+ categories in under 60 seconds. That is not a full security audit, but it tells you your public exposure profile before an attacker does.

3. Treat every security release as urgent — even for software you don't think about. The 570 July patches covered Windows, Office, Azure, and server products. If your hosting provider, your CDN, or your managed service provider runs any of those, their patching timeline is now your risk timeline. Ask your hosts: do you patch within 24 hours of a critical release?

4. Reduce the number of things that can break. Every plugin, every integration, every third-party script is a potential vulnerability surface. The fewer components your site depends on, the smaller your exposure window when the next emergency patch ships. This is not about removing functionality — it is about knowing what you run and why.

5. Have a response plan for the 24 hours after a critical disclosure. Not a 30-page incident response document. A simple checklist: check your version, apply the patch, verify the update, scan for signs of compromise, review access logs. That sequence — repeated for every critical release — is worth more than any expensive security product purchased after the fact.

The numbers you should remember

These are not abstract enterprise metrics. They describe the environment your website operates in right now.

What to do this week

If you run a WordPress site, an ecommerce store, or any web application that matters to your business, here is a practical starting point:

1. Check your WordPress version right now. If you are not on 7.0.2, 6.9.5, or later, you are exposed to a chain that attackers are actively exploiting. Update today.

2. Enable auto-updates for WordPress core, themes, and plugins. Then check once a week that updates actually ran. Auto-update is your first line of defence — but only if it is turned on.

3. Run a free security scan to see your public exposure profile — SSL, headers, DNS, email authentication, CMS detection, and more. It takes under a minute and gives you a baseline.

4. Ask your hosting provider about their patching timeline. If they do not patch critical vulnerabilities within 24–48 hours, you are inheriting their risk.

5. Write down your 5-step response checklist for the next critical disclosure. When the next wp2shell-level event lands — and it will — you will know exactly what to do instead of scrambling.

AI is changing the speed of vulnerability discovery. The question is not whether the next critical patch will arrive faster than you expect — it is whether you will be ready when it does. WardenBit helps small businesses understand their security exposure before attackers do. Run a free scan →

Is your site ready for the next emergency patch? Run a free security scan — 40+ automated checks, instant results, no commitment. It takes under a minute and tells you what an attacker can see from the outside.