image

32 jaar oud Telnet-lek kan aanvaller volledige controle over servers geven

vrijdag 20 maart 2026, 14:13 door Redactie, 18 reacties

Onderzoekers hebben een 32 jaar oude kwetsbaarheid in Telnet ontdekt waardoor aanvallers in het ergste geval volledige controle over de server kunnen krijgen. Een beveiligingsupdate is nog niet beschikbaar. De kwetsbaarheid bevindt zich in de Telnet daemon van GNU Inetutils (telnetd), een verzameling van netwerkprogramma's, waaronder een telnet-client en -server, een ftp-client en -server en rsh-client en -server.

Het uit 1969 stammende Telnet laat gebruikers op afstand op machines inloggen. In 1994 werd er een kwetsbaarheid in de code geïntroduceerd, die recentelijk werd ontdekt. Het probleem (CVE-2026-32746) bevindt zich in de Linemode feature van het Telnet-protocol. Hierbij wordt het netwerkverkeer beperkt tot een aantal packets per command line, in plaats van een aantal packets per getypt karakter. Dit is vooral bedoeld voor trage verbindingen.

Linemode heeft een optie genaamd Set Linemode Characters (SLC) waarmee de state van speciale karakters kan worden ingesteld of veranderd. De server kan zo aan de client laten weten dat voor bepaalde commando's specifieke control codes moeten worden gebruikt, laten onderzoekers van securitybedrijf watchTowr weten. De server stuurt hiervoor een lijst met speciale karakters en karakterwaardes die moeten worden vervangen. De client kan, als die wil dat er aanpassingen worden gedaan, een reply met nieuwe waardes versturen.

De server slaat al deze waardes op in een array met een vaste omvang, zonder te controleren of de ontvangen waardes wel passen, wat tot een buffer overflow kan leiden. Onderzoekers van Dream Security Research Team die het probleem ontdekten waarschuwen dat een aanvaller via het lek willekeurige code als root kan uitvoeren en de server volledig kan compromitteren.

De onderzoekers van watchTowr merken op dat het probleem aanwezig is in 'alleen' GNU inetutils, maar de meeste leveranciers hun Telnetd-implementatie op dezelfde code baseren. Daardoor is onduidelijk welke platforms allemaal risico lopen. Het raakt volgens de onderzoekers in elk geval alle grote Linux-distributies. Tevens is ook van Citrix NetScaler, macOS Tahoe, TrueNAS Core en andere systemen bevestigd dat die kwetsbaar zijn.

"Het meest opvallende aan deze kwetsbaarheid is de enorme reikwijdte ervan. Een goed deel van het grote aantal systemen dat een Telnet-server draait bevat deze kwetsbare code", aldus de onderzoekers, die verwachten dat het probleem nog jaren aanwezig zal blijven. Op het moment van schrijven is er nog geen update beschikbaar. De meest recente versie van GNU Inetutils, versie 2.7, is nog steeds kwetsbaar. Daardoor zijn er ook voor Linux-distributies nog geen patches beschikbaar.

Reacties (18)
20-03-2026, 15:22 door Anoniem
Je mag tegenwoordig toch wel ervan uitgaan dat TELNET op geen enkel netwerk meer gebruikt wordt? In ieder geval zeker niet op internet gekoppelde systemen en dat firewalls dit blokkeren of zeer beperkt toestaan.

En indien dit bij een organisatie niet het geval is...... Vervang dan je hele Security team. Met hun gaat het m toch nooit worden.
20-03-2026, 17:22 door Anoniem
Door Anoniem: Je mag tegenwoordig toch wel ervan uitgaan dat TELNET op geen enkel netwerk meer gebruikt wordt? In ieder geval zeker niet op internet gekoppelde systemen en dat firewalls dit blokkeren of zeer beperkt toestaan.

En indien dit bij een organisatie niet het geval is...... Vervang dan je hele Security team. Met hun gaat het m toch nooit worden.
Vooral op devices met beperkte resources zie je nog wel eens telnet, de crypto van ssh is dan blijkbaar te zwaar. Als je zo'n device nodig hebt doet je security team daar ook weinig aan. Uiteraard kan je wel andere mitigerende maatregelen nemen.
20-03-2026, 17:26 door Anoniem
Door Anoniem:
Door Anoniem: Je mag tegenwoordig toch wel ervan uitgaan dat TELNET op geen enkel netwerk meer gebruikt wordt? In ieder geval zeker niet op internet gekoppelde systemen en dat firewalls dit blokkeren of zeer beperkt toestaan.

En indien dit bij een organisatie niet het geval is...... Vervang dan je hele Security team. Met hun gaat het m toch nooit worden.
Vooral op devices met beperkte resources zie je nog wel eens telnet, de crypto van ssh is dan blijkbaar te zwaar. Als je zo'n device nodig hebt doet je security team daar ook weinig aan. Uiteraard kan je wel andere mitigerende maatregelen nemen.

Dan zet je ze op een Air Gapped netwerk. Maar zeker niet aan de rest van het netwerk. Kopen ze maar een apparaat dat wel een veilige connectie kan opzetten.
20-03-2026, 17:39 door Anoniem
Vooral op devices met beperkte resources zie je nog wel eens telnet, de crypto van ssh is dan blijkbaar te zwaar.

Je mag hopen dat dergelijke systemen op een aparte vlan draaien en dat alleen vaste ip adressen/reeksen (nl die van de beheerders) op dat vlan mogen.
20-03-2026, 19:02 door Anoniem
Net op tijd gestopt om telnet te gebruiken! Dat was inderdaad ook ongeveer 32 jaar geleden!
20-03-2026, 19:56 door linuxpro - Bijgewerkt: 20-03-2026, 19:58
Dan moet je ook maar geen telnet gebruiken... en misschien moet de telnet daemon maar 's uit GNU Inetutils worden gehaald. De client, het telnet programma zelf, is soms best handig om even snel te kijken of er iets op een bepaade poort luistert maar ook daar zijn alternatieven voor.
20-03-2026, 21:44 door Anoniem
Door linuxpro: Dan moet je ook maar geen telnet gebruiken... en misschien moet de telnet daemon maar 's uit GNU Inetutils worden gehaald.

In 1994 was het nog niet zo normaal om geen telnet te gebruiken.

"Bug in veel gebruikt open source pakket sinds 1994 niet gezien " . Ff in gedachten houden als iemand weer eens al te hard op de "many eyes" theorie zit.

Elders vroeg ooit iemand hoe (een vendor) een 10.0 CVE niet kon zien.

Dit is een 9.8 CVE.


https://codeberg.org/inetutils/inetutils/src/branch/master/telnetd/slc.c
537 regels code in deze file.

Even niet spieken - zie je meteen :

https://codeberg.org/inetutils/inetutils/pulls/17/files
Zo ziet (deze) 9.8 CVE eruit
21-03-2026, 12:00 door Anoniem
Als je toch geen telnet hoeft te gebruiken:
poort 23 van je router maar eens helemaal dicht zetten.
21-03-2026, 13:53 door Anoniem
Synology heeft deze kwetsbaarheid al op 19 maart gepatcht!!!

Fixed a security vulnerability regarding Telnetd (CVE-2026-32746)(Synology-SA-26:03).
21-03-2026, 16:00 door Anoniem
Ik ken geen enkele distributie of server waar standaard telnet wordt geinstalleerd. Telnet is iets uit het verre verleden, net als het finger, ident, gopher, etc. protocol.

Waarschijnlijk weten de meeste beheerders geeneens meer wat deze oude services doen.
21-03-2026, 21:11 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Je mag tegenwoordig toch wel ervan uitgaan dat TELNET op geen enkel netwerk meer gebruikt wordt? In ieder geval zeker niet op internet gekoppelde systemen en dat firewalls dit blokkeren of zeer beperkt toestaan.

