How to protect your app from AI-powered attacks

AI agents can help attackers find vulnerabilities and work out how to exploit them. They can examine code, test an idea, and try another approach when it fails. I expect this to make it cheaper to investigate small apps that attackers would previously have ignored.

If you run an app, you need to know what’s exposed, how to patch it, and what an attacker could reach after getting in. You also need a way to notice suspicious activity and recover from a compromise.

The critical PHP vulnerabilities disclosed in October 2026 show why this matters. Researchers used AI to help turn old runtime bugs into working attacks against real applications. If you run PHP, that post covers the immediate patching work.

Here I want to start with what you can do to protect your app, then look at the security research and incidents behind my concern.

How I would prepare

For a small app, I would start by finding out exactly what is running.

List the domains and services you expose. Include abandoned previews, old containers, and the server you only use for one background task. Record who patches each runtime and how you would take it offline.

Then remove the things you don’t need. A deleted test deployment gives an attacker fewer opportunities and gives you one less system to maintain.

The PHP release is a good rehearsal. Could you identify every PHP runtime you operate? Could you tell whether your hosting provider had patched it? Would you remember the copy bundled inside a container?

Protect the accounts that control everything else

Start with your email, password manager, and the accounts controlling your domains and cloud resources. Access to one of those can let someone reset passwords or redirect traffic without finding a bug in your application.

Use a password manager to generate a unique password for every account. NIST explains why this helps: it makes long, unique passwords practical to use, while making the vault itself an important account to protect.

Enable multifactor authentication wherever it’s available. Prefer passkeys or security keys when the service supports them. CISA recommends phishing-resistant authentication, and stronger options are worth prioritizing on your most important accounts. My passkeys and WebAuthn guide explains how they resist fake login sites.

Keep recovery codes somewhere you can access if your phone is lost. Check who else has administrator access, and remove access that is no longer needed.

MFA protects account logins. A runtime vulnerability that executes before login still needs its own patch. Work through both kinds of exposure.

Give your home devices fewer places to reach

If you work from home, your network is part of this too. Cameras, smart TVs, and other connected devices don’t need unrestricted access to your work computer.

The Northern Ireland Cyber Security Centre recommends separating smart devices from devices holding private data. An isolated guest network can be an option. Check that the router blocks access to your main network; creating a second Wi-Fi name alone doesn’t create that boundary.

Keep the router and devices updated, and retire devices that no longer receive fixes. Check that anything you still need, such as controlling a device from your phone, works after the change.

Make updates routine enough to do urgently

If deploying a patch is frightening, you’ll postpone it.

Keep the build and deployment process working. Test the important user flows, and have a rollback procedure. For a security update, check that rolling back won’t put the vulnerable version back online.

Use supported runtimes and follow your providers’ security notices. Prioritize exposed vulnerabilities according to their impact and evidence of exploitation. You need a way to interrupt normal work for a critical update.

Managed services can reduce the maintenance you own. Check where that responsibility ends. A managed database doesn’t update the runtime inside your application container.

DigitalOcean’s PHP advisory gives a concrete example of how this responsibility changes between products:

The same advisory warns about existing Marketplace installations and old snapshots. Removing a vulnerable image from the Marketplace doesn’t update the server you created from it. Restoring a backup taken before the fix brings the vulnerable runtime back.

Include those copies in your inventory. After a restore, apply the required security updates before letting public traffic reach the application. A provider announcement saying a runtime is patched should lead you to check whether your running workload has received it.

Keep dependency versions locked and review updates before promoting them into production. A lockfile helps you control when an update arrives; it cannot make a compromised release safe. Check the provenance of build artifacts where available, and keep production credentials out of routine package installation and testing.

Limit what a compromised app can reach

Assume one application process gets compromised. What can it read or change?

A database account for one app should have access to the data that app needs. A deployment token should have the smallest useful scope. Backups should be protected from deletion by the same credentials used by the running application.

Keep databases and administrative interfaces off the public internet when public access isn’t necessary. Separate development credentials from production credentials.

Keep a record of where each important credential is used and how to revoke it. Practice replacing one without exposing the replacement to the environment you’re investigating. Removing a malicious package won’t invalidate a key it already stole.

Don’t count on a separate Linux user as the boundary either. After its kernel research (more on it below), OpenAI wrote that a low-privileged account on a system missing its latest patches should be treated as root for a well-resourced attacker. If your app runs as its own user on a VPS with an old kernel, code execution in the app can turn into control of the whole server. My CVE-2026-98432 post shows how to check the running kernel and update it. For code you trust less, OpenAI recommends isolation with gVisor or Firecracker virtual machines.

