Reminds me of the Solaris telnet 0-day from 2007

Posted Jan 20, 2026 22:13 UTC (Tue) by dcantrell (subscriber, #75800)
Parent article: Remote authentication bypass in telnetd

This one and the Solaris one from 2007 read the same, even noting that Solaris' telnet bug in 2007 reads like a Linux and AIX rlogin bug from 1994.

https://www.kb.cert.org/vuls/id/881872
https://it.slashdot.org/story/07/02/12/1118248/solaris-te...

I could not find where LWN posted about the story. Wayback Machine can be used to dig up the blogs.sun.com posts and other things.

What was interesting in 2007 was that Sun was in the middle of OpenSolaris being a thing so all of the code was open[-ish] at the time too. So when the vulnerability was announced, everyone could go and look at the code. Sun did some PR work on blogs.sun.com and elsewhere to show how quickly the coordinated working up a fix, testing it, and getting updates out to customers. What we didn't get from that was that, hey, maybe all the other OSes should check their telnet code. Oh well.

to post comments

Reminds me of the Solaris telnet 0-day from 2007

Posted Jan 20, 2026 22:58 UTC (Tue) by edmonds42 (guest, #42670) [Link] (2 responses)

> What we didn't get from that was that, hey, maybe all the other OSes should check their telnet code.

We wouldn't have found this particular inetutils bug if we had gone looking in 2007, though, because it wasn't introduced until 2015, alarmingly enough.

Reminds me of the Solaris telnet 0-day from 2007

Posted Jan 20, 2026 23:57 UTC (Tue) by dcantrell (subscriber, #75800) [Link]

True, but too bad inetutils couldn't inherit Sun's fix. It's like all new telnet offerings have to start from that original implementation.

Reminds me of the Solaris telnet 0-day from 2007

Posted Jan 22, 2026 4:22 UTC (Thu) by smurf (subscriber, #17840) [Link]

No, but whoever introduced the problem might have remembered not to use unvetted data as arguments in the first place.

Ultimately the problem is that, inside telnetd, the output of the code that processes the template for the arguments to /bin/login is a new string which is then split … instead of a proper argv vector. The current patch includes a nice little blacklist of possible shell metacharacters (ASCII only of course, and not excluding control characters (other than tab and newline)) to paper over the problem, but I hesitate to call that a solution.

Better idea: blacklist the whole inetutils-telnetd package.