Kort sagt: Sårbarheder i PHP indberettes fortroligt, helst via den private advisory-formular i GitHub-repositoriet php/php-src, alternativt til security@php.net. PHP-udviklerne klassificerer fundet som højt, middel eller lavt; alvorlige fejl rettes i et adskilt sikkerheds-repositorium og offentliggøres først med udgivelsen sammen med et GitHub Security Advisory og oftest et CVE-nummer. Ved PHP2Shell forløb denne proces i hastigt tempo: Forudgående varsling den 20.10.2026, patches den 21.10.2026, supplerende henvisning den 23.10.2026.
Hvem tager sig af sikkerheden hos PHP?
PHP er et open source-projekt. Sikkerhedspolitikken i wikien beskriver det som et projekt af frivillige uden budget til dusører. For hver version findes der release managers, som er ansvarlige for udgivelserne. Dertil kommer PHP Foundation, som ifølge egen fremstilling hyrer et team af deltids- og fuldtidsudviklere, der arbejder med vedligeholdelse, sikkerhed og nye funktioner i PHP.
For virksomheder betyder det: Der findes ingen producent med kontrakt, hotline eller tilsikrede reaktionstider. Den, der har brug for bindende tilsagn, får dem fra sin Linux-distribution, sin hostingudbyder eller en udbyder af langtidssupport, ikke fra PHP-projektet selv. Denne forsyningskæde bør I kende.
Sådan indberettes en sårbarhed
Vejen er beskrevet i sikkerhedspolitikken på GitHub:
- Indberette: via den private formular til security advisories i repositoriet
php/php-src. Den, der ikke kan bruge den eller vil drøfte et emne, som ikke er en fejlrapport, skriver til security@php.net. - Beskrive kortfattet: Ønsket er et kort eksempel, der viser fejlen, ikke en lang rapport om mulige følger. Så kan teamet gennemgå den hurtigere.
- Fortrolighed: Indberetningen forbliver privat indtil offentliggørelsen.
- Omtale: Indberettere nævnes efter MITRE's credit-system som bidragydere.
Den ældre wiki-side nævner desuden den klassiske fejl-tracker med typen »Security«. Afgørende er i dag vejen via GitHub.
Hvad PHP-projektet klassificerer som sikkerhedssårbarhed
Ikke ethvert nedbrud er en sikkerhedssårbarhed. Wikien nævner fire kriterier: En fejl tillader uberettigede handlinger, overskrider sikkerhedsgrænser, åbner adgang til fremmede data eller forringer tilgængeligheden eller ydelsen alvorligt. Der klassificeres i tre niveauer:
| Niveau | Betydning ifølge politikken | CVE-nummer |
|---|---|---|
| Højt | Tredjeparter kan kompromittere de fleste installationer, udføre kode eller læse filer | som regel ja |
| Middel | lignende virkning, men kun under sjældnere betingelser, f.eks. en sjælden udvidelse eller konfiguration | oftest ja |
| Lavt | teoretisk muligt, i praksis meget vanskeligt at udnytte | oftest nej |
Lige så oplysende er listen over, hvad der udtrykkeligt ikke er en sikkerhedssårbarhed: ondsindet kode, der udføres bevidst, omgåelser af open_basedir og disable_functions, ondsindede inddata til unserialize(), brugen af FFI og en almindelig hukommelsesafbrydelse, hvor memory_limit slår til, og kun den aktuelle forespørgsel slutter. For driftsansvarlige betyder det: disable_functions er fornuftig hærdning, men ingen forsvarsmur.
Fra rettelse til offentliggørelse
Rettelser til høje og middel sårbarheder indarbejdes ifølge wikien i et adskilt sikkerheds-repositorium, før udgivelsen oprettes. Sårbarheder med lav klassificering behandles som almindelige fejlrettelser. Sårbarheden offentliggøres efter princippet om ansvarlig offentliggørelse: først rettelsen, derefter detaljerne. Udgivelser kommer ifølge wikien oftest om torsdagen, hyppigt som led i de regulære månedlige udgivelser.
Med udgivelsen kommer et GitHub Security Advisory med egen identifikator (GHSA) og alvorlighedsgrad. I repositoriet er der for eksempel den 24.09.2026 udkommet flere advisories om stream wrappers, FastCGI og filtre med alvorlighedsgrader fra lav til høj. Kildepakkerne på php.net tilbydes med SHA-256-kontrolsummer og GPG-signaturer fra release managers; git-tags er signeret. Hvilke versionsgrene der overhovedet endnu får sikkerhedsrettelser, viser siden om PHP-versioner og release-cyklussen.
PHP2Shell som eksempel på alvorlige tilfælde
PHP2Shell viser, hvordan processen forløber under pres:
- 20.10.2026: php.net varsler en kritisk sikkerhedsudgivelse til den 21.10.2026 kl. 14:00 UTC og forbeholder sig at udgive tidligere, hvis detaljer bliver offentlige, eller angreb dukker op. Ifølge flere rapporter var detaljer faktisk blevet kendt før udløbet af spærrefristen; baggrunden belyser Hvorfor PHP-sårbarheden blev kendt før patchen.
- 21.10.2026: PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35 udkommer, dertil advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) og GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), begge klassificeret som kritiske. Ifølge php.net havde Linux-distributioner og udbydere af langtidssupport modtaget rettelserne på forhånd. For 7.4, 8.0 og 8.1 findes der minimale backports.
- 23.10.2026: En informativ henvisning om CVE-2026-115560 anbefaler
session.upload_progress.enabled=0; det fulde advisory følger med den næste udgivelse.
Hvad driftsansvarlige kan udlede heraf
- Abonnere på kilder: php.net, GitHub-advisories fra
php/php-srcog sikkerhedsmeddelelserne fra jeres distribution. - Kende forsyningskæden: Hvem leverer jeres PHP-pakke, og hvor hurtigt kommer backports frem dér?
- Planlægge tidsvinduer: Kritiske udgivelser kan komme uden for den sædvanlige rytme; et patch-vindue skal kunne åbnes med kort varsel.
- Indplanlægge genstart: En opdatering virker først, når alle PHP-processer er genstartet.
- Sikre dokumentation: Dokumentér version, pakkestatus og tidspunkt.
Hvordan hjælper PHP SOS konkret?
Med PHP-patchservicen overtager vi den del, der ligger hos jer:
- Følge meddelelser: Vi iagttager php.net, advisories og distributionernes meddelelser og vurderer, om jeres systemer er berørt.
- Gennemføre patchen: Opdatering fra den passende kilde, genstart af alle processer, kontrol af den kørende version.
- Sikre overgangen: Hvor opdateringen hænger, gennemfører vi de officielle midlertidige foranstaltninger.
- Dokumentere: I får en dokumentation med versioner, pakkestatus og tidspunkter.
Ofte stillede spørgsmål
Hvordan indberetter man en sårbarhed i PHP?
Helst via den private indberetningsformular til security advisories i GitHub-repositoriet php/php-src. Den, der ikke kan bruge den, skriver til security@php.net. Indberetningen forbliver fortrolig indtil offentliggørelsen.
Betaler PHP-projektet en dusør for fundne sårbarheder?
Nej. Ifølge sikkerhedspolitikken er PHP et projekt af frivillige uden penge til bug bounties. Indberettere nævnes dog som bidragydere.
Er en omgåelse af disable_functions en sikkerhedssårbarhed?
Ifølge PHP-projektets politik ikke. Omgåelser af open_basedir og disable_functions gælder ikke som sikkerhedsproblem i PHP. Indstillingerne er hærdning, men ingen pålidelig sikkerhedsgrænse.
Hvor erfarer jeg om nye PHP-sårbarheder?
På php.net's forside med udgivelsesmeddelelserne og i security advisories i GitHub-repositoriet php/php-src. Den, der får PHP fra distributionen, følger desuden dens sikkerhedsmeddelelser.
Hvorfor blev PHP2Shell offentliggjort på en onsdag?
Udgivelser kommer ifølge wikien oftest om torsdagen. Til PHP2Shell varslede php.net den 20.10.2026 en sikkerhedsudgivelse til onsdag den 21.10.2026 kl. 14:00 UTC og forbeholdt sig at udgive tidligere, hvis detaljer blev offentlige.