WordPressers kregen vrijwel direct na het uitrollen van nieuwe beveiligingspatches te maken met een WordPress update-lek waar aanvallers snel op reageerden. Volgens Defiant werd de kwetsbaarheid al binnen uren in de gaten gehouden en gericht geprobeerd te misbruiken, terwijl de aanval vooral gericht is op het updateproces van de WordPress core.
Het gaat om een raceconditie in het mechanisme waarmee WordPress bestanden uitpakt en voorbereidende stappen uitvoert tijdens core-upgrades. Hoewel de aanval complex is, kan de fout uitlopen op remote code execution (RCE): code die op de server van de bezoekende website wordt uitgevoerd.
Wat is het WordPress update-lek precies?
De kern zit in de manier waarop WordPress een volledige core-update verwerkt. Tijdens het upgradeproces worden installatiebestanden uitgepakt naar een staging-omgeving. In een deel van de gevallen ontstaat daarbij een race: aanvallers proberen precies op het juiste moment toegang te krijgen tot web-toegankelijke tussenbestanden.
Defiant beschrijft dit als een racecondition die zonder authenticatie kan worden misbruikt. Dat betekent dat een aanvaller geen gebruikersaccount op de site nodig heeft om te starten. Tegelijkertijd is de aanval niet “klik en klaar”; er zijn meerdere voorwaarden en het venster om te raken is kort.
Waarom maakt een staging-omgeving de aanval mogelijk?
Veel servers geven webbestanden terug op basis van mappen die bereikbaar zijn via HTTP. De kwetsbaarheid hangt samen met voorspelbare staging-paden die tijdens upgrades zichtbaar kunnen zijn. Defiant stelt dat WordPress nieuwe bestanden uitpakt in een directory die op veel systemen via het web benaderbaar kan zijn.
Om dit goed te begrijpen: de aanvaller heeft niet alleen de juiste update-inhoud nodig, maar ook toegang tot de staging tree op een manier die de timing van het updateproces volgt.
Welke voorwaarden noemt Defiant?
- Een volledige pakketupdate met de benodigde installerbestanden.
- Web- en PHP-toegang tot de staging-omgeving.
- Een voorspelbaar of gevonden staging-pad om de juiste locatie te benaderen.
- Voldoende tijd om de actie af te ronden voordat WordPress tijdelijke bestanden opruimt.
Hoe ziet de aanval er in de praktijk uit?
Defiant geeft aan dat aanvallers al bezig waren met pogingen om het venster te raken. Ze zouden de kwetsbare paden herhaaldelijk benaderen (“polling”) om de momenten te vinden waarop het updateproces precies lang genoeg blijft hangen om misbruik te kunnen doen.
Volgens Defiant draait het dus om timing: een aanvaller moet de zeer smalle tijdsperiode treffen waarin WordPress de core-update uitpakt.
Wat deed WordPress om het WordPress update-lek te verhelpen?
In de gepatchte versie heeft WordPress maatregelen genomen om de aanvalskansen te verkleinen. Defiant noemt specifiek dat WordPress:
- de staging-directory randomiseert, zodat paden minder voorspelbaar worden;
- een index guard toevoegt;
- voorkomt dat gestagde configuratiegegevens op een onveilige manier worden “doorgeschoven” tijdens het proces.
Welke versie moet je gebruiken?
De patch kwam beschikbaar in WordPress 7.1.4. Defiant meldt dat de kwetsbaarheid in 7.1.4 is opgelost en ook is teruggeplaatst naar eerdere onderhoudstakken (backported) via WordPress 4.7.
Daarnaast wijst Defiant erop dat WordPress 7.1.4 niet alleen deze raceconditie oplost. De release bevatte patches voor in totaal 22 beveiligingsproblemen, waaronder meerdere XSS-issues, problemen met de interactivity API, een ongeauthenticeerde informatielek en een autorisatiezwakte.
Ook werden de ingesloten root certificates geüpdatet vanwege een recente intrekking (eMudhra-revocation), wat relevant kan zijn voor TLS-trust op je omgeving.
Was er al misbruik voordat je het door had?
Ja, met name in de “vroegste” periode na patching. Defiant/Wordfence-telemetrie liet volgens het bericht actieve pogingen zien om precies de installerpaden binnen te vallen die bij de staging-fase horen.
De eerste treffers op een nieuwe firewallregel kwamen snel binnen: negen minuten na implementatie. In de eerste 21 uur werden bovendien meer dan 18.500 verzoeken geregistreerd die mikten op staged setup-config.php-gerelateerde paden.
Belangrijk detail: Wordfence meldde geen succesvolle compromissen. Dat betekent niet dat het risico nul was, maar wel dat er geen bevestigde succesvolle inbraak is gerapporteerd in de monitoring van dat moment.
Wat moet je nu doen als je WordPress draait?
Als je site WordPress gebruikt, is het antwoord praktisch: patch zo snel mogelijk. Omdat het om het updateproces zelf draait, wil je vooral voorkomen dat een upgrade in jouw omgeving nog via een kwetsbaar pad verloopt.
Concreet kun je dit aanpakken:
- Update je WordPress core naar een versie waarin de fixes zijn verwerkt (zoals 7.1.4 en backports via 4.7).
- Controleer recente logs rond installatie- en updatepaden: zie je herhaalde verzoeken naar staging/installer-locaties?
- Gebruik webapplicatiebeveiliging (WAF) of regels die passen bij de timing en padovergangen tijdens updates.
Ben je bezig met hardening en het verkleinen van aanvalsvlakken? Dan past het om ook breder te kijken naar perimeter- en firewallkeuzes. Op onze site staat bijvoorbeeld een overzicht van kritieke firewall-risico’s die je kunnen helpen om sneller te prioriteren.
Breder perspectief: waarom dit soort issues snel opdraait
Dit incident laat zien hoe aanvallen tegen software vaak niet wachten op “jouw” reactie. Defiant beschrijft immers dat dreigingsactoren al bezig waren zodra patches beschikbaar waren. Ook al is de aanval technisch veeleisend door het smalle venster, zodra een path of timing bruikbaar is, ontstaan er automatische probing-cycli.
Daarom is het niet genoeg om alleen updates te downloaden. Je hebt ook een proces nodig waarmee je updates snel doorvoert—en daarna verifieert dat je updategedrag en je infrastructuur aansluiten op de gepatchte aanpak.
Conclusie
De WordPress update-lek waar Defiant voor waarschuwt draait om een raceconditie in het core-updateproces. Zonder inlog kan een aanvaller proberen om via web-toegankelijke staging-paden precies tijdens het uitpakken een RCE te veroorzaken. De patch in WordPress 7.1.4 (en backports) maakt staging minder voorspelbaar en voegt extra guards toe.
Hoewel er in de gemonitorde periode geen succesvolle compromissen zijn gerapporteerd, is dit wel een scenario dat je snel moet uitsluiten door direct te updaten en je logs rond updates na te trekken.
Bron: https://www.securityweek.com/fresh-wordpress-vulnerability-in-attackers-crosshairs/
