Een kwetsbaarheid in libssh2 heeft de veiligheidsalertes doen afgaan in systemen en applicaties die deze bibliotheek gebruiken voor het beheren van SSH-2-verbindingen. De kwetsbaarheid, geïdentificeerd als CVE-2026-55200, treft libssh2 tot en met versie 1.11.1 inbegrepen en kan een externe aanvaller in staat stellen geheugen corruptie te veroorzaken door speciaal gemanipuleerde SSH-pakketten.
Deze kwetsbaarheid beïnvloedt SSH in het algemeen niet automatisch en betekent niet dat alle servers met OpenSSH blootgesteld zijn. Het is essentieel om te identificeren welke producten, tools of interne ontwikkelingen afhankelijk zijn van libssh2, direct of indirect, en in welke context SSH-verkeer wordt verwerkt. Daar ligt het risico dat de kwetsbaarheid een reële dreiging vormt voor servers, agents, implementatiehulpmiddelen, geautomatiseerde clients of componenten in andere applicaties.
Een probleem met pakkengrootte
De oorzaak ligt in de functie ssh2_transport_read() in transport.c. Volgens de beschrijvingen op NVD en VulnCheck stelde libssh2 geen passend bovengrenslimiet aan het packet_length-veld bij het verwerken van SSH-pakketten. Een te grote waarde kon leiden tot een out-of-bounds schrijf in het heap-geheugen, met potentiële impact op beschikbaarheid, integriteit en vertrouwelijkheid.
De kwetsbaarheid is gecategoriseerd onder CWE-680, wat een zwakte is die een combinatie bevat van een integer overflow en daaropvolgend buffer overflow. In de praktijk zijn dergelijke fouten bijzonder gevoelig omdat een schijnbaar beperkte fout in grootte-berekening of validatie wél kan leiden tot geheugencorruptie en in sommige gevallen tot remote code execution.
De gepubliceerde scores verschillen; dit is gebruikelijk wanneer verschillende bronnen gebruikmaken van verschillende meetmethoden of beoordelingen op verschillende tijdstippen. VulnCheck beoordeelt de kwetsbaarheid als kritisch, met 9,2 in CVSS 4.0, terwijl NVD een score van 8,3 in CVSS 3.1 toont na analyse, met een hoge ernst.
Buiten de exacte cijfers is de kernboodschap helder: het betreft een ernstige zwakte in een laag-niveau bibliotheek, die door software wordt gebruikt die mogelijk niet meteen zichtbaar is in de bestaande inventarisatie.
De fix staat al in de code
De fix is doorgevoerd in commit 97acf3d in de libssh2-repository, gekoppeld aan de wijziging ‘Additional boundary checks for packet length’. De patch voegt extra checks toe op de packetlengte en geeft een foutmelding wanneer packet_length groter is dan LIBSSH2_PACKET_MAXPAYLOAD, in plaats van door te gaan met een onveilige verwerking.
De wijziging is klein in omvang, maar significant in impact. Vijf toegevoegde en één gewijzigde regel vormen een effectieve maatregel om een route voor geheugencorruptie te sluiten, die was te activeren door pakketten die buiten de toegestane lengtes waren voorbereid. Dergelijke patches benadrukken waarom het continu controleren van limieten een cruciaal onderdeel blijft van beveiliging in C-bibliotheken.
Systeembeheerders en beveiligingsteams worden geadviseerd om zo snel mogelijk te updaten naar een versie of pakket dat deze fix bevat, of het equivalent te patchen wanneer de distributie nog geen officiële update heeft uitgebracht.
Het is niet voldoende om alleen het systeempakket bij te werken. libssh2 kan ingebed zijn in applicaties, appliances, back-up clients, deployment tools, DevOps-integraties of commerciële producten. Een goede review van de Software Bill of Materials (SBOM), dependency-scanners, gekoppelde dynamische pakketten en containerimages is daarom essentieel.
Wat moeten technische teams controleren?
De focus moet liggen op systemen die SSH-verkeer accepteren vanaf onbetrouwbare netwerken of verbinding maken met SSH-servers die niet onder controle van de organisatie staan. Hoewel het exacte risico afhangt van de wijze waarop elke toepassing libssh2 gebruikt, verdienen systemen die blootstaan aan het internet, klantnetwerken, geautomatiseerde verbindingen en externe beheerverbindingen prioriteit.
Bij Linux-servers is de eerste stap controleren of libssh2 geïnstalleerd is en welke versie de distributie levert. Vervolgens moet nagegaan worden of de leverancier het benodigde patch al heeft verwerkt, aangezien sommige distributies beveiligingsbackports toepassen zonder meteen naar de nieuwste upstream-versie te upgraden. Alleen de versie controleren kan misleidend zijn.
In containers moet de controle omvatten: base-images, interne tool-images en build-pipelines die software met native afhankelijkheden produceren. Een oude container met een kwetsbare libssh2 kan onopgemerkt blijven als deze niet is opgebouwd met bijgewerkte pakketten.
Daarnaast is het versterken van monitoring belangrijk. Exploitpogingen kunnen sporen achterlaten in negotiation-fouten, onverwachte afsluitingen, onverwachte crashes of ongewone SSH-activiteiten. Het patchen blijft het beste, maar bewaking helpt om verdachte activiteiten te detecteren binnen de blootstellingsperiode.
De kernles is bekend maar niet altijd toegepast: kritieke kwetsbaarheden bevinden zich niet altijd in de zichtbare service. Vaak zitten ze verstopt in gedeelde bibliotheken die door andere programma’s worden gebruikt. Het controleren waar libssh2 in de supply chain verschijnt, is net zo belangrijk als de update uitvoeren.
Veelgestelde vragen
Wat is CVE-2026-55200?
Een kwetsbaarheid in libssh2 die het mogelijk maakt om een write-out-of-bounds in geheugen te veroorzaken bij het verwerken van gemanipuleerde SSH-pakketten. Dit kan potentieel leiden tot remote code execution.
Trekt dit alle SSH-servers aan?
Niet automatisch. Het treft software die gebruikmaakt van een kwetsbare libssh2. Het betekent niet dat alle servers met open poort 22 automatisch kwetsbaar zijn, vooral niet als ze niet libssh2 gebruiken.
Wat moet ik eerst doen?
Update libssh2 naar een versie of pakket dat de fix bevat (commit 97acf3d). Vervolgens moet je controleren of afhankelijkheden en containerimages ook al zijn bijgewerkt.
Bronnen:
NVD
VulnCheck
GitHub – libssh2