Bare én av de 91 sårbarhetene Spring har rettet, er kritisk

Spring har rettet 91 sårbarheter fordelt på en rekke delprosjekter, skriver SecurityWeek. Varslene på spring.io er datert 20. august. Spring har merket én av dem kritisk, og den gjelder den innebygde LDAP-tjeneren i Spring Security, der en angriper som når lytteporten kan logge inn med en kjent administrativ bind-DN og deretter lese eller endre oppføringer i katalogen. Over et dusin av de øvrige er merket høy alvorlighetsgrad. Sikkerhetsselskapet Sonatype har ifølge SecurityWeek analysert rettelsene og funnet at de berører mer enn 200 000 programvarekomponenter.

Hva som skjer teknisk

Spring er et rammeverk med åpen kildekode for å bygge applikasjoner på Java-plattformen. SecurityWeek beskriver det som et rammeverk som forenkler utvikling av virksomhetsapplikasjoner gjennom avhengighetsinjeksjon, aspektorientert programmering og moduler for web, data og meldingshåndtering. Rammeverket lå tidligere under VMware og hører nå til Broadcom. Varsellisten på spring.io viser at rettelsene fra 20. august fordeler seg over et stort antall delprosjekter, blant dem Spring Security, Spring Data JPA, Spring Cloud Config, Reactor Netty, Spring Data REST, Spring Integration, Spring AI, Spring AMQP, Reactor Core og Spring Batch. SecurityWeek oppgir at mer enn 200 sårbarheter er rettet i Spring hittil i år, mot 16 i 2025 og 22 i 2024, og knytter veksten til at Broadcom har tatt i bruk KI.

Den kritiske feilen heter CVE-2026-59270. Varselet fra Spring forklarer at den innebygde UnboundID-katalogtjeneren i Spring Security, klassen UnboundIdContainer, registrerer en administrativ pålogging uansett oppsett og binder lytteren sin til alle tilgjengelige nettverksgrensesnitt. To forutsetninger må være oppfylt. Applikasjonen må faktisk bruke UnboundIdContainer, enten satt opp direkte eller gjennom automatisk oppsett i Spring Boot med egenskapene som begynner på spring.ldap.embedded. Lytteporten må dessuten kunne nås fra der angriperen står, altså ikke låst til localhost av en brannmur eller en nettverksregel utenfor applikasjonen. Er begge deler på plass, kan angriperen logge inn med den kjente administrative bind-DN-en og lese eller endre oppføringer i katalogen, som ligger i minnet. Varselet viser til en CVSS-vektor som beskriver angrep over nettet, lav kompleksitet, ingen krav til rettigheter og ingen medvirkning fra en bruker. Spring oppgir fritt tilgjengelige rettelser i Spring Security 7.1.1 og 7.0.7. De øvrige rettede utgavene, altså 7.1.0.1, 7.0.6.1, 6.5.12, 6.4.19, 5.8.28 og 5.7.26, er merket Enterprise Support Only. Fire av de seks rammede greinene har dermed ingen fritt tilgjengelig rettelse i varselet.

Den andre feilen som trekkes fram, CVE-2026-59285, ligger i Spring for GraphQL. Her er kildene uenige om alvorligheten. Spring har merket den høy, mens Sonatype ifølge SecurityWeek omtaler den som en kritisk sårbarhet for kjøring av kode. Varselet setter opp fire betingelser som alle må være oppfylt. Applikasjonen må bruke Spring GraphQL, den må bruke Jackson 2.x til å lese JSON, den må eksponere et paginert Connection-felt, og klassestien må inneholde bestemte klasser som kan utnyttes til å kjøre utilsiktet logikk når objekter opprettes eller leses inn. Er alle fire oppfylt, kan en angriper lage en GraphQL-forespørsel som fører til kjøring av kode. Spring viser til CWE-502, kategorien for usikker deserialisering. Berørte utgaver er Spring for GraphQL 2.0.0 til 2.0.4, og 2.0.5 er den fritt tilgjengelige rettelsen. SecurityWeek nevner i tillegg CVE-2026-59318, en sårbarhet med middels alvorlighetsgrad i verktøykallene i Spring AI. Ifølge Sonatype kan den gi utvidede rettigheter gjennom instruksjoner som smugles inn i teksten språkmodellen leser.

Hva det betyr for deg som eier Java-applikasjonene

Bygger dere programvare på Java, er sjansen stor for at Spring allerede står i avhengighetstreet uten at noen har tatt et bevisst valg om det. Sonatypes tall på mer enn 200 000 berørte programvarekomponenter sier noe om hvor utbredt rammeverket er. Vår vurdering er at den viktigste oppgaven denne uken ikke er å oppdatere Spring, men å finne ut hvor Spring faktisk finnes hos dere. Et byggverktøy som Maven eller Gradle henter inn avhengighetene til avhengighetene sine, og det er alminnelig kunnskap om slike verktøy, ikke noe varslene sier. Konsekvensen er likevel konkret for deg. Et bibliotek du aldri har hørt om, kan ha dratt med seg en Spring-komponent inn i produktet ditt, og da har du den uten å ha bestemt det.

Samtidig er det verdt å holde hodet kaldt om alvorligheten. Bare én av de 91 er merket kritisk, og den forutsetter at applikasjonen din faktisk kjører den innebygde katalogtjeneren, og at porten kan nås utenfra. Kjører du ikke UnboundIdContainer, gjelder ikke den kritiske feilen deg. To ting vil vi likevel at du tar med videre. Den ene er at fire av de seks rammede greinene av Spring Security bare får rettelsen gjennom en betalt støtteavtale, og det gjør oppgraderingen til et budsjettspørsmål like mye som et teknisk spørsmål. Den andre er at Spring og Sonatype er uenige om GraphQL-feilen, der Spring sier høy og Sonatype sier kritisk. Når merkelappen spriker, er det ditt eget oppsett som avgjør, og da må noen faktisk se etter om betingelsene i varselet er oppfylt hos dere.

Berigo anbefaler

• Kartlegg hvor Spring finnes hos dere, både som direkte avhengighet og som avhengighet av noe annet. Bruk avhengighetsrapporten fra byggverktøyet, ikke hukommelsen til utviklerne.
• Sjekk om noen av applikasjonene deres kjører den innebygde UnboundID-katalogen fra Spring Security. Er svaret ja, behandle CVE-2026-59270 som en hastesak.
• Finn ut hvilken grein av Spring Security dere står på, og avklar om rettelsen deres krever en betalt støtteavtale før dere legger oppgraderingsplanen.
• Gå gjennom de fire betingelsene i varselet for CVE-2026-59285 mot deres egne GraphQL-tjenester. Ikke stol på alvorlighetsmerkingen alene når kildene er uenige.
• Be leverandørene svare skriftlig på om produktene de leverer inneholder de rammede Spring-komponentene, og på når rettelsene kommer.