Security.Launches 18 Aug 2026

Every plugin, theme and the core version, with the exact version string.

The published advisories, matched on slug and version range.

A vulnerability in a feature the site does not use is not the same as one in the checkout. It says which.

Ordered by exploitability and by what the affected page does for the business.

It tells you. It does not update, deactivate or edit anything. Remediation is a separate action you approve.

Anything writable that should not be, and the config file above all.

Backups, database dumps, logs and editor swap files sitting in the web root.

Whether the two most brute-forced endpoints on the internet are open and unlimited.

Whether the REST API and author archives hand out account names to anybody who asks.

What is present, what is missing, and what each missing one actually allows.

It observes. It writes nothing, anywhere.

Files and database, before any header or permission changes.

The dashboard editor turns one stolen password into full code execution.

Unless something on the site is genuinely using it, which it checks first.

The REST author endpoint and the author archive redirect.

One at a time, because a wrong content policy takes a site down.

To what WordPress documents, not to what is most restrictive.

Load the critical pages after every change. Anything that breaks goes back immediately.

Every core, plugin and theme file compared against what it should be.

Suspicious files are moved somewhere they cannot execute, and kept.

Injected code out of legitimate files, with the original kept beside it.

A clean that does not find the entry point is a clean you do again next week.

Not clean means not finished. It says so rather than declaring victory.

What was found, when it arrived, what it did, and what has changed. Written for the client.

If a security plugin already limits attempts it reports the current setting and exits, rather than adding a second limiter that fights the first.

Failed attempts over the last week, the addresses behind them, and which account names are being guessed.

Every setting it is about to change, by value, before it changes one.

A count, a lockout window, and a longer window for repeat offenders. Set high enough that a real person mistyping twice is unaffected.

Your addresses are allowed through before the limit turns on, so the lockout cannot lock out the agency.

The configuration returns to what step three recorded, and the limit stops applying immediately.

Confirm a correct sign in still works, and that a deliberate run of wrong passwords from a test address gets stopped where it should.

Every administrator and editor, and whether any of them already carry a second factor. If they all do, it exits here.

Who holds what today, so the rollout can be reversed to a real state rather than a default.

Editors and below are left alone at first, because the account worth stealing is the one that can install code.

They can still sign in while they enrol. A hard cut off locks out a client on a Monday morning and ends the conversation.

Each administrator, whether they have set it up, and how many days are left. It cannot enrol anybody on their behalf, because only they hold the device.

The policy returns to what step two recorded and everyone signs in exactly as they did before.

The requirement becomes mandatory only once every administrator has enrolled, so nobody is locked out on the day it lands.

Every directory and file that matters, with its current mode and its owner.

Not against the most restrictive setting possible, which breaks updates, uploads and the media library.

If nothing is writable that should not be, it reports and changes nothing.

So each file goes back to the exact number it had, rather than to a general default that was never true here.

The configuration file, then anything world writable, then the rest. One at a time, with the site checked after each.

Every mode step four recorded is restored in one action.

A permission change that hardens the site and stops the media library is not a fix, it is a different outage.

Including the locale, because the file list differs between them and a mismatch there produces false alarms.

WordPress publishes a hash for every file it ships. This compares against that list, not against a general idea of what should be there.

Changed, missing, and files sitting in a core directory that WordPress never shipped at all.

Hosts add files legitimately. It says which differences have a known innocent explanation and which have none.

It compares and lists. It replaces no file and deletes nothing, because cleaning up before the investigation destroys the evidence of how they got in.

Every plugin, its exact version, and whether it came from the WordPress directory.

The directory publishes a hash per file per version. Each installed file is checked against its own version, never against the newest one.

A paid plugin publishes no hashes, so it cannot be verified this way. Those are listed separately rather than passed silently as clean.

The file, the size of the change, and whether it reads like a customisation somebody made or like code that was added from outside.

It reads and compares. It restores no file, because overwriting a deliberate customisation is its own outage.

Every plugin, its version, and the date of the last release the author published.

