CVE-2026-70615: Kritisk fejl i boringproxy giver SSH-adgang
Fejl i boringproxy lader lavprivilegerede brugere kapre serverens SSH-adgang. Opdatér eller fjern tunnel-oprettelse for utroværdige brugere.
Hvad er det?
CVE-2026-70615 er en sårbarhed i boringproxy, et selvhostet værktøj til at oprette tunneler og eksponere interne tjenester på internettet. Fejlen skyldes newline injection, hvor et program fejlagtigt tillader indsættelse af linjeskift i data, der senere skrives direkte i en systemfil. En bruger, der har lov til at oprette tunneler, kan sende et procent-kodet linjeskift i domæneparameteren, når en tunnel oprettes. Det gør det muligt at skrive en vilkårlig linje ind i serverkontoens authorized_keys fil, som styrer hvilke SSH-nøgler der har adgang til serveren. Sårbarheden findes i alle versioner til og med 0.10.0.
Hvem rammer det?
Det rammer virksomheder, der kører boringproxy til og med version 0.10.0, typisk udviklingsteams eller it-afdelinger, der bruger værktøjet til at eksponere interne systemer eller test-miljøer på internettet. Alle brugere med tilladelse til at oprette tunneler kan udnytte fejlen, uanset hvor lav deres oprindelige rettighed er.
Hvad kan ske?
En bruger med kun tunnel-rettigheder kan indsætte sin egen SSH-nøgle i serverens authorized_keys fil og dermed få vedvarende adgang til serverens kommandolinje. Herfra kan angriberen læse databasefilen i klartekst og få fat i alle brugertokens, private nøgler til tunneler og TLS-certifikater. I praksis mister virksomheden kontrollen over alle tjenester, der eksponeres via boringproxy, og angriberen kan udgive sig for andre brugere eller opsnappe krypteret trafik.
Hvor alvorligt er det?
CVSS-scoren er 9,9 ud af 10, hvilket er kritisk. Angrebet kræver kun et lavt privilegeret login, ingen brugerinteraktion fra andre, og kan udføres over netværket med lav kompleksitet. Fordi fejlen giver adgang uden for det oprindelige system (scope changed), rammer den både fortrolighed, integritet og tilgængelighed fuldt ud. Der er ikke oplysninger om aktiv udnyttelse eller offentligt tilgængelig kode, men fejlen er let at udnytte for enhver, der allerede har en almindelig brugerkonto.
Hvad gør jeg nu?
Følg disse trin for at lukke hullet og begrænse skaden:
- Opdatér boringproxy til en version nyere end 0.10.0, så snart en rettet version foreligger fra projektet.
- Indtil en rettelse findes, skal I fjerne eller begrænse tunnel-oprettelsesrettigheder til kun betroede administratorer.
- Gennemgå serverens authorized_keys fil manuelt for uautoriserede eller ukendte SSH-nøgler og fjern dem.
- Skift alle tokens, tunnel-private nøgler og TLS-certifikater, der har været tilgængelige for boringproxy-serveren, da de kan være kompromitteret.
- Gennemgå logfiler for tunnel-oprettelser med usædvanlige tegn i domænefeltet, der kan indikere forsøg på udnyttelse.
- Kontakt en sikkerhedsrådgiver, hvis I ikke selv kan verificere, om systemet allerede er kompromitteret, eller hvis I mangler ressourcer til at gennemgå logs og nøgler.
Begræns adgang og opdatér snarest muligt
Vi anbefaler, at I straks begrænser, hvem der kan oprette tunneler i boringproxy, og at I gennemgår authorized_keys filen for uautoriserede nøgler. Det er ikke forsvarligt at vente, hvis systemet er tilgængeligt for flere brugere end en snæver kreds af administratorer, da fejlen er nem at udnytte. Har I kun en enkelt betroet administrator med tunnel-rettigheder, kan I afvente en officiel rettelse, men bør stadig overvåge for mistænkelig aktivitet.
Tidslinje
Konkrete eksempler
Udviklerteam i dansk softwarevirksomhed mister kontrol over testmiljø
Et udviklerteam bruger boringproxy til at eksponere et internt testmiljø for eksterne samarbejdspartnere. En udvikler med almindelig tunnel-adgang udnytter fejlen til at indsætte sin egen SSH-nøgle på serveren. Herfra får udvikleren adgang til databasen med alle brugertokens og TLS-certifikater, og virksomheden opdager først problemet, da uautoriseret trafik registreres uger senere.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er ramt, hvis I kører boringproxy i version 0.10.0 eller ældre, og hvis mere end en betroet administrator har rettighed til at oprette tunneler. Tjek jeres installerede version og gennemgå brugerlisten for tunnel-rettigheder.
Hvordan tjekker vi, om vi allerede er kompromitteret?
Gennemgå serverens authorized_keys fil for SSH-nøgler, I ikke selv har tilføjet. Se også efter usædvanlige tegn som procent-kodede linjeskift i domænefelter i tunnel-loggen.
Kan vi vente til weekenden med at reagere?
Hvis flere brugere end en snæver kreds af administratorer har tunnel-rettigheder, bør I begrænse adgangen med det samme frem for at vente. Der findes ingen officiel rettelse endnu, så adgangsbegrænsning er den eneste effektive foranstaltning.
Skal vi anmelde hændelsen, hvis vi finder en uautoriseret nøgle?
Hvis I finder tegn på uautoriseret adgang og persondata eller kundedata kan være berørt, skal I vurdere anmeldelsespligt efter databeskyttelsesforordningen og eventuelt kontakte Datatilsynet inden for 72 timer.
Findes der en rettet version af boringproxy?
På offentliggørelsestidspunktet er der ikke oplyst nogen rettet version. Følg projektets officielle kanaler for opdateringer, og indfør adgangsbegrænsning som midlertidig løsning.
Kan vi bruge en anden løsning end at fjerne tunnel-rettigheder?
Et alternativ er at overvåge og validere domæneparameteren, før den når serveren, men det kræver ændringer i koden og er ikke en garanteret løsning. Adgangsbegrænsning er den mest pålidelige midlertidige foranstaltning.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
boringproxy through 0.10.0 contains a newline injection vulnerability that allows authenticated low-privileged users with tunnel-creation permission to inject arbitrary lines into the server account’s SSH authorized_keys file by supplying a percent-encoded newline character in the domain parameter of the tunnel creation endpoint. Attackers can insert an unrestricted public key entry into authorized_keys to gain persistent shell access, and subsequently read cleartext credentials from the database file including all user tokens, tunnel private keys, and TLS certificates.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.