These decisions reduce the damage when a vulnerability gets through your other defenses. They still matter if the attacker is much better at finding bugs than you are.

Test the rules your application depends on

Updating dependencies won’t catch every mistake in your own code.

Can one customer read another customer’s invoice? Can someone call an admin endpoint directly? Can repeating a request issue a second refund?

Write tests for these rules and enforce them on the server. An attacker doesn’t have to use your interface, and an agent can help investigate the routes behind it.

My free Security Fundamentals course covers how to identify these boundaries and test them.

Use an agent to help defend what you own

Give an agent a limited, authorized task. Ask it to review an authentication flow, trace where secrets go, or propose tests for access control failures.

Require evidence for its findings. It should identify the affected path and explain how to reproduce the problem safely. Review the patch and keep a regression test for the behavior it fixes.

Cloudflare open sourced the security audit skill that seeded its own vulnerability discovery harness. It works with any coding agent that supports skills and subagents. It maps the codebase, hunts for issues, and hands every candidate to a fresh agent that tries to disprove it. Findings end up as confirmed, rejected, or needing validation. Install it with:

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit

Then ask your agent to “security audit this codebase”. Cloudflare explains how the harness grew from it in Build your own vulnerability harness. I covered two other scanners, DeepSec and the Codex Security CLI, in their own posts.

DeepSec goes through the whole repository. For the code you push after that, Vercel launched Security Review in public beta on November 3, for Pro and Enterprise teams. It runs on every push to a connected GitHub repository and reviews the diff against what’s already deployed, so it finishes in seconds. Findings show up in a Security dashboard and as pull request comments. Vercel Agent can validate a finding and commit the fix, or you can pull the findings into your own agent with vercel security vulnerabilities. Reviews are free until November 10, 2026, then billed at the model provider’s token rate plus $0.25 per million tokens.

Guillermo Rauch shared the first 24 hours: 6,817 vulnerabilities identified, 580 of them critical or high, and 1,411 already patched by the agent. Those are Vercel’s numbers, and they don’t say how many findings turned out to be false positives.

I used AI to help secure a server after moving it. That was useful work. An agent can help you get maintenance done that you would otherwise keep postponing.

Start with a disposable environment or a read-only review. Give it more access when the task requires it and you understand what it can change. A generated report saying the system is secure doesn’t make it secure.

If you’ve only used AI through a chat window, try an agent on a small project you own. Ask it to trace an unfamiliar request path and write a test for a missing permission check. Watch how it uses the code and the test results, then check its conclusions yourself.

You can learn where these tools help without giving them production access. That experience also makes it easier to judge what an attacker could do with similar tools, and which defensive work you can get done sooner.

Have an agent review new security logs

A code review helps you find weaknesses before deployment. I would also try using an agent to look for suspicious activity while the service is running.

Give it read-only access to a separate copy of your security logs. On AWS, that could include CloudTrail, which records account activity. Elsewhere, start with authentication logs and changes to administrator permissions. If you already collect events in a SIEM, a system for centralizing and analyzing security events, the agent can work from that feed.

Reviewing newly arrived events every five minutes is one possible starting point. That doesn’t mean an attack will be detected within five minutes. AWS says CloudTrail log delivery itself averages about five minutes, with no guarantee.

Ask the agent to flag suspicious activity and explain why it deserves attention. An alert should include the account involved, the time, and the original events so you can check its reasoning. Keep existing rule-based alerts running too. Test the whole path with a known event, and alert separately if the reviewer stops running or logs stop arriving.

If the volume is too high, I would try a cheaper first pass that groups repeated events and selects candidates for a more capable model to investigate. Rules or a small classifier can do that work. Check what the filter discards, because anything it misses won’t reach the second stage. High-priority rules should still alert you directly.

The reviewer needs restrictions too. Logs can contain text an attacker supplied, including prompt injections. Enforce read-only access outside the model, and keep production-changing tools out of this workflow. OWASP’s guidance explains why limited permissions matter here. Remove secrets and unnecessary personal data before sending logs to a model provider.

I would start with alerts I review myself, then use the results to judge whether the agent is finding useful things or producing noise.

Know what you would do after a break-in

Keep useful logs outside the application server. Decide which events should alert you, such as unexpected administrator creation or changes to deployment credentials.

Test restoring a backup into a separate environment. Check that the application works with the restored data. Keep recovery credentials somewhere you can reach if your main account is locked out.

Prepare a static maintenance response you can enable before requests reach the vulnerable runtime. If you need to isolate the application, you should know how to do that without accidentally serving its source files. Keep the instructions accessible outside the system you’re taking offline.

