Twee grote gaten in beveiligingsbibliotheek libssh2 geven malware- en dosgevaar

De opensourcebibliotheek libssh2 heeft twee ernstige kwetsbaarheden in alle versies van deze software voor beveiligde verbindingen. Aanvallers kunnen hiermee malware installeren of systemen platleggen. Patches staan op GitHub, maar moeten nog in releases verwerkt worden.

Libssh2 is een bibliotheek voor ssh-verbindingen en zit standaard geïntegreerd in vele applicaties, tools, programmeersoftware en besturingssystemen. De ene kwetsbaarheid (CVE-2026-55200) in deze veelgebruikte clientsoftware is een geheugenfout waarlangs aanvallers via te grote ssh-packets eigen code kunnen uitvoeren op kwetsbare systemen. Deze kwetsbaarheid krijgt dan ook het cijfer 9,2 in kwetsbaarhedenclassificatie CVSS 4.0.

De andere kwetsbaarheid in libssh2 (CVE-2026-55199) zit in de authenticatie tussen clientsystemen en servers, waarbij de server het verbindende systeem kan platleggen met een denial-of-serviceaanval. Deze kwetsbaarheid krijgt het cijfer 8,2 in CVSS 4.0. Voor zover bekend zijn er nog geen aanvallen die deze twee ernstige kwetsbaarheden uitbuiten.

Wachten tot fixes doordruppelen

De fixes voor de twee kwetsbaarheden zijn via commits op GitHub opgenomen in de hoofdtak van de software, schrijft Heise.de. Deze wijzigingen aan de code van libssh2 kwamen eind april en twee weken geleden uit. De twee commits zijn echter nog niet verwerkt in een nieuwe release van de bibliotheek zelf. Op de officiële site is de kwetsbare versie 1.11.1 uit oktober 2024 de recentste release.

Verder moeten veel Linux-aanbieders een gefixte versie van libssh2 nog opnemen in hun distributies. De op beveiliging gerichte Linux-distributie Kali heeft sinds 20 mei al libssh2-versie 1.11.1-3. Deze derde subrelease bevat mogelijk de patches voor de twee kwetsbaarheden. Debian Linux test die nieuwe versie van libssh2 sinds 18 mei.

Digitale beveiliging. Bron Getty Images, JuSun

Reacties (28)

[Stetsed]

Ik zie dit niet in de post en ik denk dat dit zeer belangrijk is om te noteren. Dit is niet OpenSSH dus wat op bijna elke server staat die er bestaat. Dit is een andere library voor het SSH protocol. Ik zie daar op meerdere plekken all een beetje paniek over, dus wou dit even duidelijk maken.

Dit betekent niet dat het niet gevaarlijk is, LibSSH2 wordt bijvoorbeeld gebruikt door curl voor SFTP en SCP protocollen. Maar het gevaarlijkste is dus als jij software hebt dit bijvoorbeeld een backup doet naar een server over SSH en daar maak je gebruik van LibSSH2. Want als die server dan compromised is dan kan dat zeker problemen veroorzaken.

[Reactie gewijzigd door Stetsed op 23 juni 2026 14:55]

[Ultraman]

Goed om inderdaad te vermelden dat het client-side is en niet de server side.

[RobertMe]

Niet alleen dat het client side is, maar ook dat het dus (schijnbaar) niet in de openssh client zit. Dus als jij "ssh willekeurige server" doet maakt dit géén gebruik van libssh2 en is het dus ook níet kwetsbaar.

Het gaat echt alleen om (bepaalde) software die "iets met SSH kan doen" en niet zelf het SSH protocol implementeert maar daarvoor gebruik maakt van libssh2. Zoals dus schijnbaar curl dat @Stetsed aanhaalt. Maar bv git die ook SSH kan gebruiken doet bij mijn weten weer gewoon "ssh ..." uitvoeren op de CLI / als subproces en zal dan weer niet kwetsbaar zijn.

[Oon]

In beide gevallen ben je al comped als dit lek misbruikt wordt, dus ik snap het theoretische probleem wel maar als je een SSH-verbinding maakt die niet tussen twee vertrouwde systemen is dan ben je m.i. al iets vreemds aan het doen

[DDX]

In hoeverre is curl op windows bijvoorbeeld kwestbaar ?
Curl bij windows 11 is versie 8.19.0 en loopt al achter op de laatste curl release (8.20.0)

[hottestbrain]

Welke curl implementatie gebruik je? Microsoft coreutils is namelijk volledig hergeschreven in Rust met als doel volledige compatibiliteit, maar het is een wezenlijk ander beestje.

