Hardcoded inloggegevens in Dell-software geven roottoegang tot VMware-omgevingen

Dell waarschuwt voor een kritieke kwetsbaarheid in zijn herstelsoftware voor virtuele machines van VMware. Het lek heeft de hoogst mogelijke CVSS-score van 10. Aanvallers misbruiken het al anderhalf jaar en krijgen er rootrechten mee op hypervisors die virtuele machines draaien.

Dell waarschuwt gebruikers nu, nadat Googles securitytak Mandiant het bedrijf informeerde over deze kwetsbaarheid (CVE-2026-22769). Het gaat om ingebakken inloggegevens in Dells software RecoverPoint for Virtual Machines. Volgens onderzoekers van Mandiant is er sprake van actief misbruik op beperkte schaal. Dit gebeurt al sinds zeker halverwege 2024, ontdekten de securityexperts van Google.

De inloggegevens zitten hardcoded in de Tomcat-webserver die Dell gebruikt in zijn herstelsoftware voor VMware-omgevingen. Deze gegevens horen bij een beheerdersaccount in de Dell-software. Via dit account kunnen aanvallers een kwaadaardig bestand uploaden, waarmee ze rootrechten krijgen op het systeem waarop de virtuele machines draaien. Dat onderliggende systeem is hypervisorsoftware ESXi van VMware, die direct op de hardware draait zonder zonder tussenkomst van een regulier besturingssysteem.

Nu upgraden

Dell adviseert klanten om zo snel mogelijk te upgraden naar versie 6.0.3.1 HF1 van RecoverPoint for Virtual Machines. Gebruikers op de oudere versie 5.3 SP4 P1 moeten eerst nog upgraden naar versie 6.0 SP3 voordat ze naar de actueelste, veilige versie kunnen upgraden. Dell biedt ook een herstelscript, dat beheerders moeten draaien op hun systemen met de VMware-herstelsoftware van de computerleverancier.

Hack/Security. Bron: Saifulasmee Chede/iStock/Getty Images

Reacties (60)

[gatlarf]

Gebruikers op de oudere versie 5.3 SP4 P1 moeten eerst nog upgraden naar versie 6.0 SP3

Djeezes, breng daar dan een emergency patch voor uit in plaats van een upgrade door de strot te duwen die nu snelsnel moet getest worden. Ik ken de software niet persoonlijk en ken de eventuele impact niet, maar als je zo’n joekel van een fout maakt, ga je je gebruikers toch verderhelpen op iedere geïmpacteerde major releasedie nog actueel gebruikt wordt?

[DDX]

Als ik het zo lees is het 'herstelscript' zoals genoemd de hotpatch zegmaar.
Al is dat herstelscript wel encoded op een of andere manier (geen zin om verder te kijken of je dit makkelijk kan lezen)

https://www.dell.com/supp...emediation-script-for-dsa

[seapip]

Even snel gekeken en inderdaad verhelpt het script al het grootste probleem (hardcoded wachwoord), kort samengevat:

Het script genereert een willekeurig admin-wachtwoord, versleutelt dit met SHA-512, past de Tomcat-gebruikersconfiguratie aan, beperkt de toegang tot de Tomcat Manager-app tot alleen localhost, maakt back-ups van configuratiebestanden en herstart de Tomcat-service.

[bindsa]

Dit is de gedecode versie van het script, fixt het inderdaad:

48453499b7a6fb8ac532a553361cb64d

unlimited

not_restricted

The id of the script is:49767

Tomcat Issue Resolution

RP4VM

#!/bin/bash

set -e


TOMCAT_USERS_FILE="/home/kos/tomcat9/tomcat-users.xml"

ATTACHED_FILE="/home/kos/kbox/src/installation/Installation/scripts/tomcat_set_webapps_for_attached.bash"

DETACHED_FILE="/home/kos/kbox/src/installation/Installation/scripts/tomcat_set_webapps_for_detached.bash"

SERVER_XML="/home/kos/tomcat9/server.xml"

