Site Hardening · Part 9
The advice everyone gives
Turn on automatic updates. It is the first line of almost every WordPress security checklist, and for most sites it is good advice. The most common way into a WordPress site is a known flaw in software that was never updated, and automatic updates close that door without anyone having to remember.
After this compromise, the owner turned them off — everywhere, for every site on the account.
That needs explaining, and it needs the cost stated honestly, because it is not the right choice for everyone.
Why he turned them off
His reason fits in one sentence: he did not want anything changing on his sites without his knowledge.
It sounds like a preference. It is actually a security position, and it follows directly from how this compromise was found and fought.
Every way of spotting an intrusion comes down to comparison — what the site should be, against what it is. Part 10 of the investigation series calls it a known-good baseline: a list of every file, its size and its date, taken while the site is healthy, so that “what changed?” becomes a quick question.
Automatic updates wreck that comparison. An overnight update rewrites hundreds of files at once. The next morning, every one of them differs from the baseline, and a real intrusion hidden among them looks exactly the same as the update. Plugins and themes updating on their own schedules make it worse — on a busy site, something changes almost every week.
With automatic updates off, every change on the server should be one the owner made. Anything else is a finding.
What it costs
Be honest about the other side, because it is real.
With updates off, you are the update system. When a security release comes out, nothing happens until you notice it and apply it. If you’re busy, away, or simply forget, the site sits on a known flaw that attackers are actively scanning for — which is the most common way sites get compromised in the first place.
From the case file. With every update now a deliberate job, the other sites on the account drifted behind the main one and all came due at the same time. Nothing bad came of it. It is exactly the trade, though: control over change, paid for in attention.
The cost falls hardest on sites with lots of plugins. Every plugin is another project’s release schedule to watch. That is part of why Part 8 comes first: a site with almost no plugins has almost nothing to track.
How to do manual updates safely
If you choose control, make it a routine rather than a good intention.
- Subscribe to release announcements for WordPress itself and for anything you run. Security releases are announced; the only question is whether you hear.
- Treat security releases differently from feature releases. Features can wait for a convenient day. Security fixes get applied within days, not months.
- Update deliberately, one site at a time, and check the site afterwards — the live pages, not the success message.
- Take a fresh baseline straight after. The update is now the known-good state, and anything that changes after it is a question again. The owner uses a small hashing program for this: dropped into a folder, it records a fingerprint of every file in it. Change a single byte and that file’s fingerprint changes. It goes onto the server, runs, and comes straight back off — it is never left there.
- Update from the official source. Never from a copy you happen to have, and never a “free” version of a paid plugin from somewhere else.
Done this way, an update does something useful beyond fixing bugs: it replaces core files with known-good copies from the source. Replace, don’t inspect is the cleanup principle; a careful update is the same principle on a schedule.
Which choice is right for you
Leave automatic updates on if nobody will reliably watch for security releases, if the site runs many plugins, or if it is looked after occasionally rather than regularly. A site that updates itself is far safer than one that waits for an owner who never comes.
Turn them off only if you will genuinely do the work: watch releases, apply security fixes quickly, check the site afterwards, and keep a baseline you actually compare against. Without that last part, you have taken the risk and gained nothing for it.
Either way, decide on purpose. The worst position is the common one — updates half on, half off, and nobody sure which.
An out-of-date site and a compromised one can look the same from the outside. A recovery review compares what is on the server with what should be.
Start a Recovery ReviewPaid assessment · scope agreed up front
Back: Fewer Moving Parts: Running WordPress With Almost No Plugins
Next: Hardening You Can Verify: Reading Your Logs Every Day
Hub: Site Hardening Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.