En indien dit bij een organisatie niet het geval is...... Vervang dan je hele Security team. Met hun gaat het m toch nooit worden.
Vooral op devices met beperkte resources zie je nog wel eens telnet, de crypto van ssh is dan blijkbaar te zwaar. Als je zo'n device nodig hebt doet je security team daar ook weinig aan. Uiteraard kan je wel andere mitigerende maatregelen nemen.

Dan zet je ze op een Air Gapped netwerk. Maar zeker niet aan de rest van het netwerk. Kopen ze maar een apparaat dat wel een veilige connectie kan opzetten.

Air gapped in een gebouw waar zenog koper leidingen hebben voor de vaste communicatie lijn zeker! Dan is je servertje ook uitgelezen, of je er nou Ollama op draait of iets anders. Je maakt mij niet wijs dat van oude gebouwen installatietekeningen of voorschriften zijn waar de leidingen zitten, wat ik wel weet is dat ze te traceren zijn.
23-03-2026, 10:21 door Anoniem
Het uit 1969 stammende Telnet laat gebruikers op afstand op machines inloggen. In 1994 werd er een kwetsbaarheid in de code geïntroduceerd, die recentelijk werd ontdekt.
Nou, dan moesten we op termijn maar eens in beraad gaan over hoe we dit probleem zouden kunnen gaan verhelpen in de nabije toekomst. Het is natuurlijk absoluut niet de bedoeling dat men zichzelf zomaar access kan verschaffen tot een server. Je moet niet denken aan de gevolgen dat dat kan hebben!
23-03-2026, 12:22 door Anoniem
Door Anoniem:
Het uit 1969 stammende Telnet laat gebruikers op afstand op machines inloggen. In 1994 werd er een kwetsbaarheid in de code geïntroduceerd, die recentelijk werd ontdekt.
Nou, dan moesten we op termijn maar eens in beraad gaan over hoe we dit probleem zouden kunnen gaan verhelpen in de nabije toekomst. Het is natuurlijk absoluut niet de bedoeling dat men zichzelf zomaar access kan verschaffen tot een server. Je moet niet denken aan de gevolgen dat dat kan hebben!

Dat is de laatste dertig of veertig jaar al de uitdaging.
En de gevolgen die het kan hebben zijn bekend . Men noemt die een 'inbraak in het computersysteem' .

En omdat het nu telnet is roept iedereen hier "maar dat moet allang uit staan" . Voor telnet klopt dat.

Dezelfde zorg kun je hebben over ssh , over een maildaemon, over een webserver , een fileshare - ELK protocol dat "iets" doet met de buitenwereld en actief is.
En implementaties van die protocollen komen dus ook regelmatig langs met vulnerabilities.

Oplossingen die genoemd worden :

"We moeten alles herschrijven in een andere programmeertaal waarin dit soort fouten niet gemaakt kunnen worden" . (diverse kandidaten) .
Merk op dat zelfs een klein beetje code zoals telnetd blijkbaar geen leuk oefenproject was voor een van de fans van een alternatieve taal .

Met enorm complexe permissie systemen zorgen dat bugs in (bv) telnetd minder mogelijkheden geven. (selinux, capability OSen etc etc ).
Gaat ook niet hard.

"Auditen" - code bekijken (eventueel met tools) en dit soort bugs proberen te vinden . Blijkbaar niet gedaan of niet gelukt in de afgelopen 30 jaar voor een heel wijd verbreid pakket zoals inetutils . Oeps.
23-03-2026, 14:53 door Anoniem
Je zult versteld staan wat er allemaal nog aan het netwerk hangt wat telnet ondersteunt, desnoods op een alternatieve poort (voor security by obscurity).
23-03-2026, 23:54 door Anoniem
Door Anoniem:
Het uit 1969 stammende Telnet laat gebruikers op afstand op machines inloggen. In 1994 werd er een kwetsbaarheid in de code geïntroduceerd, die recentelijk werd ontdekt.
Nou, dan moesten we op termijn maar eens in beraad gaan over hoe we dit probleem zouden kunnen gaan verhelpen in de nabije toekomst. Het is natuurlijk absoluut niet de bedoeling dat men zichzelf zomaar access kan verschaffen tot een server. Je moet niet denken aan de gevolgen dat dat kan hebben!

