Kort sagt: På RHEL, AlmaLinux og Rocky Linux kontrollerer I PHP-patchen mod PHP2Shell ad tre veje: distributionens sikkerhedsmeddelelser (dnf updateinfo), pakkens changelog (rpm -q --changelog) og starttidspunktet for PHP-processerne. Red Hat fører RHEL 7 til 10 som berørt og meldte ved hentningen, at nogle opdateringer er tilgængelige og flere under udarbejdelse. Efter opdateringen gælder: genstart fuldstændigt, ikke kun genindlæs.
Hvad Red Hat har offentliggjort om PHP2Shell
Red Hat har udgivet sikkerhedsbulletinen RHSB-2026-013 om PHP2Shell. Vi hentede den den 25. oktober 2026. De vigtigste punkter for administratorer:
- Berørt er RHEL 10, 9, 8 og 7 samt produkter og containere baseret på dem med RHEL- eller UBI-images.
- RHEL 7 er ifølge Red Hat kun berørt af CVE-2026-109619; koden til CVE-2026-109618 findes ikke dér.
- Ikke berørt er systemer uden PHP eller med PHP, der ikke behandler ikke-betroede HTTP-forespørgsler.
- Opdateringer: Nogle var tilgængelige ved hentningen, flere under udarbejdelse. Konkrete errata-numre nævnte bulletinen ikke, men henviste til errata-siderne.
Red Hat vurderer CVE-2026-109618 med egen metode som „Important“ og henviser til, at standardinstallationer fra og med RHEL 8 bruger PHP-FPM i stedet for mod_php. Det er en vurdering, ikke en afblæsning. PHP-projektet vurderer begge sårbarheder til CVSS v4.0 9,2, og BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler en øjeblikkelig opdatering.
AlmaLinux og Rocky Linux: samme kilde, eget tempo
AlmaLinux og Rocky Linux bygger deres pakker efter fra Red Hats kilder. Rettelser ankommer derfor som regel indholdsmæssigt ens, men med eget tidspunkt og under egne sikkerhedsmeddelelser. En henvisning til en Red Hat-errata betyder ikke, at pakken står klar hos jeres efterbygning samme dag.
Afgørende er derfor statussen på jeres system. Kontrollér den med pakkehåndteringens værktøjer og ikke ud fra nyheder eller fora.
Vær desuden opmærksom på, om serveren bruger spejlservere eller interne pakkekilder. I mange virksomheder henter servere deres opdateringer ikke direkte hos producenten, men via et internt spejl eller et administrationsværktøj. Er dette spejl ikke aktuelt, finder dnf ingen nye pakker, selv om de for længst er offentliggjort.
Kontrollér PHP-patchen på RHEL og efterbygninger
Følgende kommandoer er rent læsende. Pakkenavne gælder for distributionens PHP-pakker; pakker fra tredjepartskilder som Remi hedder delvis noget andet.
# Hvilke PHP-streams kender systemet, og hvilken er aktiv? (RHEL 8 og 9)
dnf module list php
# Installerede PHP-pakker med version og oprindelse
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Findes der sikkerhedsmeddelelser om CVE'erne til dette system?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# Står rettelsen i changelog for den installerede pakke?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo viser kun meddelelser om opdateringer, der endnu ikke er installeret; med --installed ser I også allerede indspillede. Et tomt resultat kan altså betyde to ting: Opdateringen er allerede indspillet, eller den er endnu ikke offentliggjort. Afstemningen med changelog afklarer det. Hvordan I fastholder resultatet som dokumentation, beskriver indlægget Dokumentér CVE-numre i pakkens changelog.
Som ved andre virksomhedsdistributioner beholder pakken som regel sin oprindelige PHP-version; kun release-angivelsen ændrer sig. Et ældre nummer ved php -v er derfor ikke et tegn på en manglende rettelse. Generelle henvisninger til versionskontrol står under Kontrollér PHP-version og patchstatus korrekt.
Genkend den rigtige driftsform
Red Hat nævner standarddriftsformerne: Fra og med RHEL 8 kører PHP via PHP-FPM, på RHEL 7 som mod_php i Apache-tjenesten httpd. Mange servere afviger herfra, f.eks. på grund af paneler, fremmede kilder eller gamle konfigurationer.
| System | Standard ifølge Red Hat | Genstart efter opdateringen |
|---|---|---|
| RHEL 8, 9, 10 og efterbygninger | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php i httpd | systemctl restart httpd |
| Containere på RHEL- eller UBI-basis | afhænger af image | Byg image påny, udskift container |
Til containere anbefaler Red Hat efter opdaterede basis-images at bygge egne images påny og udskifte kørende containere eller pods. En opdatering i den kørende container er ikke en pålidelig vej.
Efter opdateringen: genstart og kontrol
Red Hat understreger, at en genindlæsning ikke er nok. Eksisterende workers kan beholde den berørte tilstand. Genstart derfor hver tjeneste, der indlæser PHP, og kontrollér resultatet:
# Vis tjenester med forældede biblioteker (dnf-utils hhv. dnf-plugins-core)
needs-restarting -s
# Sammenlign PHP-processernes starttidspunkt med opdateringstidspunktet
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Til konfigurationen har Red Hat en praktisk henvisning: php -i viser kommandolinjens indstillinger, ikke webserverens. Den, der vil kontrollere, om midlertidige værdier som session.upload_progress.enabled=0 gælder i webkonteksten, bruger kortvarigt en beskyttet phpinfo-side og sletter den bagefter. Hvad der ellers er at tage hensyn til ved genstarten, står under Genstart PHP-FPM og alle workers.
Midlertidige foranstaltninger: Red Hats henvisninger
Hvor en opdatering endnu mangler, henviser Red Hat til de samme midlertidige foranstaltninger som php.net og supplerer med nogle praktiske henvisninger til RHEL-systemer. De erstatter ikke opdateringen.
- Tilføj linjen rigtigt: Ifølge Red Hat er linjen til
session.upload_progress.enabledi den leverede konfiguration udkommenteret, funktionen altså som standard aktiv. Værdien0skal sættes udtrykkeligt. - Indstil, så den ikke kan overskrives: via
php_admin_valuei PHP-FPM-poolen, ved mod_php i Apache-konfigurationen. Ikke viaini_set()eller.user.ini. - Find modstanderne: Red Hat anbefaler at kontrollere
.htaccess-filer, VirtualHosts og.user.ini-filer for, om de slår de berørte indstillinger til igen. - Sæt grænser også foran: Ud over
post_max_sizei PHP anbefaler Red Hat at overveje grænser for forespørgselsstørrelsen også i webserveren eller proxyen.
På PHP-FPM-systemer ligger poolene som regel under /etc/php-fpm.d/. Efter hver ændring gælder det samme som efter opdateringen: Genstart alle workers fuldstændigt.
Kører der på den samme server desuden PHP fra Remi-repositoryet, gælder der egne pakker og tjenester for det. Læs hertil indlægget Remi-repositoryet.
Hvordan hjælper PHP SOS konkret?
- Vi kontrollerer på RHEL, AlmaLinux og Rocky Linux alle PHP-pakker, streams og fremmede kilder og afstemmer dem med sikkerhedsmeddelelserne.
- Vi indspiller opdateringer, genstarter alle workers fuldstændigt og kontrollerer processernes starttidspunkter.
- I containermiljøer bygger vi images påny og udskifter kørende instanser kontrolleret.
- Statussen for hver server fastholder vi i dokumentationen fra PHP-patchservice.
Ofte stillede spørgsmål
Er RHEL 7 berørt af PHP2Shell?
Ifølge Red Hat er RHEL 7 kun berørt af CVE-2026-109619, den sårbare kode til CVE-2026-109618 findes ikke dér. På RHEL 7 er mod_php standarddriftsformen, som PHP-teamet vurderer som særligt risikabel.
Hvorfor vurderer Red Hat sårbarheden lavere end php.net?
Red Hat bruger en egen vurdering efter CVSS v3.1 og vurderer CVE-2026-109618 som Important, fordi udnyttelsen kræver præcis timing. php.net vurderer med CVSS v4.0 9,2. Begge anser kodeudførelse uden login for mulig, opdateringen er under alle omstændigheder nødvendig.
Får AlmaLinux og Rocky Linux rettelserne automatisk?
Begge bygger deres pakker efter fra Red Hats kilder og offentliggør egne sikkerhedsmeddelelser. Tidspunktet kan afvige fra Red Hat. Kontrollér derfor statussen på eget system og i meddelelserne fra jeres distribution.
Er systemctl reload php-fpm nok efter opdateringen?
Nej. Red Hat gør udtrykkeligt opmærksom på, at en genindlæsning ikke er nok, fordi eksisterende workers kan beholde den berørte tilstand. Genstart alle workers, ved mod_php Apache-tjenesten httpd.