Beveiligingsrelease WordPress 7.1.4: wat bureaus vandaag moeten doen

Update, 5 november 2026: Wordfence telt nu meer dan 240.000 geblokkeerde pogingen tegen dit lek sinds 28 oktober, met een piek van ruim 74.000 op 30 oktober. CISA zette CVE-2026-119977 op 2 november op de lijst Known Exploited Vulnerabilities. Wordfence noemt een geslaagde aanval in de praktijk nog steeds lastig, omdat hij alleen werkt in de seconden dat een update draait. Hun advies is hetzelfde als het onze: werk nu bij naar 7.1.4 of de backport van je versietak, en blokkeer PHP-bestanden in wp-content/upgrade/ op de webserver voordat je bijwerkt. Gratis gebruikers van Wordfence krijgen de firewallregel op 27 november. Bron: Wordfence, 5 november 2026.

Update, 31 oktober 2026: de aanvallen nemen toe. Wordfence meldt nu bijna 59.000 geblokkeerde pogingen in 24 uur tegen de tijdelijke installatiebestanden in wp-content/upgrade/ (tegen 18.500 in de eerste 21 uur). Nog steeds geen bevestigde inbraken. Staat een klantsite nog niet op 7.1.4 of de backport van zijn versietak, werk hem dan vandaag bij en sluit de upgrade-map op de server af; wacht niet tot maandag.

WordPress 7.1.4 verscheen op 28 oktober 2026 als beveiligingsrelease. Hij lost 22 kwetsbaarheden op in 17 adviezen, en dezelfde oplossingen zijn teruggezet naar elke ondersteunde versietak tot en met 4.7.39. Eén ervan is ongewoon: een lek in het updateproces van de kern zelf, waarvoor geen login nodig is. Het is lastig te misbruiken, maar aanvallers begonnen er binnen een dag naar te zoeken, en het is het enige probleem in deze release dat een firewallplugin niet kan tegenhouden. Hier lees je wat dat betekent voor de klantsites die je onderhoudt, en wat je vandaag doet.

Wat er is opgelost

• Code uitvoeren zonder login tijdens een update. Vóór 7.1.4 had de map waarin WordPress updates uitpakt, binnen wp-content/upgrade/, een voorspelbare naam, en verwijderde het opruimen de index.php die het tonen van de mapinhoud blokkeert. Een aanvaller die de paar seconden treft waarin een update draait, op een site waar die map via het web bereikbaar is, kon code uitvoeren. Patchstack beoordeelt de complexiteit van de aanval als hoog en noemt misbruik niet praktisch. Omdat de uitgepakte kopie de plugins van je site niet laadt, kan een firewallplugin op PHP-niveau dit verzoek niet blokkeren.
• Opgeslagen XSS vanaf accounts met de rol Bijdrager en hoger, vooral in de Interactivity API (7 van de 17 adviezen) en in een aantal kernblokken.
• Customizer: niet-gepubliceerde wijzigingssets konden worden gezien door bezoekers die niet zijn ingelogd.

Wie getroffen is

Elke site op een versie onder 7.1.4 of onder de bijbehorende backport (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 enzovoort, tot en met 4.7.39). Sites op 4.6 of ouder krijgen helemaal geen oplossing. De XSS-problemen tellen het zwaarst op sites waar klanten, schrijvers of gastauteurs een account met de rol Bijdrager of hoger hebben.

Controleer een site in twee minuten

1. Versie: ga in wp-admin naar Dashboard → Updates, of voer uit wp core version. Alles onder 7.1.4 (of de backport van je versietak) heeft de update nodig.
2. Upgrade-map: open https://example.com/wp-content/upgrade/ in een privévenster. Een 403 of 404 is wat je wilt. Een bestandslijst of een lege 200-pagina betekent dat de map via het web bereikbaar is.
3. Accounts: filter bij Gebruikers op Bijdrager, Auteur en Redacteur. Verwijder de accounts die niemand gebruikt.

Wat je nu doet

1. Werk de kern bij naar 7.1.4 of de backport voor je versietak. Kleine beveiligingsreleases installeren zichzelf normaal gesproken; controleer of dat ook gebeurd is, want hosts en sommige plugins zetten automatische kernupdates uit. Zorg eerst voor een verse back-up, en controleer daarna de homepage, een formulier en het afrekenen.
2. Blokkeer webtoegang tot de upgrade-map op de webserver, niet in een plugin. Op Apache: een .htaccess bestand in wp-content/upgrade/ met Require all denied. Op nginx: location ^~ /wp-content/upgrade/ { deny all; }. WordPress schrijft via PHP nog steeds naar de map, dus updates blijven werken. Op managed hosting waar je de server niet kunt aanpassen, vraag je je host dit te doen.
3. Sites op 4.6 of ouder: plan nu de overstap naar een ondersteunde versie. Voor deze sites komt geen oplossing.

Aanvallers zoeken naar dit lek, maar er zijn geen geslaagde inbraken bevestigd, dus een bijgewerkte site met een afgesloten upgrade-map heeft door deze release alleen geen terugzetting of nieuwe sleutels nodig. Zie je wel onbekende bestanden in wp-content/upgrade/ of nieuwe beheerdersaccounts, behandel het dan als een inbraak: zet terug vanuit een back-up van vóór die bestanden verschenen en wijzig daarna wachtwoorden en salts. Onze routine voor een kwetsbaarheidsdag bevat alle stappen.

Hoe Verploy helpt

Elke update wordt gecontroleerd. Risicovolle updates worden eerst op een kopie getest. De WordPress-kern telt altijd als risicovol: hij wordt getest op een privékopie van de site voordat de live site verandert, en faalt een controle na de livegang, dan wordt de site automatisch teruggedraaid. Nachtelijke versleutelde back-ups in de EU geven je een schoon punt om naar terug te gaan, en bekende kwetsbaarheden verschijnen per site met een link naar de bron.

Bron: Patchstack, “WordPress 7.1.4 Security Release”, 28 oktober 2026, patchstack.com. Waarschuwing van Wordfence over misbruik, 29 oktober 2026, zoals gemeld door SecurityOnline; cijfer over 24 uur zoals gemeld door CyberPress, 31 oktober 2026. Gecontroleerd op 31 oktober 2026.