Bij dreiging en patchvertraging in 2026 draait het niet alleen om wat er al misbruikbaar is, maar ook om wat er gebeurt tijdens het patchproces. Volgens onderzoek van Picus Security kan een deel van de getroffen WordPress-sites nog worden aangevallen op het moment dat de fix wordt geïnstalleerd van een actief uitgebuite kwetsbaarheid.
De kwetsbaarheid heet CVE-2026-119977 en raakt WordPress 4.7 t/m 7.1.3. WordPress bracht de oplossing uit in versie 7.1.4 en ook in passende updates voor oudere branches. Toch is er volgens de onderzoeker één extra stap nodig om de kans op een aanval tijdens het updaten te verkleinen.
Waarom een WordPress-fix niet meteen “safe” voelt
De kern van het probleem zit in de manier waarop WordPress updates installeert. Tijdens een core-update pakt WordPress een nieuwe versie uit in een tijdelijke map onder wp-content/upgrade. Die tijdelijke kopie bevat ook installatieregels en bestanden die door de webserver bereikt kunnen worden.
De onderzoeker legt uit dat de update die de fix installeert, de bestanden eerst uitpakt met behulp van de oude, nog niet gerepareerde code die op de site al aanwezig is. Daardoor kan een aanvaller, als hij precies op tijd toeslaat, code laten uitvoeren voordat de tijdelijke kopie wordt verwijderd.
Wie kan er worden blootgesteld (en wanneer niet)
Niet elke update-actie maakt een site even kwetsbaar. Het hangt af van het type updatepakket dat WordPress aanbiedt en welke bestanden daarin zitten.
- Complete pakketten bevatten altijd de benodigde installer-bestanden, waardoor de tijdelijke kopie mogelijk webbereikbaar is.
- Partial pakketten zijn alleen “risicovol” als ze toevallig de installerbestanden bevatten. Als die niet in het pakket zitten, kan het scenario niet tot uitvoering leiden.
De onderzoeker merkt ook op dat sites met automatische achtergrondupdates dezelfde updater-stappen volgen. Dus ook daar geldt: als het pakket de installerbestanden bevat en de map webtoegang heeft, kan de aanvalsvindster timing benutten.
De webmap die je moet afschermen: wp-content/upgrade
De eerste en meest praktische aanbeveling is om webtoegang tot /wp-content/upgrade/ te blokkeren voordat je de update uitvoert. Omdat WordPress die folder direct op schijf gebruikt, breekt een blokkade in de webserver de update volgens de onderzoeker niet.
Concreet zijn dit de voorgestelde opties:
- Nginx: voeg een regel toe die deny all afdwingt voor /wp-content/upgrade/.
- Apache: gebruik in de virtual host een <Directory>-blok met “Require all denied” voor die map.
- Alleen .htaccess mogelijk: zet boven de WordPress rewrite-regels een redirect naar 403 voor ^/wp-content/upgrade/.
Belangrijk detail: plaats niet zelf een .htaccess-bestand in wp-content/upgrade. De updater verwijdert alles in die map vóórdat hij opnieuw uitpakt, waardoor zo’n regel niet blijft staan op het moment dat je hem nodig hebt.
Sluit af met een check: controleer of een verzoek naar /wp-content/upgrade/ echt een 403-antwoord geeft.
Wat je vervolgens moet doen: update naar de vaste versies
Na het afschermen van de webtoegang kun je de fix installeren. Werk minimaal bij naar:
- WordPress 7.1.4 (voor 7.1.x)
- de beveiligde releases voor jouw branch (ook beschikbaar vanaf 4.7 t/m 7.1.3, volgens de WordPress security advisory)
Hoewel de fix de tijdelijke map een willekeurige naam geeft, blijft het upgradeproces volgens het onderzoek tijdens de installatie gebruikmaken van oude updater-logica. Daarom is juist die blokkade van wp-content/upgrade zo’n doorslaggevende “vangrail”.
Waarom een handmatige update soms veiliger aanvoelt
Naast de serverblokkeringsmaatregel noemt de onderzoeker een alternatief: een handmatige update buiten de webroot. Dat betekent grofweg:
- maak een back-up van bestanden én database
- pak de nieuwe WordPress release uit in een map die niet door de webserver wordt bediend
- kopieer de core-bestanden naar de juiste locaties zonder wp-config.php of andere vitale configuratie aan te raken
- draai daarna de database-update van WordPress
Het voordeel is dat je voorkomt dat er ooit een tijdelijk installer-pakket ontstaat in een map die bereikbaar is via HTTP/HTTPS.
Daarbij: de onderzoeker geeft aan dat WP-CLI wp core update geen “echte” omzeiling biedt. Die gebruikt dezelfde updater-stappen en pakt volgens dezelfde principes uit richting wp-content/upgrade.
Wat zegt de dreigingskant: actief misbruik en timing
De kwetsbaarheid staat op de bekende lijst van geexploiteerde kwetsbaarheden van CISA. In publicaties rond het onderwerp wordt ook beschreven dat aanvallen begonnen kort na het uitrollen van een firewall-regel, en dat de “vensters” in labtestomgevingen maar seconden duurden.
Hoewel WordPress de ernst als “laag” rateert in het eigen advies, is de praktische impact van dreiging en patchvertraging in 2026 juist dat je tijdens patching een korte, maar reële periode kunt openzetten voor misbruik—zeker als de tijdelijke map webtoegang heeft.
Controleer je site: signalen om te onderzoeken
Voor sites die na de release mogelijk nog op een getroffen versie bleven draaien, adviseert Wordfence om te zoeken naar specifieke aanwijzingen. Denk aan:
- onverwachte verzoeken naar PHP-bestanden onder wp-content/upgrade
- administratoraccounts die je niet herkent
- plugins die niemand bewust heeft geïnstalleerd
- PHP-bestanden in wp-content/upgrade die daar niet thuishoren
Zie je meerdere signalen, behandel het dan niet als “foutje”: beschouw het als incidentverkenning. Zorg er bovendien voor dat je direct naar de vaste versies gaat, nadat je de webmap van upgrade afschermt.
Praktische checklist voor je volgende WordPress-update
Als je dit vandaag moet uitvoeren, kun je het proces compact aanpakken:
- Blokkeer webtoegang tot /wp-content/upgrade/ (Nginx/Apache/.htaccess zoals hierboven).
- Test dat een bezoek resulteert in 403.
- Update naar 7.1.4 of de bij jouw branch passende fix.
- Check na de update op verdachte content of accounts.
- Voor oudere installaties: upgrade naar een ondersteunde versie, omdat oudere releases geen security updates meer ontvangen.
Door deze volgorde te volgen, verklein je het “tijdrisico” dat ontstaat tijdens de installatie van de fix—een typisch thema binnen dreiging en patchvertraging in 2026.
Meer context: patchbeheer en korte aanvalvensters
Wil je ook breder begrijpen hoe patchvertraging en exploit-kansen samenkomen, dan kan je deze artikelen helpen bij je aanpak:
