# RHEL, AlmaLinux och Rocky Linux: kontrollera PHP-patchen

> Kontrollera PHP-patch på RHEL, AlmaLinux och Rocky: vad Red Hat rapporterar om PHP2Shell, hur ni frågar efter errata, changelog och moduler och startar om rätt.

Källa: https://phpsos.de/sv/blog/rhel-almalinux-rocky-php/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**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.

```bash
# 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](https://phpsos.de/sv/blog/cve-im-changelog-nachweisen/).

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](https://phpsos.de/sv/php2shell/php-version-pruefen/).

## 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:

```bash
# 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](https://phpsos.de/sv/php2shell/php-fpm-neustart/).

## 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.enabled` bortkommenterad i den levererade konfigurationen, funktionen alltså aktiv som standard. Värdet `0` måste sättas uttryckligen.
- **Sätt så att det inte går att skriva över:** via `php_admin_value` i PHP-FPM-poolen, vid mod_php i Apache-konfigurationen. Inte via `ini_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_size` i 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.

> **Tips:**
> 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](https://phpsos.de/sv/blog/remi-repository-php/).

## 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](https://phpsos.de/sv/leistungen/php-patch-service/).


## 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.

## Källor

- [Red Hat Security Bulletin RHSB-2026-013](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [php.net: säkerhetsmeddelanden](https://www.php.net/)