On July 23, a researcher pointed Moonshot AI’s Kimi K3 at Redis as an autonomous bug-hunting agent and walked away. Ninety minutes later it had surfaced roughly 19 distinct memory-corruption bugs across the 6.2 through 8.8 branches. A separate run turned one of them — a RedisBloom TDigest heap overflow — into a working remote-code-execution exploit in 27 minutes. Redis shipped seven patches on July 23. Three days earlier, F5 had disclosed the third unauthenticated NGINX heap overflow in two months. Two days before that, 7-Zip patched a heap overflow in its XZ decoder that sits in build agents and CI unpacking steps everywhere. None of these were discovered by the same team, the same tool, or the same method — and that’s the point. Memory-corruption bugs in load-bearing C infrastructure are not getting harder to find. They’re getting easier, from multiple directions at once, and the industry’s entire patch-management model was built on the opposite assumption.

This piece isn’t about any one of those CVEs. It’s about what happens to your vulnerability program when the cost of finding a zero-day collapses toward zero while the cost of shipping a fix stays exactly where it’s been for a decade.

The discovery cost curve just collapsed

Treat 2026 as the year autonomous bug-hunting stopped being a research demo and started producing a measurable share of the CVEs you triage.

XBOW — built by the team behind GitHub Copilot and CodeQL — spent 2025 running fully automated web-app penetration tests and submitting the results to HackerOne. By mid-2026 it had over 1,060 vulnerabilities submitted, the #1 ranking on HackerOne’s global leaderboard ahead of thousands of human researchers, and leaderboard recognition from Microsoft’s own MSRC bounty program. A principal pentester’s 40-hour manual engagement, matched by the agent in 28 minutes.

Google’s Big Sleep found a real SQLite zero-day in late 2024 and by August 2025 had racked up 20 more, mostly in FFmpeg and ImageMagick — the kind of ubiquitous, thanklessly-maintained C libraries that sit three dependencies deep in everything.

Anthropic’s Claude Mythos Preview, unveiled in April 2026, is the current high-water mark: an internal red-team assessment autonomously discovered and exploit-chained thousands of high- and critical-severity zero-days across every major operating system and browser, with Anthropic reporting that over 99% were still unpatched at disclosure time. One documented chain strung four separate bugs into a JIT heap spray that walked out of both the browser renderer sandbox and the OS sandbox. Anthropic didn’t just publish a blog post about it — it stood up Project Glasswing, a defensive coalition with AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks, explicitly to get ahead of the moment this capability becomes commodity tooling rather than frontier-lab research.

DARPA’s AI Cyber Challenge gives you the controlled-experiment version of the same story. In the 2025 final, seven Cyber Reasoning Systems processed 54 million lines of real open-source code, identified 86% of injected vulnerabilities (up from 37% at semifinals), patched 68% of what they found, and turned up 18 previously unknown real-world flaws as a side effect. Average cost per task: $152. Average time to remediate: 45 minutes. That’s not a typo against the industry norm of weeks of engineer time per critical fix — it’s a different unit of measurement entirely.

Stack the numbers next to each other and the pattern isn’t “AI found some bugs.” It’s that four independent efforts — a commercial pentesting product, a research lab’s internal tooling, a frontier AI vendor’s safety assessment, and a DARPA-funded government competition — converged on the same result inside about eighteen months: vulnerability discovery in real production software is now bounded by compute and agent-hours, not by the supply of skilled human researchers.

The Redis case is the mundane version, and that’s what makes it important

Mythos Preview and the AIxCC finals are headline-grabbing because of scale. The Redis story is more useful because it’s boring and repeatable — the kind of thing that will happen to a piece of software you run, not just to browsers and kernels.

Both bugs Kimi K3 surfaced were classic, decades-old memory-safety patterns:

  • A stream shared-NACK double-free — Redis consumer groups track pending, not-yet-acknowledged entries with NACK structures that can be shared across consumers in the same group. The agent found a state where the bookkeeping frees the same heap chunk twice, which is a textbook heap-grooming primitive once you can reallocate attacker-controlled data into the gap between the two frees.
  • A RedisBloom TDigest heap overflow — the loader sizes a buffer from one field of a serialized payload, then trusts a different, attacker-controlled “capacity” field when copying data in. Classic CWE-787 out-of-bounds write, and any path that deserializes a TDigest — replication, RESTORE, RDB/AOF load, a module command — is a candidate trigger.

