I was drinking my coffee this morning, scrolling through X, when I realized we are completely ignoring a massive shift in cybersecurity.

Sundar Pichai has been warning us about something recently.

He talked about how AI is moving beyond just finding bugs in software. He warned that it is moving into the territory of actually proving that software is exploitable.

There is a massive difference between those two things.

If you run a static analysis tool on a codebase today, it will hand you a list of potential vulnerabilities. Most of them are false positives. It's just a machine guessing that a piece of code looks a little suspicious.

But an exploit? An exploit is proof. It is a working, weaponized script that actually breaks the system.

And a few days ago, a team at Alibaba published a paper that asks a question with very hard consequences.

Can large language models confirm software vulnerabilities by actually building working exploits for them?

The researchers' answer is yes.

But it only works when the AI stops acting like a single genius and starts acting like a team.

That sounds like a minor detail. But when you look at how they actually pulled this off.. it changes how we have to think about the entire software supply chain.

Automated exploit generation is not a new concept. The cybersecurity industry has been trying to automate this for years.

But historically, it usually fails for very familiar reasons.

The first traditional method is fuzzing. Think of fuzzing like throwing millions of random, mutated inputs at a wall to see what sticks. It works for simple crashes. But fuzzers miss deep, complex execution paths because they are basically guessing.

The second method is symbolic execution. This is where you use heavy math to try and solve the code like a complex algebra equation.

But symbolic execution chokes on complex, real-world code. Because in modern programming, the right input isn't just a simple value. It is often a carefully assembled object. It is a class instance. Or it's a string that has to follow a very specific structure to pass the security checks.

Math solvers cannot easily process that. The paper is blunt about why, no existing SMT solver can handle constraints of the form "give me a function or class that satisfies these properties." That kind of reasoning needs higher-order logic, and the solvers we have just can't do it.

So when LLMs got good at coding, people thought they were the magic bullet. Just paste the vulnerable code into a prompt and ask the AI to write an exploit.

But a plain LLM is not enough either.

An LLM can imitate code. It can look at a vulnerability and guess what an exploit should look like. But when you give it a massive repository, it loses the thread. It hallucinates details that don't exist.

And the worst is, when it generates a script and the execution fails, it struggles to repair its own mistakes. If it gets a NullPointerException, it just stops.

Humans don't hack like that.

When a human security researcher is trying to break into a system, they don't write the perfect exploit on the first try. They read the code. They write a draft. They run it. They watch it crash. They read the error log. They realize they passed the wrong object type. They tweak the code. And they try again.

That loop.. read, act, fail, learn.. is the entire job. And until now, no AI was doing that loop properly.

The researchers behind this paper understood this. They built a system called VulnSage.

And VulnSage's real move is that it turns exploit generation into a workflow. It doesn't use one massive prompt. It uses a multi-agent framework to simulate a human researcher's process.

First, there is a Code Analyzer agent. It runs static analysis on the library and extracts the exact vulnerable dataflow.

Then, it hands that information to a Code Generation agent. But this agent doesn't write the exploit yet. It rewrites the vulnerable path into natural language constraints first.

Then it generates a candidate exploit.

Finally, a Validation agent takes that code and actually runs it in a secure sandbox. It compiles it. It tracks the memory. It watches it execute.

If it fails, it hands the crash logs and execution traces to a set of Reflection agents. These agents look at the errors, figure out what went wrong, and tell the Generation agent how to fix it. Or, they conclude that the original alert was just a false positive and explain exactly why.

That second part is quietly massive. We will come back to it.

They repeat this loop. Acting, failing, and learning. The paper says exploits that fail on the first try usually take around 8 rounds of back-and-forth to correct.

But here is the part that most people are completely missing.

The interesting part about this paper isn't just the multi-agent loop. It is how the AI translates the problem.

The hard part of software exploitation is rarely "solve these math equations." The hard part is "figure out how this code expects to be used."

In the paper, the researchers show how VulnSage handles complex constraints. Instead of trying to use math to solve the path, the agents write the problem in ordinary language.

They write things like, "the first argument must be a class type, and the class should be a Job class or its subclass."

They write the constraints in plain English.