Have a short response procedure that covers isolation, preserving evidence, revoking access, and rebuilding from trusted inputs. If someone has already taken over a server, installing the security update doesn’t remove what they left behind.

The Linux Server Security course goes through this operational side in more detail.

We’ve been automating attacks for a long time

The internet was dangerous long before anyone connected a language model to a terminal.

The Morris worm spread across networked computers in 1988. Software could already move between machines and exploit weaknesses without a person typing each command.

We’ve since had scanners, password attacks, exploit kits, and tools that throw enormous numbers of unusual inputs at software to see what breaks. That last technique is called fuzzing, and it has helped find bugs for years.

We’ve also had repeated reminders that a problem in one shared component can affect applications everywhere. Log4Shell in 2021 was a remote code execution vulnerability in a Java logging library. Organizations had to work out where that library existed inside their systems while attackers were already exploiting it.

So the idea that attacks can be automated, or that one dependency can put a huge number of sites at risk, is familiar.

The history of machines finding the weaknesses is worth looking at too.

2016: machines competing to find and fix bugs

DARPA’s Cyber Grand Challenge put automated systems into a competition to find vulnerabilities, exploit them, and patch software. Mayhem won.

This happened years before the current coding agents. The competition used a controlled environment, so winning it didn’t mean a machine could break into any company. But the research goal was already clear: automate work that had required security specialists.

2024: an agent finds a real SQLite bug

Google’s Project Zero and DeepMind reported a vulnerability found by Big Sleep, their AI agent, in SQLite.

It was a memory safety bug in a widely used database engine. Google said it was found before reaching an official release, so SQLite users weren’t affected.

That’s a useful example of this going well. An agent found a real problem, and the developers fixed it before users received the vulnerable code.

2025: more real bugs, plus reports of malicious use

At the finals of DARPA’s AI Cyber Challenge, the competing systems found 54 planted vulnerabilities across 63 challenges. They also discovered 18 real vulnerabilities that the organizers hadn’t planted.

These were specialized systems with substantial engineering behind them. Still, the results went beyond solving a prepared exercise.

Later that year, Anthropic reported disrupting an AI-assisted espionage campaign. According to its account, attackers used Claude Code to carry out substantial parts of the work. Humans chose targets and remained involved.

That’s the provider’s account of what it observed, rather than an independent measurement of all AI attacks. It gives us a concrete example of malicious use alongside the defensive research.

2026: Firefox, PHP, then Linux

In March, Anthropic reported finding 22 security vulnerabilities in Firefox, including 14 rated high severity.

In April, Mozilla reported fixes for 271 vulnerabilities identified during its initial evaluation of Claude Mythos Preview. Mozilla later explained the engineering work behind those results.

Those numbers aren’t counts of successful attacks against users. They describe vulnerabilities identified and fixed in a defensive collaboration. They do show that heavily tested software can still contain a lot for these tools to find.

Then, in October, the PHP security release fixed two critical vulnerabilities, known as PHP2Shell, that can allow an attacker to execute code without logging in. Some demonstrated paths run before your application code, which means your login screen cannot protect that part of the runtime.

In Wiz’s account of the research, AI helped with discovery and with adapting working exploits across different applications and memory layouts. Wiz also credits Calif, OpenAI, and the PHP team for their work on discovery, coordination, and patch verification.

This was a coordinated research effort. The part I find worrying is how much of the difficult adaptation work can now be handed to an agent. Sam Altman later said models found serious PHP bugs by scanning widely, which I covered in my notes on his Cheeky Pint interview.

In November, OpenAI published results from an automated pipeline it ran against the Linux kernel. Agents picked the parts of the kernel an ordinary user can reach, scanned them, reproduced the bugs in virtual machines, wrote exploits and proposed patches. Security researchers reviewed the output before it went to the maintainers.

The mid-October run reproduced 1,724 vulnerabilities. It produced 948 distinct exploits that turn an unprivileged local account into root on a stock desktop Linux distribution, with the standard kernel protections turned on. The run cost $1,213,430 in API credits, about $1,279 per exploit.

In July, the same harness with GPT-5.6 Sol found 166 of these. The newer model found more than five times as many, even though the kernel had three months of fixes in between.

Like the Firefox numbers, these are bugs reported to maintainers with patches attached. OpenAI says it started with the critical ones and is sending the rest through its Patch the Planet program.

A security incident can stop your business before a break-in

The PHP disclosure also shows what happens while everyone works out whether they can keep their systems online.

CERT-EU advised isolating internet-facing applications when an immediate patch wasn’t feasible. The Dutch NCSC temporarily took its own website offline as a precaution.

