Kort sagt: Säkerhetsluckor i PHP rapporteras konfidentiellt, helst via det privata advisory-formuläret i GitHub-repositoryt php/php-src, alternativt till security@php.net. PHP-utvecklarna klassar fyndet som högt, medelhögt eller lågt; allvarliga fel rättas i ett separat säkerhetsrepository och publiceras först med releasen tillsammans med ett GitHub Security Advisory och oftast ett CVE-nummer. Vid PHP2Shell gick den här processen i rasande fart: förhandsbesked den 20 oktober 2026, patchar den 21 oktober 2026, kompletterande anvisning den 23 oktober 2026.
Vem tar hand om säkerheten i PHP?
PHP är ett öppen källkod-projekt. Säkerhetspolicyn i wikin beskriver det som ett projekt av volontärer utan budget för belöningar. För varje version finns release managers som ansvarar för utgivningen. Dessutom finns PHP Foundation, som enligt egen beskrivning anlitar ett team av deltids- och heltidsutvecklare som arbetar med underhåll, säkerhet och nya funktioner i PHP.
För företag betyder det: Det finns ingen tillverkare med avtal, hotline eller garanterade svarstider. Den som behöver bindande löften får dem av sin Linux-distribution, sitt webbhotell eller en leverantör av långtidssupport, inte av PHP-projektet självt. Den här leveranskedjan bör ni känna till.
Så rapporteras en lucka
Vägen är beskriven i säkerhetspolicyn på GitHub:
- Rapportera: via det privata formuläret för Security Advisories i repositoryt
php/php-src. Den som inte kan använda det eller vill diskutera ett ämne som inte är en felrapport skriver till security@php.net. - Beskriva kortfattat: Önskvärt är ett kort exempel som visar felet, inte en lång rapport om möjliga konsekvenser. Då kan teamet gå igenom det snabbare.
- Konfidentialitet: Rapporten förblir privat fram till publiceringen.
- Omnämnande: Den som rapporterar nämns som bidragsgivare enligt MITRE:s credit-system.
Den äldre wiki-sidan nämner dessutom den klassiska felspåraren med typen ”Security”. Avgörande är idag vägen via GitHub.
Vad PHP-projektet klassar som säkerhetslucka
Inte varje krasch är en säkerhetslucka. Wikin nämner fyra kriterier: Ett fel tillåter obehöriga åtgärder, överskrider säkerhetsgränser, öppnar åtkomst till andras data eller försämrar tillgänglighet eller prestanda allvarligt. Klassningen sker i tre nivåer:
| Nivå | Betydelse enligt policyn | CVE-nummer |
|---|---|---|
| Hög | Tredje part kan kompromettera de flesta installationer, köra kod eller läsa filer | i regel ja |
| Medel | liknande verkan, men bara under ovanligare villkor, till exempel ett sällsynt tillägg eller en sällsynt konfiguration | oftast ja |
| Låg | teoretiskt möjlig, i praktiken mycket svår att utnyttja | oftast nej |
Lika upplysande är listan över det som uttryckligen inte är en säkerhetslucka: skadlig kod som körs avsiktligt, kringgående av open_basedir och disable_functions, skadlig indata till unserialize(), användning av FFI och ett vanligt minnesavbrott där memory_limit slår till och bara den aktuella förfrågan tar slut. För driftansvariga betyder det: disable_functions är en vettig härdning men ingen skyddsvall.
Från rättelse till publicering
Rättelser för höga och medelhöga luckor förs enligt wikin in i ett separat säkerhetsrepository innan releasen skapas. Lågt klassade fel hanteras som vanliga felrättningar. Luckan publiceras enligt principen om ansvarsfullt avslöjande: först rättelsen, sedan detaljerna. Releaser kommer enligt wikin oftast på torsdagar, ofta inom ramen för de ordinarie månatliga utgivningarna.
Med releasen kommer ett GitHub Security Advisory med egen beteckning (GHSA) och allvarlighetsgrad. I repositoryt har till exempel den 24 september 2026 flera advisories om stream wrappers, FastCGI och filter publicerats, med allvarlighetsgrader från låg till hög. Källpaketen på php.net erbjuds med SHA-256-kontrollsummor och GPG-signaturer från release managers; git-taggarna är signerade. Vilka versionsgrenar som alls fortfarande får säkerhetsrättelser visar sidan om PHP-versioner och release-cykeln.
PHP2Shell som exempel på skarpt läge
PHP2Shell visar hur processen fungerar under tryck:
- 20 oktober 2026: php.net tillkännager en kritisk säkerhetsrelease för den 21 oktober 2026 kl. 14:00 UTC och förbehåller sig rätten att publicera tidigare om detaljer blir offentliga eller attacker dyker upp. Enligt flera rapporter hade detaljer faktiskt blivit kända före spärrfristens slut; bakgrunden belyser Varför PHP-luckan blev känd före patchen.
- 21 oktober 2026: PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35 kommer, dessutom advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) och GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), båda klassade som kritiska. Enligt php.net hade Linux-distributioner och leverantörer av långtidssupport fått rättelserna i förväg. För 7.4, 8.0 och 8.1 finns minimala backports.
- 23 oktober 2026: En informativ anvisning om CVE-2026-115560 rekommenderar
session.upload_progress.enabled=0; det fullständiga advisoryt följer med nästa release.
Vad driftansvariga kan dra av det
- Prenumerera på källor: php.net, GitHub-advisories från
php/php-srcoch säkerhetsmeddelandena från er distribution. - Känna leveranskedjan: Vem levererar ert PHP-paket, och hur snabbt kommer backports dit?
- Planera tidsfönster: Kritiska releaser kan komma utanför den vanliga takten; ett patchfönster måste kunna ordnas med kort varsel.
- Planera omstart: En uppdatering verkar först när alla PHP-processer har startats om.
- Säkra bevis: Dokumentera version, paketläge och tidpunkt.
Hur hjälper PHP SOS konkret?
Med PHP-patchtjänsten tar vi över den del som ligger hos er:
- Följa meddelanden: Vi bevakar php.net, advisories och distributionernas meddelanden och bedömer om era system berörs.
- Genomföra patchen: Uppdatering från rätt källa, omstart av alla processer, kontroll av den körande versionen.
- Säkra övergången: Där uppdateringen fastnar genomför vi de officiella tillfälliga åtgärderna.
- Dokumentera: Ni får ett bevis med versioner, paketlägen och tidpunkter.
Vanliga frågor
Hur rapporterar man en säkerhetslucka i PHP?
Helst via det privata rapporteringsformuläret för Security Advisories i GitHub-repositoryt php/php-src. Den som inte kan använda det skriver till security@php.net. Rapporten förblir konfidentiell fram till publiceringen.
Betalar PHP-projektet belöning för hittade luckor?
Nej. Enligt säkerhetspolicyn är PHP ett projekt av volontärer utan pengar för bug bounties. Den som rapporterar nämns dock som bidragsgivare.
Är ett kringgående av disable_functions en säkerhetslucka?
Enligt PHP-projektets policy inte. Kringgående av open_basedir och disable_functions räknas inte som säkerhetsproblem i PHP. Inställningarna är härdning men ingen pålitlig säkerhetsgräns.
Var får jag veta om nya PHP-säkerhetsluckor?
På php.nets startsida med release-meddelandena och i Security Advisories i GitHub-repositoryt php/php-src. Den som får PHP från sin distribution följer dessutom distributionens säkerhetsmeddelanden.
Varför publicerades PHP2Shell en onsdag?
Releaser kommer enligt wikin oftast på torsdagar. För PHP2Shell tillkännagav php.net den 20 oktober 2026 en säkerhetsrelease för onsdagen den 21 oktober 2026 kl. 14:00 UTC och förbehöll sig rätten att publicera tidigare om detaljer skulle bli offentliga.