# Kontrollér PHP-version og rettelsesstatus korrekt

> Kontrollér PHP-versionen korrekt: sådan genkender I rettelsesstatus, distributionens backports og kørende processer og ved, om PHP2Shell er lukket.

Kilde: https://phpsos.de/da/php2shell/php-version-pruefen/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** For at kontrollere PHP-versionen er `php -v` ikke nok. I skal vide, hvilken PHP-version webserveren faktisk bruger, om pakken indeholder rettelsen, også som backport med gammelt nummer, og om alle processer er blevet genstartet efter opdateringen. PHP2Shell er rettet i 8.5.12, 8.4.27, 8.3.36 og 8.2.35.

## Hvorfor versionsnummeret alene ikke er nok

Til PHP2Shell findes der en klar liste over rettede versioner. I praksis fører tre situationer alligevel til fejlvurderinger:

- **Flere installationer:** Kommandolinjen viser PHP 8.3, men websitet kører via en pool med PHP 8.1.
- **Backports:** Distributioner og hostingudbydere indspiller nogle gange rettelser i eksisterende pakker. Så viser f.eks. Plesk fortsat 8.2.34, selv om der er rettet.
- **Gamle processer:** De nye filer ligger på disken, men de kørende workers stammer stadig fra før.

For direktion og ikke-teknikere hjælper en enkel tommelfingerregel: Spørg ikke kun »Hvilken PHP-version har vi?«, men »Er PHP2Shell lukket på alle servere, og hvordan kan vi se det?«. Et holdbart svar indeholder tre beviser: version eller backport, pakkestatus og tidspunktet for genstarten.

Den tekniske kontrol har derfor tre trin: version, pakkestatus, kørende processer. Kommandoerne nedenfor er rent læsende. Pakke- og tjenestenavne afviger fra distribution til distribution, PHP-kilde og hostinggrænseflade; eksemplerne tager udgangspunkt i PHP 8.3.

## Kontrollér PHP-version på kommandolinjen

```bash
php -v                                  # version i kommandolinjen
ls /etc/php/ 2>/dev/null                # Debian/Ubuntu: installerede grene
php-fpm8.3 -v                           # version af FPM-binæren (navnet varierer fra distribution til distribution)
php -i | grep -E "^PHP Version|Server API|Loaded Configuration File"
```

Under RHEL, AlmaLinux eller Rocky hedder FPM-binæren som regel `php-fpm`; ved software collections eller fremmede kilder ligger yderligere versioner i egne stier. Plesk og cPanel medbringer egne PHP-installationer, som findes ved siden af system-PHP'en. Hvordan I går frem dér, beskriver vi på siderne om [Plesk](https://phpsos.de/da/server/plesk/) og cPanel.

Hvilken PHP-version et website bruger i webkonteksten, ser I mest pålideligt i pool- eller VirtualHost-konfigurationen eller i hostinggrænsefladen. En phpinfo-side viser det ligeledes; opret den kun kortvarigt, med adgangsbeskyttelse og tilfældigt navn, og slet den straks bagefter.

Ved shared hosting har I som regel ikke adgang til kommandolinjen. Så viser hostinggrænsefladen den indstillede PHP-version pr. website. Om en backport er indspillet og genstartet, står dér sjældent. Her er hostingudbyderens skriftlige bekræftelse den pålidelige vej.

## Kontrollér pakkestatus og backports

Pakkestatus viser, hvad jeres distribution faktisk har leveret:

```bash
# Debian/Ubuntu
apt policy php8.3-fpm
apt changelog php8.3-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"

# RHEL, AlmaLinux, Rocky, Fedora
dnf info php-fpm
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619"
```