RPA_VERSION_FULL=$(dpkg -l | awk '/^ii[[:space:]]+recoverpoint-allpackages/ {print $3; exit}' | cut -d'.' -f1-5)

if dpkg --compare-versions "$RPA_VERSION_FULL" lt "5.3.4.0.0" || dpkg --compare-versions "$RPA_VERSION_FULL" gt "6.0.3.1.0"; then

echo "ERROR: Script execution is not permitted on this RPA Version: $RPA_VERSION_FULL"

exit 0

fi

if grep -q 'algorithm="SHA-512"' "$SERVER_XML" && grep -q 'RemoteAddrValve' "$SERVER_XML"; then

echo "ERROR: Script execution aborted, this script was previously executed on the server"

exit 0

fi

cd /root

mkdir -p BKP_Files

BKP_Files="/root/BKP_Files/"


RANDOM_PASSWORD=$(openssl rand -base64 24)

ENCODED_PASSWORD=$(/usr/share/tomcat9/bin/digest.sh -a SHA-512 "$RANDOM_PASSWORD")

ENCODED_PASSWORD=${ENCODED_PASSWORD#*:}

cp -f "$TOMCAT_USERS_FILE" "$ATTACHED_FILE" "$DETACHED_FILE" "$SERVER_XML" "$BKP_Files"

sed -i -E 's|(username="admin"[[:space:]]+password=")[^"]+(" roles="manager-script")|\1'"$ENCODED_PASSWORD"'\2|' "$TOMCAT_USERS_FILE"

sed -i -E 's|^PASSWORD_TOMCAT="[^"]*"|PASSWORD_TOMCAT="'"$RANDOM_PASSWORD"'"|' "$ATTACHED_FILE"

sed -i -E 's|^PASSWORD_TOMCAT="[^"]*"|PASSWORD_TOMCAT="'"$RANDOM_PASSWORD"'"|' "$DETACHED_FILE"

sed -i '/<Service name="mango-base">/,/<\/Service>/ s/algorithm="SHA"/algorithm="SHA-512"/' "$SERVER_XML"

sed -i '/<Service name="reaper-app">/,/<\/Service>/ s/algorithm="SHA"/algorithm="SHA-512"/' "$SERVER_XML"

sed -i '/<Service name="mango-base">/,/<\/Service>/ {

s#<Context path="/manager" docBase="/usr/share/tomcat9-admin/manager" antiResourceLocking="false" privileged="true" />#<Context path="/manager" docBase="/usr/share/tomcat9-admin/manager" antiResourceLocking="false" privileged="true">\

<Valve className="org.apache.catalina.valves.RemoteAddrValve"\

allow="127\\.\\d+\\.\\d+\\.\\d+|::1" />\

</Context>#

}' "$SERVER_XML"


sed -i '/<Service name="reaper-app">/,/<\/Service>/ {

s#<Context path="/manager" docBase="/usr/share/tomcat9-admin/manager" antiResourceLocking="false" privileged="true" />#<Context path="/manager" docBase="/usr/share/tomcat9-admin/manager" antiResourceLocking="false" privileged="true">\

<Valve className="org.apache.catalina.valves.RemoteAddrValve"\

allow="127\\.\\d+\\.\\d+\\.\\d+|::1" />\

</Context>#

}' "$SERVER_XML"

echo "Deployment completed successfully. Please note that Server may take a few minutes to reflect the changes."

setsid bash -c "sleep 3; systemctl stop tomcat9; sleep 5; systemctl start tomcat9" >/dev/null 2>&1 &

exit 0

[PolarBear]

Base64 encoded, ook weer niet zo complex:

offtopic:
48453499b7a6fb8ac532a553361cb64d

unlimited

not_restricted

The id of the script is:49767

Tomcat Issue Resolution

RP4VM

#!/bin/bash

set -e


TOMCAT_USERS_FILE="/home/kos/tomcat9/tomcat-users.xml"

ATTACHED_FILE="/home/kos/kbox/src/installation/Installation/scripts/tomcat_set_webapps_for_attached.bash"

