Bots and automated attacks
Programs that probe thousands of sites a minute looking for old versions and weak passwords. They're the number one threat, and it's all automatic.
Guides
Website security, explained properly
What actually threatens a site, what «normal» sites neglect and how I protect mine — with the honesty to tell you that absolute security doesn't exist.
In short
Almost no attack on a website is targeted: they're automated bots exploiting known vulnerabilities in outdated CMS, themes and plugins. The defences that really matter are few and concrete: a small attack surface, updates, HTTPS, automatic backups and strong passwords. Absolute security doesn't exist, but a well-built site is a far harder target.
Gian Luca Partengo
Web developer since 1995 · bespoke websites · Updated:
The first thing to understand about web security: almost no attack is personal. It's not a hacker in a hoodie with a grudge against you, but an army of bots scanning the internet day and night for sites with known flaws to exploit automatically.
Your site doesn't need to be «impregnable»: it just needs to be a more awkward target than the rest. Most attacks stop in front of a well-built site that lacks the flaws bots look for.
95%of attacks are automated: bots, not hackers interested in you specifically
43%of the web runs on WordPress: the biggest and most-scanned target
24/7bots hunt for vulnerabilities non-stop, day and night
What do you actually need to defend against?
Forget the movie scenario: the real threats are few, recurring and almost always automated.
Outdated plugins and themes
On a CMS every plugin is third-party code. A single old extension with a known flaw is the most exploited entry point of all.
Weak passwords and brute force
Attacks trying millions of combinations against the login. A weak or reused password is like leaving the key under the doormat.
Injection and unprotected forms
Unvalidated fields and forms let attackers inject commands (SQL injection, XSS) to steal data or take control of the site.
Malware and defacement
Malicious code injected to steal data, spread spam or replace your pages. It often stays hidden for weeks.
Exposed data and missing HTTPS
Without HTTPS data travels in the clear and Google flags the site as «not secure». It's the bare minimum, and today it's non-negotiable.
The attack surface: typical WordPress or custom?
Security isn't just «patching»: it's reducing opportunities. The more components a site has, the more doors there are to guard.
A custom site has no public CMS, no third-party plugins and no admin panel to defend. Less exposed code simply means fewer things that can break.
Attack surface
Exposed surface
WordPressWide
CustomMinimal
Third-party components
WordPress50+
Custom0
Urgent updates
WordPressFrequent
CustomRare
Indicative values: no site is invulnerable, but the exposed surface changes the real risk a great deal.
How do I secure the sites I build?
Security isn't a plugin you install: it's the way the site is built, from the first line of code.
No CMS, no plugins
No public panel, no third-party extensions to update. The smallest possible attack surface, by design.
HTTPS and security headers
SSL everywhere and security headers (HSTS, CSP, X-Frame-Options) that tell the browser how to protect your visitors.
Validated, bot-proof forms
Every input is checked and sanitised server-side, with anti-spam protection and no intrusive captchas. No doors left open.
Automatic backups
Regular, automatic copies of the site. If something happens — even your own mistake — you're back online in hours, not days.
Solid hosting with a firewall
A serious host with an application firewall (WAF) and monitoring blocks most attacks before they reach the site.
Updates and monitoring
With the CARE service I keep the site updated and watched over time: security is ongoing maintenance, not a one-off job.
Does absolute security exist?
I'll say it plainly, because anyone promising you a «100% unbreakable» site is lying. Against a targeted, well-funded attack no site on earth is guaranteed: not even those of large companies with dedicated security teams.
Daily backups
If the worst happens, a recent copy is the difference between a few hours' nuisance and a disaster. It's your safety net.
Monitoring
Spotting a problem quickly limits the damage. Automatic checks and alerts flag unusual behaviour right away.
Fast recovery
A custom site, with no bloated database or plugins, restores quickly from a clean copy. Fewer parts, simpler recovery.
So the realistic goal isn't invulnerability, but not being the easy target and getting back online fast if something goes wrong. That's exactly how I build: minimal surface, backups, fast recovery.
What does the wp2shell vulnerability in WordPress core teach us?
On 17 July 2026 WordPress published an emergency security update for a vulnerability chain that could lead to remote code execution before authentication. This case matters because it did not involve a plugin: it affected core and could work against a stock installation.
A real case, not a hypothetical scenario
The point is not to create alarm around WordPress, but to read the structure of the risk: when a chain starts in core, the problem appears before plugins, themes or admin panels enter the conversation.
-
01
REST API
The issue started in batch routes available before login.
-
02
SQL injection
The flaw could open unintended database queries.
-
03
Pre-auth RCE
The combination could lead to remote code execution without credentials.
This does not mean every WordPress site is insecure or that custom code is invulnerable. It means general-purpose platforms multiply the same flaw across many sites.
The lesson for a business
Security starts with architecture. A custom site does not magically remove every risk, but it can remove WordPress core, the CMS REST API, the public admin panel, themes and the plugin ecosystem. In my approach that means less shared attack surface, fewer dependencies and fewer emergency updates — alongside input validation, security headers, backups and monitoring.
Verified primary sources
-
WordPress.org — WordPress 7.0.2 Security ReleaseOpen source · new tab
Official notice covering severity, forced updates, fixed versions and CVE references.
-
Searchlight Cyber — wp2shellOpen source · new tab
Adam Kues's original research with attack conditions, affected versions and mitigations.
-
NVD — CVE-2026-63030Open source · new tab
National Vulnerability Database record for the REST API, SQL injection and Remote Code Execution chain.
Sources accessed and verified on 19 July 2026. Versions, mitigations and vulnerability status may change: always check the official advisories.
Frequently asked questions about security
The most common doubts about attacks, WordPress, HTTPS and backups.
Is my site too small to be attacked?
It's the most common mistake. Attacks don't choose victims: they're automated bots hitting anyone with a known flaw, from a personal blog to an e-commerce store. Being small doesn't make you invisible, just less prepared.
Is WordPress insecure?
WordPress itself isn't «insecure», but its popularity and heavy use of third-party plugins make it the most-hit target on the web. Most breaches come from old or poorly written plugins and themes, but core can also contain critical flaws: the July 2026 wp2shell RCE affected stock installations running versions 6.9.0–6.9.4 and 7.0.0–7.0.1.
Is a security plugin enough to protect the site?
It helps, but it's a band-aid: it adds code itself and needs updating. Real security comes from reducing what you have to protect, not from piling tools on top of an already fragile site.
What is HTTPS and do I really need it?
HTTPS encrypts data between the visitor and the site. Today it's effectively mandatory: without it, browsers show the «not secure» warning and Google penalises you. The certificate is free and should always be enabled.
How often should backups be made?
It depends how much the site changes: a weekly backup is fine for a brochure site, an e-commerce needs at least daily. The golden rule: automatic and stored off the server too.
Is a custom site unhackable?
No, and be wary of anyone who promises it. It's far harder to hit because it has a minimal attack surface — no CMS, no plugins — but absolute security doesn't exist. The goal is to reduce risk and recover fast.
What happens if my site gets hacked?
With a recent backup and a clean site you're restored in a few hours. Without backups you risk losing everything or paying for a long, costly recovery. That's why prevention and backups matter more than any «wall».
Next step
Want a site that's harder to break into?
Explore the technical standards included in custom websites: essential code, fewer dependencies, protections, backups and proportionate checks.