# Na PHP2Shell: waarom meer meldingen waarschijnlijk zijn

> Na PHP2Shell zijn meer PHP-meldingen waarschijnlijk. Waaraan u dat herkent, welke bronnen u volgt en hoe uw team voorbereid en op tijd reageert.

Bron: https://phpsos.de/nl/blog/weitere-php-meldungen/  
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:** Na PHP2Shell zijn meer meldingen over PHP waarschijnlijk, omdat er al twee dagen na de patch een derde aanwijzing kwam, een volledig advisory nog uitstaat en distributies hun pakketten gespreid naleveren. Wie nu een vast proces voor monitoring, beoordeling, update en herstart inricht, reageert op het volgende nieuwe PHP-beveiligingslek in uren in plaats van dagen.

## De patch was niet het einde van het verhaal

Op 21 oktober 2026 dichtte het PHP-project de twee kritieke lekken CVE-2026-109618 en CVE-2026-109619 met de versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Veel verantwoordelijken hebben daarna een vinkje gezet. Twee dagen later, op 23 oktober, volgde echter een nieuwe aanwijzing van php.net over CVE-2026-115560.

Deze derde aanwijzing betreft alleen een ongebruikelijke sessieconfiguratie. Maar ze toont een patroon dat men van grote beveiligingszaken kent: als een component plotseling in de schijnwerpers staat, kijken veel vakmensen tegelijk nauwkeuriger. Of daaruit meer lekken ontstaan, weet vandaag niemand. Waarschijnlijk is wel dat de nieuwsstroom niet opdroogt.