Taking a site offline to protect it costs you availability even if nobody has compromised it. Depending on what that site does, people lose access to a service, orders stop, or employees have to find another way to work.

And you can face several incidents at once. Around the PHP release, other reports exposed weaknesses at different layers of the software we depend on. These incidents span several days, and the reports don’t show that AI caused each attack.

Your development tools need protection too

On October 21, GitLab patched a vulnerability rated 10.0 out of 10. Under certain conditions, an unauthenticated attacker could execute code on the GitLab server. Affected releases went back to GitLab 7.0, released in 2014. GitLab.com was already patched.

The software you use to store and deliver your application needs the same attention as the application itself. A compromise there can put source code and deployment credentials within reach. Check your CI runners and package registries when you inventory what needs protecting.

Updating a dependency can introduce the attacker

Also on October 21, LiteLLM’s release pipeline was compromised. The malicious release reached PyPI and official container registries, including images under the latest tag. It contained a credential stealer and tools for remote code execution.

In an affected Python environment, the malicious startup files could run without anyone importing LiteLLM. Starting Python was enough. The maintainers also said the official GitHub source tag was clean: the distributed artifacts had been built from an attacker-controlled repository.

So reviewing the source on GitHub told you nothing about the package you had installed.

A different failure is a name the model invented. Slopsquatting is someone registering that name so a later install runs their code.

Builds need restricted credentials too. If a dependency can read your production secrets while you’re building or testing, a supply-chain incident can expose them before your app ever goes live.

Your provider can become part of the emergency

Railway reported possible unauthorized access to customer environment variables, including decrypted contents for some of them. It recommended rotating all stored environment variables and private registry credentials as a precaution while the investigation continued.

Railway paused all deployments during the investigation. Customers had to respond to a possible secret exposure while their usual route for deploying changes was unavailable.

I would want to know how to revoke credentials directly with the service that issued them, without relying on my hosting dashboard. I would also keep an application build and a database export that I could use elsewhere.

That last concern became very concrete at Zeabur. On October 17, the company announced it would wind down after a second security incident. It scheduled service shutdowns for December. Its founder described growing architectural complexity and security and operational shortcomings alongside the business pressures behind the decision.

A provider incident can leave you planning a migration while you’re still checking what was exposed.

Even the certificate trust can fail

The eMudhra incident is an uncomfortable example of how weak a critical component can be.

Security researcher Scott Helme recovered eight intermediate certificate-authority private keys whose values were all below 256. One was 4. Others included 66 and 237. He also reported recovering the keys with a single prompt to an AI agent.

These are keys used to sign certificates that other software trusts, and the failure was in how they were generated.

eMudhra said its root private keys were unaffected and that the affected intermediates hadn’t issued customer certificates. Browser vendors blocked the intermediates, but other clients needed attention too. Python’s security guidance called for updates to packaging tools and certificate bundles, including copies inside containers and virtual environments.

An updated browser doesn’t mean the script calling your payment provider has an updated trust store.

Together, these incidents make the preparation work much broader. We need to be able to patch a runtime while also checking a dependency, revoking credentials, or dealing with an unavailable provider. More capable agents will add pressure to systems that already struggle with that workload.

An agent can keep working when the first attempt fails

Think about how you use a coding agent.

You give it a problem. It reads the code, runs something, gets an error, and changes its approach. Sometimes you have to intervene. Sometimes it works through a long sequence of failures on its own.

That same loop is useful for vulnerability research.

An agent with the appropriate tools can examine a code path, form a hypothesis, and test it in a lab. If the result doesn’t match its expectation, it can inspect what happened and try again.

Running a scanner against a list of known vulnerabilities is useful. An agent can also investigate why something unusual happened and decide what to examine next.

It will make mistakes. It can spend hours chasing something that doesn’t exist. But the attacker gets to decide how much time and money to spend on those attempts, and can run several investigations in parallel, so a low success rate can still pay off.

There’s also a difference between helping one person work faster and running several investigations at once. An agent can continue testing while its operator is away. Another can examine a different component. A useful result from one investigation can give the others a new place to look.

That takes money, computing resources, and engineering. Running more agents also creates more failures to investigate, and repeating a bad approach can waste the entire budget. The useful question is how much validated research an attacker can afford to do against each target.

OpenAI’s Linux kernel research puts numbers on part of it. A successful exploit took $359 in API credits on average. The failed attempts averaged $3,922 each, mostly hard race conditions where the agent kept trying. Pwn2Own and TyphoonPWN have paid $20,000 and $70,000 for a Linux kernel exploit like these, so at those prices the 948 exploits would be worth 16 to 55 times what the whole run cost.