DETACHED_FILE="/home/kos/kbox/src/installation/Installation/scripts/tomcat_set_webapps_for_detached.bash"

SERVER_XML="/home/kos/tomcat9/server.xml"

RPA_VERSION_FULL=$(dpkg -l | awk '/^ii[[:space:]]+recoverpoint-allpackages/ {print $3; exit}' | cut -d'.' -f1-5)

if dpkg --compare-versions "$RPA_VERSION_FULL" lt "5.3.4.0.0" || dpkg --compare-versions "$RPA_VERSION_FULL" gt "6.0.3.1.0"; then

echo "ERROR: Script execution is not permitted on this RPA Version: $RPA_VERSION_FULL"

exit 0

fi

if grep -q 'algorithm="SHA-512"' "$SERVER_XML" && grep -q 'RemoteAddrValve' "$SERVER_XML"; then

echo "ERROR: Script execution aborted, this script was previously executed on the server"

exit 0

fi

cd /root

mkdir -p BKP_Files

BKP_Files="/root/BKP_Files/"


RANDOM_PASSWORD=$(openssl rand -base64 24)

ENCODED_PASSWORD=$(/usr/share/tomcat9/bin/digest.sh -a SHA-512 "$RANDOM_PASSWORD")

ENCODED_PASSWORD=${ENCODED_PASSWORD#*:}

cp -f "$TOMCAT_USERS_FILE" "$ATTACHED_FILE" "$DETACHED_FILE" "$SERVER_XML" "$BKP_Files"

sed -i -E 's|(username="admin"[[:space:]]+password=")[^"]+(" roles="manager-script")|\1'"$ENCODED_PASSWORD"'\2|' "$TOMCAT_USERS_FILE"

sed -i -E 's|^PASSWORD_TOMCAT="[^"]*"|PASSWORD_TOMCAT="'"$RANDOM_PASSWORD"'"|' "$ATTACHED_FILE"

sed -i -E 's|^PASSWORD_TOMCAT="[^"]*"|PASSWORD_TOMCAT="'"$RANDOM_PASSWORD"'"|' "$DETACHED_FILE"

sed -i '/<Service name="mango-base">/,/<\/Service>/ s/algorithm="SHA"/algorithm="SHA-512"/' "$SERVER_XML"

sed -i '/<Service name="reaper-app">/,/<\/Service>/ s/algorithm="SHA"/algorithm="SHA-512"/' "$SERVER_XML"

sed -i '/<Service name="mango-base">/,/<\/Service>/ {

s#<Context path="/manager" docBase="/usr/share/tomcat9-admin/manager" antiResourceLocking="false" privileged="true" />#<Context path="/manager" docBase="/usr/share/tomcat9-admin/manager" antiResourceLocking="false" privileged="true">\

<Valve className="org.apache.catalina.valves.RemoteAddrValve"\

allow="127\\.\\d+\\.\\d+\\.\\d+|::1" />\

</Context>#

}' "$SERVER_XML"


sed -i '/<Service name="reaper-app">/,/<\/Service>/ {

s#<Context path="/manager" docBase="/usr/share/tomcat9-admin/manager" antiResourceLocking="false" privileged="true" />#<Context path="/manager" docBase="/usr/share/tomcat9-admin/manager" antiResourceLocking="false" privileged="true">\

<Valve className="org.apache.catalina.valves.RemoteAddrValve"\

allow="127\\.\\d+\\.\\d+\\.\\d+|::1" />\

</Context>#

}' "$SERVER_XML"

echo "Deployment completed successfully. Please note that Server may take a few minutes to reflect the changes."

setsid bash -c "sleep 3; systemctl stop tomcat9; sleep 5; systemctl start tomcat9" >/dev/null 2>&1 &

exit 0

[William_H]

Hier schrok ik ook van. Dit gaat er toe leiden dat sommige partijen nog niet gaan patchen want een upgrade vraagt (terecht een uitvoerigere) andere testprocedure dan een patch.

