You read that a hacker used AI agents to breach websites, and now you are looking at your own site wondering whether it was one of them. That is a fair thing to check tonight. The checks are ordinary ones, and you can start most of them from your own logins.
Reuters reported on October 19, 2026, citing observations from NorForge researcher Snorre Fagerland, that an attacker used AI agents to attempt intrusions against more than 1,200 websites through the week ending October 18. The attacker's records indicated access to websites linked to more than 100 companies. Reuters put the cost at about $5,000 in AI-token usage.
Those are attempts and apparent access, not 1,200 confirmed breaches. Start with who can log in to your site, then what is out of date, then what your host leaves open.
Key Takeaways
Reuters reported on October 19, 2026 that AI agents attempted intrusions on more than 1,200 websites in the week ending October 18, with access indicated for sites linked to more than 100 companies.
The 1,200 figure counts sites the agents tried, and the 100 figure counts companies whose websites the attacker's records indicate access to.
The reported weaknesses included a Memcached session store with unauthorized write access, unsafe handling of saved PHP objects, an old Zend Framework weakness and exposed admin interfaces.
List every administrator, turn on MFA, check for pending updates, ask your host about exposed services and 30 days of logs, and confirm a backup has been restored in a test.
Bring in a professional if ownership is unclear, updates fail, payments or sensitive data are involved, logs are missing, or something on the site has changed that you did not change.
Is my website the kind of site these AI agents break into?
The agents did not use one trick. They found weaknesses during each target's own exploration. The reported weaknesses included unauthorized write access to a Memcached session store (a memory cache some servers use to hold login sessions), unsafe handling of saved PHP objects, an old Zend Framework weakness and exposed administrative interfaces.
So, the useful question is not whether your site looks like a big company's. It is whether your site has the same kinds of open doors: software that is out of date, an admin area anyone on the internet can reach, a login with no second step, or services your host left public. The fixes are the ordinary ones: current supported software, unused components removed, admin panels restricted, unique passwords, MFA and tested backups.
| Figure | What it counts |
|---|---|
| More than 1,200 websites | Sites the agents attempted to break into through the week ending October 18, 2026 |
| More than 100 companies | Companies whose websites the attacker's records indicate access to |
| About $5,000 | AI-token usage Reuters reported for the activity |
Gambit Security reported a separate campaign from September 22 involving about 100 organizations and at least 30 breached websites. Different dates, targets and tools. For company-wide policies, the post on company-level safeguards against AI agent attacks covers that side.
You do not need an AI-specific defense. The same controls reduce exposure whether the probing comes from an AI agent, a script or a person. Skip the hunt for an AI signature in your traffic and skip blocking crawlers; spend the hour on the checks in order.
What do I check first, and in what order?
Work through these in this order. The first three you can do from your own logins. The rest are questions for your host or developer, and it helps to write down what you find as you go.
| Step | What to do | Who does it |
|---|---|---|
| 1 | List every administrator and remove unknown or former users | You |
| 2 | Turn on MFA for each administrator account | You |
| 3 | Check the CMS, themes, plugins and server runtime for pending updates | You or your developer |
| 4 | Ask whether admin panels, staging sites, database tools, SSH and backups are publicly reachable | Host or developer |
| 5 | Request 30 days of access, authentication, file-change and firewall logs | Host or developer |
| 6 | Confirm backups are separate from the live site and have been restored in a test | You and your host |
If any step turns up something you do not recognize, follow the steps for suspicious changes before you delete or fix anything.
Who can log in to my website, and does every admin have MFA?
Open your website dashboard, then your hosting, domain and payment accounts, and the email account you use to administer them. In the dashboard, open the list of users and look at the roles. Every administrator should be a person you can name. Remove former employees and old agencies, and give each remaining account a unique password that you do not use anywhere else.
If you find an administrator you do not recognize, stop and follow the steps for suspicious changes before you remove it. A removed account can also remove the evidence of how it got there.
CISA's small-business guidance says to require MFA wherever possible and to start with administrator accounts and anyone who handles sensitive data. MFA is a second proof of identity, such as a code from an app, so a stolen password alone does not open the account. Turn it on for your website dashboard, hosting, domain registrar and email.
What is out of date on my website, and how do I check?
Look for pending updates in four places: your CMS or site platform, your themes, your plugins or extensions, and the server software your site runs on, such as the PHP version. In WordPress, the Updates screen in the dashboard lists the first three. WordPress.org says, "To keep your WordPress site secure, you should always update your plugins and themes to the latest version," and its page on plugin and theme auto-updates shows how to switch them on. On other platforms, ask whoever built the site where that screen is.
Delete what you do not use. A deactivated plugin or an old theme still sits on the server, and removing unused components is one of the fixes for exactly this kind of exposure. Before you update, take a backup. Afterward, load your key pages and send a test message through your contact form.
OWASP's guidance on vulnerable and outdated components says to keep an ongoing process for monitoring, triaging and applying updates across a site's life. When a warning about a plugin lands in your inbox, what a plugin vulnerability warning means walks through it, and checking WordPress plugins for urgent security updates covers the screens. Updates that fail, or that nobody owns, are the work website maintenance exists to cover.
What should I ask my host or developer about?
Some exposure cannot be seen from your dashboard. Send your host or developer one message with these questions:
- Are the admin panel, staging sites, database tools, Memcached and SSH reachable from the public internet?
- If they are, can access be restricted to the people who need it?
- Can you send access, authentication, file-change and firewall logs for the last 30 days?
- Which PHP or other server runtime version is the site on, and is it still supported?
If the answer to the first question is yes for anything you do not use, ask for it to be closed. If your host cannot supply logs, treat that as a finding of its own. Without logs, nobody can say what happened on the site last month.
Is my backup separate from the site, and has anyone restored it?
A backup stored on the same server as the site can be altered or lost along with it. Confirm the date of the last backup and where it is kept. It should live apart from the live site, in an account the site itself cannot reach.
NIST's Small Business Quick-Start Guide recommends regularly backing up data and testing the backups. A test means someone restores a copy to a safe place and confirms that pages, forms and logins work. Until that happens, you have a file, not a recovery plan.
What should I do if I find something I do not recognize?
An unknown administrator, unfamiliar files, unexpected redirects, changed contact details or altered payment instructions all call for the same response. Stop making casual edits. Do not delete suspicious files until a developer or incident responder has kept a copy, because deleting removes the evidence of how someone got in. Then call your host or a security professional.
The steps in what to do in the first 24 hours after a website is hacked give the sequence. A routine update check and an incident response are different jobs, and the second one belongs to someone with the access and the experience to do it.
Does a site with no plugins and no admin login face the same weaknesses?
A site with no server-side plugins, no CMS administration and no public admin login does not present the same set of weaknesses described in the October campaign. It has no plugin list to fall behind on and no admin page for an agent to find.
It can still be reached through other doors: the hosting account, the deployment pipeline, the domain registrar, exposed secrets, misconfigured storage, third-party scripts, or a developer's compromised credentials. The useful question is where code runs and where privileged access exists. OWASP's Top Ten lists the broader categories. Whatever your site is built on, the accounts around it need MFA, unique passwords and former users removed.
When should I bring in a professional?
Your own checks cover the common gaps. They cannot prove that custom code is safe, that a hidden service is closed, that logs are complete, that an unknown file is harmless or that a backup will restore. Bring in help when any of these is true:
- Nobody can say who owns the domain, the hosting or the site accounts.
- Updates fail or break the site.
- The site takes payments or holds sensitive customer data.
- Your host cannot provide logs.
- Something on the site has changed that you did not change.
- The site runs custom code or integrations that no one has reviewed.
Ask any reviewer for evidence, a ranked fix list and a restore test. A good review leaves you knowing what to fix first and how to get back if something goes wrong.
Check your first-hour plan
Pick an answer to begin.
1. What does the figure of more than 1,200 websites in the Reuters report count?
2. Which accounts does CISA say to put MFA on first?
3. You find a file on your site that you do not recognize. What comes first?
Frequently Asked Questions About a Hacker Using AI Agents to Breach Websites
Can AI agents hack any website?
They can automate probing and exploitation, but exposure depends on the site's software, configuration, accounts and services. Current software, restricted admin access and MFA reduce it.
Were 1,200 websites breached?
No. Reuters reported attempted intrusions against more than 1,200 websites through the week ending October 18, 2026. The attacker's records indicated access to websites linked to more than 100 companies.
Was every company's network compromised?
The reported figure concerns websites linked to those companies, not their whole networks. Check your own site's accounts and updates rather than assuming either way.
What should I check first on my own site?
List your administrators and remove unknown or former users, turn on MFA for each one, then check for pending updates. After that, ask your host about exposed services, logs and backups.
Can a static website be hacked?
It has fewer CMS and plugin weaknesses, but the hosting, domain, deployment and account access around it still need protection.
Do I need a security audit?
Consider one when ownership, logs, updates, custom code or recovery are unclear, when the site handles payments or sensitive data, or when something has changed that you did not change.
Final Thoughts
The attempts Reuters reported on October 19, 2026 reached websites through ordinary gaps: old software, open admin interfaces, weak session handling and accounts without a second step. Your first hour goes to the same short list. Know who can log in, put MFA on every administrator, clear pending updates, ask your host what is public and request 30 days of logs, and confirm a backup has been restored in a test.
Once those are done, the next headline reads differently. You will know who holds the keys to your site, where the backup lives and what to ask your host. If a rebuild is ever on the table, a site with no plugins to patch is an option, and our web design work builds exactly that.
If a check turns up something you cannot explain, or you would rather have it done once and properly, Web Leveling can run a website security audit and hand you a ranked fix list and a tested way back. We work with small and medium businesses across the country and overseas. Tell us what you found on your site, and we will tell you what to do next.
Terms
Website security words in this post
Tap a term to see what it means.
MFA. Multi-factor authentication, a second proof of identity such as an app code, required on top of a password.
Administrator account. A login that can change a site's content, settings, users and software.
Memcached. A memory cache some servers use to speed up a site, and in some setups to hold login sessions.
Session store. The place a server keeps the records that show a visitor is logged in.
Staging site. A private copy of a website used for testing changes before they go live.
Access log. A server record of requests made to a site, including logins and file changes.
Restore test. Putting a backup back in a safe place to confirm the site works from it.
