How Hackers Are Using AI to Find Software Vulnerabilities

For most of computing history, finding a security flaw in software was slow, skilled, manual work. A researcher would read code for weeks, or run automated tools that threw random data at a program for days, hoping something broke in an interesting way.

That economics has changed. Large language models can read millions of lines of code and reason about what might go wrong in them. The same capability that helps a developer spot a bug helps an attacker spot one — and it does so at a speed and scale that has quietly reset the timeline every defender was working to.

This article explains what has actually changed, what has not, and what it means for anyone running a website or a business that depends on software. It is written for defenders, so it describes the techniques conceptually rather than operationally.

The Short Version

AI has not invented a new kind of attack. Buffer overflows, SQL injection, authentication bypasses and memory-corruption bugs are the same classes of flaw catalogued for decades in MITRE's CWE list and the OWASP Top Ten.

What AI has changed is cost and speed. Work that required a skilled specialist and weeks of attention can now be attempted by someone far less expert, in hours, across far more targets. Attacks that were previously uneconomical against small targets are now worth automating.

That is the whole story, and it is enough to matter.

How Vulnerabilities Were Found Before AI

To see what changed, it helps to know what it replaced.

Manual code review

A researcher reads source code looking for mistakes — a length check that is off by one, user input reaching a dangerous function, a permission check that can be skipped. This is effective and extremely slow. A serious review of a large application is weeks of expert attention.

Fuzzing

Automated tools feed a program enormous volumes of malformed input and watch for crashes, on the theory that a crash often indicates a memory-handling bug that might be exploitable. Fuzzing has found an enormous number of real vulnerabilities and remains a backbone technique.

Its weakness is that traditional fuzzing is undirected. It generates input more or less blindly, so it spends most of its time exploring paths that lead nowhere and can run for days before reaching interesting code.

Static analysis

Tools scan code without running it, matching known dangerous patterns. Fast and scalable, but historically prone to flagging thousands of theoretical issues that turn out to be unreachable in practice — the false-positive problem that made many teams ignore their own scanners.

The Five Ways AI Changes This

1. Reading code at a scale no human team can

A language model can be pointed at an entire repository and asked, in effect, "where might user input reach something dangerous?" It does not merely pattern-match; it can follow data through function calls, reason about what a variable might contain, and flag the specific line where an assumption breaks.

A human reviewer gets tired after a few hundred lines. A model does not, and it can be run against thousands of open-source projects simultaneously. The quality is not yet equal to an expert reviewer — but it does not need to be when the volume is a million times greater.

2. Smarter fuzzing

The most consequential change is probably here. Instead of generating random input, a model can read the code first, understand what input format the program expects, and generate test cases aimed at the paths most likely to break.

This turns fuzzing from brute force into something closer to targeted probing. Campaigns that previously ran for days and found nothing now find issues in hours, because the search is informed rather than blind.

3. Turning a patch into an exploit

This is the technique that most directly affects ordinary website owners, and it deserves to be understood clearly.

When a vendor releases a security patch, that patch is public. Comparing the patched version against the previous one shows exactly which lines changed — and therefore exactly where the flaw was. This technique, patch diffing, is decades old. What was hard was the next step: working backwards from "here is the fix" to "here is how to trigger the bug".

That step used to take a skilled researcher days or weeks. Models that can read both versions and reason about the difference have compressed it dramatically. The practical consequence is that the patch itself is now a reliable map to the vulnerability, available to anyone within hours of release.

4. Reverse engineering compiled software

Much commercial software ships only as compiled binaries, with no source code. Analysing it means reading decompiled output that is correct but nearly unreadable — stripped of names, comments and structure.

Models are good at this specific translation problem: taking machine-generated, meaningless code and producing a plausible, human-readable explanation of what it does. That lowers the barrier to analysing closed-source software considerably.

5. Assembling the exploit, not just finding the flaw

Finding a bug and building something that reliably exploits it are different skills, and the second is harder. Assistance with that second step — scaffolding, debugging the attempt, adapting it across versions — is where AI makes the largest difference to someone who is competent but not expert.