[kdekker]

Zeker weten? Er lijken wel plannen in die richting geweest te zijn, maar gezien de versienummering van curl op Windows (ik heb 8.13.0), is het gewoon de 'Daniel Stenberg' en kennelijk geen rust variant (maar C).

En curl is vrij breed te configureren. Daarmee kun je niet zomaar zeggen dat curl de ene of de andere ssh implementatie gebruikt, al lijkt libssh2 de meest voorkomende combi. Zie ook: https://curl.se/docs/libs.html.

Officeel hoor je bij je curl binaries de open source licentie mee te geven. Aan de hand daarvan kun je zien - al zie ik die licentie even niet terug op mijn Windows systeem - wat er bij zit. En anders geeft curl --version wat info, maar niet welke SSH implementatie gebruikt is. Iig is libssh2 de meest voorkomende. Het is even geleden dat ik hier vaak mee werkte, maar openssh was het niet (wel openssl, maar dat is wat anders, zie ook: https://curl.se/docs/ssl-compared.html). Ik vermoed dan ook dat @Stetsed iets door elkaar haalt. Ik zie op de curl website weinig over OpenSSH en curl (anders dan allerlei problemen).

[Reactie gewijzigd door kdekker op 23 juni 2026 15:39]

[Stetsed]

Ik heb een citaat toegevoegt eerder. Het komt van(https://everything.curl.dev/usingcurl/ssh/), de website die jij citeert gaat over SSL niet over SSH want curl heeft ondersteuning voor veel meer protocollen. En als voorbeeld op mijn machine als ik curl --version doe(Arch Linux), zie ik op dit moment:
curl 8.20.0 (x86_64-pc-linux-gnu) libcurl/8.20.0 OpenSSL/3.6.3 zlib/1.3.2 brotli/1.2.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.69.0 ngtcp2/1.23.0 nghttp3/1.16.0 mit-krb5/1.21.3

En op debian(Trixie) zie ik het ook, daar is het ook 1.11.1

[Reactie gewijzigd door Stetsed op 23 juni 2026 15:50]

[kdekker]

Dan zeg ik het anders: op bijna ieder windows en linux systeem staat curl en het sftp en scp deel wordt verzorgt door libssh2. Dat zeg jij ook, maar ik zei nog wat meer, nl. dat curl in principe niets doet met openssh. Dat is ook een binary die op veel linux systemen staat, niet geraakt wordt door deze bug, maar is voor curl niet relevant.

Overigens kwam mijn bron van de autheur van curl. Dat lijkt me de belangrijkste bron om beweringen over curl te controleren.

Dus de opmerking over openssh resulteer m.i. in ruis en de binary die libssh2 gebruikt is dus curl (cURL, oftewel command-line URL, veel gebruikt in allerlei tools). Wat dan @DDX zegt (en ik heb soortgelijke output) dat SCP/SFTP niet in de Windows curl binary zitten. Maar eigenlijk zijn scp (wat ook een los Linuix commando is) niet zo heel 'Windows-achtig'. Idem sftp. Windows is meer ftps (wat bij https hoort, en dus juist SSL is ipv SSH).

Het onderscheid client-side en server-side is tamelijk arbitrair, als de ene server als client van de andere data binnenvist of verstuurd. Maar goed, dat is een andere notitie, meer voor @Ultraman.

[Reactie gewijzigd door kdekker op 23 juni 2026 17:04]

[keranoz]

Het verschilt blijkbaar per distro. Mijn NAS die op Debian draait heeft cURL 8.14.1 met `libssh2/1.11.1`. Mijn werk laptop met OpenSUSE heeft een cURL 8.20.0 met `libssh/0.11.4/openssl/zlib`.

[Arjanjnl]

Op openSUSE is libssh2 en libssh4 geïnstalleerd.

libssh2 = versie 1.11.1

libssh4 = versie 0.11.4

[DDX]

curl 8.19.0 (Windows) libcurl/8.19.0 Schannel zlib/1.3.1 WinIDN WinLDAP
Release-Date: 2026-03-11
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt mqtts pop3 pop3s smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS HSTS HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM SPNEGO SSL SSPI threadsafe Unicode UnixSockets

Al staat daar niet bij ssh/libssh.
Dit is dus de curl die standaard bij windows geleverd wordt/updates vanuit Microsoft krijgt.

[Daantje20]

Ligt er aan of curl met LibSSL of Schannel is gecompileerd.

[Elminster]

libssl != libssh

LibSSL of Schannel doen er dus niet toe. Dat zijn compleet andere libraries.

[SuperDre]

Beide problemen zijn niet echt een probleem zolang je niet met een malafide server connect, dus in theorie nog niet zo'n probleem.

[JAVE]

Maar hoe weet je dat de betrouwbare server waar je contact mee hebt niet gehacked is?

[baseoa]

Dat kan altijd. Als jouw ssh wachtwoordauthenticatie heeft, kan het dat ook meelezen dan. Je weet bijvoorbeeld ook niet of Outlook momenteel gehackt is en of je e-mails nog wel veilig staan. Afhankelijk van ernst (impact) kun je maatregelen nemen om de kans daarop te verminderen (aanvalsoppervlak op de server verminderen bijvoorbeeld) of de impact beperken (niet met die server verbinden tot de update uit is; vanuit een VM met die server verbinden; ...). Dit is een constant iets en niet enkel relevant nu dat we toevallig van een lek weten in de clientsoftware

[Oon]

In theorie kan dat natuurlijk als het een gedeelde server is of als er een zero-day gebruikt is om die server te hacken, maar als je gewoon alles up to date hebt en netjes keypairs gebruikt voor authenticatie dan is de kans op een server die jij zelf beheert vrij klein. En tot nu toe hebben al deze nieuwe CVE's nog toegang tot het systeem nodig gehad, als er een CVE komt die je SSH auth volledig kan omzeilen dan hoor je dat héél snel.

[Reactie gewijzigd door Oon op 23 juni 2026 23:43]

[M3m3nt0m0r1]

"Op de officiële site is de kwetsbare versie 1.11.1 uit oktober 2024 de recentste release."

Ik vind dit persoonlijk bizar. Alle grote softwarebouwers worden trouwens gefileert als ze pas maanden later een nieuwe versie uitbrengen met de patchcode erin verwerkt, maar hier houden ze willens en wetens een oude versie live die vulnerable is....

[lenwar]

Deze CVE is van 17 juni dit jaar. Zo lang is het dus nog niet bekend

[fuzzyIon]

Gewoon sshd laten luisteren op de exit van de (bijvoorbeeld wireguard) tunnel. Geen sleutels geen verbinding. Geen verbinding geen ssh probleem. Je verplaatst de trust boundary.

[Elminster]

Dit gaat over libssh2, niet over openssh.

Deze library wordt niet gebruikt door openssh.

$ ldd /sbin/sshd
linux-vdso.so.1
libselinux.so.1 => /usr/lib/x86_64-linux-gnu/libselinux.so.1
libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6
libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0
/lib64/ld-linux-x86-64.so.2
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1

[darkfader]

Helaas werkt did trucje maar tijdelijk. Genoeg poortscanners actief die de databases bijwerken dat jij die poort zo hebt ingesteld.

[baseoa]

Alternatieve poort is echter niet wat fuzzylon voorstelt maar een VPN-server ervoor zetten

[batjes]

Haha, het staat wel komisch "het dos-gevaar", pas op straks is je GUI weer text based en veranderen muiskliks in cd en dir.

[nvaert1986]

Nah, gezien het in dit geval veelal Linux distributies betreft, de DOS cmd die de terminal overneemt

[_JGC_]

Debian heeft idd 1.11.1-3, maar daarin zitten niet de fixes voor deze bugs:
https://metadata.ftp-mast...ibssh2_1.11.1-3_changelog

Ze hebben daarbij CVE-2026-7598 (integer overflow in userauth_password) gefixt die ook nog steeds niet in een publieke release zit.

Upstream vindt dit overigens niet belangrijk:
https://github.com/libssh2/libssh2/issues/1925

En ergens kan ik ze wel gelijk geven in het commentaar op dat ticket: je maakt verbinding met een gehackte server, je stuurt je inloggegevens naar de server, je gaat bestanden downloaden en verwerken... dan is een crashende of hangende client je laatste zorg... je wachtwoord ligt op straat en het bestand dat je zojuist gedownload hebt is mogelijk niet het bestand wat je zocht.

[Plux]

Ik ben wel eens gehackt.. ik had open Linux systeem.. ze hebben een heel belangrijk document geremoved of zo..


Ik ben nooit meer hetzelfde geworden

Eigenlijk is dit een fishing attempt voor een reactie van Niles Whitbread die het gedaan zou kunnen hebben..

Prima kerel verder

Maar als het document nog ergens is zou ik het weer willen hebben

[Reactie gewijzigd door Plux op 24 juni 2026 01:08]