Flora and Fauna: The Rot Under Italian Websites

I've spent the last month looking closely at Italian websites, and I can't stop seeing the same shape. It doesn't matter if the invoice was €50,000 or €5,000. The rot underneath is the same rot. Different species of the same organism.

So I want to write down what I've been seeing, without naming anyone, because the problem isn't any specific company. The problem is structural.

The Expensive Tier

Picture a company that pays an agency €50,000 to build a website. It's a real business — clients, invoices, real email flowing through real accounts. They want a professional presence, and €50k is, by any reasonable measure, a professional budget.

The agency delivers a WordPress site on shared hosting. Elementor for the builder, a premium theme, a stack of plugins. All the versions are current — I'll give them that. The agency is not stupid. They know how to click "Install" and "Update."

What they did not do:

Turn off XML-RPC, which has been the default credential-attack vector on WordPress for a decade
Restrict /wp-json/wp/v2/users, which by default leaks every username and the admin's email address to anyone who opens a browser tab
Install a login rate limiter
Add multi-factor authentication on the admin account
Put any WAF in front of the site
Set a single security header — no HSTS, no CSP, nothing

None of this requires probing. A WordPress instance with XML-RPC enabled and system.multicall exposed turns a single HTTP request into up to a thousand credential guesses. Combined with an open user-enumeration endpoint, that means an attacker gets both the target list and the machinery to attack it, from an unauthenticated browser, in two GET requests. No rate limit means no ceiling on attempts. No MFA means no second line. It's the kind of misconfiguration that moves a site from "probably fine" to "compromised whenever someone decides to" in a single weekend.

For €50,000, the site was shipped as a default hosting-provider install with a theme painted on top. No hardening. None.

The reflex response from agencies whose work gets flagged is usually "we're not vulnerable." They believe it, because in their mental model "vulnerable" means "has a CVE." The idea that shipping with the front door unlocked is a vulnerability in itself — that one doesn't land.

The Cheaper Tier

Now picture a marketing agency that builds WordPress sites for small businesses — opticians, padel clubs, small manufacturers, medical offices. Invoices in the €5k–€15k range. Lower ceiling, lower floor.

If you look at a handful of sites from one such agency's portfolio using nothing but each site's homepage HTML and publicly-available DNS data — zero active probing, no login attempts, no touching anything — the patterns emerge immediately. You don't need any special access. You just need to View Source.

Across that kind of sample, you typically see:

Full plugin versions voluntarily disclosed in the page source, via the default <meta name="generator"> tag and asset URLs like ?ver=3.11.3
Plugins between one and three years behind current
No DMARC enforcement, meaning any random person on the internet can send email as @theircompany.com
No HSTS

It's common to find page builders running with known, published, exploitable CVEs. Core and plugin stacks frozen two or three years ago. Page builders from 2021 sitting on PHP runtimes that reached end-of-life in 2022.

These sites aren't "hacked," in the sense that nothing has obviously broken. But they're sitting with unlocked doors on a public street, and the only reason nothing has happened is that nobody important-enough has tried. That's not a security posture. That's luck.

The Pattern

The interesting thing isn't any individual site. It's that the shape is identical across the price range.

The pattern goes like this: a small or mid-sized Italian business decides they need a website, or a redesign. They go to a marketing agency — because marketing agencies are who they already know, and because the pitch is framed around brand and aesthetics and online presence, not infrastructure.

The marketing agency does not build the site. They subcontract it to a freelancer, or a junior developer on retainer, or an offshore shop. That person installs WordPress, picks a theme from ThemeForest or uses Elementor, clicks through the plugins the client asked for (multilingual, SEO, contact form, cookie banner), fills in the copy, and ships.

Nobody in that chain owns what happens after launch.

The marketing agency considers the job done when the client signs off on the design. The subcontractor was paid for delivery, not maintenance. The hosting provider's terms say security is the customer's responsibility. And the customer — the optician, the padel club, the medical office — has no idea any of these seams exist. They think they bought a finished product. They actually bought a snapshot that degrades into a liability the moment it's deployed.

Months pass. Plugins rot. Vulnerabilities publish. The site keeps serving pages. Nothing visibly breaks, so nothing gets fixed. The client gets the occasional alarming email from a security plugin and forwards it through three or four people — the marketing agency, the subcontractor, a cousin who "knows about computers" — each of whom says "ask whoever handles the site." Nobody does.

A typical alert chain goes through four or five separate middlemen, each one punting, none of them actually looking at the site. The plugin generating the alert is years out of date. The person who originally installed it moved on two jobs ago.

Why This Happens

Three things.

One: role confusion. Marketing agencies sell websites. Websites run on infrastructure. Infrastructure requires operational discipline. Marketing agencies do not have operational discipline, because they are marketing agencies. They are graphic designers and copywriters who learned enough WordPress to charge five figures. The people buying don't know to ask about the difference, because the pitch never surfaces it.

Two: no maintenance contract means no maintenance. Standard practice in every other industry — you pay for the thing, you pay a smaller ongoing fee to keep it working — has not made it into the Italian SME web market. It's treated as an optional upsell, usually declined. And the agency has no incentive to push, because once the site is shipped and the final invoice is paid, there's nothing left to fight for.