Voor u als beheerder betekent dat: houd rekening met vervolgmeldingen in plaats van door elke verrast te worden. Het tot nu toe verloop van de gebeurtenissen vat onze [PHP2Shell-chronologie](https://phpsos.de/nl/ratgeber/php2shell-chronologie/) samen.

## Waarom meer meldingen waarschijnlijk zijn

De volgende inschatting berust op openbaar bekende feiten. Ze is geen voorspelling van concrete lekken.

1. **Een advisory staat nog uit.** php.net behandelt CVE-2026-115560 in de reguliere releasecyclus en heeft aangekondigd het volledige advisory met de volgende release te publiceren. Tot dan geldt `session.upload_progress.enabled=0` als oplossing.
2. **De details waren vroeg openbaar.** Volgens meerdere berichten werden details vóór het einde van het embargo bekend. Volgens berichten heeft watchTowr CVE-2026-109618 naar eigen zeggen nagebootst. Zulk werk leidt vaak tot vervolgvragen over aangrenzende codeplekken.
3. **Distributies leveren gespreid.** Ubuntu heeft op 21 oktober met USN-8948-1 de actuele releases voorzien en met USN-8948-2 correcties voor 14.04 tot 20.04 via Ubuntu Pro nageleverd. Red Hat schreef in zijn bulletin dat sommige updates beschikbaar waren en andere in bewerking.
4. **De ontwikkelversie is getroffen.** Volgens php.net bevat ook PHP 8.6.0 RC4 de correcties. Wie vooraf versies test, moet ook die omgevingen bijwerken.
5. **Oude versies blijven open.** Voor PHP 8.1 en ouder bestaan alleen minimale broncode-backports. Elke aanbieder die zulke versies uitlevert, meldt zijn stand zelfstandig en op eigen tijdstippen.

## Hoe een nieuw PHP-beveiligingslek u bereikt

Meldingen komen langs verschillende wegen en met verschillende betrouwbaarheid. De volgorde is vrijwel altijd gelijk: eerst het PHP-project, dan distributies en hostingproviders, daarna overheden en media.

| Bron | Wat u daar leert | Hoe betrouwbaar |
|---|---|---|
| php.net | Getroffen takken, verholpen versies, tussentijdse maatregelen | Primaire bron |
| Ubuntu, Debian, Red Hat | Pakketstanden per release, tijdstip van uitlevering | Primaire bron voor uw systeem |
| Hostingproviders en paneelaanbieders | Stand van de eigen PHP-builds | Alleen bindend als schriftelijk |
| BSI, CERT-Bund | Beoordeling van de situatie, waarschuwingsniveau, aanbevelingen | Overheidsinschatting |
| Vakpers en beveiligingsbedrijven | Waargenomen aanvallen, cijfers, achtergronden | Nuttig, als bericht aanmerken |

Belangrijk is het verschil tussen „er is een patch” en „mijn systeem heeft de patch”. De eerste uitspraak staat op php.net. De tweede moet u voor elke server zelf aantonen.

> **Tip:**
> Abonneer u via RSS of e-mailnieuwsbrief op de meldingen van php.net en uw distributie en stuur ze door naar een gedeelde mailbox of een kanaal dat meer dan één persoon leest. Vakantie en ziekte zijn de meest voorkomende redenen voor vertraagde updates.

## Wat u vóór de volgende melding moet voorbereiden

De ervaring met PHP2Shell laat zien waar tijd verloren gaat: bij het zoeken naar servers, bij het regelen van verantwoordelijkheden en bij de vergeten herstart. Dat alles is vooraf te regelen.

- **Inventaris:** Een lijst van alle servers en websites met PHP-tak, uitvoeringsmodus (PHP-FPM, mod_php, LiteSpeed) en pakketbron. Zonder die lijst begint elke melding met zoeken. Hoe dat lukt, beschrijft de bijdrage [Inventaris van alle websites en servers](https://phpsos.de/nl/blog/inventar-websites-server/).
- **Verantwoordelijkheid:** Voor elk systeem staat vast wie patcht, wie herstart en wie vrijgeeft. Bij hostingproviders en bureaus hoort dat in het contract.
- **Beoordelingsraster:** Drie vragen volstaan voor de eerste inschatting. Is onze tak getroffen? Gebruiken wij de getroffen functie of uitvoeringsmodus? Is er een patch of alleen tussentijdse maatregelen?
- **Testroute:** Een stagingomgeving waarin een PHP-update in korte tijd kan worden getest.
- **Bewijs:** Een vast formaat waarin pakketstatus, changelog-treffers en herstarttijd worden vastgelegd.

Hoe zo'n proces als routine in plaats van als brandweeroptreden werkt, staat onder [Patchmanagement als proces](https://phpsos.de/nl/blog/patch-management-prozess/). Achtergrond over hoe het PHP-project met lekken omgaat, biedt de pagina [Hoe het PHP-project beveiligingslekken behandelt](https://phpsos.de/nl/php/php-sicherheitsprozess/).

## De eigen configuratie als vroegwaarschuwingssysteem

Een deel van de vervolgmeldingen betreft alleen bepaalde instellingen. CVE-2026-115560 is daarvan een voorbeeld: php.net noemt als voorwaarde dat een toepassing de sessieserializer tijdens de uitvoering omzet terwijl upload progress actief is. Toepassingen die dat nooit doen, zijn volgens php.net niet getroffen.

Wie zijn werkzame configuratie kent, kan zulke meldingen sneller beoordelen. Leg daarom voor elke tak vast welke waarden aan de serverzijde zijn ingesteld en welke toepassingen ze mogen overschrijven. Een eenvoudige vergelijking van de actieve instellingen helpt al:

```bash
# Werkzame waarden van de opdrachtregel (de webconfiguratie kan afwijken)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"

# Ingestelde waarden in de FPM-pools (pad verschilt per distributie)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
```

De opdrachtregel toont niet noodzakelijk wat in de webcontext geldt. Duidelijkheid geven de pool- of VirtualHost-configuratie en, kortstondig en beschermd, een phpinfo-pagina.

Een ander voordeel: wie weet welke tussentijdse waarden nog uit de PHP2Shell-week zijn ingesteld, kan ze na de volgende reguliere release bewust controleren. Sommige instellingen, zoals uitgeschakelde upload progress, kunnen blijvend zinvol blijven. Andere, zoals zeer krappe uploadgrenzen, moet u na overleg met de vakafdelingen weer aan de werkelijke behoefte aanpassen.

## Hoe helpt PHP SOS concreet?

- Wij volgen de meldingen van php.net, distributies en BSI en beoordelen nieuwe aanwijzingen voor uw concrete systemen.
- Wij stellen samen met u de inventaris van alle PHP-installaties op en leggen verantwoordelijkheden per server vast.
- In het kader van een [beveiligingsonderhoudscontract](https://phpsos.de/nl/leistungen/security-wartungsvertrag/) spelen wij updates in, herstarten alle processen en documenteren de stand.
- Bij meldingen zonder patch stellen wij tussentijdse maatregelen niet-overschrijfbaar in en controleren ze achteraf.


## Veelgestelde vragen

**Is er na PHP2Shell al een nieuw PHP-beveiligingslek?**  
Op 23 oktober 2026 heeft php.net een aanwijzing over CVE-2026-115560 gepubliceerd. Code-uitvoering is daarbij alleen mogelijk met een ongebruikelijke sessieconfiguratie. Een volledig advisory moet met de volgende reguliere release volgen.

**Moet ik na elke nieuwe melding direct handelen?**  
Niet elke melding vraagt dezelfde haast. Beslissend zijn de ernst, of uw configuratie getroffen is en of er een patch beschikbaar is. Een vastgelegd proces helpt dat in minuten in plaats van dagen te beoordelen.

**Waar hoor ik het eerst van nieuwe PHP-lekken?**  
Primaire bronnen zijn de meldingen op php.net en de beveiligingsaanwijzingen van uw distributie, zoals Ubuntu Security Notices, de Debian Security Tracker of Red Hat. Het BSI informeert via waarschuwingsmeldingen. Mediaberichten zijn nuttig, maar vaak later en minder nauwkeurig.

**Waarom melden distributies soms dagen later dan php.net?**  
Distributies moeten de correctie overnemen in hun eigen pakketten, bouwen en testen. Voor oudere releases kan dat langer duren of alleen via aanvullende aanbiedingen verlopen. Daarom loont het beide bronnen afzonderlijk te volgen.

## Bronnen

- [php.net: meldingen en beveiligingsaanwijzingen](https://www.php.net/)
- [Ubuntu Security Notice USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [BSI (Duitse federale dienst voor informatiebeveiliging)](https://www.bsi.bund.de/)