WordPress, CMS, custom sites: sloppy development is what gets you hacked

Every day, automated bots crawl millions of websites looking for one thing: a known, unpatched flaw. They don't care who you are, how small your business is, or how unlikely a target you think you make. They don't target you personally — they target vulnerabilities, and the internet is scanned non-stop, 24/7. If your site has a weakness a bot recognizes, it will be found, usually within days of going live, and often within hours of a new vulnerability being published.

This is the uncomfortable truth behind most hacked websites: the breach wasn't sophisticated, and it wasn't personal. It was a door someone forgot to lock — a plugin that hadn't been updated in two years, a login form with no rate limiting, a contact form that quietly trusted whatever a visitor typed into it. In almost every case we've investigated, the root cause traces back to the same thing: development that cut corners. Not a lack of security tools, but a lack of discipline while the code was written.

Whether your site runs on WordPress, PrestaShop, Joomla, or a completely custom-built platform, the logic is the same. The technology you choose matters far less than the care put into building and maintaining it.

WordPress & CMS: the #1 target

WordPress alone powers over 40% of the web, which makes it — by sheer volume — the single most attacked CMS on the internet. PrestaShop, Joomla, Drupal and the rest follow the same pattern at a smaller scale. This popularity is precisely why attackers automate their scans against these platforms: one working exploit can be replayed against millions of sites in minutes.

But here's the part that matters: WordPress itself is safe. Its core is maintained by a large, professional security team, audited constantly, and patched fast when an issue is found. The vulnerabilities that get exploited almost never live in WordPress core. They live in what's bolted onto it:

• Outdated or abandoned themes and plugins — the #1 cause of WordPress breaches. A plugin installed once and never updated, or one whose developer stopped maintaining it, becomes a permanently open door.
• Weak or reused passwords on admin accounts, with no two-factor authentication, no lockout after failed attempts.
• An unprotected /wp-admin or default login URL, exposed directly to the internet for anyone — or any bot — to try.
• Obsolete PHP or CMS core versions kept running because "it still works," ignoring months or years of security patches.
• Dodgy, nulled or pirated add-ons downloaded outside official marketplaces — some ship with backdoors already built in.

None of this is a flaw in the CMS. It's negligence in how the site was set up and looked after — usually by a developer or agency that installed plugins without ever planning to maintain them.

Custom projects aren't spared

"We built it ourselves, from scratch, so we're not exposed to plugin vulnerabilities" is a sentence we hear often — and it's a dangerous one. A custom project has no plugin ecosystem to patch, true. But it depends entirely on the rigor of whoever wrote every single line of code. Without a CMS's security team, a large user base, or a bug bounty community watching for flaws, mistakes in custom code can sit undiscovered for years — until a bot stumbles on them.

The most common holes we find during custom-code audits:

• SQL injection — database queries built by concatenating user input directly, instead of using prepared statements. This is still, in 2026, one of the most common and most damaging flaws in home-grown web applications.
• Cross-site scripting (XSS) — user input displayed back on a page without being sanitized, letting an attacker inject scripts that run in your visitors' browsers.
• Unfiltered file uploads — a form that accepts "any file" and stores it in a web-accessible folder, allowing an attacker to upload and execute malicious code.
• Missing authorization checks — an endpoint that verifies a user is logged in, but never verifies they're allowed to access that specific record (client A viewing client B's invoices, for instance).
• Hardcoded secrets — API keys, database passwords or admin credentials written directly into the source code, sometimes pushed to a public repository.
• Unprotected endpoints — internal APIs or admin routes with no authentication at all, reachable by anyone who guesses the URL.
• Verbose error messages that leak your server paths, database structure or stack traces straight to the visitor — a free map for an attacker.

These aren't exotic attacks reserved for large corporations. They're textbook mistakes, and they show up constantly in projects built under a tight deadline, by a freelancer who never revisited the code, or by a team without a security review step in its process.

The consequences of a breach

A security hole rarely stays theoretical for long once a bot finds it. The consequences are concrete, and they compound quickly:

• Defacement — your homepage replaced with a message, an image, or simply gone.
• SEO spam injection — hidden pages and links stuffed into your site to promote pharmaceuticals, gambling or counterfeit goods, quietly damaging your domain's reputation with Google.
• Customer data theft — names, emails, addresses, sometimes payment details, exposed or sold. Beyond the trust damage, this triggers GDPR obligations: mandatory breach notification, potential fines, and a duty of transparency to every affected customer.
• Ransomware — your site or its database encrypted, with a ransom demanded to get it back, and no guarantee you ever will.
• Google blocklisting — the dreaded "This site may be hacked" or "Deceptive site ahead" warning in search results and browsers, which can erase your organic traffic overnight and take weeks to clear even after the fix.

Cleaning up after a breach almost always costs more — in time, reputation and lost revenue — than the audit and fixes that would have prevented it.

How to close the holes

Good news: most of what matters is neither expensive nor exotic. It's discipline, applied consistently.

• Keep the CMS core, themes and every plugin updated — remove anything abandoned or unused.
• Apply the principle of least privilege: every account and every process gets only the access it strictly needs.
• Use prepared statements for every database query — never concatenate user input into SQL.
• Validate and sanitize every input, on both the client and server side, and check every file upload's type and content.
• Put a web application firewall (WAF) in front of the site to filter malicious traffic before it reaches your code.
• Run automated, tested backups — offsite, and verified to actually restore.
• Enforce HTTPS everywhere with HSTS, and set proper security headers (CSP, X-Frame-Options, etc.).
• Require two-factor authentication on every admin account, with strong, unique passwords.
• Schedule regular security audits — don't wait for a breach to find out where you stand.

We help clients implement exactly this, whether the fix is on a custom AI-assisted build, as part of a broader server security audit, or through ongoing website maintenance that keeps updates, backups and monitoring running in the background. If you'd rather start by simply knowing where things stand, our website audit covers security alongside performance, UX and SEO.

FAQ