# Säkra FrankenPHP

> FrankenPHP säkerhet efter PHP2Shell: kontrollera den inbäddade PHP-versionen, bygg om binär eller image, starta om workers rent och härda värdena.

Källa: https://phpsos.de/sv/server/frankenphp/  
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:** FrankenPHP är en applikationsserver baserad på Caddy som bäddar in PHP i sitt eget program. För säkerheten i FrankenPHP efter PHP2Shell betyder det: det är inte distributionens PHP-paket som räknas utan PHP-versionen i FrankenPHP-binären eller container-imagen. Bygg eller hämta en version med åtgärdad PHP och starta om alla workers.

## Varför FrankenPHP patchas annorlunda

I klassiska uppsättningar levererar distributionen PHP som ett paket, och en uppdatering byter ut filerna. FrankenPHP innehåller däremot PHP som ett inbäddat bibliotek. Den som använder den officiella binären eller en container-image som bygger på den får PHP med på köpet. En `apt upgrade` på värden ändrar ingenting i det.

PHP2Shell omfattar CVE-2026-109618 och CVE-2026-109619, vardera med CVSS v4.0 9,2. PHP-projektet nämner uttryckligen FrankenPHP bland de berörda driftlägena. Åtgärdade är PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Det avgörande är alltså mot vilken PHP-version er FrankenPHP har byggts.

## Worker-läget och PHP2Shell

FrankenPHP kan köra applikationer i worker-läge. Då laddas applikationen en gång och hanterar sedan många förfrågningar efter varandra i samma process. Det ger snabbhet men förlänger livslängden för varje process.

