Remi-förrådet: hålla PHP aktuellt på RHEL-system

Kort sagt: Remi PHP-förrådet levererar aktuella PHP-versioner för Fedora och RHEL-familjen, antingen som modulström som ersätter system-PHP eller som Software Collection som installerar flera versioner parallellt. PHP2Shell-rättningarna 8.2.35, 8.3.36, 8.4.27 och 8.5.12 aviserades där den 22 oktober 2026. Kontrollera varje installerad version för sig och starta om varje tillhörande tjänst.

Varför så många RHEL-servrar hämtar PHP från Remi

Företagsdistributioner som RHEL, AlmaLinux och Rocky Linux satsar på lång stabilitet. De levererar få PHP-grenar och behåller dem i åratal. Många applikationer kräver dock nyare versioner än distributionen erbjuder. Här kliver Remi Collets förråd in, han är en mångårig paketunderhållare för PHP i Fedora- och RHEL-miljön.

Remi bygger PHP-versionerna i snabb följd efter de officiella releaserna. Om PHP2Shell kom den 22 oktober 2026 ett inlägg i förrådets blogg om versionerna 8.2.35, 8.3.36, 8.4.27 och 8.5.12. Där nämns de två kritiska sårbarheterna CVE-2026-109618 och CVE-2026-109619 och uppdateringen rekommenderas enträget. Red Hats säkerhetsmeddelanden gäller inte för de paketen; vad Red Hat rapporterar för de egna paketen står i inlägget RHEL, AlmaLinux och Rocky Linux: kontrollera PHP-patchen.

Två vägar: modulström eller Software Collection

Enligt Remi-bloggen finns buildarna för Enterprise Linux från version 8 på två vägar. Vilken som används på er server avgör hur ni kontrollerar och startar om.

Software Collections ligger typiskt under /opt/remi/phpXY, deras konfiguration under /etc/opt/remi/phpXY. Det är praktiskt för att köra gamla och nya applikationer på en server. Men det är också den vanligaste orsaken till att en version förbises vid uppdateringen.

En anmärkning om kommandoraden: Software Collections är inte automatiskt tillgängliga under kommandot php. Beroende på inställning anropar cronjobb och skript dem via ett eget kommando eller en full sökväg. Kontrollera därför även crontabs och driftsättningsskript om ni vill veta vilken collection som används för vad.

Kontrollera Remi PHP-förrådet efter PHP2Shell

Följande kommandon är rent läsande och visar vilka Remi-paket som är installerade och vilken nivå de har.

# Aktiva paketkällor: är remi-modular eller remi-safe inkopplat?
dnf repolist

# Aktiv modulström för PHP
dnf module list --enabled php

# Baspaket och parallellt installerade Software Collections
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort

# Version för varje installerad collection
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done

För grenarna med support är läget entydigt: står där 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller nyare finns rättningen med. Hos Remi motsvarar versionsnumret i regel upstream-versionen, till skillnad från distributionspaketen som ofta behåller sitt gamla nummer.

För äldre collections som php81, php80 eller php74 finns ingen officiell målversion. Remi för PHP 8.1 som End-of-Life. Om ett installerat paket innehåller en rättning mot PHP2Shell klargör ni i changelogen, till exempel med rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Utan träff behandlar ni paketet som oklart. Hur ni styrker sådana träffar rent beskriver inlägget Styrka CVE-nummer i paketets changelog.

Uppdatering och omstart av varje version

Själva uppdateringen är hos Remi oftast odramatisk: dnf upgrade hämtar nya paket för ström och collections. Den kritiska delen kommer efteråt. Varje collection har sin egen FPM-tjänst, och var och en måste startas om.

# Lista alla PHP-FPM-tjänster, även collectionernas
systemctl list-units --type=service --all | grep -E "php.*fpm"

# Kontrollera starttider för alla PHP-processer
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"

Starttider före uppdateringen betyder: den tjänsten arbetar fortfarande med gammal kod. Varför en omladdning inte räcker förklarar sidan Starta om PHP-FPM och alla workers.

Remi och distributionen: vem ansvarar?

Den som via modulström byter till Remi byter leverantör för PHP. Säkerhetsmeddelandena från Red Hat, AlmaLinux eller Rocky Linux avser då inte längre de installerade PHP-paketen. Omvänt rapporterar Remi inga problem i systemets övriga paket. Båda källorna måste ni alltså hålla under uppsikt.

Varifrån ett installerat paket kommer visar paketdatabasen, till exempel med rpm -qi php-fpm i fälten för tillverkare och paketerare. Eftersom det för Remi-paket inte finns några errata i Red Hats mening lämpar sig förrådets blogg som aviseringsväg; den går att prenumerera på via RSS-flöde. Vid PHP2Shell kom anvisningen där en dag efter de officiella releaserna.

För företag är den uppdelningen inget hinder, men den måste dokumenteras. Anteckna vilka servrar som hämtar PHP från Remi, vem som läser rapporterna och vem som startar om tjänsterna efter en uppdatering. Annars förlitar sig var och en på den andre.

Håll ordning: färre versioner, mindre risk

Software Collections inbjuder till att låta gamla versioner ligga kvar. Efter PHP2Shell är det en bra tidpunkt att städa:

1. Klargör för varje collection vilken webbplats eller vilket cronjobb som använder den.
2. Inaktivera oanvända collections och ta bort dem efter en observationstid.
3. Lyft applikationer på gamla collections till en gren med support.
4. Dokumentera de återstående versionerna med ändamål och ansvarig.

Hur man behåller överblicken över många parallella versioner beskriver inlägget Flera PHP-versioner på en server.

Hur hjälper PHP SOS konkret?

• Vi kartlägger alla Remi-strömmar och collections på era servrar och kopplar dem till webbplatser och cronjobb.
• Vi kontrollerar PHP2Shell-läget per version via paketversion och changelog.
• Vi installerar uppdateringar, startar om varje tjänst och styrker det med processernas starttider inom ramen för PHP-patchtjänsten.
• Collections som inte längre behövs tar vi bort kontrollerat efter samråd.

Vanliga frågor

Källor

• Remi's RPM repository: Blog
• Red Hat Security Bulletin RHSB-2026-013
• php.net: versioner som stöds