Neither bug is pre-auth. Both need an authenticated session. That used to be a meaningful mitigating factor — most write-ups would tell you “low risk, requires authentication” and move on. It isn’t anymore, for two reasons that have nothing to do with the bug itself: Redis instances are routinely reachable from application tiers with shared or weak credentials, and an agent that can find 19 zero-days in 90 minutes of unsupervised time can just as easily be pointed at your specific fleet’s config, module set, and ACL policy instead of upstream Redis in the abstract. “Requires auth” used to mean “requires a skilled attacker with access.” Increasingly it just means “requires access.”

Patching did not get faster to match

Here’s the number that should worry you more than any individual CVE this quarter: Mandiant’s M-Trends 2026 report puts the mean time-to-exploit at negative seven days. Attackers are weaponizing vulnerabilities before the fix ships and often before the flaw is even public. In 2018, that same metric was +63 days — you had two months of buffer after disclosure. It crossed zero in 2024. It is now solidly negative.

Meanwhile, Veracode’s 2025 State of Software Security report puts the average time to fix a security flaw at 252 days, up 47% since 2020, with 32% of identified vulnerabilities still open past 180 days. Put the two numbers next to each other: attackers routinely have working exploitation before day zero; the median organization needs the better part of a year to close the hole. That gap — not any single CVE — is where every ransomware affiliate crew currently operating has been living for the last three years, and AI-accelerated discovery is about to widen it, not narrow it, because it only compresses one side of the equation.

This is the mechanism worth sitting with: AI bug-hunting is currently helping the supply side of vulnerability disclosure — more bugs found, faster, by vendors and researchers who then responsibly disclose and patch. That’s a genuine defensive win when Google, Anthropic, or a bounty program is running the agent. But the underlying capability doesn’t check who’s holding it. The same class of tool that found the Redis bugs in 90 minutes for a security researcher will, on some timeline shorter than anyone would like, be running inside a ransomware affiliate’s toolkit against your specific edge appliance, backup server, or VPN gateway — the same targets covered again and again on this site because they’re already the softest entry points on the network. Storm-1175 went from zero-day acquisition to domain-wide Medusa deployment in under 24 hours using conventional research. An affiliate crew with agent-assisted discovery doesn’t need to buy a broker’s zero-day anymore; it can grow its own, against your stack specifically, over a weekend.

Why “just patch faster” isn’t the answer

The instinctive response — tighten SLAs, mandate 72-hour patch windows for criticals — doesn’t survive contact with how patching actually works in a real environment:

  • Change control has a floor. Testing a Redis or NGINX upgrade against your actual workload, staging it, and rolling it through prod takes real validation time regardless of how fast the patch was written. AIxCC’s 45-minute remediation was against synthetic vulnerabilities in a competition harness with no downstream integration risk. Your production database cluster is not a competition harness.
  • The dependency tree is deep and asynchronous. NGINX’s July fix doesn’t help you until NGINX Ingress Controller, Gateway Fabric, and App Protect WAF each ship their own downstream release — which is exactly what happened with CVE-2026-42533, where the core fix landed weeks before the embedded products caught up. Every layer of repackaging adds its own lag.
  • Embedded and appliance firmware doesn’t patch on a 45-minute cycle, or sometimes at all. The edge devices and network appliances covered repeatedly in this publication’s incident coverage often run vendor firmware with quarterly-at-best update cadences, and a meaningful fraction are past end-of-support and getting nothing.
  • You can’t test your way to zero regression risk at emergency speed. The faster you’re asked to patch, the more you’re trading validation for velocity — which is its own risk on systems like Redis or your ingress layer where an outage is its own incident.

None of that is an argument for complacency. It’s an argument that “reduce time-to-patch” is fighting the wrong variable. If attackers already have negative time-to-exploit and AI-assisted discovery is pushing that further negative, you cannot win a race measured in days when your own pipeline is structurally measured in weeks. The lever that’s actually available to you is exposure and blast radius, not patch latency.

What actually works when discovery is free

Treat every piece of C/C++ infrastructure you run — Redis, NGINX, your TLS stack, anything parsing untrusted input — as though a zero-day for it exists right now, because the base rate for that being true just went up materially. Concretely:

