The WordPress vulnerability that opens when you click Update. Attackers sent 240,000 requests to catch the moment.

01 What the flaw does, in plain terms

The problem is what sits in that folder during those seconds. A full WordPress package includes setup-config.php, the wizard that asks for database details on a brand-new install. The staged copy looks for a configuration file in the wrong places, decides the site has never been set up, and offers to set it up [ Picus 2026 ] . Before 7.1.4 the folder name was predictable. On many servers it could also be listed in a browser, because the clean-up step deleted the blank index.php that normally hides the contents [ Patchstack 2026 ] .

Umut Bayram, who reported the bug, describes the full attack. The attacker gives the staged installer the details of a database they control. The installer writes a new wp-config.php. The update then copies that file over your real one. Your site now reads from the attacker’s database, where they create the first administrator and upload a plugin that runs their code [ Picus 2026 ] . No password, no click from you. Your content stays where it was, but your site stops using it.

Experts disagree on how practical the attack is. Patchstack’s Dave Jong says he “would not call it practical to exploit”, because the attacker has to request the right path at the exact moment an update runs. He also notes it is the only bug in the release that needs no account [ Patchstack 2026 ] . Attackers only need it to be cheap, and polling a URL every few seconds costs almost nothing.

02 Ten days from fix to federal deadline

The attacks started on the day of the fix. Wordfence counts more than 240,000 blocked attempts across the sites it protects, most of them automated requests for addresses such as /wp-content/upgrade/wordpress-6.9.11/setup-config.php [ Wordfence, Nov ] . Three addresses sent nearly 150,000 of them between them. Two of the busiest sources polled the same small groups of sites for about 14.5 hours, waiting for one of them to update [ Wordfence, 28 Oct ] .

Read those figures for what they are: blocked requests, logged by one vendor. They show how hard attackers are trying. They do not count break-ins, and we have not found a public report that names a site taken over this way. CISA lists the flaw as exploited and asks agencies for forensic triage as well as the patch [ CISA KEV ] .

03 Did auto-updates protect you?

Mostly, with one catch. WordPress installs minor security releases in the background by default, and Wordfence says sites with background updates on should already be patched [ Wordfence, Nov ] . From 7.1.4 onwards the working folder gets a 16-character random name, the blank index.php stays in place, and a staged wp-config.php can no longer be copied over the live one [ Patchstack 2026 ] .

The catch is the update that brought the fix. It was performed by the old, flawed updater. Wordfence and the researcher both make this point: moving from a vulnerable version to a fixed one runs the vulnerable process one last time [ Picus 2026 ] . Patchstack adds that the window opens on every update, “including unattended ones” [ Patchstack 2026 ] . So if your site auto-updated on the evening of 28 October, while attackers were already polling, it was exposed for a few seconds.

One detail affects how likely the window was to open. The researcher says full update packages carry the installer, while smaller “partial” packages carry it only if those files happen to be included [ Picus 2026 ] . You cannot easily tell after the fact which one your site downloaded. Your logs can tell you whether anyone came knocking.

04 How to check whether you were hit

Start with the time your site moved to the fixed version. The file wp-includes/version.php changes during every core update, so its modification date is a good marker. Then work through this list, or hand it to your host or developer. If the site takes logins or payments, a website penetration test shows what an attacker can still reach after the patch.

A clean log does not prove a clean site. Wordfence says so directly [ Wordfence, Nov ] , and some hosting plans keep access logs for only a few days. If your logs from late October are already gone, the wp-config.php and administrator checks matter most.

05 Close the window before the next update

Updating to 7.1.4 fixes this bug. One server rule removes the whole class of problem: nobody on the internet needs to reach /wp-content/upgrade/. WordPress uses that folder internally and never sends visitors there. Patchstack and Wordfence both advise blocking it at the web server [ Patchstack 2026 ] .

• nginx. Add location ^~ /wp-content/upgrade/ { deny all; } to the site’s server block and reload nginx.
• Apache. In the .htaccess at the site root, add RewriteRule ^wp-content/upgrade/ - [F,L] above the WordPress rules, with RewriteEngine On. Do not put an .htaccess inside the upgrade folder itself. The unpatched updater deletes it [ Picus 2026 ] .
• Test it. Request https://yoursite/wp-content/upgrade/ in a browser. You want a 403 or 404, never a file listing.
• Turn off directory listing everywhere. A listable folder handed attackers the folder name before 7.1.4. Set Options -Indexes on Apache, and make sure autoindex is off on nginx.

Security plugins have a blind spot here. The staged installer runs from its own files and never loads your WordPress, so a firewall plugin that runs inside WordPress does not see the request [ Patchstack 2026 ] . Wordfence’s firewall catches it only in its Extended Protection mode, and free users receive the rule on 27 November [ Wordfence, Nov ] . The server rule above works today and costs nothing.

Keep auto-updates on for core security releases. The risk this bug exposed is real, but a site that waits a week to update spends that week fully exposed to whatever the release fixed. WordPress 7.1.4 alone fixed a long list of other flaws, from stored cross-site scripting to unpublished Customizer drafts that strangers could read [ WordPress.org 2026 ] .

06 If you run fifty sites, not one

Agencies and managed service providers face the same bug at a larger scale, and with one extra problem. Attackers polled small groups of sites for hours. A fleet that updates on a schedule, all at once, gives them a predictable minute to aim at. Three steps make the next one of these routine. MSPs that want the testing done under their own brand can use our white-label partner programme.

• Know every site and its version. Keep one list of every WordPress install you manage, with its version and who can update it. Include the client sites you built years ago and no longer bill for.
• Ship the block once. Put the /wp-content/upgrade/ rule in your server template or your host’s control panel, so every new site starts with it.
• Check the logs fleet-wide. Run the access-log search from chapter 4 across every site for 28 October onwards. One grep across a log store is faster than fifty logins.

An attacker needs one site you forgot to update and the right ten seconds. You can find that site first. Your free external exposure audit shows every website under your name that answers on the internet, which WordPress version each one runs, and whether its upgrade folder, admin login and installer files can be reached from outside. You get the list ranked by what to fix first. Get your free audit.