# Waarom het PHP-lek vóór de patch bekend werd

> Waarom het PHP-lek vóór de patch bekend werd: hoe embargo's werken, wat er op 20 oktober gebeurde en wat beheerders voor hun patchproces kunnen leren.

Bron: https://phpsos.de/nl/blog/php-luecke-vorzeitig-bekannt/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** Het PHP-lek werd vroegtijdig bekend, omdat volgens meerdere berichten details openbaar werden vóór het einde van het afgesproken embargo, onder meer via een forumbijdrage op 20 oktober 2026. php.net kondigde daarop de beveiligingsrelease aan voor 21 oktober om 14:00 UTC. Voor beheerders bleef daardoor nauwelijks voorbereidingstijd over. De les: een patchproces moet ook zonder voorwaarschuwing werken.

## Het begin: een aankondiging met enkele uren vooraf

Normaal horen beheerders van een kritiek lek op het moment dat ook de update klaarstaat. Bij PHP2Shell was dat anders. Op 20 oktober 2026 publiceerde php.net een voorafgaande aankondiging: een kritieke beveiligingsrelease op de volgende dag om 14:00 UTC, dus 16.00 uur Duitse tijd, voor twee lekken met CVSS v4.0 9.2.

Ongebruikelijk was een zin in de melding. Het PHP-team behield zich het recht voor eerder te publiceren als details van een van de lekken openbaar zouden worden of er aanwijzingen voor actief misbruik zouden opduiken. Volgens meerdere berichten, onder meer van SOC Prime en BleepingComputer, was precies dat de achtergrond: informatie was al vóór de geplande datum in omloop.

## Hoe gecoördineerde bekendmaking normaal verloopt

Achter grote beveiligingsupdates zit meestal een procedure die vakmensen „Coordinated Disclosure” noemen, oftewel afgestemde bekendmaking. Vereenvoudigd verloopt die zo:

1. **Melding:** Onderzoekers vinden een lek en melden het vertrouwelijk aan het project.
2. **Analyse en correctie:** Het project controleert de melding, ontwikkelt een fix en kent CVE-nummers toe.
3. **Voorafgaande informatie:** Geselecteerde partners, bijvoorbeeld Linux-distributies, ontvangen de correctie onder embargo, zodat hun pakketten op de afgesproken dag klaar zijn.
4. **Publicatie:** Op een vast tijdstip verschijnen patch, beveiligingsmelding en pakketten tegelijk.

