AI-driven attacks: what changes and what still protects you

Since 2025 there has been evidence that attackers no longer use language models just for highly convincing phishing emails, but also have them carry out attacks that have to be taken seriously. For the business of running websites and servers this changes less than many headlines suggest — in one respect, though, it changes a good deal: speed.

What the evidence shows

In November 2025, Anthropic, the maker of the Claude language model, described the first documented attack campaign carried out largely by an AI. A state-sponsored group targeted around 30 organisations. Among them technology companies, financial institutions and government agencies. According to Anthropic's analysis, the AI did 80 to 90 per cent of the work, with humans making decisions only occasionally. In a small number of cases the intrusion did succeed.¹

Barely a year later, this is no longer an isolated case. Anthropic's report from September 2026 describes intrusions completed within hours, and individual operators pursuing dozens of targets in parallel. One case concerns websites directly: a single actor used AI to develop an attack on a previously unknown weakness affecting the WordPress re-installation process. In doing so the actor managed to create an administrator account without valid credentials — successful against at least four websites. The actor also tampered with one victim's backups so that restoring them would have handed the actor access to the system again straight away.²

In May 2026, Google's Threat Intelligence Group for the first time found a zero-day exploit that it believes was developed with AI: a bypass of two-factor authentication in a popular open-source, web-based system administration tool, intended for mass exploitation. This exploit code was intercepted while still in operational planning, before it was used. What Google describes in these two reports is autonomy in individual steps — agents that find vulnerabilities on their own, and malware that carries on by itself on an already compromised device — not a complete attack that no one steers any more.^{3, 4}

The same capability is, however, also available to defenders. In 2025, Google's AI agent Big Sleep found a critical flaw in the SQLite database that, according to Google, was known only to attackers. That only helps those who then actually install the fix.⁵

What changes: speed and volume

An attack consists of many small steps: finding services, identifying versions, looking for a suitable vulnerability, adapting the attack code, evaluating responses, carrying on. Until now, most of these needed people with experience and time. A language model handles many of them in seconds, around the clock and against many targets at once.

This is clearest in the time between a vulnerability becoming known and its exploitation. Mandiant, Google's incident response unit, measured an average of 63 days for 2018 and 2019, and five days for 2023. In the M-Trends 2026 report, the estimated mean is minus seven days: exploitation routinely happens before a patch even exists. The trend began before AI, but AI accelerates it.^{6, 7}

In June 2026, Germany's Federal Office for Information Security (BSI) noted that AI can derive from a published patch within minutes to hours what an exploit needs to look like. Its conclusion: organisations must be able to review vulnerabilities, assess them and, where necessary, roll out patches within minutes to a few hours at most. A few days, it says, is not an adequate response time.⁸

The second change concerns the choice of targets. When an attack takes less work, targets that used to be too small become worthwhile — exactly the shift Anthropic describes. The assumption that a small website is of no interest to attackers was always risky. Today it is simply wrong: automated attacks do not necessarily choose by importance, but by reachability.²

What does not change: how attacks succeed

What is notable is what these reports lack: new attack techniques. Anthropic states explicitly that none of the operations it describes depended on a technique defenders had never seen. These are the familiar ways in — stolen credentials, unpatched devices at the network edge, exposed services, injected database code (SQL injection), phishing. Mandiant reaches the same conclusion for 2025: the vast majority of successful intrusions still stem from fundamental human and systemic failures, not from AI itself.^{2, 7}

For websites, one figure is particularly telling: according to VulnCheck, content management systems accounted for a third of all vulnerabilities newly added to its list of actively exploited flaws in the first half of 2026. Every extension that is installed but not needed enlarges the attack surface without doing anything useful.⁹

This leads to the core point of this article: attacks with AI do not necessarily call for a new kind of protection. What has always helped still helps. But security today has to be thought through afresh: without gaps, automated and consistently monitored.

Layers instead of a silver bullet

Unfortunately we cannot name a single measure here that fixes every problem and makes every system secure. So we build on a layered model: each layer catches part of it, and each assumes the one before it has failed. This is how we run the websites and applications we host for our clients, and our own. The following sections go through these layers in detail.

The “edge”: web application firewall and CrowdSec

Every request to one of our publicly reachable web services first passes through a web application firewall (WAF): ModSecurity with the OWASP Core Rule Set, a collection of rules maintained jointly by a global community against the common attack patterns — injected database code, foreign scripts, access to files outside the permitted area. The rules recognise patterns, not the specific individual vulnerability. They therefore also stop some of the attacks on vulnerabilities for which no patch exists yet. That buys us time we did not even know we would need.

Alongside it, CrowdSec analyses the logs and recognises behaviour rather than individual requests: someone systematically searching for admin interfaces, trying passwords or probing servers for known vulnerabilities. Such addresses are blocked before they reach the website. Then there is the network: anyone running CrowdSec shares the attacks they detect and in return receives a jointly maintained blocklist. An address attacking elsewhere can therefore already be blocked on our side before it sends its first request.