If that cost keeps falling, the consequences accumulate. More code gets examined, more unusual results get followed up, and more attacks become worth adapting to a particular deployment. We should prepare for that pressure even while the tools remain unreliable at some tasks.

Being small will protect you less

If a custom attack requires a specialist to spend weeks on your app, your app needs to be worth that effort.

If parts of the investigation become cheaper, more targets become worth trying.

That’s my expectation for what comes next. Mass scanning will continue, with more automated investigation behind the interesting results. A strange response from your forgotten admin tool could become the beginning of a longer attempt.

An attacker doesn’t need to know who you are. Your server might have credentials for another service. It might hold customer data, send email, or run workloads someone else would rather you paid for.

Even an unsuccessful intrusion attempt can cost you money if it consumes paid API calls or expensive background jobs.

I would stop using “nobody cares about this app” as part of a security plan.

Old software will get a lot of new attention

We have decades of deployed software. Much of it was written when today’s tools didn’t exist.

Some of that code has had excellent security review. Some has barely had maintenance. An old internal service might become reachable through a new proxy, or gain access to data it was never designed to protect.

I expect agents to uncover more problems in this accumulated code. They’ll also help people turn published vulnerability details into attacks against installations that haven’t been patched.

We already had urgent patching before AI. My concern is that more of the work between reading an advisory and producing a usable attack can be automated. Depending on the vulnerability, defenders may have less time to react.

The Linux research shows the pace. During the 10 days the scan and review took, 61 of the bugs it found were patched upstream, 43 more had patches in staging, and 299 were being discussed in public, many found by other people. A kernel fix protects your server only after you install it and reboot.

Code that was scanned once isn’t finished either. OpenAI recommends scanning again with each new model generation, because the stronger model found bugs in the same kernel that the earlier one had missed.

This doesn’t mean there’s a date when everything gets hacked. A bug, a working exploit in a lab, and a successful compromise of your deployment are different things. Permissions and deployment details still affect what an attacker can do.

It does make long delays harder to justify when an exposed service has a serious fix available.

Our own agents create another way in

There’s also the agent you invited into the system yourself.

We give coding agents repository access, shell commands, and credentials. Some can deploy applications or change cloud resources.

An agent may then read a web page, an issue, or a file containing instructions written by someone else. If it follows those instructions as though they came from you, that’s prompt injection.

The prompt injection entry in my AI glossary covers how Claude Code, Codex, Cursor and Grok Build limit what that text can do.

The attacker is trying to redirect software that already has permission to act.

I would treat an agent with production access as another privileged application. Give it a separate identity where possible, restrict its permissions, and keep credentials short-lived. Enforce limits outside the conversation, through the tools and infrastructure it uses.

Telling it “never reveal secrets” doesn’t remove its ability to send a secret somewhere. Keeping a password out of the model’s context helps, but an agent allowed to use that password can still perform harmful actions through the authenticated session.

I’ve written more about how agents can log in without seeing passwords. The permissions after login deserve just as much attention.

Agents doing security work need the same checks. In an early run of OpenAI’s kernel pipeline, 20 of 200 exploits reported as successful got root through a different unknown bug than the one the agent was assigned. In another run, an agent hit an unexpected crash, traced it to QEMU, the emulator running its test machine, and exploited that too. OpenAI now verifies how an agent reached a result, not only the result, and tests its sandboxes before running this kind of research inside them.

I can be optimistic and still take this seriously

I think AI can make building software much more accessible. The defensive examples in this post also give me reasons to be optimistic about finding and fixing vulnerabilities.

But the transition can be painful. A small team may suddenly have to validate more security reports, patch several services, and explain downtime to its customers. Useful discoveries create immediate work for people who already have other responsibilities.

Attackers can choose which weakness to pursue. The people operating the software have to keep the service running while they respond. Better research tools help, but deploying a fix still involves real systems and real people.

That’s what makes this feel urgent to me. The capabilities already demonstrated are enough reason to revisit how we protect our work. I want the benefits of these tools, and I want to be prepared when someone uses them against something I depend on.

There is useful work we can do before the next disclosure

The SQLite and Firefox examples are encouraging because developers used these tools to find and fix problems. More capable agents can help defenders examine code that has waited years for attention.

But finding a bug creates work for someone. Maintainers have to validate it, develop a compatible fix, and get that fix to users. Funding the projects we depend on matters here too. Faster discovery won’t help much if the people maintaining the software can’t keep up.

For the apps we run ourselves, we can improve that last part now.

Pick one deployment. Find out what’s exposed, who can change it, and how it gets patched. Restore its backup. Remove the old admin tool you’ve been meaning to delete.

Want me to talk about your product? You can sponsor this site.