The biggest WordPress security risk may be your credentials
One advantage of watching millions of websites over many years is seeing how attacks change.
Thomas remembers a time when JavaScript injections were common. Later, attackers targeted FTP credentials stored on developers’ computers. Today, his team increasingly finds malicious plugins designed to look legitimate.
The methods keep evolving.
“What worked even three, six months ago doesn’t work today,” Thomas said.
That makes one of the numbers Thomas shared especially interesting: according to We Watch Your Website’s own data, 64% of the WordPress infections they see are caused by stolen administrator credentials.
In many cases, attackers don’t need to discover an obscure vulnerability buried in a plugin or theme. They can target the people who already have legitimate access to the site.
Information-stealing malware on someone’s computer can capture a WordPress login URL, username, password, and even authentication cookies. Phishing can accomplish something similar by convincing someone to enter credentials into a page designed to look like a service they already use.
For an agency, the potential impact gets bigger. Thomas described phishing campaigns targeting credentials for website management platforms. One compromised account could give an attacker access to dozens or even hundreds of client websites.
“You cannot be careful enough with login credentials,” he said.
Strong passwords and two-factor authentication still matter. So do updates, patches, security tools, and the other layers we’ve learned to put around WordPress. But protecting a website also means protecting the people and devices that have permission to access it.
For agencies managing multiple client sites, that makes credential management an ongoing part of keeping those sites secure.
Treat admin access like a set of keys
One of Thomas’s most practical recommendations is also one of the easiest to put into practice: give everyone who needs administrative access their own account.
That makes it possible to understand who logged in, where they logged in from, and what may have happened afterward. When several people share one administrator account, investigating suspicious activity gets much harder.
Cory compared it to giving copies of your house key to a group of people and forgetting who still has one.
The same idea applies when someone no longer needs access. Thomas has seen administrator accounts sitting unused for years. His recommendation is to regularly review access and remove accounts that are no longer needed. If someone needs access again later, you can create a new account.
For agencies managing client websites, that makes access management an ongoing responsibility. Review administrator accounts regularly. Remove access when projects end. Use two-factor authentication or passkeys where available. Protect the devices used to access client sites.
And remember to log out.
Authentication cookies can keep a session active after you’re finished working. Thomas pointed out that logging out ends that session, reducing the window in which a stolen authentication cookie could give an attacker access.
These are familiar security practices, but they matter even more as the ways we build and manage websites change. And with more people using AI to create apps, plugins, and custom code, there’s another layer of security to consider.
Go beyond “make it secure”
Credential theft is a problem for websites that already exist. AI-generated code introduces another security challenge.
Vibe coding has made software development accessible to people who may never have considered themselves developers. You can describe what you want, iterate with an AI model, and potentially have a working application surprisingly quickly.
But getting an application to work doesn’t necessarily mean it’s ready to put on the web.
“One of the things that good developers are really good at is patching, plugging holes, preventing vulnerabilities and exploitations,” Thomas said.
In the AI-generated applications Thomas and his team have analyzed, they’ve encountered problems such as API keys embedded directly in code and vulnerabilities that could expose sensitive information. Meanwhile, attackers are actively scanning websites for opportunities, regardless of whether the site was built with WordPress, custom code, or an AI development platform.
So how do you account for security when building with AI?
Thomas recommends starting with the prompt, but getting specific. Ask the model to consider risks like cross-site scripting and SQL injection, along with data privacy and GDPR requirements that may apply to your application.
As Thomas put it: “You’ve got to do something more than just describe your app.”
But prompting is only a starting point. Thomas cautions against treating the model’s response as proof that an application is secure. His team’s testing found that adding security requirements to prompts can help, but it doesn’t replace testing the resulting code.
That’s where security analysis comes in.
Thomas’s team has been developing an analyzer specifically for AI-generated applications. Their process combines static code analysis with adversarial verification and penetration testing.
In one research project, an initial scan identified as many as 375 possible vulnerabilities in an application. Their system then challenged those findings and narrowed the list to 68 vulnerabilities it considered legitimate. From there, it tested whether those vulnerabilities could be exploited, generated potential code fixes, and tested the application again.
There’s a useful lesson here beyond Thomas’s particular tool: AI-generated code still needs verification.
Security should be part of the building process, from the instructions you give the model through testing the code it produces.
Using AI to fight back
The same technology creating new security challenges can also help us find and respond to them.
AI makes it easier to build software, and attackers can use it to look for weaknesses or adapt their methods. Security teams can use many of the same capabilities to identify threats faster and make sense of enormous amounts of data.
Thomas’s own work is a good example.
Since starting We Watch Your Website in 2007, he has saved the malicious code his team has found while cleaning infected websites. That archive now helps train a specialized language model built for one purpose: identifying website malware.
“All it knows is what’s malicious and what’s not,” Thomas said.
His team also feeds information from website files, access logs, and database tables into its system. AI helps analyze that activity and distinguish between an attack, reconnaissance, and harmless behavior.
Years of security experience and data are helping make that AI more useful. AI gives Thomas and his team another way to apply what they’ve learned across millions of websites.
That’s a useful way to think about AI and security more broadly. The fundamentals we’ve developed over decades still matter. AI gives us new ways to apply them, test our work, and respond as threats continue to evolve.
Build quickly. Test carefully.
There’s a lot to be excited about in this new era of building for the web.
AI can help people turn ideas into working applications faster, give developers new ways to automate repetitive work, and make custom functionality more accessible. But speed doesn’t remove the need for good security practices.
That’s the thread running through Thomas’s advice.
When you build with AI, include security requirements from the start, but don’t stop at the prompt. Scan and test the code it produces. Pay particular attention to authentication, API keys, customer information, and other sensitive data. And use additional tools or expertise to verify what the AI tells you.
AI can also be part of the defense. Security teams are using it to analyze patterns, identify suspicious activity, and apply years of accumulated security knowledge at a much larger scale.
The tools will keep changing. The attacks will, too.
The best approach is to keep the fundamentals strong while adapting how you apply them: protect access, test what you build, verify the results, and make security part of the process from the beginning.