@DDX Zoals ik het in het artikel hierboven lees, moet je alsnog eerst upgraden en geldt wat @gatlarf en ik zeggen nog steeds. En dat maakt dat deze oplossing niet echt handig is. Zeker met iets wat al 1.5 jaar misbruikt wordt. Deze patch/upgrade heeft echt prio 0, maar ga dat maar eens in een testprocedure proppen.

[Reactie gewijzigd door William_H op 18 februari 2026 15:26]

[matty___]

Toch bijzonder slordig. Er is zo veel tooling die hierop af zou gaan.

[Bor]

Wanneer het lek bekend is wel maar getuige het feit dat dit lek al lange tijd wordt misbruikt was er niet "zo veel tooling die hierop af zou gaan". Een doorsnede kwetsbaarheid scanner kan bv alleen zaken vinden waarvan het op de hoogte is.

[Djerro123]

Maar dit zou niet door een kwetsbaarheidscanner gevonden moeten worden; dit zit al in je CI straat. Sterker nog, een verplichte pre commit hook zou dit al pakken, maar een beetje serieuze partij scant regelmatig haar repos op hardcoded credentials.


Aan de andere kant kan het natuurlijk zo zijn dat dit gewoon een slordige, obfuscated implementatie is, waardoor het ook voor secret scanners niet makkelijk te vangen is. Het zal vast niet “const pwd = “MySecr3t!!123” zijn geweest (hoop ik)

[Bor]

Een goede toevoeging wat mij betreft. Aan de ontwikkelkant heb je absoluut gelijk. Ik bekeek het van de kant van de afnemer. Daar is het vinden van dit soort zaken echt een stuk minder vanzelfsprekend.

[ktorfs]

Als afnemer kan je hier inderdaad weinig aan doen, zelfs opmerken normaliter niet. Maar dit zijn fouten van het stagiair-niveau, onvergeeflijk voor een bedrijf als Dell zijnde.

[Pinkys Brain]

Moet Dell eigenlijk gewoon vertellen wat de achtergrond is en hoe ze dat in de toekomst gaan vermijden.

De CVE database heeft een veld nodig voor een link naar post mortems. Kan je simpelweg kijken naar welke bedrijven geen post mortems publiceren voor hoge score vulnerabilities.

[Reactie gewijzigd door Pinkys Brain op 18 februari 2026 17:44]

[fastedje]

Er z8j5n ook security tools die je sourcecode kunnen scannen op dit soort inkoppertjes, zials snyk bijvoorbeeld.

[DDX]

Los van feit dat hardcoded login niet handig is, gebruikers die zo'n service gewoon aan het internet / door iedereen in het office benaderbaar maken is ook niet slim.

[William_H]

Misschien zitten de criminelen al binnen in het netwerk, dan heb je natuurlijk al een probleem, maar dat maakt dit lek wel erg. Je moet er altijd vanuit gaan dat je gekraakt kunt worden. Dan heb je nog interne blokkades. Als dan dit soort services op je netwerk draaien, en zo makkelijk te manipuleren zijn, ben je kansloos.

[Pinkys Brain]

Hoe kan dit nog vandaag de dag? Geen code review en incompetentie?

Als dit code is van een infiltrant dan lacht hij zich kapot dat ze bij Dell zo incompetent zijn dat hij de backdoor niet eens hoefde te verstoppen en dat ze waarschijnlijk niet eens op het idee kunnen komen dat zij niet zo incompetent zijn. Ik hoop dat ze al zijn code tegen het licht houden, wie weet zitten er een dozijn obfuscated backdoors in plus deze ... maar ik denk niet dat het gebeurt.

[bzzzt]

Dat ze Apache Tomcat nog gebruiken zegt waarschijnlijk dat die tool al minstens 10-20 jaar oud is. Dus waarschijnlijk eerder een geval 'slecht onderhoud' dan dat er vandaag de dag nog een fout gemaakt is.
Waarschijnlijk ooit in elkaar gezet door een ge-outsourced clubje en nooit meer naar gekeken.

[GertMenkel]

