SAP Commerce-sårbarhed: Hvad skal virksomheden gøre?

En kritisk sårbarhed i SAP Commerce Cloud bliver aktivt udnyttet. Både CERT Santé og CERT-EU omtaler observeret udnyttelse. Virksomheder, der anvender SAP Commerce Cloud 2211 med Data Hub Adapter, bør derfor straks få undersøgt, om deres løsning er berørt.

Sårbarheden har betegnelsen CVE-2026-58231. SAP har klassificeret den som kritisk med en CVSS-score på 10,0. Ifølge CERT Santé kan en angriber potentielt udnytte den via netværket uden først at have et brugernavn eller en adgangskode. Et vellykket angreb kan blandt andet give mulighed for at køre skadelig kode og påvirke systemer og data.

Det betyder ikke, at alle virksomheder med SAP Commerce Cloud er kompromitteret. Det betyder, at berørte virksomheder hurtigt bør få afklaret deres situation og ikke betragte installationen af en opdatering som den eneste nødvendige handling.

Kort fortalt: Det bør virksomheden gøre

Bed den interne IT-funktion, SAP-ansvarlige eller driftsleverandør om at dokumentere:

• Om virksomheden anvender en berørt version med Data Hub Adapter aktiveret.
• Om alle relevante miljøer er opdateret til en rettet version.
• Om den opdaterede løsning efterfølgende er sat korrekt i drift og testet.
• Om relevante logs og ændringer er undersøgt for tegn på uautoriseret aktivitet.
• Hvilke forretningsprocesser og data der kan være påvirket, hvis der findes tegn på kompromittering.

Hvis leverandøren står for driften, bør virksomheden ikke nøjes med en melding om, at sagen er håndteret. Bed om versionsoplysninger, tidspunkt for opdatering og genudrulning, resultatet af kontrollen samt en beskrivelse af eventuelle fund.

Hvem er berørt af SAP Commerce-sårbarheden?

SAPs officielle sikkerhedsoversigt angiver, at CVE-2026-58231 berører følgende produktversioner:

• SAP Commerce Cloud COM_CLOUD 2211
• SAP Commerce Cloud COM_CLOUD 2211-JDK21
• Installationer, hvor Data Hub Adapter er aktiveret

CERT Santé angiver SAP Commerce Cloud 2211.55, 2211-jdk21.17 eller nyere som rettede versioner. Den opdaterede version skal efterfølgende genudrulles, også kaldet redeploy, før rettelsen reelt er sat i drift.

Virksomheder, der ikke selv har det tekniske overblik, bør kontakte deres SAP-ansvarlige eller driftsleverandør. Afklaringen bør omfatte både produktion, test, udvikling og andre miljøer, der kan være forbundet med virksomhedens systemer.

Hvorfor kan sårbarheden få forretningsmæssige konsekvenser?

SAP Commerce Cloud kan understøtte webhandel og være forbundet med blandt andet produktdata, ordreflow, kundedata, betalingsprocesser og interne systemer. Et angreb kan derfor få konsekvenser, der rækker ud over selve SAP-løsningen.

Afhængigt af virksomhedens opsætning kan konsekvenserne eksempelvis være:

• Utilgængelig webhandel eller afbrudte ordreprocesser
• Fejl eller forsinkelser i integrationer og leverancer
• Uautoriserede ændringer i systemer eller data
• Adgang til kunde- eller forretningsoplysninger
• Behov for midlertidigt at begrænse systemer, mens hændelsen undersøges

Den konkrete risiko afhænger af, hvordan løsningen er konfigureret, eksponeret og forbundet med andre systemer. En offentlig advarsel er derfor ikke i sig selv dokumentation for, at virksomheden er blevet ramt. Den er derimod grund til at prioritere afklaringen højt.

En opdatering er først gennemført, når den er sat i drift

SAP offentliggjorde sikkerhedsrettelsen den 11. august 2026 og anbefaler, at kunder prioriterer relevante sikkerhedsopdateringer. CERT Santé oplyser samtidig, at der ikke findes en alternativ afværgeforanstaltning for denne sårbarhed.

For den berørte løsning er det ikke tilstrækkeligt, at opdateringen er hentet eller planlagt. Den rettede version skal genudrulles og efterfølgende kontrolleres. Virksomheden eller dens leverandør bør som minimum:

• Bekræft versionsniveauet i hvert relevant miljø.
• Gennemfør den nødvendige genudrulning.
• Test centrale ordre-, katalog- og integrationsprocesser.
• Registrér tidspunkt, ansvarlig og testresultater.
• Håndtér eventuelle fejl efter virksomhedens procedurer for ændringsstyring.

Sikker Digital anbefaler, at virksomheder udpeger en ansvarlig for opdateringer og stiller krav til IT-leverandørens processer. Det er særligt relevant, når et kritisk system drives af en ekstern partner.

Undersøg, om sårbarheden kan være blevet udnyttet

Da der er observeret aktiv udnyttelse, bør virksomheden undersøge, om der er tegn på uautoriseret aktivitet. Kontrollen kan gennemføres parallelt med opdateringen, men relevante spor bør bevares, inden ændringer og oprydning påvirker dem.

Den tekniske kontrol bør tilpasses miljøet og kan blandt andet omfatte:

• Relevante applikations-, adgangs- og integrationslogs.
• Uventede ændringer i privilegerede konti og serviceforbindelser.
• Ukendte eller usædvanlige ændringer i integrationer.
• Deployhistorik og andre ændringer omkring det relevante tidsrum.
• Aktivitet mod det berørte tekniske endpoint.

Virksomheden bør på forhånd aftale, hvilke fund der udløser eskalation til den hændelsesansvarlige, SAP-support, driftsleverandøren eller eksterne specialister.

Hvis der findes tegn på kompromittering, bør virksomhedens hændelses- og IT-beredskabsplan aktiveres. Planen skal understøtte en klar fordeling af ansvar, bevarelse af dokumentation og prioritering af kritiske forretningsprocesser under undersøgelsen.

Vurder særskilt, om personoplysninger er berørt

En kritisk sårbarhed udgør ikke automatisk et anmeldelsespligtigt brud på persondatasikkerheden. Det afgørende er, om der konkret er sket en sikkerhedshændelse, som har påvirket personoplysningers fortrolighed, integritet eller tilgængelighed.

Hvis undersøgelsen viser eller giver begrundet mistanke om et brud på persondatasikkerheden, skal den dataansvarlige vurdere risikoen for de berørte personer. Datatilsynet oplyser, at anmeldelse som udgangspunkt skal ske uden unødig forsinkelse og om muligt inden 72 timer, medmindre det er usandsynligt, at bruddet medfører en risiko for personers rettigheder eller frihedsrettigheder.

Sagen bør først lukkes, når virksomheden har et dokumenteret grundlag for at vurdere, at risikoen er håndteret. Dokumentationen bør omfatte:

• Hvilke installationer og miljøer der blev undersøgt.
• Version før og efter opdateringen.
• Tidspunkt for opdatering og genudrulning.
• Gennemførte test og resultater.
• Hvilke logs og ændringer der blev kontrolleret.
• Eventuelle fund, opfølgende handlinger og resterende risiko.
• Dokumentation modtaget fra en driftsleverandør.

Det giver ledelsen et klart overblik over, om webhandel, integrationer, data og driftsstabilitet er tilstrækkeligt beskyttet. Samtidig styrker det virksomhedens fremtidige sårbarhedshåndtering, fordi ansvar, beslutninger og gennemførte handlinger kan genfindes og genbruges ved næste kritiske varsel.