Kort gezegd: Op RHEL, AlmaLinux en Rocky Linux controleert u de PHP-patch tegen PHP2Shell langs drie wegen: de beveiligingsmeldingen van de distributie (dnf updateinfo), de pakket-changelog (rpm -q --changelog) en de starttijd van de PHP-processen. Red Hat noemt RHEL 7 tot 10 als getroffen en meldde bij het opvragen dat enkele updates beschikbaar zijn en andere in bewerking. Na de update geldt: volledig herstarten, niet alleen herladen.
Wat Red Hat over PHP2Shell heeft gepubliceerd
Red Hat heeft over PHP2Shell het beveiligingsbulletin RHSB-2026-013 uitgegeven. Wij hebben het op 25 oktober 2026 opgevraagd. De belangrijkste punten voor beheerders:
- Getroffen zijn RHEL 10, 9, 8 en 7 en daarop voortbouwende producten en containers op basis van RHEL- of UBI-images.
- RHEL 7 is volgens Red Hat alleen getroffen door CVE-2026-109619; de code voor CVE-2026-109618 zou daar niet aanwezig zijn.
- Niet getroffen zijn systemen zonder PHP of zonder PHP dat niet-vertrouwde HTTP-verzoeken verwerkt.
- Updates: Enkele waren bij het opvragen beschikbaar, andere in bewerking. Concrete errata-nummers noemde het bulletin niet, maar verwees naar de errata-pagina's.
Red Hat beoordeelt CVE-2026-109618 met een eigen methode als „Important” en wijst erop dat standaardinstallaties vanaf RHEL 8 PHP-FPM in plaats van mod_php gebruiken. Dat is een inschatting, geen geruststelling. Het PHP-project beoordeelt beide lekken met CVSS v4.0 9.2, en het BSI (de Duitse federale dienst voor informatiebeveiliging) adviseert de directe update.
AlmaLinux en Rocky Linux: dezelfde bron, eigen tempo
AlmaLinux en Rocky Linux bouwen hun pakketten na uit de bronnen van Red Hat. Correcties komen daarom inhoudelijk meestal gelijk aan, maar op eigen tijdstip en onder eigen beveiligingsmeldingen. Een verwijzing naar een Red Hat-erratum betekent niet dat het pakket bij uw nabouw dezelfde dag klaarstaat.
Beslissend is daarom de stand op uw systeem. Controleer hem met de hulpmiddelen van de pakketbeheerder en niet aan de hand van nieuws of forums.
Let er bovendien op of op de server spiegelservers of interne pakketbronnen worden gebruikt. In veel bedrijven halen servers hun updates niet rechtstreeks bij de fabrikant, maar via een interne spiegel of een beheertool. Is die spiegel niet actueel, dan vindt dnf geen nieuwe pakketten, hoewel ze allang zijn gepubliceerd.
De PHP-patch op RHEL en nabouwen controleren
De volgende opdrachten zijn uitsluitend lezend. Pakketnamen gelden voor de PHP-pakketten van de distributie; pakketten uit externe bronnen zoals Remi heten deels anders.
# Welke PHP-streams kent het systeem, welke is actief? (RHEL 8 en 9)
dnf module list php
# Geïnstalleerde PHP-pakketten met versie en herkomst
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Zijn er beveiligingsmeldingen voor de CVE's voor dit systeem?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# Staat de correctie in de changelog van het geïnstalleerde pakket?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo toont alleen meldingen voor updates die nog niet zijn geïnstalleerd; met --installed ziet u ook reeds ingespeelde. Een leeg resultaat kan dus tweeërlei betekenen: de update is er al in of nog niet gepubliceerd. De changelog-vergelijking brengt duidelijkheid. Hoe u het resultaat als bewijs vastlegt, beschrijft de bijdrage CVE-nummers in de pakket-changelog aantonen.
Zoals bij andere bedrijfsdistributies behoudt het pakket meestal zijn oorspronkelijke PHP-versie; alleen de releasevermelding verandert. Een ouder nummer bij php -v is daarom geen aanwijzing voor een ontbrekende correctie. Algemene aanwijzingen voor de versiecontrole staan onder PHP-versie en patchstatus juist controleren.
De juiste uitvoeringsmodus herkennen
Red Hat noemt de standaarduitvoeringsmodi: vanaf RHEL 8 draait PHP via PHP-FPM, op RHEL 7 als mod_php in de Apache-service httpd. Veel servers wijken daarvan af, bijvoorbeeld door panelen, externe bronnen of oude configuraties.
| Systeem | Standaard volgens Red Hat | Herstart na de update |
|---|---|---|
| RHEL 8, 9, 10 en nabouwen | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php in httpd | systemctl restart httpd |
| Containers op RHEL- of UBI-basis | per image | Image opnieuw bouwen, container vervangen |
Voor containers adviseert Red Hat na bijgewerkte basisimages de eigen images opnieuw te bouwen en draaiende containers of pods te vervangen. Een update in de draaiende container is geen betrouwbare weg.
Na de update: herstart en controle
Red Hat benadrukt dat een reload niet volstaat. Bestaande workers kunnen de getroffen toestand behouden. Herstart daarom elke service die PHP laadt, en controleer het resultaat:
# Services met verouderde bibliotheken tonen (dnf-utils resp. dnf-plugins-core)
needs-restarting -s
# Starttijd van de PHP-processen vergelijken met het tijdstip van de update
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Voor de configuratie heeft Red Hat een praktische aanwijzing: php -i toont de instellingen van de opdrachtregel, niet die van de webserver. Wie wil controleren of tussentijdse waarden zoals session.upload_progress.enabled=0 in de webcontext werken, gebruikt kortstondig een beschermde phpinfo-pagina en verwijdert die daarna. Waar u bij de herstart verder op moet letten, staat onder PHP-FPM en alle workers herstarten.
Tussentijdse maatregelen: de aanwijzingen van Red Hat
Waar een update nog ontbreekt, verwijst Red Hat naar dezelfde tussentijdse maatregelen als php.net en voegt enkele praktische aanwijzingen voor RHEL-systemen toe. Ze vervangen de update niet.
- Regel echt aanvullen: Volgens Red Hat staat de regel voor
session.upload_progress.enabledin de uitgeleverde configuratie als commentaar, de functie is dus standaard actief. De waarde0moet uitdrukkelijk worden ingesteld. - Niet-overschrijfbaar instellen: via
php_admin_valuein de PHP-FPM-pool, bij mod_php in de Apache-configuratie. Niet viaini_set()of.user.ini. - Tegenspelers zoeken: Red Hat adviseert
.htaccess-bestanden, VirtualHosts en.user.ini-bestanden erop te controleren of ze de getroffen instellingen weer inschakelen. - Ook ervoor grenzen stellen: Naast
post_max_sizein PHP raadt Red Hat aan ook in de webserver of proxy grenzen voor de aanvraaggrootte te overwegen.
Op PHP-FPM-systemen staan de pools in de regel onder /etc/php-fpm.d/. Na elke wijziging geldt hetzelfde als na de update: alle workers volledig herstarten.
Draait op dezelfde server bovendien PHP uit de Remi-repository, dan gelden daarvoor eigen pakketten en services. Lees daarover de bijdrage De Remi-repository.
Hoe helpt PHP SOS concreet?
- Wij controleren op RHEL, AlmaLinux en Rocky Linux alle PHP-pakketten, streams en externe bronnen en vergelijken ze met de beveiligingsmeldingen.
- Wij spelen updates in, herstarten alle workers volledig en controleren de starttijden van de processen.
- Voor containeromgevingen bouwen wij images opnieuw en vervangen draaiende instanties gecontroleerd.
- De stand per server leggen wij vast in het bewijs van de PHP-patchservice.
Veelgestelde vragen
Is RHEL 7 getroffen door PHP2Shell?
Volgens Red Hat is RHEL 7 alleen getroffen door CVE-2026-109619, de kwetsbare code voor CVE-2026-109618 zou daar niet aanwezig zijn. Op RHEL 7 is mod_php de standaarduitvoeringsmodus, die het PHP-team als bijzonder riskant beoordeelt.
Waarom beoordeelt Red Hat het lek lager dan php.net?
Red Hat gebruikt een eigen beoordeling volgens CVSS v3.1 en deelt CVE-2026-109618 in als Important, omdat misbruik nauwkeurige timing vergt. php.net beoordeelt met CVSS v4.0 9.2. Beiden achten code-uitvoering zonder aanmelding mogelijk, de update is in elk geval nodig.
Krijgen AlmaLinux en Rocky Linux de correcties automatisch?
Beide bouwen hun pakketten na uit de bronnen van Red Hat en publiceren eigen beveiligingsmeldingen. Het tijdstip kan van Red Hat afwijken. Controleer de stand daarom op uw eigen systeem en in de meldingen van uw distributie.
Volstaat systemctl reload php-fpm na de update?
Nee. Red Hat wijst er uitdrukkelijk op dat een reload niet volstaat, omdat bestaande workers de getroffen toestand kunnen behouden. Herstart alle workers, bij mod_php de Apache-service httpd.