PHP-beveiligingsupdate: eerst patchen, daarna geheimen en toegang controleren

Op 21 oktober 2026 bracht PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit voor CVE-2026-109618 en CVE-2026-109619. Deze kritieke kwetsbaarheden kunnen code-uitvoering op afstand zonder aanmelding mogelijk maken. De officiële aankondiging noemt installaties die webverzoeken verwerken als risicogroep, waaronder PHP-FPM en Apache mod_php. Updaten is de volledige oplossing; tijdelijke maatregelen zijn niet gelijkwaardig.

Een kwetsbare installatie bewijst geen inbraak. Behandel patchen, onderzoek en herstel van toegangsgegevens als samenhangende taken en beslis op basis van je omgeving en het bewijs.

Controleer wat de verzoeken echt verwerkt

Inventariseer openbare websites, interne diensten, containers en hostingaccounts met PHP. Bevestig versie en patchstatus van de runtime voor webverzoeken; de opdrachtregelversie kan bij een andere installatie horen.

Vraag bij beheerde hosting om bevestiging van het toegepaste pakket, de betrokken dienst en de herstart of uitrol. Distributies kunnen oplossingen terugporteren. Vraag daarom om hun bevestiging in plaats van alleen naar het upstream-versienummer te kijken. Bepaal samen met de beheerder het bereik aan de hand van de PHP-beveiligingsadviezen. Publiceer geen diagnosepagina met serverconfiguratie.

Beperk blootstelling en herstel een betrouwbare omgeving

Stem de update snel af met hosting of het operationele team. Beperk blootstelling of isoleer systemen als de incidentbeoordeling dat vraagt, terwijl je relevant bewijs bewaart. Stel dringende indamming niet uit om eerst alle logs te verzamelen.

Controleer de blootstellingsperiode, web- en systeemlogs, onverwachte bestanden of processen en relevante auditgebeurtenissen bij providers. Geen waarschuwingen of normaal ogende logs bewijzen niet dat de host onaangetast is.

Is een inbraak vastgesteld of redelijkerwijs vermoed, volg dan je incidentprocedure om vanuit betrouwbare bron te herbouwen of herstellen. Een patch verwijdert de blijvende toegang van een aanvaller niet. Genereer, ontvang of installeer vervangende geheimen niet op een onbetrouwbare host of een onbetrouwbaar apparaat.

Beoordeel toegangsgegevens vóór rotatie

Maak een lijst van wat het getroffen proces kon lezen: applicatieconfiguratie, omgevingsvariabelen, deploymenttokens, databasegegevens en API-sleutels. Bepaal rechten, bereik en mogelijke blootstelling. De aankondiging bewijst niet dat alle toegangsgegevens in de organisatie zijn gelekt.

Coördineer voor mogelijk blootgestelde gegevens vervanging en intrekking bij de uitgever vanaf een betrouwbaar beheerapparaat. Installeer vervangingen in de betrouwbare herbouwde omgeving en verifieer legitieme integraties. Bepaal de volgorde volgens actief misbruik, providerfuncties en afhankelijkheden. Beloof geen ononderbroken dienst en laat een blootgestelde sleutel niet uit gemak onbeperkt actief.

Controleer zo nodig sessies en hersteltoegang en leg per wijziging de verantwoordelijke vast. Zet nooit ruwe geheimen in een incidentticket of log. OWASP

Beëindig noodtoegang na het werk

Geef hulpverleners individuele accounts met beperkte rechten en een afgesproken eindtijd. Controleer na herstel tijdelijke rollen, sessies, deploymenttoegang en overdrachtslinks. Verwijder onnodig behouden rechten en bevestig het resultaat in de betreffende dienst, niet alleen met een kalenderherinnering.

Houd drie controles uit elkaar

Draag pas tijdelijk over nadat vertrouwen is hersteld

Als je proces het toestaat, maak een notitie met wachtwoord vanaf een betrouwbaar systeem voor de minimale informatie van een geverifieerde ontvanger. Verstuur het wachtwoord apart en gebruik verval of toegangslimieten wanneer je abonnement die ondersteunt. Plaats er geen wallet-herstelzinnen of privésleutels in.

LOCK.PUB is een beperkt overdrachtsmiddel: het patcht PHP niet, herstelt geen besmette apparaten, trekt geen providersleutel in en haalt geen kopieën terug. Het vervangt geen geheimenbeheer, identiteitscontrole of incidentrespons.

Veelgestelde vragen

Eindigt het onderzoek zodra PHP is bijgewerkt?

Nee. De update verhelpt de kwetsbaarheid; bewijs en blootstelling bepalen welk onderzoek, herstel en welke wijzigingen aan toegangsgegevens nog nodig zijn.

Schakelt een vervallen notitie haar API-sleutel uit?

Nee. Trek die sleutel bij de provider in of vervang hem daar. Gekopieerde toegangsgegevens staan los van de afleverlink.

Lees ook: API-sleutels delen met duidelijke grenzen.