Why is that a breakthrough? Because LLMs are fundamentally built to understand language, not formal logic. When you write the constraints in ordinary language, the model can actually reason about the code structure. It can figure out exactly which object to build, and which method path will keep the malicious input alive all the way to the target.

This makes exploit generation work on complex software. The exact type of software where older, traditional methods completely fail.

In other words, the claim this paper is making is not just "we solved constraints differently."

The claim is "we can now turn code understanding itself into a path to real exploits."

And the data backs it up.

On a JavaScript benchmark called SecBench.js, VulnSage generated 34.64% more successful exploits than EXPLOADE.js, the previous state-of-the-art tool. That is a clean win on a controlled benchmark.

But the researchers didn't stop there. They unleashed the framework on a different dataset, every package on npm and Maven that they could get their hands on. Roughly 60,000 JavaScript packages and 80,000 Java packages. The exact libraries that almost every modern app, website, and enterprise system depends on.

And on that real-world dataset, VulnSage discovered and verified 146 zero-day vulnerabilities.

146 brand new, completely unknown ways to break into the open source software your favorite apps are built on. And the AI didn't just point them out. It wrote the actual, working proof-of-concept code to show exactly how to do it.

73 of these have already been assigned CVE IDs.

The cost?

About $0.97 per vulnerability. And it took about 8 minutes each.

For less than a dollar, an AI framework audited complex codebases, reasoned about the object structures in plain English, wrote an exploit, tested it in a sandbox, learned from its own crashes, and handed over a working zero-day in a library that thousands of companies are quietly importing into production.

Now, here is the part I told you we would come back to.

When VulnSage fails to generate an exploit, it doesn't just shrug and move on. It tries to figure out why it failed.

And in the researchers' own evaluation, more than half of the failed cases turned out to be false positives. The original static analysis alert was wrong. There was a sanitizer in the middle of the code path. Or the analysis was just being too paranoid.

VulnSage caught all of that.. and explained the reason.

This is the part of the paper that I think defenders should be paying the most attention to. Because right now, security teams drown in static analysis reports. They get thousands of alerts a week, most of them garbage, and humans have to manually sift through them.

VulnSage doesn't just find the real vulnerabilities. It also tells you, with reasoning, which alerts you can safely ignore.

That is two wins in one tool.

If you've been reading me for a while, you know I look at these things pragmatically. I don't do blind optimism, and I don't do doom-scrolling.

But we have to look at the math here.

When the cost of finding a zero-day in a popular open source library drops to under a dollar, the entire economics of cybersecurity flips.

Right now, the internet relies on the fact that finding a critical vulnerability is hard. It takes weeks of human labor. That friction is what keeps the system safe. Most bad actors just don't have the time or the skill to dig that deep into an enterprise Java library.

VulnSage removes the friction. It turns a highly specialized research problem into a cheap, repeatable engineering loop. And because it is targeting open source packages specifically, every single bug it finds is a bug that lives inside thousands of downstream applications at the same time.

From my point of view, this forces an absolute necessity in how we build software going forward. We can no longer rely on human teams to manually audit and patch code. If the offensive side is using $0.97 agent swarms to find holes in the dependencies we all share, the defensive side has to use the exact same swarms to patch them before the code is ever pushed.

The future of cybersecurity isn't humans versus hackers. It's defensive AI agents fighting offensive AI agents inside the supply chain.

And the humans? We just set the rules and watch the logs.

This is exactly why I keep talking about the gentle singularity. We just fundamentally moved the baseline of what intelligence costs.

I'm not sharing this to make you panic. I'm sharing it because this is the reality we are stepping into. And awareness is the only way we adapt.

Let me know what you think. What happens when the cost of finding a zero-day in the libraries you depend on drops to under a dollar?

If you made it this far, you're not a casual reader. You actually think about this stuff.

So here's my ask. If this article made you think, even a little, share it with one person. Just one. Someone who's in the AI space. Someone who reads. Someone who would actually sit with these ideas instead of scrolling past them.

That's how this newsletter grows. Not through ads or algorithms. Through you sending it to someone and saying "read this."

And honestly? That means more to me than any metric.