Ik zie het probleem met Tomcat niet zo. Wordt nog gewoon bijgewerkt, werkt prima. Dat hele idee van losse subapplicaties van Java EE is dan wel een beetje naar de achtergrond gegaan, maar frameworks nemen Tomcat nog steeds mee als intern component.

Ik draai mijn website ook nog op een combinatie van Apache (1995, omdat ze hele praktische OIDC-integratie hebben) en Nginx (2004). Zelfs mijn modernste VPS draait Caddy (2015, 11 jaar oud).

[bzzzt]

Het werkt prima en ik neem niemand kwalijk het te gebruiken zo lang het goed gesupport wordt. Mijn opmerking is alleen dat bepaalde componenten (of programmeertalen) niet meer zo heel populair zijn en daardoor niet zo vaak in nieuw gebouwde software opgenomen zullen worden.

[Sebastian1313]

Met alle respect, maar ik lees drie keer het woord "waarschijnlijk" in uw tekst. Laten we het even bij de feiten houden alstublieft. U weet het op dit moment niet, dat is zeker...

[bzzzt]

Als er niet gespeculeerd mag worden kan dit forum beter gelijk opgedoekt worden.

[Polderviking]

Tomcat wordt nog gewoon onderhouden/aan gewerkt?

[GreatDictator]

Het zit ingebakken in ArcGIS Enterprise. Elke organisatie met een beetje fatsoenlijke geo-omgeving heeft dat draaien; de grote meerderheid van Nederlandse overheden bijvoorbeeld. In hoeverre dat van buitenaf aan te roepen valt zal natuurlijk wel sterk verschillen.

[bzzzt]

Ik ken nog wel een bult 'enterprise' tools waar Tomcat en andere oude software zit ingebakken. Punt is dat dat meestal niet de meest technisch progressieve applicaties zijn en dat meestal komt doordat ergens begin deze eeuw iemand besloten heeft dat de software ook 'web' moest hebben

[SPee]

Niet bewust. Met het Spring Boot framework krijg je nog steeds een (embedded) Tomcat mee.

[bzzzt]

Klopt, maar de populariteit van Java is behoorlijk aan het afnemen.

[gimbal]

Het is Tomcat 9... laatste patch is uit januari 2026. Nog gewoon up to date.

Er is ook een Tomcat 10, Tomcat 10.1 en een Tomcat 11 inmiddels. Het feit dat men nog steeds Tomcat 9 gebruikt is wel een teken van ouderdom ja. Maar niet ZO oud.

[bzzzt]

Dat ze nu 9 leveren zegt natuurlijk niet dat ze daarmee begonnen zijn. Wel dat ze kennelijk weinig waarde aan updates hechten.

[nicenemo]

Tomcat 11 zit in de laatste Spring-boot frameworks. wordt ook gewoon bijgewerkt. Hoe oud zijn Linux en Windows?

[bzzzt]

Ik heb ook nergens gezegd dat Tomcat per definitie 'out of date' is, maar het is wel een server met een wat ouderwets design met support voor legacy technieken die in moderne applicaties vrijwel nooit meer gebruikt worden maar wel het aanvalsoppervlak vergroten. Er zijn ondertussen meerdere compactere en snellere netwerk servers voor Java applicaties die ik eerder zou verwachten in een 'cloud ready' stack dus heb echt geen idee waarom Spring boot daar zo aan hecht...

[nicenemo]

Het werkt en het is standaard.Je kunt ook Jetty, Netty of Undertow gebruiken. Ik had geen mening welke beter is. Het staat bij bij mij ook op de wishlist om eens verder uit te zoeken naast 600 andere dingen. Een vraag aan Gemini liet zien dat Jetty voor een simpele beheer app beter is. Undertow is Dan weer beter voor high throughput maar kost meer geheugen aldus Gemini.

Rond 2003, toen alles nog XML of .NET moest heten ook al had het er niks mee te maken, heb ik wel direct op Tomcat servlets gebouwd.

Ik kom van Java EE waar je nog veel meer spullen hebt die in een Kubernetes omgeving niet nodig zijn.

Spring-boot ten opzichte van Java EE is een verademing; Quarkus is het mogelijk lichtere alternatief.

