Ofte stillede spørgsmål
Hvilke PHP-versioner er berørt?
Alle versioner før 8.5.12, 8.4.27, 8.3.36 og 8.2.35 i de understøttede grene. PHP 8.1 og ældre er end of life og får ingen udgivelse fra PHP-projektet; betragt dem som berørte, medmindre din leverandør bekræfter en backportet rettelse.
Mit website viser ingen PHP-version. Er jeg sikker?
Ikke nødvendigvis. At skjule versionen (expose_php = Off) er god praksis, men patcher ikke noget. Tjek på serveren med php -v, eller spørg din udbyder.
Værktøjet viser en gammel version, men min host siger, at den er patchet. Hvem har ret?
Måske begge. Linux-distributioner som Debian, Ubuntu og RHEL backporter ofte sikkerhedsrettelser uden at ændre versionsnummeret. Spørg din host, hvilket pakkebuild der er installeret, og om dets changelog nævner CVE-2026-109618 og CVE-2026-109619.
Er WordPress, Laravel eller mit CMS berørt?
Fejlene sidder i selve PHP, så enhver applikation, der kører på en berørt PHP, er eksponeret. Forskerne demonstrerede angreb uden autentificering på WordPress, Drupal og Joomla, men det var kun eksempler — selv en almindelig »Hello World«-side er nok. At opdatere WordPress eller plugins løser det ikke; PHP skal opdateres.
Kan data lække, selv om der ikke blev kørt kode?
Ja. CVE-2026-109619 kan afsløre PHP-processens hukommelse — adgangskoder, sessionstokens, API-nøgler og certifikater fra andre forespørgsler — uden at angriberen kører kode. Sådanne læk efterlader ingen filer og er svære at opdage, så skift hemmelighederne for ethvert website, der har kørt en berørt version på internettet.
Hjælper det at slå session.upload_progress fra?
Nej. php.net angiver session.upload_progress.enabled=0 som en delvis afhjælpning for nogle bekræftede veje i CVE-2026-109619. Det dækker ikke alle varianter og gør intet mod CVE-2026-109618.
Er en web application firewall nok?
En WAF eller forespørgselsgrænser kan mindske eksponeringen, mens du opdaterer, men problemerne ligger i, hvordan PHP håndterer forespørgsler og hukommelse. Opdatering er stadig nødvendig.
Skal jeg genstarte noget efter opdateringen?
Ja. PHP-FPM, Apache, LiteSpeed og langtkørende workers fortsætter med at køre den gamle kode, indtil de genstartes. Containere skal genskabes fra det nye image.
Hvad gør dette værktøj egentlig?
Det sender én HEAD-forespørgsel (eller en GET, hvis HEAD ikke er tilladt) til den adresse, du indtaster, følger op til tre omdirigeringer og læser svar-headers som X-Powered-By og Server. Det sender aldrig exploit-payloads, store forespørgsler eller uploads, og det scanner ikke andre stier.
Er det lovligt at tjekke et hvilket som helst website?
Tjek kun websites, du ejer eller har tilladelse til at vurdere. Forespørgslen er den samme som et normalt besøg, men ansvarlig brug er dit ansvar. Vi begrænser antallet af tjek pr. netværk og pr. website.
Blev PHP 8.5.12 rettet fuldstændigt?
Den 22. oktober 2026 cirkulerede rapporter om et nedbrud i 8.5.12, men de blev ikke bekræftet som en fjernudnyttelig sårbarhed. Vi følger php.net; hvis en ny udgivelse kommer, opdateres dette website, og datoen for »senest verificeret« ændres.
Hvor kan jeg læse de officielle detaljer?
På php.net og i PHP-projektets GitHub-meddelelser GHSA-w8hw-w9fx-j79w og GHSA-6wmf-4rv5-p3rp. Forskerholdet (Wiz Research, OpenAI Codex Security og Calif) har offentliggjort sine resultater på php2shell.com.
Hvem fandt sårbarhederne?
Forskere fra Wiz Research, OpenAI Codex Security og Calif, gennem koordineret offentliggørelse med PHP’s sikkerhedsteam, som udarbejdede rettelserne. Se The PHP Foundations indlæg om udgivelsen.