Wijsheid is te onderzoeken wat het dit lek uit 1994 heeft veroorzaakt, wat dit lek op de server heeft ingebouwd, dan wel bekend is, al dertig jaar. Het misbruik ervan is dan invuloefening. Dat is pas een eenvoudige analysetool, of niet soms?
24-03-2026, 11:36 door Joep Lunaar
Wijsheid is: wees niet zo stupide producten die een telnet daemon draaien bloot te stellen aan ongeautoriseerde toegang (WAN én LAN), plaats dergelijke producten daarvoor dan tenminste op een afgeschermd VLAN.
Meer wijsheid is: koop sowieso geen (goedkope) gadgets zonder eerst na te gaan wat op het netwerk uitspoken.

Veelal voldoet dergelijke apparatuur niet aan de wettelijke eisen qua informatiebeveiliging.
En wijheid is dat er een keer op die regels wordt gehandhaafd.

Het telnet protocol en de implementatie ervan staan al lange tijd bekend als ongeschikt voor veilige (beheer)toegang. Dus waar dat nog voorkomt moeten in elk geval extra beschermingsmaatregelen zijn getroffen. Het zou toch anno 2026 volstrekt vanzelfsprekend moeten zijn dat routers die de ISPs hun klanten leveren behalve een privé- en gastennetwerk ook een IOT netwerk (afgescheiden VLAN) bieden. Dat die routers daarin nog niet voorzien is een gospe.
24-03-2026, 18:00 door Anoniem
Door Joep Lunaar: Wijsheid is: wees niet zo stupide producten die een telnet daemon draaien bloot te stellen aan ongeautoriseerde toegang (WAN én LAN), plaats dergelijke producten daarvoor dan tenminste op een afgeschermd VLAN.

Het _protocol_ nadeel van telnet is dat het geen encryptie gebruikt voor de login credentials.

Als je telnetd nu achter een TLS wrapper (stelnet) had gehangen was dat protocol nadeel opgelost, toch ?
Deze bug niet.

Maar waarom is het nu precies WEL wijsheid om codebases die tientallen keren groter zijn WEL toegankelijk te maken ?

nogmaals :

+ if (slcbuf + sizeof slcbuf - slcptr <= 6)
+ return;

Is het _enige_ dat een 9.8 CVE maakte.

En dan mag je best bang worden als je de (gigantische) codebases van SSHD, OpenVPN, OpenSSL, OpenSwan bekijkt (en, en, en) bekijkt en je afvraagt of zo'n "oeps vergeten te checken" stukje er ook in ontbreekt.


Meer wijsheid is: koop sowieso geen (goedkope) gadgets zonder eerst na te gaan wat op het netwerk uitspoken.

Was het een foute keuze van "gadgets" om een van de wijd verspreide GNU opensource projecten te kiezen ?
Normaal is (zeker hier) dat het standaard advies juist, in plaats van zelf iets in elkaar te laten klutsen door een intern.

protocol telnet is niet meer OK - maar "enorme bug in simpele codebase in 32 jaar niet publiek gevonden" is een veel groter zorgpunt , m.i.
28-03-2026, 15:44 door Joep Lunaar
Door Anoniem:
Door Joep Lunaar: Wijsheid is: wees niet zo stupide producten die een telnet daemon draaien bloot te stellen aan ongeautoriseerde toegang (WAN én LAN), plaats dergelijke producten daarvoor dan tenminste op een afgeschermd VLAN.

Het _protocol_ nadeel van telnet is dat het geen encryptie gebruikt voor de login credentials.
Als je telnetd nu achter een TLS wrapper (stelnet) had gehangen was dat protocol nadeel opgelost, toch ?
Deze bug niet.

