PHP-hull stengte norske tjenester – oppdateringene er klare

Etter varselet om to kritiske PHP-feil 21. oktober 2026 stengte Sikt tilgangen til Feide, Digitaliseringsdirektoratet tok ned nettsidene sine, og OsloMets nettsider ble utilgjengelige, ifølge Shifters omtale av stengningene. Tiltakene ble satt inn fordi tjenestene kunne være sårbare. Stengningene viser ikke i seg selv at uvedkommende fikk tilgang.

PHP publiserte sikkerhetsrettelsene 21. oktober: PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35 retter CVE-2026-109618 og CVE-2026-109619, som kan gi kodekjøring uten innlogging. Installasjoner som kjører eldre utgaver i disse grenene, trenger oppdatering. For eldre PHP-grener må systemeiere undersøke om driftsleverandøren har levert en tilbakeført rettelse, eller planlegge overgang til en støttet utgave.

Stengningene rammet både nettsider og innlogging

Feide har en annen rolle enn en vanlig institusjonsnettside: Tjenesten brukes til innlogging i utdannings- og forskningssektoren. Når tilgangen til den stenges, kan brukere miste inngangen til digitale tjenester selv om disse tjenestene ellers fungerer. For Digitaliseringsdirektoratet og OsloMet var den synlige følgen utilgjengelige nettsider. De ulike utslagene sprang ut av den samme vurderingen av mulig eksponering for PHP-feilene.

Ved et varsel om mulig kodekjøring over internett kan en driftsansvarlig velge å stenge trafikken før det er avklart om en angriper har forsøkt å utnytte feilen. Det reduserer tiden en mulig sårbar installasjon er tilgjengelig, mens den kjørende PHP-utgaven og leverandørens rettelser undersøkes. En rettelse som er publisert, beskytter først tjenesten når den faktisk er installert i miljøet som håndterer forespørslene.

Disse PHP-installasjonene trenger oppdatering

Feilene gjelder PHP-installasjoner som betjener nettforespørsler. Det omfatter flere måter å kjøre PHP på, blant annet PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. Derfor kan både en offentlig nettside og innloggingen bak den være relevant, uavhengig av om virksomheten omtaler løsningen som et PHP-prosjekt. Det avgjørende er hvilken PHP-kode som faktisk kjøres når en forespørsel kommer inn.

Risikoen er særlig tydelig for Apache med mod_php. Her er det demonstrert en angrepsvei der en forespørsel uten innlogging kan utløse feilen før applikasjonens egen kode kjører. Dermed er kontroll av applikasjonens pålogging alene ikke nok til å avklare eksponeringen. Andre oppsett som tar imot nettforespørsler omfattes også av varselet, selv om den demonstrerte angrepsveien ikke er lik i alle miljøer.

De ordinære rettede utgavene gjelder hver sin vedlikeholdte versjonsgren. Eldre grener får ikke lenger vanlige sikkerhetsutgivelser direkte fra PHP-prosjektet. Det er gjort tilgjengelig begrensede kildekoderettelser for noen eldre grener, og enkelte Linux-distribusjoner og leverandører kan levere egne sikkerhetspakker. For slike installasjoner er spørsmålet om den konkrete pakken inneholder rettelsen, ikke bare hvilket versjonsnummer den viser.

Ny vurdering av angrepsaktiviteten

En oppdatert vurdering fra NCSC-NL 23. oktober beskriver én melding om mulig utnyttelse i utlandet, uten bekreftelse på at angrepet lyktes. Videre undersøkelser tilsier at feilene er kompliserte å utnytte, og at omfattende utnyttelse er mindre sannsynlig enn først anslått. Myndigheten fastholder likevel rådet om å installere sikkerhetsoppdateringene raskt.

Det er forskjell på en demonstrert angrepsvei, et mulig forsøk og et bekreftet innbrudd. De tidlige meldingene om aktivitet gir ikke grunnlag for å slå fast at de norske tjenestene ble kompromittert. Den lavere vurderte sannsynligheten for omfattende angrep endrer heller ikke hva en ubeskyttet, internetteksponert installasjon kan risikere dersom feilen faktisk utnyttes.

Prioriteringen for norske systemeiere

Først bør virksomheter kartlegge PHP-installasjoner som kan nås fra internett, særlig tjenester som tar imot forespørsler uten innlogging. Kartleggingen må omfatte kjøremiljøet bak nettstedet eller innloggingen, ikke bare applikasjonens navn og versjon. Dersom PHP leveres gjennom en vertstjeneste, en Linux-distribusjon eller en annen leverandør, må leverandørens sikkerhetspakke og installasjonsstatus inngå i vurderingen.

Der en oppdatering ikke kan installeres straks, kan tilgang til den sårbare tjenesten begrenses mens rettelsen klargjøres. Konfigurasjonsendringer kan redusere bestemte angrepsveier, blant annet knyttet til minnehåndtering og opplastingsøkter, men gir ikke full beskyttelse. Hvilke midlertidige tiltak som er aktuelle, avhenger av hvordan PHP er satt opp og hvilke funksjoner tjenesten trenger.

En stengt tjeneste bør åpnes igjen når rettelsen er lagt inn i installasjonen som faktisk betjener trafikken, og driften er kontrollert etter endringen. For virksomheter som venter på en leverandørpakke, er tilgjengeligheten av den pakken det konkrete neste holdepunktet. Den oppdaterte risikovurderingen gir ikke alene grunnlag for å sette en fortsatt sårbar tjeneste tilbake på nettet.

Les også:

• Citrix-hull utnyttes nå – en oppdatering rydder ikke bort et innbrudd
• YouTube Super Thanks: 70 prosent er før den norske skatten
• Norrsken og Nvidia åpner KI-lab – norske gründere kan søke