This is the same capability that makes AI coding assistants useful to developers, pointed at a different goal. The tools do not distinguish between constructive and destructive intent.

The Time Window Has Collapsed

For a defender, the single most important number is how long you have between a patch being published and an exploit existing in the wild.

Historically that window was measured in weeks, sometimes months — long enough for a sensible organisation to test an update and roll it out on a normal schedule. It is now frequently measured in hours.

That has a direct, unglamorous consequence: a patching policy built around "we apply security updates monthly" is no longer a security policy. It is a scheduled gap.

The PHP vulnerabilities disclosed as PHP2Shell illustrate the whole dynamic. As covered in our breakdown of the PHP2Shell vulnerability and the critical PHP security flaws behind it, two memory-handling bugs affected roughly 1.5 million PHP hosts, prompted government portals to be taken offline, and — notably — were themselves found with AI assistance. Once the patch existed, the clock started for every unpatched server, and the people reading that patch had the same tools the discoverers did.

The CISA Known Exploited Vulnerabilities catalog is the clearest public record of this pattern: a steady stream of flaws moving from disclosure to confirmed active exploitation, often very quickly.

What AI Still Cannot Do

The hype overshoots in predictable places, and knowing where is useful.

Business logic flaws

The most damaging vulnerabilities often involve no broken code at all. A checkout that lets you apply a discount twice. A password reset that trusts an email address it should not. An API that returns another customer's record when you change one number in the URL.

Every line in those examples does exactly what it was written to do. Finding the flaw requires understanding what the system is *for*, and that remains a human strength — which is also why manual penetration testing has not been replaced.

Confident wrong answers

Models hallucinate vulnerabilities. They produce detailed, plausible, entirely fictional reports about flaws that do not exist. Open-source maintainers have been swamped with AI-generated security reports that waste reviewer time and bury genuine findings.

For an attacker, the equivalent cost is chasing leads that go nowhere. For a defender, it means AI output needs verification before action, every time.

Chaining and context

Real intrusions rarely use one flaw. They chain several — a minor information leak enables a weak authentication bypass, which enables code execution. Reasoning across an entire system, over time, with the patience to assemble a chain, is still where skilled humans outperform automation.

The Same Tools Are Defending

This is the part that balances the picture, and it is genuinely significant.

The capability is symmetrical. Vendors now run AI analysis over their own code before release, catching flaws that would previously have shipped. Several critical vulnerabilities in widely used software — PHP2Shell among them — have been found by defenders using exactly these techniques, and disclosed responsibly rather than exploited.

Automated patch generation is maturing too: a model that can identify a flaw can often propose the fix, which shortens the window on the defending side as well. And AI-assisted monitoring is better than signature-based tools at spotting behaviour that is merely unusual rather than known-bad, a theme we explored in AI cybersecurity and the future of digital trust.

The honest summary is that both sides got faster. Whether that is a net gain depends almost entirely on whether a given organisation patches quickly — which is a management question, not a technical one. Our piece on the risks of AI in cybersecurity looks at the other side of that ledger.

What This Means If You Run a Website

Stripped of the drama, the practical advice is short and dull, which is usually a sign it is correct.

• Patch within days, not months. This is the single highest-value change. Enable automatic security updates wherever the risk of an unattended update is lower than the risk of staying vulnerable.
• Know what you are running. You cannot patch software you have forgotten about — an old plugin, a staging site, an abandoned subdomain. Attackers find these before you do.
• Keep your PHP, CMS and dependencies current. Most mass compromises exploit flaws with patches that have been available for months.
• Assume your public code is being read. If your application is open source, or your JavaScript is served to the browser, it is already being analysed.
• Use layered defences. A web application firewall buys time when patching is delayed. It is not a substitute for patching, and treating it as one is a common and expensive mistake.
• Have an incident plan. In India, CERT-In requires certain cyber incidents to be reported within strict timeframes — know your obligations before you need them.

