WordPress heeft een kritieke fout in de kernsoftware verholpen, waardoor een aanvaller zonder account een site een PHP-bestand kan laten laden van buiten de themamappen.
Op sommige servers kan dat nog verder gaan, waardoor de aanvaller zijn eigen code kan uitvoeren. De oplossing die op 22 september werd uitgebracht in WordPress 7.1.2, met oplossingen voor elke branch die het project nog steeds ondersteunt, terug naar 4.7, en WordPress vertelt site-eigenaren om nu te updaten.
WordPress beoordeelt de fout als kritiek, kent er een CVSS-score van 9,2 aan toe en kent er CVE-2026-87902 aan toe. Om dit te bereiken is geen account en geen actie van een ingelogde gebruiker vereist.
Elke versie van 4.7.0 tot en met 7.1.1 wordt beïnvloed. Dat omvat 7.1.1, uit de beveiligingsrelease van WordPress van 17 september, dus een site die minder dan een week geleden is bijgewerkt, heeft deze nog steeds nodig. Het is een andere fout dan de fouten die in de release zijn opgelost.
De release waarnaar moet worden bijgewerkt, is afhankelijk van de branch die u uitvoert:
|
Branch dat u beheert |
Bijwerken naar |
|---|---|
| 7.1.x | 7.1.2 |
| 7.0.x | 7.0.6 |
| 6.9.x | 6.9.9 |
| 6.8.x | 6.8.10 |
| 6.7.x | 6.7.9 |
| 6.6.x | 6.6.9 |
WordPress heeft de oplossing uit beleefdheid teruggezet naar elke oudere branch die het nog steeds ondersteunt, tot en met 4.7.37. De volledige lijst staat in de release notes.
Sites waarop automatische achtergrondupdates zijn ingeschakeld, starten de update automatisch. Anderen kunnen updaten vanaf het dashboard onder Updates, of de release downloaden van WordPress.org. WordPress biedt geen aparte oplossing, dus updaten is de oplossing.
Het laden van een lokaal PHP-bestand voert uit wat dat bestand al doet. Om dat om te zetten in code naar keuze van de aanvaller is een tweede voorwaarde vereist: de server moet al een PHP-bestand hebben dat iets nuttigs doet wanneer het wordt geladen. Dat zijn de ‘sommige servers’ in de beschrijving van WordPress, en daarom betekent de fout niet dat volledige code wordt uitgevoerd op elke getroffen site.
Het probleem zit hem in de manier waarop WordPress het sjabloonbestand voor een pagina kiest. Een van de bestandsnamen die het bouwt, is afkomstig van een deel van het webadres, en op de getroffen versies heeft WordPress die waarde niet uitgevoerd via zijn eigen controle op ../ traversal-stappen, waarbij de aangrenzende code al werd gebruikt.
Omdat de naam is opgebouwd als page-{value}.php, heeft een werkende aanval ook nodig dat het actieve thema een map op het hoogste niveau heeft waarvan de naam begint met page-, en dat het doelbestand moet eindigen op .php. Bij sommige thema’s, waaronder oudere standaard WordPress-thema’s, wordt een map geleverd die daarin past.
Beveiligingsleverancier Patchstack zegt in zijn eigen analyse dat twee controles een site-eigenaar vertellen hoe kwetsbaar ze zijn: of het actieve thema een map op het hoogste niveau heeft waarvan de naam begint met page-, en of PHP draait met een instelling genaamd register_argc_argv ingeschakeld, waarvan een bekende code-uitvoeringstechniek afhankelijk is.
Geen van beide is een oplossing, zegt het bedrijf, maar beide laten zien hoe dicht een site bij het ergste geval is. Die instelling staat standaard uit op PHP 8.5 en standaard aan op oudere PHP-versies.
Op 22 september waren er geen meldingen dat de fout bij aanvallen werd gebruikt, geen openbare proof-of-concept-exploit en geen vermelding ervoor in de Amerikaanse CISA Known Exploited Vulnerabilities-catalogus.
WordPress heeft Robert Ressl gecrediteerd voor het vinden en rapporteren van de fout. The Hacker News heeft contact opgenomen met WordPress en Ressl voor commentaar.