Wat ook helpt GraalVM om de boel naar native te krijgen, er compile time alles uit te strippen dat je niet gebruikt. Dit voor een bestaande applicatie opzetten is wel iets wat tijd kost . In sommige gevallen is mogelijk eerst ombouw van Spring-Boot naar Quarkus en dan native de betere oplossing.

[bzzzt]

Undertow is Dan weer beter voor high throughput maar kost meer geheugen aldus Gemini.

Dat is de eerste keer dat ik dat hoor, zou dat wel eerst grondig uitzoeken voor het klakkeloos aan te nemen.

Rond 2003, toen alles nog XML of .NET moest heten ook al had het er niks mee te maken, heb ik wel direct op Tomcat servlets gebouwd.

Guilty . Dat was in die tijd ook behoorlijk lang de standaard binnen bedrijven.

Spring-boot ten opzichte van Java EE is een verademing; Quarkus is het mogelijk lichtere alternatief.

Quarkus is ook een aantal jaar 'jonger' en heeft daardoor nog meer focus op cloud-native. Door dingen die eerder dynamisch bij opstarten bepaald werden te vervroegen naar compilatie tijd starten die applicaties inderdaad fors sneller op.

Wat ook helpt GraalVM om de boel naar native te krijgen, er compile time alles uit te strippen dat je niet gebruikt. Dit voor een bestaande applicatie opzetten is wel iets wat tijd kost . In sommige gevallen is mogelijk eerst ombouw van Spring-Boot naar Quarkus en dan native de betere oplossing.

Er is wat twijfel over of native compilatie de beste lange termijn oplossing is. Het werkt nl niet echt samen met veel dynamische features van Java dus veel frameworks en code werken niet zonder forse aanpassingen. Je kan bv geen code (zoals plugins) at runtime meer laden, alle gebruikte code moet vooraf bekend zijn. Het is allemaal oplosbaar maar voor veel grote codebases bijna ondoenlijk. Daarnaast is er ook nog een alternatief (CRaC) wat een feature is die snapshots van opgestarte servers maakt. Start ook snel, en dynamische code blijft gewoon werken. Benieuwd welke oplossing langer blijft leven...

[nicenemo]

Heb inmiddels Tomcat vervangen door Undertow als experimentje. Het lijkt sneller, maar meten is weten. Nog wel wat raar gedrag gezien in combinatie met logging. Als ik een null logger gebruik in integratie testen dan bevriest alles. Interessant, en dat bevalt niet.

en update Undertow is uit het raam voor Spring-boot 4, not supported. Dood paard. Tomcat lijkt de betere optie te zijn. ik zie nog wat opties voor Tomcat tuning. Even kijken of dat nodig is.

[Reactie gewijzigd door nicenemo op 22 februari 2026 08:59]

[elsinga]

Alsof hardcoded credentials niet altijd gevonden en uitgebuit worden.... Heel slordig....

[Macron]

Dat is toch wel amateurisme van de bovenste plank voor zo'n groot bedrijf

[skelleniels]

Daarom alles van management in apart onbereikbaar VLAN steken, dan kan dit soort fratsen niet misbruikt worden.

[JPK1960]

Als inmiddels ex COBOL ontwerper/programmeur herinner ik me dat data hard coderen in 1994 al werd beschouwd als vloeken in de kerk.

[beerse]

Zomaar een paar vragen:

Hoe lang geleden was Dell eigenaar van VMware?

Waar kan ik dit product plaatsen? Is het in de ESXi laag (wat ooit een gestripte RedHat omgeving was) Is het een apart product dat op de ESXi omgeving wordt geladen om vmware-gasten te bedienen/hacken/recoveren? Of is dit de webinterface van de ESXi machines om ze zonder vsphere omgeving te gebruiken? Of is dit iets dat parallel aan ESXi in het systeem staat om in geval van issues met ESXi toch iets te kunnen booten en daarna te recoveren?

[Sandor_Clegane]

lol, hardcoded........ in een webserver............ Ik hoop dat de management vlans een beetje werken.,