Kort sagt: Remi PHP-repositoryet leverer aktuelle PHP-versioner til Fedora og RHEL-familien, enten som modul-stream, der erstatter system-PHP, eller som Software Collection, der installerer flere versioner parallelt. PHP2Shell-rettelserne 8.2.35, 8.3.36, 8.4.27 og 8.5.12 blev varslet dér den 22. oktober 2026. Kontrollér hver installeret version for sig, og genstart hver tilhørende tjeneste.
Hvorfor så mange RHEL-servere får PHP fra Remi
Virksomhedsdistributioner som RHEL, AlmaLinux og Rocky Linux satser på lang stabilitet. De leverer få PHP-grene og beholder dem i årevis. Mange applikationer kræver dog nyere versioner, end distributionen tilbyder. Her træder repositoryet fra Remi Collet til, en mangeårig pakkevedligeholder af PHP i Fedora- og RHEL-miljøet.
Remi bygger PHP-versionerne kort efter de officielle udgivelser. Til PHP2Shell udkom der i repositoryets blog den 22. oktober 2026 et indlæg om versionerne 8.2.35, 8.3.36, 8.4.27 og 8.5.12. Deri nævnes de to kritiske sårbarheder CVE-2026-109618 og CVE-2026-109619, og opdateringen anbefales indtrængende. Red Hats sikkerhedsmeddelelser gælder ikke for disse pakker; hvad Red Hat melder om egne pakker, står i indlægget RHEL, AlmaLinux og Rocky Linux: Kontrollér PHP-patchen.
To veje: modul-stream eller Software Collection
Ifølge Remi-bloggen står buildsene til Enterprise Linux fra version 8 klar ad to veje. Hvilken der bruges på jeres server, afgør, hvordan I kontrollerer og genstarter.
| Vej | Repository | Virkning | Typisk tjeneste |
|---|---|---|---|
Modul-stream, f.eks. php:remi-8.3 |
remi-modular | erstatter system-PHP, én standardversion | php-fpm |
Software Collection, f.eks. php83 |
remi-safe | yderligere version parallelt i egen sti | egen tjeneste pr. version, f.eks. php83-php-fpm |
| Testpakker og release-kandidater | remi-modular-test, remi-test | forhåndsversioner | ikke til produktion |
Software Collections ligger typisk under /opt/remi/phpXY, deres konfiguration under /etc/opt/remi/phpXY. Det er praktisk, når gamle og nye applikationer skal drives på én server. Men det er også den hyppigste grund til, at en version overses ved opdateringen.
En henvisning til kommandolinjen: Software Collections står ikke automatisk til rådighed under kommandoen php. Afhængigt af opsætningen kalder cronjobs og scripts dem via en egen kommando eller en fuld sti. Kontrollér derfor også crontabs og deployment-scripts, hvis I vil vide, hvilken collection der bruges til hvad.
Kontrollér Remi PHP-repositoryet efter PHP2Shell
Følgende kommandoer er rent læsende og viser, hvilke Remi-pakker der er installeret, og hvilken status de har.
# Aktive pakkekilder: Er remi-modular eller remi-safe indbundet?
dnf repolist
# Aktiv modul-stream for PHP
dnf module list --enabled php
# Basispakker og parallelt installerede Software Collections
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Version af hver installeret collection
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
Ved de understøttede grene er situationen entydig: Står der 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller nyere, er rettelsen indeholdt. Hos Remi svarer versionsnummeret som regel til upstream-versionen, i modsætning til distributionspakkerne, som ofte beholder deres gamle nummer.
Til ældre collections som php81, php80 eller php74 findes der ingen officiel målversion. Remi fører PHP 8.1 som End-of-Life. Om en installeret pakke indeholder en rettelse mod PHP2Shell, afklarer I i changelog, f.eks. med rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Uden fund behandler I pakken som uafklaret. Hvordan I dokumenterer sådanne fund ordentligt, beskriver indlægget Dokumentér CVE-numre i pakkens changelog.
Aktivér ikke test-repositories som remi-test eller remi-modular-test varigt på produktionsservere. De leverer release-kandidater, der er beregnet til tests.
Opdatering og genstart af hver version
Selve opdateringen er hos Remi som regel ukompliceret: dnf upgrade henter nye pakker til stream og collections. Den kritiske del følger bagefter. Hver collection har sin egen FPM-tjeneste, og hver skal genstartes.
# List alle PHP-FPM-tjenester, også collections'
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Kontrollér starttidspunkter for alle PHP-processer
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Starttidspunkter før opdateringen betyder: Denne tjeneste arbejder stadig med gammel kode. Hvorfor en genindlæsning ikke er nok, forklarer siden Genstart PHP-FPM og alle workers.
Remi og distribution: Hvem er ansvarlig?
Den, der omstiller til Remi via modul-stream, skifter leverandør for PHP. Sikkerhedsmeddelelserne fra Red Hat, AlmaLinux eller Rocky Linux refererer så ikke længere til de installerede PHP-pakker. Omvendt melder Remi ikke problemer i systemets andre pakker. Begge kilder må I altså holde øje med.
Hvor en installeret pakke stammer fra, viser pakkedatabasen, f.eks. med rpm -qi php-fpm i felterne for producent og pakkevedligeholder. Fordi der for Remi-pakker ikke findes errata i Red Hats forstand, egner repositoryets blog sig som underretningsvej; den kan abonneres på via RSS-feed. Ved PHP2Shell udkom henvisningen dér en dag efter de officielle udgivelser.
For virksomheder er denne opdeling ingen hindring, men den skal dokumenteres. Notér, hvilke servere der får PHP fra Remi, hvem der læser meddelelserne, og hvem der genstarter tjenesterne efter en opdatering. Ellers stoler hver på den anden.
Hold orden: færre versioner, mindre risiko
Software Collections inviterer til at lade gamle versioner bare ligge. Efter PHP2Shell er det et godt tidspunkt at rydde op:
- For hver collection afklares, hvilket website eller cronjob der bruger den.
- Deaktivér ubrugte collections, og fjern dem efter en observationstid.
- Løft applikationer på gamle collections til en understøttet gren.
- Dokumentér de resterende versioner med formål og ansvarlig.
Hvordan man bevarer overblikket over mange parallelle versioner, beskriver indlægget Flere PHP-versioner på én server.
Hvordan hjælper PHP SOS konkret?
- Vi registrerer alle Remi-streams og collections på jeres servere og knytter dem til websites og cronjobs.
- Vi kontrollerer PHP2Shell-status pr. version via pakkeversion og changelog.
- Vi indspiller opdateringer, genstarter hver tjeneste og dokumenterer det med processernes starttidspunkter som led i PHP-patchservice.
- Collections, der ikke længere er nødvendige, fjerner vi kontrolleret efter aftale.
Ofte stillede spørgsmål
Har Remi stillet PHP2Shell-versionerne til rådighed?
Ja. I repositoryets blog blev versionerne 8.2.35, 8.3.36, 8.4.27 og 8.5.12 varslet den 22. oktober 2026 med henvisning til to kritiske sårbarheder, CVE-2026-109618 og CVE-2026-109619, og den indtrængende anbefaling om at opdatere.
Hvad er forskellen på modul-stream og SCL hos Remi?
Via en modul-stream erstatter I system-PHP med en Remi-version, så er der én PHP-version som standard. Software Collections installerer yderligere versioner parallelt i egne stier, hver med egen tjeneste.
Får PHP 8.1 fra Remi stadig opdateringer?
Remi fører PHP 8.1 som End-of-Life, PHP-projektet vedligeholder ikke længere grenen. Om en bestemt 8.1-pakke indeholder en rettelse mod PHP2Shell, kontrollerer I i den installerede pakkes changelog. Uden post gælder statussen som uafklaret.
Skal jeg genstarte hver PHP-version efter en Remi-opdatering?
Ja. Hver parallelt installeret version har en egen FPM-tjeneste. Genstartes kun hovedversionens tjeneste, kører de andre videre med gammel kode.