Kort gezegd: Beveiligingslekken in PHP worden vertrouwelijk gemeld, bij voorkeur via het privé-advisoryformulier in de GitHub-repository php/php-src, alternatief aan security@php.net. De PHP-ontwikkelaars delen de bevinding in als hoog, middelhoog of laag; zware fouten worden in een gescheiden beveiligingsrepository gecorrigeerd en pas met de release gepubliceerd, samen met een GitHub Security Advisory en meestal een CVE-nummer. Bij PHP2Shell verliep dit proces in sneltreinvaart: voorankondiging op 20 oktober 2026, patches op 21 oktober 2026, aanvullende aanwijzing op 23 oktober 2026.
Wie zorgt bij PHP voor de beveiliging?
PHP is een open-sourceproject. Het beveiligingsbeleid in de wiki beschrijft het als een project van vrijwilligers zonder budget voor beloningen. Voor elke versie zijn er release managers die verantwoordelijk zijn voor de publicaties. Daarnaast is er de PHP Foundation, die volgens eigen zeggen een team van deeltijd- en voltijdontwikkelaars opdracht geeft dat werkt aan onderhoud, beveiliging en nieuwe functies van PHP.
Voor bedrijven betekent dat: er is geen fabrikant met contract, hotline of toegezegde reactietijden. Wie bindende toezeggingen nodig heeft, krijgt ze van zijn Linux-distributie, zijn hoster of een aanbieder van langetermijnondersteuning, niet van het PHP-project zelf. Deze leveringsketen moet u kennen.
Zo wordt een lek gemeld
De route is in het beveiligingsbeleid op GitHub beschreven:
- Melden: via het privéformulier voor security advisories in de repository
php/php-src. Wie dat niet kan gebruiken of een onderwerp wil bespreken dat geen foutrapport is, schrijft naar security@php.net. - Beknopt beschrijven: Gewenst is een kort voorbeeld dat de fout toont, geen lang rapport over mogelijke gevolgen. Zo kan het team sneller beoordelen.
- Vertrouwelijkheid: De melding blijft tot de publicatie privé.
- Vermelding: Melders worden volgens het creditsysteem van MITRE als bijdragers genoemd.
De oudere wikipagina noemt bovendien de klassieke foutentracker met het type „Security”. Bepalend is tegenwoordig de route via GitHub.
Wat het PHP-project als beveiligingslek aanmerkt
Niet elke crash is een beveiligingslek. De wiki noemt vier criteria: een fout staat onbevoegde acties toe, overschrijdt beveiligingsgrenzen, geeft toegang tot vreemde gegevens of schaadt beschikbaarheid of prestaties ernstig. Er wordt in drie niveaus ingedeeld:
| Niveau | Betekenis volgens het beleid | CVE-nummer |
|---|---|---|
| Hoog | Derden kunnen de meeste installaties compromitteren, code uitvoeren of bestanden lezen | in de regel ja |
| Middel | vergelijkbare werking, maar alleen onder zeldzamere voorwaarden, bijvoorbeeld een zeldzame extensie of configuratie | meestal ja |
| Laag | theoretisch mogelijk, praktisch zeer moeilijk uit te buiten | meestal nee |
Even veelzeggend is de lijst van wat uitdrukkelijk geen beveiligingslek is: kwaadaardige code die opzettelijk wordt uitgevoerd, het omzeilen van open_basedir en disable_functions, kwaadaardige invoer voor unserialize(), het gebruik van FFI en een gewone geheugenafbreking waarbij memory_limit ingrijpt en alleen het huidige verzoek eindigt. Voor beheerders betekent dat: disable_functions is zinvolle hardening, maar geen verdedigingswal.
Van fix naar publicatie
Correcties voor hoge en middelhoge lekken worden volgens de wiki in een gescheiden beveiligingsrepository doorgevoerd voordat de release wordt gemaakt. Laag ingedeelde fouten lopen als gewone foutcorrecties. Het lek wordt gepubliceerd volgens het principe van verantwoorde openbaarmaking: eerst de correctie, dan de details. Releases verschijnen volgens de wiki meestal op donderdag, vaak in het kader van de reguliere maandelijkse publicaties.
Met de release verschijnt een GitHub Security Advisory met eigen aanduiding (GHSA) en ernstniveau. In de repository zijn bijvoorbeeld op 24 september 2026 meerdere advisories over stream wrappers, FastCGI en filters verschenen, met ernstniveaus van laag tot hoog. De bronpakketten op php.net worden aangeboden met SHA-256-controlesommen en GPG-handtekeningen van de release managers; de Git-tags zijn ondertekend. Welke versietakken überhaupt nog beveiligingscorrecties krijgen, toont de pagina over de PHP-versies en de releasecyclus.
PHP2Shell als voorbeeld van het noodgeval
PHP2Shell toont hoe het proces onder druk verloopt:
- 20 oktober 2026: php.net kondigt een kritieke beveiligingsrelease aan voor 21 oktober 2026 om 14:00 UTC en behoudt zich het recht voor eerder te publiceren als details openbaar worden of aanvallen opduiken. Volgens meerdere berichten waren details inderdaad vóór het verstrijken van de embargotermijn bekend geworden; de achtergronden belicht Waarom het PHP-lek vóór de patch bekend werd.
- 21 oktober 2026: PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 verschijnen, plus de advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) en GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), beide als kritiek ingedeeld. Volgens php.net hadden Linux-distributies en aanbieders van langetermijnondersteuning de correcties vooraf ontvangen. Voor 7.4, 8.0 en 8.1 zijn er minimale backports.
- 23 oktober 2026: Een informatieve aanwijzing over CVE-2026-115560 adviseert
session.upload_progress.enabled=0; het volledige advisory volgt met de volgende release.
Wat beheerders hieruit afleiden
- Bronnen volgen: php.net, de GitHub-advisories van
php/php-srcen de beveiligingsmeldingen van uw distributie. - Leveringsketen kennen: Wie levert uw PHP-pakket, en hoe snel komen backports daar aan?
- Tijdvenster plannen: Kritieke releases kunnen buiten het gebruikelijke ritme komen; een patchvenster moet op korte termijn mogelijk zijn.
- Herstart inplannen: Een update werkt pas wanneer alle PHP-processen opnieuw zijn gestart.
- Bewijs veiligstellen: Versie, pakketstand en tijdstip documenteren.
Hoe helpt PHP SOS concreet?
Met de PHP-patchservice nemen wij het deel over dat bij u ligt:
- Meldingen volgen: Wij observeren php.net, de advisories en de meldingen van de distributies en beoordelen of uw systemen zijn getroffen.
- Patch doorvoeren: Update uit de passende bron, herstart van alle processen, controle van de draaiende versie.
- Overgang beveiligen: Waar de update blijft hangen, voeren wij de officiële overgangsmaatregelen door.
- Documenteren: U ontvangt een bewijs met versies, pakketstanden en tijdstippen.
Veelgestelde vragen
Hoe meldt men een beveiligingslek in PHP?
Bij voorkeur via het privé-meldformulier voor security advisories in de GitHub-repository php/php-src. Wie dat niet kan gebruiken, schrijft naar security@php.net. De melding blijft tot de publicatie vertrouwelijk.
Betaalt het PHP-project een beloning voor gevonden lekken?
Nee. Volgens het beveiligingsbeleid is PHP een project van vrijwilligers zonder geld voor bug bounties. Melders worden wel als bijdragers genoemd.
Is het omzeilen van disable_functions een beveiligingslek?
Volgens het beleid van het PHP-project niet. Het omzeilen van open_basedir en disable_functions geldt niet als beveiligingsprobleem van PHP. De instellingen zijn hardening, maar geen betrouwbare beveiligingsgrens.
Waar hoor ik van nieuwe PHP-beveiligingslekken?
Op de startpagina van php.net met de releasemeldingen en in de security advisories van de GitHub-repository php/php-src. Wie PHP uit de distributie betrekt, volgt bovendien de beveiligingsmeldingen daarvan.
Waarom werd PHP2Shell op een woensdag gepubliceerd?
Releases verschijnen volgens de wiki meestal op donderdag. Voor PHP2Shell kondigde php.net op 20 oktober 2026 een beveiligingsrelease aan voor woensdag 21 oktober 2026, 14:00 UTC, en behield zich het recht voor eerder te publiceren als details openbaar zouden worden.