A company that has never deployed artificial intelligence (AI) still has a different security posture than it had a year ago, because the people attacking its website adopted the technology even though the company did not. Artificial intelligence reaches your website whether or not you adopted it, through the attackers who now find vulnerabilities in hours instead of months, through the suppliers who write your code with it, and through the features that arrived inside software you already run. In July 2026 a researcher at Searchlight Cyber reported finding a critical vulnerability chain in WordPress core with model assistance, in a little over 10 hours and for about $25 of subscription time. The security firm Patchstack then recorded the first real exploitation attempts against live sites roughly 90 minutes after the fix was released. None of the businesses caught in that window had an artificial intelligence strategy.
This article is about website security in the AI era, and it is written for the owner or technical lead of an ordinary website, the kind built on a content management system with some plugins, some integrations, and an agency or a small internal team keeping it running. It assumes you have made no decision about artificial intelligence at all. The advice is deliberately vendor-neutral and recommends no tooling, which means you can act on it with whoever already maintains your site.
In short
Attackers now find vulnerabilities cheaply enough that the gap between a patch being published and that patch being exploited is measured in hours, and in the July 2026 WordPress case it was 90 minutes. The suppliers who build and maintain your site have adopted the same tools, and Veracode's 2026 testing puts the security pass rate of generated code at 55 percent. Most organizations have also acquired artificial intelligence features without ever deciding to, through plugins that added them in an update and through staff using public tools with company data.
The three ways artificial intelligence reaches your website security
Artificial intelligence changes your security position without your participation because it made three previously expensive things cheap, and all three sit upstream of your website instead of inside it. Finding a vulnerability used to mean paying a scarce specialist for several weeks, and shipping a conversational feature meant funding a research team. Both are now affordable to a company of any size, and so is producing code by the thousand lines. That price collapse happened over roughly two years, between the first widely available coding models and the agentic tooling of 2026, and your attackers, your suppliers, and your own software vendors each pass some of it on to you.
Most of what is written about artificial intelligence security addresses a different problem. It is aimed at organizations building autonomous systems of their own, and it deals with securing models, agents, and the permissions they hold. That work matters enormously for the companies doing it, and the Open Worldwide Application Security Project published a dedicated Top 10 for Agentic Applications on December 9, 2025 to address exactly that audience. None of it describes what reaches a marketing site, a membership portal, or an online store whose owner has never opened a model provider account.
The three routes, what each one changes, and the evidence behind it:
| Route | How it reaches you | What it changes for you | Evidence |
|---|---|---|---|
| Your attackers use it | Vulnerability discovery and exploit development became cheap, so published fixes are weaponized within hours | Your response time, now the binding constraint on your exposure | 90 minutes from patch to first exploitation (Patchstack, July 2026) |
| Your suppliers use it | Agencies, plugin authors, and package maintainers write with model assistance, and that code carries more defects and more dependencies | What review and provenance you require, and of whom | 55% of generated code passes security testing (Veracode, 2026) |
| You already added it | Features arrived inside software you already run, and staff use public tools with company data | What you actually have, which most organizations have never inventoried | 66% used AI at work believing it was against policy (PagerDuty, 2026) |
Route one: your attackers use artificial intelligence
Attackers reach you first because vulnerability research got dramatically cheaper, which compressed the interval between a fix becoming public and that fix being exploited. The clearest demonstration so far arrived in July 2026. A researcher at Searchlight Cyber, Adam Kues, used a commercial language model to analyze WordPress core from first principles and found two flaws that chain together into a full compromise. One is a routing confusion bug in the REST application programming interface batch endpoint, the other a SQL injection in a query parameter. Chained, they let an unauthenticated attacker run code on a default installation with no plugins required.
Kues reported that the work took a little over 10 hours of model runtime and cost about $25, calculated as a pro-rata share of a monthly subscription. By his own account, which is the researcher's claim and not an independent finding, "No security researcher could have found and completed this exploit chain in 10 hours without AI". He also mentions, almost in passing, that he spent longer understanding the exploit than the model spent creating it. The $25 is the number that gets quoted. The second one is the number that changes who your realistic attacker is.
WordPress published fixes across three release branches on July 17, 2026, and enabled forced updates through the auto-update system for affected installations. Patchstack recorded the first genuine exploitation attempts roughly 90 minutes after the patched release shipped, and about three hours after the fix was committed publicly. Within days the company had blocked more than 65,000 exploitation attempts originating from more than 1,500 distinct addresses, with the overwhelming majority aimed at the single vulnerable endpoint. On July 21, 2026 the United States Cybersecurity and Infrastructure Security Agency added both vulnerabilities to its Known Exploited Vulnerabilities catalog, confirming exploitation in the wild.
The publication of a fix is now the starting gun for attacks instead of the end of the risk. Attackers read published patches to learn exactly what changed, and model assistance has made that reading fast. Nothing about this is specific to WordPress, and none of it suggests WordPress is unsafe. The project received a coordinated disclosure, shipped fixes across every supported branch on the same day, and pushed them out automatically, which is close to the best response available to any platform. Any widely used system would face the same arithmetic, and this conclusion is not ours alone. The Hacker News made the same argument in July 2026, and several security vendors reached it independently over the same months.
So a patching process built around days of grace no longer matches reality. If your site is updated when someone gets to it, or on a monthly maintenance visit, the window in which you are exposed is precisely the window in which mass exploitation happens. We wrote a separate piece on what a safe update process actually looks like, and the mechanics translate across platforms. The schedule that seemed cautious two years ago has quietly become the risk.
Route two: your suppliers and dependencies use artificial intelligence
Your suppliers reach you second, because the people writing the code you depend on adopted artificial intelligence faster than the review practices around it matured. This is the software supply chain, and artificial intelligence now touches every link in it. It applies to your agency, to the authors of every plugin and module on your site, and to the maintainers of the open-source packages sitting underneath those. You did not choose the tools any of them use.
The measured picture is neither catastrophic nor reassuring. Veracode has evaluated more than 150 language models on code generation across successive snapshots, testing against four common vulnerability classes including SQL injection and cross-site scripting, and its 2026 analysis found that only 55 percent of generation tasks result in secure code. Syntactic correctness, meanwhile, now exceeds 95 percent, while the security pass rate remains, in the company's words, "virtually identical to where they stood two years ago".
Generated code compiles, runs, passes a functional test, and looks entirely reasonable in review, while carrying a defect that only shows up under adversarial conditions. That is the worse failure mode, because broken code announces itself in the first test run and gets fixed on the spot. Working code with a quiet flaw in it ships, and stays shipped until somebody attacks it.
A second effect operates on your dependency tree. Researchers presenting at USENIX Security 2025 generated 2.23 million code samples across 16 models and found that 19.7 percent of them referenced a software package that does not exist, at rates of 5.2 percent for commercial models and 21.7 percent for open-source ones. Attackers noticed the pattern and began registering the invented names, so that a developer following a confident suggestion installs hostile code. A 2026 re-evaluation across five current frontier models measured hallucination rates in a much narrower band of 4.6 to 6.1 percent, so the problem has shrunk considerably since the original study. That same re-evaluation still identified 53 invented package names that remained available for registration after disclosure, which is 53 working attack opportunities. This open-repository risk predates artificial intelligence, and Arch Linux reported a high volume of malicious package adoptions and updates in its community repository in June 2026. What artificial intelligence changed is the number of doors leading to a mechanism that already existed.
The natural reflex is to have the same technology review that code, and AI-assisted review tools do genuinely catch familiar vulnerability patterns. They also generate noise, and that noise carries a cost nobody budgets for. A false positive is indistinguishable from a real flaw until a person checks it, so a tool that flags heavily consumes the time it was meant to free up.
The curl project demonstrated this publicly. Daniel Stenberg, its maintainer, ended a bug bounty program on January 31, 2026 that had run since April 2019, paid out more than $100,000, and led to 87 fixed vulnerabilities. The cause was not a shortage of reports but their quality. The proportion that turned out to be genuine vulnerabilities, north of 15 percent for years, had fallen below 5 percent during 2025 under a flood of AI-generated submissions. Stenberg described the cost in human terms rather than technical ones, citing a serious mental toll on maintainers.
What happened next deserves as much attention as the episode itself. The program reopened in March 2026, and by April Stenberg reported that the confirmed-vulnerability rate had returned to roughly 15 to 16 percent, its pre-AI level, against a submission volume around double that of 2025. The noise cleared within months. The lesson is therefore not that artificial intelligence should be kept out of development, but that what protects you is the triage process and not the tool. A team that has an AI review its code without anyone adjudicating the output has added work without adding security.
For you it comes down to what you require, and of whom. Three points are enough to place a supplier: whether review of generated code differs from review of handwritten code, whether a person approves every new dependency, and whether anyone can tell you what your site depends on today. The same logic governs the choice of platform itself, which we covered in a separate piece.
Route three: you already added artificial intelligence without calling it AI
The third route is the one most organizations traveled without noticing, because the technology arrived inside things they had already bought. A plugin added a summarization feature in a routine update, the site search quietly became semantic, and a chat widget went live because marketing wanted one. Meanwhile staff began using public tools for work, which is the phenomenon security teams call shadow artificial intelligence.
Shadow artificial intelligence is the set of tools and features in use across an organization that were never reviewed, approved, or inventoried by the people responsible for its security.
The prevalence is higher than most leaders assume. A 2026 survey by PagerDuty of 1,250 office professionals in non-technical roles at companies above $500 million in revenue found that 66 percent had used AI tools at work despite believing it was against company policy. In the same survey, 43 percent had entered work correspondence into public tools and 34 percent had entered customer data.
Where these features touch your website, they introduce an attack class that traditional web security does not cover.
Prompt injection is an attack in which text given to an artificial intelligence system is written so the system treats it as an instruction to obey instead of data to process. If a chat widget on your site reads your product pages, and an attacker can influence any text it reads, that text can carry instructions. No reliable defense against prompt injection exists as of 2026, so the practical response is to limit what a compromised system can reach and not to rely on blocking the attack.
What this raises is a question of ownership. Somebody has to be able to answer what AI is running on or around your website, what data it can read, and who approved it. In most organizations that question has never been asked, which means the answer gets discovered during an incident.
Why prevention is not the answer
None of the three routes can be closed by prevention, because vulnerability discovery cannot be made expensive again, no team can review every transitive dependency it inherits, meaning the packages its own packages pull in, and prompt injection has no reliable defense as of 2026. Website security in the AI era is therefore less about keeping attackers out and more about what happens after one gets in. That is an uncomfortable conclusion and not a counsel of despair, because it redirects effort toward the things that still work.
The gap between recognizing this and acting on it is wide. Research published in July 2026 by INE found that only 22 percent of organizations felt prepared for AI-driven cybersecurity operations. A separate 2026 survey of 235 large-enterprise security and technology executives found that 92 percent lacked full visibility into the artificial intelligence identities operating in their environment, and 95 percent doubted they could detect or contain a compromised one. Those two figures describe the same failure from different angles, and in both cases the missing capability is detection and containment, not another preventive control.
The realistic goal is a platform where a compromise is noticed in hours instead of months and cannot reach beyond the system it started in. That reframing changes what is worth paying for. Time-to-detection becomes a number you actually track. Backups get tested by restoring them, not by confirming the job ran. Credentials get scoped so a compromised component cannot reach the database, the mail system, and the file store all at once, and update capability gets treated as standing infrastructure that can move within hours rather than as a policy stating that updates happen promptly.
None of that is exotic and none of it requires artificial intelligence expertise. It is ordinary operational discipline applied on the assumption that something will get through. The companies that come out of the next few years intact will mostly be the ones that noticed early and contained the damage, whatever their preventive controls looked like on paper. Getting there means treating maintenance as a standing capability instead of an occasional visit.
Frequently asked questions
Does AI security matter if my company does not use AI?
Yes. Artificial intelligence changes your security position through three routes that do not require you to have adopted it. Attackers use it to find vulnerabilities far more cheaply than before, which shortens the time between a patch being published and that patch being exploited to a matter of hours. The suppliers who build and maintain your site have adopted the same tools, and independent testing puts the security pass rate of generated code near 55 percent. Most organizations have also acquired artificial intelligence features without deciding to, through plugins that added them in an update, through chat widgets, or through staff using public tools with company data.
How quickly do I need to patch a critical security vulnerability in 2026?
Faster than most maintenance arrangements allow. In the WordPress core vulnerability chain disclosed in July 2026, the security firm Patchstack observed real exploitation attempts roughly 90 minutes after the fix was released, because attackers read published patches to learn what changed and model assistance makes that reading fast. A monthly or even weekly update visit leaves a window that overlaps with mass exploitation. The practical target for a critical, remotely exploitable flaw in internet-facing software is same-day, which is less a policy question than a capability question. If applying an urgent update requires scheduling, approval, and someone being available, that capability does not exist yet.
Is AI-generated code less secure than code written by people?
On the available evidence, AI-generated code carries more defects, though the difference is one of degree rather than kind. Veracode's 2026 analysis, covering more than 150 language models tested against four common vulnerability classes, found that only 55 percent of generation tasks produce secure code, a figure the company describes as virtually unchanged over two years while other model capabilities improved sharply. The more useful finding is the gap between correctness and security, because syntax is right more than 95 percent of the time. Generated code therefore tends to compile, run, and pass functional review while carrying a flaw that only appears under attack.
What is prompt injection, and can it affect a normal website?
Prompt injection is an attack that smuggles instructions into the text an artificial intelligence system reads, so the system carries them out instead of simply processing the words. It affects a normal website as soon as that site runs anything that reads text and acts on it, which today commonly means a chat widget, an AI-powered site search, or a support assistant. If an attacker can influence any text the system reads, including page content, customer reviews, or uploaded documents, that text can carry instructions. No reliable defense exists as of 2026, so the sound approach is to limit what such a system can access and not to rely on filtering the attack.
What should I ask my agency or hosting provider about AI security risk?
Five questions cover most of the ground. First: how quickly can you apply an emergency security update, measured in hours from the advisory? Second: do you review AI-assisted code differently from handwritten code, and does a person approve every new dependency? Third: can you tell me every artificial intelligence feature currently running on my site, including ones that arrived through plugin updates? Fourth: how would we find out if the site were compromised, and how long would that take? Fifth: if one component were compromised, what else could it reach? Vague answers to any of these are informative in themselves, and none of the five requires the provider to buy anything.
Putting it into practice
If you take one thing from this, make it the inventory. You cannot make decisions about artificial intelligence risk on a platform whose artificial intelligence you have not cataloged, and that catalog rarely takes more than a day to produce. From there the sequence for web platform security is the ordinary one. Know what you run, know how fast you can change it, know how you would find out that something went wrong, and limit what any single failure can reach.
Two neighboring pieces go deeper where this one stays broad. Our practitioner playbook on safe updating covers the response capability that route one demands, and our guide to making a website readable to AI agents covers the other side of the relationship, where these systems arrive as visitors and not as threats. If you would rather have someone else answer the five questions to ask your agency about AI security risk on your own platform, that is what an independent audit is for.
Keroberos is a web technology consultancy that advises businesses on platform selection, commissions and delivers WordPress and Drupal builds, and provides staff augmentation for development teams. To discuss your platform security, contact us.