Het embargo is een afspraak om details tot dat tijdstip achter te houden. Het moet voorkomen dat aanvallers een voorsprong krijgen zolang er nog geen update is. Hoe het PHP-project beveiligingsmeldingen in het algemeen behandelt, legt de bijdrage over het [PHP-beveiligingsproces](https://phpsos.de/nl/php/php-sicherheitsprozess/) uit.

## Hoe het PHP-lek vroegtijdig bekend werd: 20 oktober

Volgens overeenstemmende mediaberichten doken de CVE-nummers op 20 oktober op in een openbare forumbijdrage, samen met de bewering dat beide lekken met de hoogste beoordeling 10.0 waren ingedeeld. De bijdrage werd volgens berichten later verwijderd. Het PHP-team bevestigde de lekken, maar noemde de beoordeling 9.2 en publicatiedatum 21 oktober.

In de uren daarna circuleerden volgens berichten schermafbeeldingen en een video die een aanval zouden tonen. Het beveiligingsbedrijf watchTowr gaf aan CVE-2026-109618 te hebben nagebootst. Cloudflare had naar eigen zeggen al sinds de vroege ochtend van 21 oktober eigen beschermingsregels actief.

Los van het uitlekken melden media onder verwijzing naar Amazon een eerste waargenomen aanvalspoging op 17 oktober. Of die verband houdt met het latere uitlekken, is openbaar niet bewezen. De volledige opeenvolging van de data toont de [PHP2Shell-tijdlijn](https://phpsos.de/nl/ratgeber/php2shell-chronologie/).

## Wat vroegtijdige bekendmaking voor beheerders verandert

Voor bedrijven had het uitlekken drie praktische gevolgen:

- **Minder voorbereidingstijd:** Tussen de voorafgaande aankondiging en de patch zat ongeveer een dag. Wie pas na de publicatie reageerde, had geen tijd om onderhoudsvensters af te stemmen.
- **Onduidelijke informatiepositie:** In de eerste uren stonden geruchten naast officiële opgaven. De onjuiste beoordeling 10.0 hield nog dagen stand.
- **Vroeg startpunt voor aanvallers:** Wie details vroeg kent, kan vroeg zoeken. Geautomatiseerde scans naar kwetsbare servers beginnen volgens de ervaring snel, zoals de bijdrage over [massascans naar ongepatcht PHP](https://phpsos.de/nl/blog/automatisierte-massenscans/) beschrijft.

Tegelijk liet de voorafgaande aankondiging zien dat de procedure ondanks het uitlekken werkte: de updates voor alle ondersteunde takken verschenen op het aangekondigde tijdstip, distributies leverden deels op dezelfde dag backports uit.

### Waarom een project niet gewoon direct publiceert

Men zou kunnen vragen waarom het PHP-team na het uitlekken niet meteen alles heeft vrijgegeven. Het antwoord ligt in de afweging waarvoor elk project in zo'n situatie staat. Een release zonder kant-en-klare pakketten van de distributies helpt alleen wie PHP zelf uit de broncode bouwt. De grote meerderheid van de servers betrekt PHP echter via Debian, Ubuntu, Red Hat, hostingproviders of containerimages. Een te vroeg tijdstip had dus details openbaar gemaakt zonder dat de meeste beheerders al iets hadden kunnen installeren.

De voorafgaande aankondiging met een vast tijdstip en het voorbehoud om desnoods eerder te publiceren was een middenweg. Beheerders konden zich voorbereiden, distributies hun pakketten afronden. Voor u als beheerder betekent dat: zo'n voorafgaande aankondiging is een signaal om meteen personeel en onderhoudsvensters in te plannen, niet pas op de dag van de patch.

> **Tip:**
> Abonneer u rechtstreeks op de beveiligingsmeldingen van php.net en van uw distributie, bijvoorbeeld via RSS of mailinglijst. Een voorafgaande aankondiging heeft alleen zin als iemand in het bedrijf haar leest.

## Wat u voor uw patchproces moet meenemen

Of een lek volgens planning of vroegtijdig bekend wordt, hebt u niet in de hand. Hoe snel u daarna kunt handelen wel. Deze punten bleken bij PHP2Shell beslissend:

| Bouwsteen | Vraag die vooraf beantwoord moet zijn |
|---|---|
| Inventaris | Welke servers en websites gebruiken PHP, in welke versie en uitvoeringsmodus? |
| Verantwoordelijkheid | Wie patcht: de eigen IT, een dienstverlener of de hostingprovider? Wie beslist over een uitschakeling? |
| Updateroute | Komt PHP uit de distributie, een repository van een derde of een containerimage? |
| Herstart | Hoe worden alle PHP-processen betrouwbaar herstart? |
| Bewijs | Hoe wordt de patchstatus aangetoond als het versienummer gelijk blijft? |
| Noodbedrijf | Is er een noodpagina voor als een server tijdelijk van het net moet? |

Wie deze vragen al heeft beantwoord, heeft bij de volgende voorafgaande aankondiging alleen nog de datum nodig. Hoe zo'n verloop er duurzaam uitziet, beschrijft de bijdrage over het [patchmanagementproces](https://phpsos.de/nl/blog/patch-management-prozess/).

## Hoe helpt PHP SOS concreet?

- **Snelle inventarisatie:** Wij leggen alle PHP-systemen vast met versie, uitvoeringsmodus en herkomst van de pakketten.
- **Patch op de afgesproken dag:** Wij installeren updates, herstarten alle PHP-processen en leggen de status per server vast.
- **Overbrugging bij vertraging:** Waar een update niet direct kan, stellen wij de tussentijdse maatregelen van php.net in en bespreken wij met u een tijdelijke uitschakeling.
- **Voorbereiding op een volgende keer:** Wij leggen samen met u verantwoordelijkheden, meldroutes en noodbedrijf vast.

Details over het verloop vindt u bij de [PHP-patchservice](https://phpsos.de/nl/leistungen/php-patch-service/).

## Conclusie

Het vroegtijdig bekend worden van PHP2Shell was geen falen van beheerders, maar wel een test voor hun voorbereiding. Een embargo kan breken. Een proces dat inventaris, verantwoordelijkheid, updateroute en bewijs al regelt, houdt dan stand.


## Veelgestelde vragen

**Wat is een embargo bij beveiligingslekken?**  
Een embargo is een afspraak om details van een lek pas op een vast tijdstip te publiceren, meestal samen met de patch. Tot dan kennen alleen de ontdekker, de fabrikant en geselecteerde partners de details, zodat updates kunnen worden voorbereid.

**Is de PHP-patch vanwege het uitlekken eerder gepubliceerd?**  
php.net kondigde op 20 oktober de beveiligingsrelease aan voor 21 oktober om 14:00 UTC en behield zich het recht voor eerder te publiceren als details openbaar zouden worden of aanvallen zouden opduiken. Volgens meerdere berichten volgde de aankondiging omdat details al vóór het einde van het embargo rondgingen.

**Is een vroegtijdig bekend lek gevaarlijker?**  
Het verkort de tijd die beheerders hebben om zich voor te bereiden en geeft aanvallers een eerder startpunt. Volgens mediaberichten werd al op 17 oktober een eerste aanvalspoging waargenomen, dus vóór de patches.

**Wat kan een bedrijf tegen zulke verrassingen doen?**  
Het kan niet voorkomen dat lekken vroeg bekend worden. Wel kan het voorbereid zijn: met een lijst van alle PHP-systemen, vaste verantwoordelijkheden, geteste updateroutes en een noodpagina voor als een server tijdelijk van het net moet.

## Bronnen

- [php.net: beveiligingsmeldingen](https://www.php.net/)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [Help Net Security: PHP2Shell vulnerabilities patched](https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619)