Maar waarom is het nu precies WEL wijsheid om codebases die tientallen keren groter zijn WEL toegankelijk te maken ?
Retorische tegenvraag: wat vertrouw je eerder, Debian als basis voor een webservice of een MS Windows server?

nogmaals :

+ if (slcbuf + sizeof slcbuf - slcptr <= 6)
+ return;

Is het _enige_ dat een 9.8 CVE maakte.
Hier staat: als minder dan 6 bytes in slcbuf beschikbaar, return. Dat het een simpel stukje code is, zegt niets, daarvoor moet je het bezien in haar context. De betroffen implementatie van telnet pretendeert heus niet geschikt te zijn voor gevoelige toepassingen. Net als dat een step niet geschikt is voor de snelweg en het dus irrelevant is of een step een voldoend korte remweg heeft bij 100 km per uur.

En dan mag je best bang worden als je de (gigantische) codebases van SSHD, OpenVPN, OpenSSL, OpenSwan bekijkt (en, en, en) bekijkt en je afvraagt of zo'n "oeps vergeten te checken" stukje er ook in ontbreekt.
Wat is je punt?
Dat veel bestaande code mogelijk nog kwetsbaarheden bevat ? (zeker het geval, wel steeds minder)
Of dat open source code meer risico's oplevert dan closed source code ? (aantoonbaar onjuist)
Of dat ontwikkelaars van FOSS (meer dan die van closed source) onzorgvuldig te werk gaan ? (aantoonbaar onjuist)

Hoe dan ook, alle relevante inspanningen in de ontwikkeling van gereedschappen voor het vinden van kwetsbaarheden in programmacode of veiliger te programmeren (Rust, Go, Ada) zijn OSS.

En de code van projecten als OpenSSL, OpenSSH en OpenSwan, die bij uitstek gericht zijn op veilige communicatie, wordt zeker flink gescand op kwetsbaarheden. En op een gegeven moment, wanneer blijkt dat de code structureel problematisch is omdat die niet voor huidige gevaren is ontworpen, dan komt er een alternatief. Zoals Wireguard als vervanging voor OpenVPN. De veiligheid van OpenSSL heeft gek genoeg een enorme boost gekregen doordat, juist vanwege de legacy, LibreSSL als alternatief is ontwikkeld. De daarbij ontwikkelde inzichten zijn voor heel wat projecten waardevol gebleken, voor OSS maar ook voor veel projecten daarbuiten.

Wat overigens niet helpt zijn "CVE jagers" die, veelal met AI, FOSS projecten overwelmen met bogus vulnerability reports.


Meer wijsheid is: koop sowieso geen (goedkope) gadgets zonder eerst na te gaan wat op het netwerk uitspoken.

Was het een foute keuze van "gadgets" om een van de wijd verspreide GNU opensource projecten te kiezen ?
Keuze voor FOSS is niets mis mee. De fout van de gadget leverancier is het gebruik van telnet wanneer het niet geschikt is voor de toepassing, waar bijvoorbeeld SSH een veel betere keuze was geweest. Net zo goed als het gebruik van hard gecodeerde wachtwoorden enz. verkeerde implementatiekeuzes zijn.

Normaal is (zeker hier) dat het standaard advies juist, in plaats van zelf iets in elkaar te laten klutsen door een intern.
Weet niet wat je bedoeld met "het standaard advies", maar, inderdaad, zelf iets (nieuw) ontwikkelen, zal zelden het niveau van een gerenommeerd OSS project kunnen halen.

protocol telnet is niet meer OK - maar "enorme bug in simpele codebase in 32 jaar niet publiek gevonden" is een veel groter zorgpunt , m.i.
Is geen zorgpunt. Omdat telnet niet is ontwikkeld met het oog op het grote boze Internet moet het stomweg niet worden toegepast in situaties waarvoor het nooit is bedoeld. En ontwikkelaars gaan daar geen tijd meer in steken. Dat producenten van gadgets het gebruiken omdat het weinig resources nodig heeft en daarmee op kosten besparen, is onverantwoordelijk van hen.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.