Last update, the WordPress version it claims to be tested against, and whether the support forum is being answered.

An abandoned plugin that formats a date is not the same problem as an abandoned form handler that accepts uploads.

For each one, the maintained plugin that does the same job, and honestly what the switch would cost you in work.

It reads and recommends. It deactivates and removes nothing.

One request per installed plugin against the directory. A plugin page that has gone is the signal.

A plugin that changed its slug has not been pulled. Treating the two the same is how you frighten a client for nothing.

The directory states a reason when it closes a plugin, and a guideline violation and a security issue are very different news.

No more updates through the normal channel, which means the version installed today is the last version there will ever be.

A pulled plugin that handles logins, payments or uploads goes to the top of the list.

It watches the directory. It deactivates and removes nothing.

The REST users route, the author archive, the feeds, the sitemap and the login error message. If all five are already closed it exits here.

A headless front end or a plugin that reads the author route breaks if it is closed blindly, so it looks before it closes.

The exact response from all five, so the change can be judged afterwards and reversed to a known state.

The REST route for signed out visitors, the author archive redirect, the author name in the feed, the sitemap entries, then the login error that tells a stranger which half was right.

It is one small file. Removing it puts all five back to how they answer today, and signed in editors keep full access throughout.

Request all five again from our network, signed out, and confirm none of them returns an account name.

Two weeks of requests, split by which method was called and what made the call. If it is genuinely in daily use it says so and does not close it.

The multicall method is what turns one request into a thousand password attempts. Publishing a post from a phone is not the same thing at all.

Which methods answer today, so the reversal is exact.

The part that makes brute force cheap goes, and the mobile app keeps working.

Based on the fortnight of real traffic from step one, not on a general rule about what sites usually need.

One action restores the endpoint exactly as it answers today.

Confirm the endpoint refuses the methods you closed and still answers the ones you kept, then watch the request log for a week for anything that started failing.

Core, and every route each plugin has registered, with the methods each one accepts.

Signed out, from our network, exactly as a stranger would ask.

The route, the status, and the kind of data in the response. Names, email addresses, order numbers and unpublished content are called out by name.

A public route the site's own front end depends on is meant to answer. A plugin route handing back form submissions is not.

Which capability check the route is missing, written so you can send it to the plugin author or apply it yourself.

It asks and records. It blocks no route, because blocking one the front end uses takes the site down in a way nobody connects to a security change.

Every header on the homepage, an admin page and a form page. If they are all present and correctly set it exits here.

Not that a header is absent, but what a browser is currently permitted to do because it is absent.

The full header set today, so the before is on record and the reversal is exact.

Frame options, referrer policy and content type options. One at a time, with the pages loaded after each.

It watches for two weeks and lists what a real policy would have blocked. Nothing is enforced and nothing is broken during that time.

Every header it added is removed in one action and the response returns to the record from step three.

The policy turns on once it stops catching things the site legitimately loads, not on the day it was written.

Every account that can install code, however it came by the role.

Who created it, when, and whether there is any record of somebody asking for it.

An account created through the dashboard leaves a different trail from one written straight into the database.

A subscriber account made three years ago that became an administrator last Tuesday is the pattern worth catching.

A registration date that does not match the first sign in, an address on a domain nobody recognises, and a display name copied from somebody real.

A new administrator is reported immediately, not in the monthly summary. It removes no account, because deleting one before you know how it got there loses the trail.

Confirm the uploads folder is writable and reachable over HTTP. If either is false it exits here and writes nothing.

Note the exact path and random filename about to be created, so cleanup is precise rather than a guess.

A file with a random name that does nothing but print a random token. It is never linked and it exists for seconds.

If the token comes back, the server executed it. If the source comes back, the folder is serving files as text, which is what it should do.

Runs whether the test passed, failed or errored, and says so loudly if the file could not be removed.

If PHP ran, any plugin that lets a visitor upload a file is a way to run code on the server, and the fix is a server rule rather than a plugin setting.