Three: Italian law punishes the people who would otherwise flag this. Article 615-ter of the Italian penal code treats virtually any probing of a system you don't own as unauthorized access. There is no equivalent of the U.S. good-faith security research carve-outs. If a researcher notices that a company's admin panel is publicly reachable and wants to tell them — legally, the safest thing to do is pretend they never noticed. Which means the only people who end up touching these sites are the original builders (who already moved on) and the attackers (who don't care about Italian law).

The result is a whole layer of the Italian economy that runs on websites nobody is watching, built by companies whose competency stops at aesthetics, hosted on infrastructure nobody has hardened, and protected by a law that keeps the good samaritans quiet.

The Specific Rot

If you want the catalog — because the catalog is always the same — here's what I keep finding:

Admin panels on default paths, publicly reachable
User enumeration endpoints returning the full user list and admin email, unauthenticated
XML-RPC enabled with system.multicall, turning a single HTTP request into a thousand password guesses
No MFA on any admin account
No login rate limiter, no CAPTCHA, no lockout plugin
Plugin and core versions disclosed in page source
End-of-life PHP runtimes in production
Zero security headers
Staging metadata shipped to production (one site's <title> literally said "Sito Staging")
Default admin usernames
DMARC set to p=none so anyone can spoof the company's email
SPF records that authorize entire /24 subnets to send mail as the domain
cPanel and webmail subdomains leaked into certificate transparency logs
Web servers on shared VPS tenancy with RDP and SMB exposed on the same IP

None of these require a zero-day. None of them require skill. They require someone who cared enough, at launch, to spend two hours doing the basics.

Nobody did. And the reason nobody did is that it's not in anyone's job description.

Why 2026 Is Different

Two forces are compressing the same timer from opposite sides.

The cost of finding flaws has collapsed. What used to require a boutique security firm, two weeks, and a five-figure engagement letter is now something an agent can do in an evening, for the cost of a few API calls. Passive fingerprinting, CVE correlation against public databases, structured remediation write-ups — the deliverables that justified five-figure invoices a year ago are collapsing into overnight output. The economic floor that protected badly-built sites is gone. Any operator who wants a list of targets can generate one in a weekend. Any competitor who wants leverage can commission an audit.

The cost of exploiting them has collapsed too. WordPress publishes thousands of new vulnerabilities every year, and that number keeps climbing. The gap between a CVE going public and automated exploitation scripts showing up in the wild is now measured in hours, not weeks. That reframes the whole maintenance conversation: even a diligent agency doing monthly patching — which is already more than most do — is operating on a cadence that's obsolete against modern threat velocity. Monthly retainers were designed for a world where a serious vuln landed every few weeks and the internet took a month to notice. That world is gone.

Which means the honest conclusion is uncomfortable: the core problem isn't just that Italian agencies don't harden or don't maintain. It's that the stack they're selling — WordPress, a theme, a dozen plugins, shared hosting — is architecturally fragile in a way that now requires enterprise-grade automated defenses to survive. Small businesses were sold infrastructure that doesn't match their risk profile or their budget. The pitch was always "you get a website"; the reality is "you get an attack surface that needs a real security operation behind it." Nobody sold it that way.

Every website in that catalog of rot is running on a timer. The timer has been there for years, but what's changed is how fast it counts down. Every month, the cost of scanning drops. Every month, the pool of people who can exploit grows. Every month, more vulnerabilities publish against the same aging installs. "Nobody's bothered yet" is not a security strategy. It's a countdown.

And the agencies shipping these sites — the ones still selling default WordPress builds in 2026 as if nothing about the threat landscape has changed — are building a portfolio of liabilities that will, eventually and inevitably, be called in.

What Should Change

Three things, in roughly this order of importance:

Maintenance has to be the default, not the upsell. A website that is not being maintained is not a website; it's a ticking clock. If an agency doesn't want to own maintenance, fine — they should say so loudly, in the contract, in plain Italian, and refer the client to someone who does. The silent assumption that "we'll update it if something breaks" is the whole problem.

Hardening is not optional, and neither is honest architecture. The list above — rate limit, MFA, no XML-RPC, no user enumeration, a WAF, basic headers — is not an advanced package. It's the transition from "installed" to "production-ready." Charging €50,000 for a site without it is professional malpractice, and charging €5,000 is not an excuse to do less. But hardening alone isn't enough anymore either. If you're going to sell a WordPress site to a small business in 2026, you have to be honest about what comes with it: an attack surface that now requires automated patching, managed WAF, continuous monitoring — or a simpler architecture (a static site, a hosted platform, something with a much smaller blast radius) that actually fits the client's risk and budget. Pretending otherwise is selling a car without brakes and calling it efficient.

The law needs to catch up to reality. As long as Italian law treats any security research as criminal, the only people who'll ever audit these sites are the ones who don't need permission because they don't plan to tell you what they found. The politicians writing these laws are not engineers. They don't know the difference between a white-hat researcher and somebody who encrypts your server and asks for Bitcoin. Until that changes, we lose.

I don't think any of this is particularly radical. Every person reading this who works in security already knows it. What I'm writing here is a description, not a discovery.

But if you're a business owner reading this, and you paid an agency for a website, and you haven't thought about any of this in two years — ask whoever built it whether XML-RPC is disabled, whether your user list is reachable unauthenticated, whether there's MFA on the admin account, and who's responsible for updating plugins this month. If nobody has a clean answer, you have your answer. The rest is downstream of that first question.

The flora and fauna of Italian websites is beautiful, varied, and quietly dying. The least we can do is notice.