Can an AI break into your website?

In July 2026, AI agents broke into Hugging Face's systems without direct human direction, and reached most of its server clusters within a single day. For a small business website, what changes is the pace: attacks come through the same doors as before, through a missed plugin update, a shared password or a file left on the server, only faster, and on many sites at once.

This page goes through what happened, what changed because of it, what stayed the same, and what is worth doing about it as the owner of a website.

What happened at Hugging Face

OpenAI was measuring its models in an internal cybersecurity test, without the usual safeguards. The agents got out of the isolated environment, and about 700 of them jointly attacked Hugging Face, the service where open AI models and datasets are stored. They wanted to find out how the test was scored. They reached internal data and keys; according to Hugging Face's disclosure, the public models stayed intact.

The attack was therefore started by an AI lab's own test, with no criminal intent. The chain, step by step and with the technical detail, is in the Workshop.

A second case became public on 24 September 2026: back in June, an OpenAI agent had reached non-public files on an Australian government portal. The operator did not notice, and only learned about it in September, from an OpenAI email (ABC News).

What changed: the pace

According to the 2026 report of Patchstack, a company working on WordPress security, for vulnerabilities exploited at scale a median of five hours passed between disclosure and the first mass attack. On a site updated once a month, such a flaw can stay open for weeks while attacks on it begin on the first day.

In April 2026, CERT-EU, the cybersecurity service of the EU institutions, wrote that by its estimate exploitation on average starts before the fix is even out; in 2018 there were still 63 days between the two. The same post notes that an AI model independently found severe flaws by the thousand and wrote working attacks for them. In November 2025, Anthropic documented an espionage campaign in which an AI already carried out 80–90 percent of the operations.

What stayed the same: the doors

A faster attacker comes in at the same places as a slower one. On a small business website, that usually means three places.

The missed update. According to Patchstack's data, in 2025, 91 percent of WordPress vulnerabilities were in plugins, 9 percent in themes, and six in WordPress core. Every plugin is a separate update track: on one that has not been updated for a long time, the flaw is public and the fix is not installed.

The shared password. At Hugging Face, a single key opened most server clusters because it had full rights everywhere. On a website, its counterpart is the admin password known to the owner, an employee, the previous agency and an occasional freelancer alike.

The forgotten file. A backup, an old installer or a log file that can also be requested from the web. At Hugging Face a file read gave away the keys; on a website a downloadable backup can give away the entire database.

What hosting protection does not catch

Many hosts offer built-in protection, and it is a real filter. According to Patchstack's measurement, however, protection running at hosting level caught only 12 percent of WordPress-specific attacks. The rest are requests that look legitimate from the host's point of view, and only become attacks inside the plugin's code.

What is worth doing about it

A security update matters within hours, the rest can be scheduled. That requires knowing what runs on the site: which plugins, which versions, and which of them has a fix out.

One person, one account. If everyone logs in with the same password, one leaked password opens every door, and afterwards there is no way to tell who did what. With personal accounts and only the rights the work needs, the damage is smaller and the trail remains.

What is not needed should not stay on the server. A deactivated plugin's files remain on the server, and some of them can be attacked just the same; a backup left on the server can be downloaded.

The backup should live somewhere else. A backup stored on the hosting can be damaged together with it, a copy stored elsewhere survives.

What I do about it in my own work

On the WordPress sites I look after, a check runs every day. It compares the list of admin accounts with the expected one, because a new admin account is a common trace of a break-in, and it looks for leaked secret keys on the public site. A backup is made every day, stored somewhere else, and the system also checks that it contains data.

Every new site I build runs on its own theme, without a page builder, and a plugin stays only where it genuinely provides a self-contained function. This site has no database and no server-side code running, and after every deployment I compare the fingerprints of the files on the server with my own copies. The rest of the care is described on the maintenance page. For an existing site, what runs under it and whether its versions have known flaws can be checked from the outside: the first assessment starts there, and it is free.

Questions on this topic

← Back to Writing