Kort sagt: På RHEL, AlmaLinux och Rocky Linux kontrollerar ni PHP-patchen mot PHP2Shell på tre vägar: distributionens säkerhetsmeddelanden (dnf updateinfo), paketets changelog (rpm -q --changelog) och PHP-processernas starttid. Red Hat anger RHEL 7 till 10 som berörda och meddelade vid hämtningen att vissa uppdateringar finns tillgängliga och fler är under arbete. Efter uppdateringen gäller: starta om fullständigt, ladda inte bara om.
Vad Red Hat har publicerat om PHP2Shell
Red Hat har gett ut säkerhetsbulletinen RHSB-2026-013 om PHP2Shell. Vi hämtade den den 25 oktober 2026. De viktigaste punkterna för admins:
- Berörda är RHEL 10, 9, 8 och 7 samt produkter som bygger på dem och containrar baserade på RHEL- eller UBI-images.
- RHEL 7 berörs enligt Red Hat bara av CVE-2026-109619; koden för CVE-2026-109618 ska inte finnas där.
- Inte berörda är system utan PHP eller utan PHP som bearbetar ej betrodda HTTP-förfrågningar.
- Uppdateringar: Vissa fanns tillgängliga vid hämtningen, fler är under arbete. Konkreta errata-nummer angav bulletinen inte utan hänvisade till errata-sidorna.
Red Hat bedömer CVE-2026-109618 med egen metod som ”Important” och påpekar att standardinstallationer från RHEL 8 använder PHP-FPM i stället för mod_php. Det är en bedömning, ingen avblåsning. PHP-projektet bedömer båda sårbarheterna med CVSS v4.0 9,2, och BSI (den tyska federala myndigheten för informationssäkerhet) rekommenderar omedelbar uppdatering.
AlmaLinux och Rocky Linux: samma källa, egen takt
AlmaLinux och Rocky Linux bygger om sina paket från Red Hats källor. Rättningar kommer därför i regel innehållsmässigt lika, men vid egen tidpunkt och under egna säkerhetsmeddelanden. En hänvisning till en Red Hat-errata betyder inte att paketet finns tillgängligt hos ert efterbygge samma dag.
Avgörande är därför nivån på ert system. Kontrollera den med paketförvaltningens verktyg och inte utifrån nyheter eller forum.
Se dessutom upp om servern använder speglar eller interna paketkällor. I många företag hämtar servrar sina uppdateringar inte direkt från tillverkaren utan via en intern spegel eller ett förvaltningsverktyg. Är den spegeln inte aktuell hittar dnf inga nya paket fast de sedan länge är publicerade.
Kontrollera PHP-patchen på RHEL och efterbyggen
Följande kommandon är rent läsande. Paketnamnen gäller distributionens PHP-paket; paket från tredjepartskällor som Remi heter delvis annorlunda.
# Vilka PHP-streams känner systemet till, vilken är aktiv? (RHEL 8 och 9)
dnf module list php
# Installerade PHP-paket med version och ursprung
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Finns det säkerhetsmeddelanden om CVE:erna för det här systemet?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# Står rättningen i changelogen för det installerade paketet?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo visar bara meddelanden för uppdateringar som ännu inte är installerade; med --installed ser ni även redan installerade. Ett tomt resultat kan alltså betyda två saker: uppdateringen är redan inne eller ännu inte publicerad. Changelog-avstämningen klargör det. Hur ni dokumenterar resultatet som bevis beskriver inlägget Styrka CVE-nummer i paketets changelog.
Liksom hos andra företagsdistributioner behåller paketet oftast sin ursprungliga PHP-version; bara release-uppgiften ändras. Ett äldre nummer vid php -v är därför inget tecken på en saknad rättning. Allmänna anvisningar för versionskontroll står under Kontrollera PHP-version och patchnivå rätt.
Känn igen rätt driftläge
Red Hat anger standarddriftlägena: från RHEL 8 körs PHP via PHP-FPM, på RHEL 7 som mod_php i Apache-tjänsten httpd. Många servrar avviker från det, till exempel genom paneler, främmande källor eller gamla konfigurationer.
| System | Standard enligt Red Hat | Omstart efter uppdateringen |
|---|---|---|
| RHEL 8, 9, 10 och efterbyggen | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php i httpd | systemctl restart httpd |
| Containrar på RHEL- eller UBI-bas | beroende på image | bygg om image, ersätt container |
För containrar rekommenderar Red Hat att bygga om de egna images efter uppdaterade basimages och ersätta körande containrar eller pods. En uppdatering i den körande containern är ingen hållbar väg.
Efter uppdateringen: omstart och kontroll
Red Hat betonar att en omladdning inte räcker. Befintliga workers kan behålla det berörda tillståndet. Starta därför om varje tjänst som laddar PHP och kontrollera resultatet:
# Visa tjänster med föråldrade bibliotek (dnf-utils resp. dnf-plugins-core)
needs-restarting -s
# Jämför PHP-processernas starttid med uppdateringstidpunkten
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
För konfigurationen har Red Hat en praktisk anvisning: php -i visar kommandoradens inställningar, inte webbserverns. Den som vill kontrollera om tillfälliga värden som session.upload_progress.enabled=0 gäller i webbkontexten använder kortvarigt en skyddad phpinfo-sida och raderar den efteråt. Vad som annars bör beaktas vid omstarten står under Starta om PHP-FPM och alla workers.
Tillfälliga åtgärder: anvisningarna från Red Hat
Där en uppdatering ännu saknas hänvisar Red Hat till samma tillfälliga åtgärder som php.net och kompletterar med några praktiska anvisningar för RHEL-system. De ersätter inte uppdateringen.
- Lägg verkligen till raden: Enligt Red Hat är raden för
session.upload_progress.enabledbortkommenterad i den levererade konfigurationen, funktionen alltså aktiv som standard. Värdet0måste sättas uttryckligen. - Sätt så att det inte går att skriva över: via
php_admin_valuei PHP-FPM-poolen, vid mod_php i Apache-konfigurationen. Inte viaini_set()eller.user.ini. - Leta efter motkrafter: Red Hat rekommenderar att kontrollera
.htaccess-filer, VirtualHosts och.user.ini-filer om de slår på de berörda inställningarna igen. - Sätt gränser även framför: Vid sidan av
post_max_sizei PHP rekommenderar Red Hat att överväga gränser för förfrågningens storlek även i webbservern eller proxyn.
På PHP-FPM-system ligger poolerna i regel under /etc/php-fpm.d/. Efter varje ändring gäller detsamma som efter uppdateringen: starta om alla workers fullständigt.
Körs på samma server dessutom PHP från Remi-förrådet gäller egna paket och tjänster för det. Läs om det i inlägget Remi-förrådet.
Hur hjälper PHP SOS konkret?
- Vi kontrollerar på RHEL, AlmaLinux och Rocky Linux alla PHP-paket, streams och främmande källor och stämmer av dem mot säkerhetsmeddelandena.
- Vi installerar uppdateringar, startar om alla workers fullständigt och kontrollerar processernas starttider.
- För containermiljöer bygger vi om images och ersätter körande instanser kontrollerat.
- Läget per server dokumenterar vi i beviset från PHP-patchtjänsten.
Vanliga frågor
Berörs RHEL 7 av PHP2Shell?
Enligt Red Hat berörs RHEL 7 bara av CVE-2026-109619, den sårbara koden för CVE-2026-109618 finns inte där. På RHEL 7 är mod_php standarddriftläget, som PHP-teamet bedömer som särskilt riskabelt.
Varför bedömer Red Hat sårbarheten lägre än php.net?
Red Hat använder en egen bedömning enligt CVSS v3.1 och klassar CVE-2026-109618 som Important, eftersom utnyttjandet kräver exakt timing. php.net bedömer med CVSS v4.0 9,2. Båda anser kodkörning utan inloggning möjlig, uppdateringen behövs i varje fall.
Får AlmaLinux och Rocky Linux rättningarna automatiskt?
Båda bygger om sina paket från Red Hats källor och publicerar egna säkerhetsmeddelanden. Tidpunkten kan avvika från Red Hat. Kontrollera därför nivån på det egna systemet och i meddelandena från er distribution.
Räcker systemctl reload php-fpm efter uppdateringen?
Nej. Red Hat påpekar uttryckligen att en omladdning inte räcker, eftersom befintliga workers kan behålla det berörda tillståndet. Starta om alla workers, vid mod_php Apache-tjänsten httpd.