Kort gezegd: De Remi PHP-repository levert actuele PHP-versies voor Fedora en de RHEL-familie, ofwel als modulestream die de systeem-PHP vervangt, ofwel als Software Collection die meerdere versies parallel installeert. De PHP2Shell-correcties 8.2.35, 8.3.36, 8.4.27 en 8.5.12 zijn daar op 22 oktober 2026 aangekondigd. Controleer elke geïnstalleerde versie afzonderlijk en herstart elke bijbehorende service.
Waarom zoveel RHEL-servers PHP van Remi betrekken
Bedrijfsdistributies zoals RHEL, AlmaLinux en Rocky Linux zetten in op langdurige stabiliteit. Ze leveren weinig PHP-takken en houden die jarenlang aan. Veel toepassingen vragen echter nieuwere versies dan de distributie aanbiedt. Daar springt de repository van Remi Collet bij, een al jaren actieve pakketbeheerder voor PHP in de Fedora- en RHEL-omgeving.
Remi bouwt de PHP-versies kort na de officiële releases. Over PHP2Shell verscheen in de blog van de repository op 22 oktober 2026 een bijdrage over de versies 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Daarin worden de twee kritieke lekken CVE-2026-109618 en CVE-2026-109619 genoemd en wordt de update dringend aanbevolen. De beveiligingsmeldingen van Red Hat gelden niet voor deze pakketten; wat Red Hat voor de eigen pakketten meldt, staat in de bijdrage RHEL, AlmaLinux en Rocky Linux: PHP-patch controleren.
Twee wegen: modulestream of Software Collection
Volgens de Remi-blog staan de builds voor Enterprise Linux vanaf versie 8 op twee wegen klaar. Welke op uw server wordt gebruikt, bepaalt hoe u controleert en herstart.
| Weg | Repository | Werking | Typische service |
|---|---|---|---|
Modulestream, bijvoorbeeld php:remi-8.3 |
remi-modular | vervangt de systeem-PHP, één standaardversie | php-fpm |
Software Collection, bijvoorbeeld php83 |
remi-safe | extra versie parallel in eigen pad | eigen service per versie, bijvoorbeeld php83-php-fpm |
| Testpakketten en release candidates | remi-modular-test, remi-test | voorlopige versies | niet voor productie |
Software Collections staan typisch onder /opt/remi/phpXY, hun configuratie onder /etc/opt/remi/phpXY. Dat is handig om oude en nieuwe toepassingen op één server te draaien. Het is echter ook de meest voorkomende reden waarom een versie bij de update over het hoofd wordt gezien.
Een opmerking over de opdrachtregel: Software Collections zijn niet automatisch beschikbaar onder de opdracht php. Afhankelijk van de inrichting roepen cronjobs en scripts ze aan via een eigen opdracht of een volledig pad. Controleer daarom ook crontabs en deployment-scripts als u wilt weten welke collection waarvoor in gebruik is.
Remi PHP-repository na PHP2Shell controleren
De volgende opdrachten zijn uitsluitend lezend en tonen welke Remi-pakketten zijn geïnstalleerd en welke stand ze hebben.
# Actieve pakketbronnen: is remi-modular of remi-safe ingebonden?
dnf repolist
# Actieve modulestream voor PHP
dnf module list --enabled php
# Basispakketten en parallel geïnstalleerde Software Collections
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Versie van elke geïnstalleerde collection
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
Bij de ondersteunde takken is de situatie eenduidig: staat daar 8.5.12, 8.4.27, 8.3.36 of 8.2.35 of nieuwer, dan is de correctie opgenomen. Bij Remi komt het versienummer in de regel overeen met de upstreamversie, anders dan bij de distributiepakketten, die vaak hun oude nummer behouden.
Voor oudere collections zoals php81, php80 of php74 bestaat geen officiële doelversie. Remi voert PHP 8.1 als End-of-Life. Of een geïnstalleerd pakket een correctie tegen PHP2Shell bevat, stelt u vast in de changelog, bijvoorbeeld met rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Zonder treffer behandelt u het pakket als onopgehelderd. Hoe u zulke treffers netjes aantoont, beschrijft de bijdrage CVE-nummers in de pakket-changelog aantonen.
Activeer testrepository's zoals remi-test of remi-modular-test niet blijvend op productieservers. Ze leveren release candidates die voor tests bedoeld zijn.
Update en herstart van elke versie
De update zelf is bij Remi meestal onopvallend: dnf upgrade haalt nieuwe pakketten voor stream en collections. Het kritieke deel volgt daarna. Elke collection heeft een eigen FPM-service, en elke moet worden herstart.
# Alle PHP-FPM-services opsommen, ook die van de collections
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Starttijden van alle PHP-processen controleren
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Starttijden vóór de update betekenen: deze service werkt nog met oude code. Waarom herladen niet volstaat, legt de pagina PHP-FPM en alle workers herstarten uit.
Remi en distributie: wie is verantwoordelijk?
Wie via een modulestream overstapt naar Remi, wisselt voor PHP van leverancier. De beveiligingsmeldingen van Red Hat, AlmaLinux of Rocky Linux hebben dan geen betrekking meer op de geïnstalleerde PHP-pakketten. Omgekeerd meldt Remi geen problemen in andere pakketten van het systeem. U moet dus beide bronnen in het oog houden.
Waar een geïnstalleerd pakket vandaan komt, toont de pakketdatabase, bijvoorbeeld met rpm -qi php-fpm in de velden voor leverancier en pakketmaker. Omdat er voor Remi-pakketten geen errata in de zin van Red Hat bestaan, is de blog van de repository geschikt als meldingskanaal; hij kan via een RSS-feed worden geabonneerd. Bij PHP2Shell verscheen de aanwijzing daar een dag na de officiële releases.
Voor bedrijven is deze verdeling geen belemmering, maar ze moet wel gedocumenteerd zijn. Leg vast welke servers PHP van Remi betrekken, wie de meldingen leest en wie na een update de services herstart. Anders verlaat ieder zich op de ander.
Orde houden: minder versies, minder risico
Software Collections nodigen uit oude versies gewoon te laten staan. Na PHP2Shell is het een goed moment om op te ruimen:
- Voor elke collection vaststellen welke website of cronjob haar gebruikt.
- Ongebruikte collections deactiveren en na een observatieperiode verwijderen.
- Toepassingen op oude collections naar een ondersteunde tak tillen.
- De resterende versies met doel en verantwoordelijke documenteren.
Hoe u het overzicht over veel parallelle versies houdt, beschrijft de bijdrage Meerdere PHP-versies op één server.
Hoe helpt PHP SOS concreet?
- Wij leggen alle Remi-streams en collections op uw servers vast en koppelen ze aan websites en cronjobs.
- Wij controleren de PHP2Shell-stand per versie via pakketversie en changelog.
- Wij spelen updates in, herstarten elke service en onderbouwen dat met starttijden van processen in het kader van de PHP-patchservice.
- Niet meer benodigde collections verwijderen wij na overleg gecontroleerd.
Veelgestelde vragen
Heeft Remi de PHP2Shell-versies beschikbaar gesteld?
Ja. In de blog van de repository zijn op 22 oktober 2026 de versies 8.2.35, 8.3.36, 8.4.27 en 8.5.12 aangekondigd, met verwijzing naar twee kritieke lekken, CVE-2026-109618 en CVE-2026-109619, en het dringende advies te updaten.
Wat is het verschil tussen modulestream en SCL bij Remi?
Via een modulestream vervangt u de systeem-PHP door een Remi-versie; er is dan één PHP-versie als standaard. Software Collections installeren andere versies parallel in eigen paden, elk met een eigen service.
Krijgt PHP 8.1 van Remi nog updates?
Remi voert PHP 8.1 als End-of-Life, het PHP-project onderhoudt de tak niet meer. Of een bepaald 8.1-pakket een correctie tegen PHP2Shell bevat, controleert u in de changelog van het geïnstalleerde pakket. Zonder vermelding geldt de stand als onopgehelderd.
Moet ik na een Remi-update elke PHP-versie herstarten?
Ja. Elke parallel geïnstalleerde versie heeft een eigen FPM-service. Wordt alleen de service van de hoofdversie herstart, dan draaien de andere met oude code door.