Kort sagt: FrankenPHP er en applikationsserver baseret på Caddy, der indlejrer PHP i sit eget program. For FrankenPHP-sikkerheden efter PHP2Shell betyder det: Ikke distributionens PHP-pakker tæller, men PHP-versionen i FrankenPHP-binærfilen eller container-imaget. Byg eller hent en udgave med rettet PHP, og genstart alle workere.
Hvorfor FrankenPHP patches anderledes
Ved klassiske opsætninger leverer distributionen PHP som pakke, og en opdatering udskifter filerne. FrankenPHP indeholder derimod PHP som indlejret bibliotek. Den, der bruger den officielle binære fil eller et container-image bygget oven på den, får PHP med i købet. En apt upgrade på værten ændrer ikke ved det.
PHP2Shell omfatter CVE-2026-109618 og CVE-2026-109619, hver med CVSS v4.0 9,2. PHP-projektet nævner udtrykkeligt FrankenPHP blandt de berørte driftsformer. Rettet er PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Afgørende er altså, mod hvilken PHP-version jeres FrankenPHP er bygget.
Worker-tilstand og PHP2Shell
FrankenPHP kan drive applikationer i worker-tilstand. Her indlæses applikationen én gang og behandler derefter mange forespørgsler efter hinanden i samme proces. Det giver hastighed, men forlænger hver enkelt procesʼ levetid.
CVE-2026-109619 beskriver en forespørgsels interne tilstand, som kan blive stående efter frigivelse af hukommelsen; en senere forespørgsel i samme worker kan udnytte den, før den nulstilles. I worker-tilstand er samspillet mellem mange forespørgsler i én proces normaltilfældet. Det er ingen grund til at undvære worker-tilstanden, men en klar grund til at gennemføre opdateringer og genstarter særligt omhyggeligt. Tekniske detaljer står under CVE-2026-109619.
FrankenPHP-sikkerhed: kontrollér versionen
Kontrollér den indlejrede PHP-version direkte i det kørende system. Følgende kommandoer læser kun; navne på tjenester og containere er eksempler.
# Installeret binær fil
frankenphp version
# I den kørende container (containernavn som eksempel)
docker exec app frankenphp version
docker exec app php -v
# Hvilket image kører faktisk? (digest viser den præcise status)
docker inspect --format '{{.Image}} {{.Config.Image}}' app
Notér PHP-versionen fra outputtet. Ligger den før de rettede versioner, er systemet sårbart. Kontrollér altid den kørende container, ikke kun det sidst byggede image, for et nyt image virker først efter udskiftningen af containerne.
Indspil opdateringen og genstart alle workere
Hvordan opdateringen ser ud, afhænger af jeres installation:
- Binær fil på værten: installér en ny FrankenPHP-release med rettet PHP-version, genstart tjenesten.
- Container: hent basis-image med rettet PHP-version, byg eget image på ny uden cache for basislaget, udskift containeren.
- Selvkompileret: byg på ny mod den rettede PHP-version, generér alle udvidelser på ny med samme version.
# Eksempel på værtsinstallation som systemd-tjeneste
systemctl restart frankenphp
# Eksempel Docker Compose: byg på ny uden cache og udskift containeren
docker compose build --pull --no-cache
docker compose up -d --force-recreate
Bagefter kontrollerer I igen PHP-versionen i den kørende container og processernes starttidspunkt. I worker-tilstand skal hver worker være genstartet. Ved Kubernetes gælder yderligere trin, beskrevet under Patch PHP i Kubernetes, for containere generelt under Patch PHP i Docker-containere.
Et tag som latest eller en hovedversion i image-navnet garanterer ikke, at I har den nyeste status. Hent basis-imaget aktivt på ny, og kontrollér derefter PHP-versionen i den kørende container.
Midlertidige foranstaltninger og hærdning
Kan opdateringen ikke ske med det samme, anbefaler php.net midlertidige foranstaltninger, som ikke giver fuldstændig beskyttelse. Ved FrankenPHP sætter I værdierne i den php.ini, som FrankenPHP indlæser, eller via PHP-indstillingerne i Caddy-konfigurationen, ikke via ini_set() i applikationen.
; php.ini i containeren eller på værten
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Med upload-funktion angiver php.net post_max_size = 32M. På PHP 8.5 kommer fatal_error_backtraces=0 til. Hukommelsesgrænsen hører hjemme på container-niveau, f.eks. via containerens hukommelsesgrænse, ikke via RLIMIT_AS eller RLIMIT_DATA. Genstart alle workere efter hver ændring.
Til den løbende drift kan det betale sig at referere til images med fast digest, bygge regelmæssigt automatiseret på ny og tage en image-scanner med i build-kæden. En patch fjerner desuden ikke skadelig software, som blev smuglet ind tidligere. Gem logs fra og med 20.10.2026; ved containere betyder det, at I sikrer dem, før containeren udskiftes.
Den, der bruger FrankenPHP som statisk bygget binær fil, bør vide, at dér er ud over PHP også alle udvidelser indbygget fast. En opdatering betyder derfor altid at udskifte hele den binære fil. Kontrollér efter udskiftningen versionen og listen over indlæste udvidelser, om alt er tilgængeligt som før, og test applikationen, før I forkaster den gamle status. I container-miljøer anbefales det at mærke hvert image med byggedatoen. Så kan I til enhver tid spore, hvilken status der kørte hvornår, og i tvivlstilfælde gå målrettet tilbage uden igen at falde tilbage på en sårbar status. Notér tildelingen af image, PHP-version og tidspunkt i jeres dokumentation.
Hvordan hjælper PHP SOS konkret?
- Vi kontrollerer, hvilken PHP-version der faktisk sidder i jeres FrankenPHP-binære filer og kørende containere.
- Via PHP-patch-servicen bygger vi images på ny, udskifter containere og genstarter alle workere, med bevis.
- Vi sikrer logs før udskiftningen og undersøger applikationen for spor.
- Til den løbende drift opsætter vi automatiserede rebuilds og image-kontroller som led i serverhærdningen.
Ofte stillede spørgsmål
Hjælper en apt- eller dnf-opdatering ved FrankenPHP?
Kun hvis FrankenPHP selv stammer fra disse pakkekilder og er bygget mod den patchede PHP. Ofte er PHP indbygget fast i FrankenPHP-binærfilen eller i container-imaget. Så skal I opdatere binær fil eller image.
Hvorfor er worker-tilstanden særlig vigtig ved PHP2Shell?
I worker-tilstand bliver applikationen i hukommelsen og behandler mange forespørgsler efter hinanden i samme proces. CVE-2026-109619 berører netop intern tilstand, som kan blive stående mellem forespørgsler i samme worker. En genstart af alle workere efter opdateringen er derfor et must.
Hvordan kontrollerer jeg, hvilken PHP-version der sidder i FrankenPHP?
FrankenPHP-binærfilen udskriver ved versionskald den indlejrede PHP-version. I containeren kan I køre kommandoen via docker exec. Sørg for at kontrollere versionen i den faktisk kørende container, ikke i det nybyggede image.
Findes der egne midlertidige foranstaltninger til FrankenPHP?
De generelle henvisninger fra php.net gælder. I sætter værdierne i den php.ini, som FrankenPHP indlæser, eller i PHP-konfigurationen i Caddy-filen, ikke via ini_set() i applikationen. Genstart derefter alle workere.