WordPress 7.1.4: lek in het updateproces laat aanvallers code uitvoeren, aanvallen al gemeld

WordPress heeft op woensdag 28 oktober 2026 versie 7.1.4 uitgebracht. Die update dicht een ernstig lek in het updateproces zelf. Een aanvaller zonder account kan daarmee eigen code op uw webserver uitvoeren. Al binnen een paar uur na de release zagen beveiligingsbedrijven de eerste aanvallen.

Het lijkt een vreemde situatie: juist tijdens het bijwerken van WordPress loopt uw site risico. Toch is bijwerken naar 7.1.4 de enige echte oplossing. In dit artikel leest u hoe het lek werkt, of uw site gevaar loopt en wat u nu moet doen.

In het kort

Wat: een lek in het updateproces van WordPress Core, waardoor een aanvaller op afstand code kan uitvoeren (remote code execution)
Geraakt: WordPress 4.7 tot en met 7.1.3
Oplossing: bijwerken naar WordPress 7.1.4 (uitgebracht op 28 oktober 2026)
Ernst: CVSS-score 8.1 (hoog). Er is (nog) geen CVE-nummer
Aanvallen: Wordfence blokkeerde in de eerste 24 uur bijna 63.000 pogingen
Extra: dezelfde update lost nog 21 andere beveiligingsproblemen op

Hoe werkt het lek?

Bij een volledige update van WordPress Core (een zogeheten full-package update) pakt WordPress de nieuwe bestanden eerst uit in een tijdelijke map. Tot en met versie 7.1.3 was die map voorspelbaar en vaak gewoon via internet bereikbaar. Tussen de uitgepakte bestanden zit ook de installer van WordPress.

Een aanvaller die precies op het juiste moment die installer aanroept, kan zo zijn eigen code op de server laten uitvoeren. Dat werkt alleen als de server PHP-bestanden in die tijdelijke map uitvoert, en dat is bij veel hostingpakketten de standaard.

Het tijdsvenster is erg klein: alleen de paar seconden waarin de update wordt uitgepakt. Dat houdt aanvallers niet tegen. Volgens Wordfence riepen aanvallers bij een aantal websites ruim veertien uur lang onafgebroken de installer aan, in de hoop één keer raak te schieten. Omdat WordPress kleine updates vaak automatisch installeert, weten aanvallers ongeveer wanneer zo’n venster openstaat.

Wat is er aangepast in WordPress 7.1.4?

De tijdelijke updatemap krijgt nu een willekeurige naam, zodat een aanvaller hem niet meer kan raden.
Er staat een beveiligd indexbestand in de map, zodat die niet zomaar te bekijken of aan te roepen is.
WordPress neemt niet langer onveilige configuratiegegevens over uit de uitgepakte bestanden.
Daarnaast zijn 21 andere lekken gedicht, waaronder meerdere vormen van stored XSS in de Interactivity API en in een aantal blokken, en een probleem waarmee een site onbereikbaar kon worden gemaakt (denial of service).

Wat moet u nu doen?

1. Controleer of uw site echt op 7.1.4 staat

Ga in WordPress naar Dashboard → Updates. Daar ziet u welke versie u draait. Veel sites krijgen deze beveiligingsupdate automatisch, maar ga daar niet blind van uit. Automatische updates mislukken regelmatig, bijvoorbeeld door verkeerde bestandsrechten of te weinig schijfruimte. Staat er nog 7.1.3 of ouder? Werk dan direct bij.

2. Werk bij op een rustig moment

Het risico zit in het bijwerken naar 7.1.4 zelf, want dan draait de oude, kwetsbare updatecode nog. Doe de update daarom liefst op een rustig moment, en niet terwijl uw site al de hele dag wordt bestookt. Heeft u een beveiligingsplugin met firewall, zoals Wordfence Premium? Die blokkeert deze aanval al. Gebruikers van de gratis versie van Wordfence krijgen die bescherming pas op 27 november 2026.

3. Blokkeer extra de tijdelijke updatemap

WordPress gebruikt de map wp-content/upgrade voor tijdelijke updatebestanden. Bezoekers hoeven daar nooit bij te kunnen, en WordPress zelf werkt rechtstreeks met de bestanden op de server, niet via internet. U kunt die map dus veilig afsluiten. Bij een Apache-server zet u deze regel bovenaan het bestand .htaccess in de hoofdmap van uw website:

RedirectMatch 403 ^/wp-content/upgrade/

Zet de regel niet in een .htaccess ín de map wp-content/upgrade zelf: WordPress maakt die map bij elke update leeg, en dan verdwijnt uw regel ook.

Gebruikt uw server alleen nginx? Voeg dan dit toe aan de serverconfiguratie:

location ^~ /wp-content/upgrade/ { deny all; }

Deze maatregel vervangt de update niet, maar sluit dit soort aanvallen ook in de toekomst grotendeels uit.

4. Controleer of u al getroffen bent

Kijk of er onbekende beheerders in WordPress staan (Gebruikers → Alle gebruikers, filter op Beheerder).
Zoek naar nieuwe of gewijzigde PHP-bestanden van de afgelopen dagen, vooral in wp-content/upgrade en wp-content/uploads.
Laat een beveiligingsplugin de WordPress-kernbestanden vergelijken met de officiële versie. Wordfence doet dat bij een standaard scan. Met WP-CLI kan het ook: wp core verify-checksums.
Let op een server die ineens veel trager of zwaarder belast is. Dat kan wijzen op een cryptominer.

Wilt u snel een eerste indruk van uw site? Gebruik onze gratis WordPress Security Scanner. Die ziet onder meer welke WordPress-versie uw site naar buiten toe laat zien.

Het derde Core-lek in korte tijd

Meestal zitten WordPress-lekken in een plugin of thema. Dit keer zit het in WordPress zelf, en het is niet de eerste keer dit jaar. In juli werd de wp2shell-aanvalsketen gedicht in versie 7.0.2, en in september volgden twee kritieke lekken in 7.1.1 en 7.1.2. De les blijft dezelfde: een WordPress-site is nooit “af”. Updates, back-ups en een firewall zijn geen luxe, maar basisonderhoud.

Hoe zit het bij onze klanten?

Alle WordPress-sites die wij in onderhoud hebben, draaien inmiddels op WordPress 7.1.4. Elke nacht controleren wij automatisch op updates. Daarnaast hebben we de kernbestanden van elke site vergeleken met de officiële versie en de tijdelijke updatemap afgeschermd. U hoeft als klant dus niets te doen.

Geen klant, maar wilt u dit soort zorgen niet meer zelf dragen? Neem contact met ons op. Wij nemen het onderhoud en de beveiliging van uw WordPress-site graag van u over.

Bronnen

📬

Meer WordPress-tips in uw inbox? Wekelijkse nieuwsbrief — geen spam, altijd afmeldbaar.