Utnyttelseskoden for SharePoint ble brukt i angrepsforsøk dagen etter at den kom

Rapid7 publiserte 11. august 2026 en teknisk analyse av CVE-2026-55040, en autentiseringsomgåelse i Microsoft SharePoint, sammen med kode som demonstrerer hvordan feilen utnyttes. Sårbarheten ble offentliggjort 14. juli 2026 av Rapid7 og Microsoft i fellesskap. Defused, som driver honningkrukker med SharePoint, oppgir på X at angripere allerede dagen etter brukte Rapid7s kode mot disse systemene. Observasjonen gjelder forsøk på utnyttelse mot lokkesystemer, og ingen av kildene sier at produksjonstjenere er kompromittert.

Hva som skjer teknisk

SharePoint tar imot et signert token, altså en JWT, som forteller hvem brukeren er. Rapid7 beskriver fire svakheter i kontrollen av dette tokenet, og det er kombinasjonen av dem som gjør angrepet mulig. Den første ligger i selve oppsettet: koden slår av kravet om at tokenet skal være signert. Da godtar biblioteket et token som oppgir at det ikke har signatur i det hele tatt, og ingen kryptografisk kontroll blir utført på det ytre tokenet. Kontrollen av mottaker og utsteder er også slått av i biblioteket, fordi SharePoint gjør den jobben selv lenger inne i koden.

Den andre svakheten er den som gjør angrepet praktisk. Tokenet kan inneholde et såkalt aktørtoken, og SharePoint finner nøkkelen til det ved å slå opp et fingeravtrykk som står i tokenets eget hode. Fingeravtrykket velges altså av den som lager tokenet. Oppslaget søker gjennom alle sertifikater SharePoint stoler på, også serverens eget sertifikat for utstedelse av tokener, og det sertifikatet kan hvem som helst hente fra endepunktet /_layouts/15/metadata/json/1 uten å logge inn. Angriperen setter fingeravtrykket til serverens eget sertifikat, oppslaget finner treff, og signaturen blir aldri kontrollert mot nøkkelen som ble funnet. De to siste svakhetene lukker sirkelen: kontrollen av utsteder godtar uttrykkelig et sertifikat som ikke er registrert som klarert utsteder, og kontrollen av signaturen er ikke kryptografisk. Resultatet er at en angriper uten pålogging kan forfalske et token og opptre som en hvilken som helst bruker eller administrator på nettstedet.

To ting er verdt å holde fra hverandre. Analysen fra Rapid7 er gjort mot SharePoint Server Subscription Edition, og feilen rettes av oppdateringene Microsoft ga ut i juli. Observasjonen fra Defused er noe annet, nemlig at koden nå brukes ute i angrepsforsøk. Honningkrukker er systemer som er satt opp for å bli angrepet, og trafikk mot dem forteller om aktiviteten som pågår, ikke om hvem som har lyktes. At avstanden fra publisert analyse til aktive forsøk var ett døgn, er derfor det viktigste tallet i saken.

Hva det betyr for deg som har SharePoint stående selv

Kjører du SharePoint i egne lokaler, er dette en sak du bør ta i dag og ikke i neste vedlikeholdsvindu. Angrepet krever ingen konto, ingen phishing og ingen brukerfeil. Det krever bare at serveren din svarer på internett og mangler julioppdateringen. Har du en installasjon du ikke er sikker på at noen eier, er det den du skal lete etter først. Vår erfaring er at det nesten alltid finnes en SharePoint-server til, satt opp for et prosjekt som ble ferdig for lenge siden.

Du bør også lete i loggene, ikke bare oppdatere. Sporet du ser etter, er forespørsler uten pålogging som likevel bærer et token, og oppslag mot endepunktet som gir ut sertifikatinformasjon. Berigos vurdering er at oppdatering alene ikke svarer på spørsmålet om noen rakk å komme inn før du lukket hullet, og det spørsmålet må besvares før saken kan legges bort. Etter NIS2 artikkel 21 er dette håndtering av sårbarheter og av hendelser, og begge delene skal kunne dokumenteres i ettertid.

Berigo anbefaler

• Installer julioppdateringen fra Microsoft på alle lokale SharePoint-servere, også dem som ikke står i tjenestekatalogen.
• Let etter forespørsler uten pålogging som bærer et token, og etter oppslag mot endepunktet som gir ut sertifikatinformasjon.
• Steng internettilgangen til SharePoint-servere som ikke må være åpne, i det minste til oppdateringen er på plass.
• Sjekk om det finnes SharePoint-installasjoner ingen har eierskap til, og gi dem en eier eller slå dem av.
• Skriv ned hva du fant og når du oppdaterte, slik at spørsmålet om kompromittering har et svar senere.