This works particularly well against automation, because automation leaves traces. Anyone sending thousands of requests in a short time creates a pattern — regardless of whether there is a person with a script or a language model behind it.

On the server: only what is needed

SSH access to our servers is not possible with passwords, not as “root” and not with arbitrary user accounts. It is possible only with a cryptographic key, and only for the few fixed users who are permitted to log in at all; addresses that have drawn attention through attacks elsewhere are dropped by the firewall before that. And the firewall lets nothing in at all by default: only what is really needed is open. We manage access centrally, and anyone who no longer belongs loses it on all servers. All of this is provided as Infrastructure as Code (IaC) and set up identically on every server, never by hand.

Against password guessing — one of the first tasks that can be handed to a machine — the remedy is therefore not a better password, but none at all.

In the container: as few privileges as possible

The applications themselves each run isolated in containers, and each has only the privileges it needs to work: the file system is read-only except for the directories where data has to live. The container never runs with root privileges, has a fixed memory limit and sits in its own network, separate from other clients' containers. Anyone exploiting a vulnerability in the application cannot overwrite its program code and also has no direct way of reaching other clients' containers to compromise them.

Just as important is what is not in the container at all. Tools needed for building but not for running have no place there. In September 2026, removing the package manager and its helper tools from the image of our own website alone eliminated 38 critical and high findings of the vulnerability scanner. Not to mention that missing tools hinder attempts at compromise, or prevent them outright. Because what is not available cannot be exploited.

In operation: knowing instead of assuming

A server is not secure because it was secure when it was set up. Every night, a scanner (Trivy) checks the installed packages of all servers and all running container images for known vulnerabilities. Security updates for the servers install automatically every day; if one remains pending for longer than one cycle, monitoring raises an alert.

This is how, in September 2026, we brought the image of our own website from 5 critical and 51 high vulnerabilities down to zero — measured, not estimated.

A window remains nonetheless: between the publication of a vulnerability and the next update, and even more so before publication. No update process can close it completely. This window is exactly what the other layers are for — the WAF, which recognises attack patterns without knowing the vulnerability, and the tight privileges that limit what a successful attack can do.

For emergencies: backups an attacker cannot delete

Anyone who has taken over a server often tries next to delete or alter the backups; the WordPress case above shows what that looks like. Our backups are encrypted, stored on a different server and written in append-only mode: a server being backed up can add new backups but cannot delete or overwrite existing ones. Older states are therefore preserved, even if an attacker has full control of that server.

That alone is not enough; you also need to know which state is clean. For this, the logs from the edge, the servers and the applications are collected on a separate server; they show when someone first got in. And we have rehearsed the restore. Backups that are never really validated in full are more a hope than a safeguard.

Protection that hits the wrong people

Each of these layers can also hit real visitors. In August 2026, the protective layer at the edge locked individual visitors out of our own website for a whole day each. The cause was a single missing file: the small icon in the browser tab (favicon) was missing, so every page view produced an error, or rather returned a 404, and a default rule counted enough occurrences of 404 errors within a given time span as an attack. That rule has since been adjusted so that the occasional 404 no longer leads straight to blocking an innocent website visitor.

In the same week, the first analysis showed who actually visits the websites we run. A bundled blocklist rejected practically all requests from AI services — on a single day around 370 of them from clients identifying themselves as ChatGPT acting on a person's request: not a crawler collecting content, but a service that wanted to read one of these pages to answer. For a company that wants to make its clients visible in AI answers, that was definitely the wrong protection. Since then we decide for ourselves, per website, whether AI services may read it: not at all, only at a person's request, or fully (including crawlers).

Neither is a side note. Protection that locks out real visitors is counterproductive and will eventually be switched off altogether, so as not to keep losing customers. That is not the point of it. And blocking everything that looks like a machine across the board is not a security strategy, but a decision against one's own visibility and discoverability.

What you can check yourself

The following questions give a sense of how well your own systems are set up. Any question that cannot be answered straight away, or not really precisely, points to something that needs doing.

• What is reachable from outside? Admin interfaces that are mainly used internally, databases and other password logins do not belong openly on the internet.
• How do you notice that one of your systems has a security vulnerability?
• How quickly does a security update actually reach your systems — and how do you know it has arrived?
• Is there something in front of the application that recognises attack patterns and steps in before the application itself is reached?
• What privileges does the application run with, and does it really need them?
• Is there a backup that even someone with full rights on the server cannot delete? When was it last restored from?
• Who is alerted when something stands out — and who decides what happens next?

AI has made attacks faster and cheaper, not unstoppable. What helps against them is the same as before. It just has to be implemented and monitored without gaps.