Shrink the attack surface before the CVE, not after. If you’re not using RedisBloom, disable it — that removes the TDigest path entirely regardless of what the next module vulnerability looks like. Audit for unused modules the same way you’d audit for unused open ports.

1
2
3
4

# redis.conf — only load modules you actually use
# comment out or remove any loadmodule line for
# modules not in active use (RedisBloom, RedisGraph, etc.)
# loadmodule /usr/lib/redis/modules/redisbloom.so

Segment and authenticate as if pre-auth bugs already exist, because the gap between “requires auth” and “trivially reachable” keeps closing. Redis and similar internal services should never be reachable from anything other than the specific application tier that needs them, with unique credentials per consumer — not a shared password copied into six services’ environment variables.

Instrument for the exploitation you can’t out-patch. Since patch latency has a floor, detection has to cover the window between disclosure and your actual deployment. For Redis specifically, watch for anomalous consumer-group claim/reclaim patterns and unexpected child processes spawned from the redis-server process tree — a double-free-to-RCE chain that succeeds will, at some point, need to execute something outside the Redis process itself:

1
2
3
4
5
6
7
8

# example Falco-style rule sketch: unexpected child process from redis-server
- rule: Unexpected Child Process from Redis
  desc: redis-server spawning a shell or unexpected binary is a strong post-exploitation signal
  condition: >
    spawned_process and proc.pname="redis-server" and
    not proc.name in (redis-server, redis-cli)
  output: "Unexpected child process from redis-server (user=%user.name command=%proc.cmdline parent=%proc.pname)"
  priority: CRITICAL

Run the same class of tool against yourself. XBOW-style autonomous pentesting and Big Sleep-style source auditing are commercially available now, not just frontier-lab research projects. If a ransomware affiliate is going to eventually run an agent against your public-facing NGINX config and internal Redis fleet, the ROI math on running one against yourself first — on your schedule, with a rollback plan — is not close.

Prioritize memory-safe rewrites for the components actually getting hit. Double-frees, use-after-frees, and heap overflows are precisely the bug classes that AI-assisted fuzzing and source review are best at finding in C/C++ codebases, and precisely the bug classes that don’t exist in a Rust-rewritten parser or decoder. This isn’t a five-year moonshot for every service — it’s a prioritization call for the specific untrusted-input-parsing hot paths (decoders, deserializers, request-line parsers) where three separate memory-corruption CVEs landing in a single publication in one week is not a coincidence, it’s a target-rich environment that agent-assisted research is going to keep finding faster than manual audits ever did.

Run a patch-readiness drill, not just a patch-SLA policy. Pick your highest-exposure service — Redis, NGINX, your VPN gateway — and time how long it actually takes, right now, to go from “patch released” to “deployed and verified in production,” including the change-control and testing steps you can’t skip. If that number is measured in weeks, that’s your actual current time-to-exploit exposure window, and it’s the number to fix before the next AI-discovered CVE lands in that same service.

Takeaways

  • Vulnerability discovery in production C/C++ infrastructure is now bounded by compute, not by researcher headcount — four independent efforts (XBOW, Big Sleep, Anthropic’s Mythos Preview, DARPA’s AIxCC) converged on that result within about 18 months.
  • Mean time-to-exploit is negative (Mandiant: -7 days) while mean time-to-remediate is still roughly 252 days (Veracode). AI-accelerated discovery widens that gap; it doesn’t close it, because it only accelerates the offense side of your own pipeline unless you’re the one running the agent.
  • “Requires authentication” is a weaker mitigating factor than it used to be — weak/shared credentials and agent-assisted, target-specific research both erode it.
  • You cannot out-patch machine-speed discovery through SLA pressure alone; change control, dependency chains, and firmware cadence have real floors. Spend the effort on exposure reduction and detection instead of chasing patch latency you structurally can’t hit.
  • Disable unused modules/features now, segment and uniquely-credential internal services like Redis, instrument for post-exploitation behavior specifically, and put memory-safe rewrites at the top of the backlog for whatever untrusted-input parser in your stack keeps showing up in CVE feeds.
  • Consider running commercial autonomous pentesting/audit tooling against your own stack before someone else points it there first — the same technology is available to both sides now, and only one of you gets to choose the schedule.