Står et af CVE-numrene i changelog, er backporten med i den installerede pakke. Mangler indførslen, er det endnu ikke et bevis på en sårbarhed: Nogle pakkevedligeholdere formulerer changelogs anderledes. Så sammenligner I pakkeversionen med jeres distributions sikkerhedsmeddelelser eller spørger udbyderen. En skabelon til denne forespørgsel finder I under [Sådan spørger I jeres hostingudbyder om rettelsesstatus](https://phpsos.de/da/ratgeber/hoster-patch-status-erfragen/).

Vigtigt: Kontrollér hver installeret PHP-pakke, ikke kun den første. På servere med flere grene er ofte én rettet og en anden ikke.

## Kører den nye version også virkelig?

En opdatering virker først, når alle PHP-processer er genstartet. Sammenhold starttidspunktet for de kørende processer med tidspunktet for opdateringen:

```bash
ps -o pid,lstart,cmd -C php-fpm8.3      # starttidspunkt for FPM-processerne
systemctl status php8.3-fpm             # siden hvornår tjenesten kører
needrestart -r l                        # Debian/Ubuntu, hvis installeret: viser forældede processer
```

Ligger starttidspunktet før opdateringen, kører der stadig gamle processer. Ved Apache med mod_php gælder det samme for Apache-processerne. Hvordan I genstarter rent, beskriver [Genstart PHP-FPM og alle workers](https://phpsos.de/da/php2shell/php-fpm-neustart/).

> **Tip:**
> Hold resultatet fast skriftligt: server, PHP-version, pakkeversion, CVE i changelog ja eller nej, tidspunkt for genstarten. Denne notits får I brug for til direktionen, forsikringsselskabet og en senere sporkontrol.

## Vurdér resultatet

| Fund | Vurdering |
|---|---|
| Officiel version 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, processer genstartet | PHP2Shell lukket |
| Ældre nummer, CVE-numre i pakkens changelog, processer genstartet | Backport indspillet, lukket |
| Ældre nummer, ingen indførsel i changelog, ingen bekræftelse | uklart, afklar hos udbyderen |
| PHP 8.1 eller ældre uden bekræftet backport | åben, midlertidige foranstaltninger og migrering nødvendig |
| Processer ældre end opdateringen | genstart mangler, sårbarheden stadig aktiv |

Forbliver en server i status »uklart«, behandler I den som en åben: Sæt midlertidige foranstaltninger og følg afklaringen op, til der foreligger et bevis. Det fulde versionsoverblik står under [Hvilke PHP-versioner er berørt?](https://phpsos.de/da/php2shell/betroffene-php-versionen/).

## Hvordan hjælper PHP SOS konkret?

Med [PHP-patch-servicen](https://phpsos.de/da/leistungen/php-patch-service/) overtager vi kontrollen og dokumentationen:

- **Finde alle installationer,** også sekundære versioner fra hostingpaneler, software collections eller containere.
- **Vurdere pakkestatus:** officiel release, backport eller åben, med bevis fra changelog eller fra udbyderen.
- **Kontrollere genstarten,** til ingen proces med gammel kode kører længere.
- **Udarbejde en kontrolprotokol,** som I kan bruge internt og over for tredjepart.


## Ofte stillede spørgsmål

**Hvorfor viser php -v en anden version end mit website?**  
På mange servere er der installeret flere PHP-versioner. Kommandolinjen bruger en af dem, webserveren eller en FPM-pool en anden. Kontrollér derfor den version, der faktisk kører i webkonteksten, f.eks. via FPM-binæren eller hostinggrænsefladen.

**Hvordan genkender jeg en backport?**  
Ved distributionspakker står rettelsen ofte i pakkens changelog, hyppigt med CVE-nummeret. Under Debian og Ubuntu hjælper apt changelog, under RHEL-lignende systemer rpm -q --changelog. Mangler indførslen, afklarer I status hos udbyderen.

**Kan jeg kontrollere PHP-versionen i hostingens kundemenu?**  
Ja, de fleste grænseflader viser den indstillede version pr. website. Om en backport er indspillet og genstartet, kan I dér som regel ikke se. Her er en skriftlig bekræftelse fra hostingudbyderen den pålidelige vej.

## Kilder

- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: Understøttede versioner](https://www.php.net/supported-versions.php)