CVE-2026-109619 beskriver en förfrågans interna tillstånd som kan finnas kvar efter att minnet frigjorts; en senare förfrågan i samma worker kan använda det innan det återställs. I worker-läget är samspelet mellan många förfrågningar i en process normalfallet. Det är ingen anledning att avstå från worker-läget, men en tydlig anledning att genomföra uppdateringar och omstarter särskilt noggrant. Tekniska detaljer finns under [CVE-2026-109619](https://phpsos.de/sv/php2shell/cve-2026-109619/).

## Säkerhet i FrankenPHP: kontrollera versionen

Kontrollera den inbäddade PHP-versionen direkt i det system som körs. Följande kommandon läser bara; namn på tjänster och containrar är exempel.

```bash
# Installerad binär
frankenphp version

# I den körande containern (containernamn som exempel)
docker exec app frankenphp version
docker exec app php -v

# Vilken image körs faktiskt? (digest visar exakt version)
docker inspect --format '{{.Image}} {{.Config.Image}}' app
```

Anteckna PHP-versionen från utskriften. Ligger den före de åtgärdade versionerna är systemet sårbart. Kontrollera alltid den container som körs, inte bara den senast byggda imagen, eftersom en ny image först får effekt när containrarna har bytts ut.

## Installera uppdateringen och starta om alla workers

Hur uppdateringen ser ut beror på er installation:

- **Binär på värden:** installera en ny FrankenPHP-release med åtgärdad PHP-version och starta om tjänsten.
- **Container:** hämta en bas-image med åtgärdad PHP-version, bygg den egna imagen på nytt utan cache för baslagret och byt ut containern.
- **Egenkompilerad:** bygg om mot den åtgärdade PHP-versionen och generera alla tillägg på nytt med samma version.

```bash
# Exempel värdinstallation som systemd-tjänst
systemctl restart frankenphp

# Exempel Docker Compose: bygg om utan cache och ersätt containern
docker compose build --pull --no-cache
docker compose up -d --force-recreate
```

Därefter kontrollerar ni PHP-versionen i den körande containern igen och processernas starttid. I worker-läget måste varje worker vara omstartad. För Kubernetes gäller ytterligare steg, beskrivna under [Patcha PHP i Kubernetes](https://phpsos.de/sv/server/kubernetes/), och för containrar i allmänhet under [Patcha PHP i Docker-containrar](https://phpsos.de/sv/php2shell/docker-container-patchen/).

> **Viktigt:**
> En tagg som `latest` eller en huvudversion i image-namnet garanterar inte att ni har den senaste versionen. Hämta bas-imagen aktivt på nytt och kontrollera därefter PHP-versionen i den körande containern.

## Tillfälliga åtgärder och härdning

Kan uppdateringen inte göras direkt rekommenderar php.net tillfälliga åtgärder som inte ger något fullständigt skydd. Med FrankenPHP sätter ni värdena i den php.ini som FrankenPHP laddar eller via PHP-inställningarna i Caddy-konfigurationen, inte via `ini_set()` i applikationen.

```ini
; php.ini i containern eller på värden
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
```

Med uppladdningsfunktion anger php.net `post_max_size = 32M`. På PHP 8.5 tillkommer `fatal_error_backtraces=0`. Minnesgränsen hör hemma på containernivå, till exempel som containerns minnesgräns, inte via `RLIMIT_AS` eller `RLIMIT_DATA`. Starta om alla workers efter varje ändring.

För kontinuerlig drift lönar det sig att referera images med fast digest, bygga om regelbundet och automatiserat och ta in en image-skanner i bygg-kedjan. En patch tar dessutom inte bort skadlig programvara som fördes in tidigare. Spara loggar från och med den 20 oktober 2026; för containrar betyder det att säkra dem innan de ersätts.

Den som använder FrankenPHP som statiskt byggd binär bör veta att där är förutom PHP även alla tillägg fast inbyggda. En uppdatering innebär därför alltid att hela binären byts ut. Kontrollera efter bytet versionen och listan över laddade tillägg för att se att allt är tillgängligt som förut, och testa applikationen innan ni förkastar den gamla versionen. I containermiljöer är det lämpligt att märka varje image med byggdatumet. Då kan ni när som helst följa upp vilken version som körde när, och vid behov gå tillbaka riktat utan att åter hamna på en sårbar version. Dokumentera kopplingen mellan image, PHP-version och tidpunkt.

## Hur hjälper PHP SOS konkret?

- Vi kontrollerar vilken PHP-version som faktiskt finns i era FrankenPHP-binärer och körande containrar.
- Via [PHP-patchtjänsten](https://phpsos.de/sv/leistungen/php-patch-service/) bygger vi om images, ersätter containrar och startar om alla workers, med belägg.
- Vi säkrar loggar före bytet och kontrollerar applikationen med avseende på spår.
- För kontinuerlig drift sätter vi upp automatiserade ombyggen och image-kontroller inom ramen för [serverhärdningen](https://phpsos.de/sv/leistungen/server-haertung/).


## Vanliga frågor

**Hjälper en apt- eller dnf-uppdatering med FrankenPHP?**  
Bara om FrankenPHP självt kommer från de paketkällorna och är byggt mot den patchade PHP-versionen. Ofta är PHP fast inbyggt i FrankenPHP-binären eller i container-imagen. Då måste ni uppdatera binären eller imagen.

**Varför är worker-läget särskilt viktigt vid PHP2Shell?**  
I worker-läget ligger applikationen kvar i minnet och hanterar många förfrågningar i följd i samma process. CVE-2026-109619 gäller just internt tillstånd som kan finnas kvar mellan förfrågningar i samma worker. En omstart av alla workers efter uppdateringen är därför ett måste.

**Hur kontrollerar jag vilken PHP-version som finns i FrankenPHP?**  
FrankenPHP-binären skriver ut den inbäddade PHP-versionen när versionen frågas efter. I en container kan ni köra kommandot via docker exec. Se till att kontrollera versionen i den container som faktiskt körs, inte i den nybyggda imagen.

**Finns det egna tillfälliga åtgärder för FrankenPHP?**  
De allmänna anvisningarna från php.net gäller. Ni sätter värdena i den php.ini som FrankenPHP laddar eller i PHP-konfigurationen i Caddy-filen, inte via ini_set() i applikationen. Starta därefter om alla workers.

## Källor

- [php.net: säkerhetsmeddelanden](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)