Smaller organisations are disproportionately exposed, because automation makes low-value targets worth attacking. Our guide to cybersecurity tools for small businesses covers the practical baseline, and the Star Health data breach is a reminder of what the consequences look like at scale in India.

Before and After AI

Frequently Asked Questions

Are hackers really using AI to find vulnerabilities?

Yes, though the change is one of scale rather than capability. AI has not created new categories of vulnerability — the flaw types are the same ones catalogued for decades. What has changed is that analysis which once needed a skilled specialist and weeks of work can now be attempted far faster, by less expert people, against many more targets at once.

Can AI write working exploits on its own?

Partially. AI is good at the scaffolding — adapting known techniques, debugging failed attempts, translating between versions. Fully autonomous discovery and exploitation of novel vulnerabilities in complex software remains difficult, and mainstream AI providers actively restrict this use. The realistic concern is AI making a competent attacker much faster, not replacing one.

How quickly are vulnerabilities exploited after a patch is released?

Much faster than before. A published patch shows exactly which lines changed and therefore where the flaw was, and AI has compressed the work of turning that into a working exploit from days or weeks down to hours in many cases. Monthly patching schedules no longer provide meaningful protection.

Was PHP2Shell found using AI?

Yes — AI-assisted analysis played a role in discovering the PHP memory-handling flaws disclosed as PHP2Shell, which affected roughly 1.5 million PHP hosts. It is a useful example of the same capability working for defenders: the vulnerabilities were found and responsibly disclosed rather than quietly exploited.

Can AI find every type of vulnerability?

No. It performs well on flaws with recognisable code patterns, such as memory-handling errors, injection flaws and unsafe input handling. It performs poorly on business logic flaws — a discount that can be applied twice, an API that returns another user's data — because every line of code in those cases is working exactly as written. Finding them requires understanding what the system is meant to do.

Does AI help defenders as much as attackers?

In capability terms, yes — the same analysis runs in both directions, and vendors increasingly scan their own code before release. The advantage goes to whichever side acts faster, and since defenders control their own patching speed, the decisive factor is organisational rather than technical.

What is patch diffing?

Comparing a patched version of software with the previous version to identify exactly which lines changed, which reveals where the vulnerability was. The technique is decades old; what is new is that AI has made the follow-on step — working backwards from the fix to a working exploit — dramatically faster.

Should small websites be worried?

More than before, because automation changes the economics. Attacking a low-value target was previously not worth a specialist's time; scanning thousands of them automatically is. Small sites are also less likely to patch quickly, which is precisely what these techniques exploit.

Do AI-generated vulnerability reports waste time?

Frequently. Models produce detailed, confident, entirely fictional vulnerability reports, and open-source maintainers have been swamped with AI-generated submissions that bury genuine findings. Any AI security output needs human verification before it is acted on.

What is the single most effective defence?

Patching quickly. Most successful mass compromises exploit flaws for which a patch has been available for weeks or months. Knowing every piece of software you run — including forgotten plugins, staging sites and old subdomains — and keeping all of it current protects against more real-world attacks than any other single measure.

Conclusion

AI has not given attackers a new weapon. It has given them a faster one, and handed the same speed to everyone else at the same time.

The flaw classes are unchanged. The defences are unchanged. What has changed is the clock: the interval between a vulnerability becoming public and being exploited at scale has collapsed from weeks to hours, and a patching rhythm that was prudent five years ago is now a standing invitation.

That is also the reassuring part. Nothing in this article calls for exotic countermeasures. It calls for doing the ordinary things faster — knowing what software you run, updating it promptly, layering defences so a delay is survivable, and treating a published security patch as something to apply this week rather than next quarter.

Frameworks like NIST's AI Risk Management Framework and guidance from national bodies such as the UK National Cyber Security Centre are catching up on the governance side. But the thing that actually protected servers during PHP2Shell was not a framework. It was whether somebody applied the update.

The attackers got faster. The question each organisation now has to answer is whether it did too.