I don’t think I’ve ever seen Haiku in a CVE discussion before, but watchTowr included Haiku among the systems that they tested which include the flawed code from GNU inetutils.
So, nifty to see Haiku is on their list of systems to check; sad to see it came up as vulnerable.
Haiku includes telnetd from FreeBSD, which doesn’t maintain it anymore. There isn’t a license friendly patch available for this version, only for the GNU inetutils one.
How about replacing it with the Toybox (0BSD license) version?
https://github.com/landley/toybox/blob/master/toys/pending/telnetd.c
Note that it might need polishing.
Is there any valid reason to not entirely remove telnetd from the Haiku default installation?
I looked into this a bit more,the article was really interesting with all the technical details,but I think it’s not true that Haiku is affected.
I tested it with the testing tool from GitHub - watchtowrlabs/watchtowr-vs-telnetd-CVE-2026-32746 · GitHub and it reported that LINEMODE is not supported.
That’s because telnetd on Haiku seems to be built without LINEMODE support.
The code section in question that contains the vulnerability is hidden behind #ifdef LINEMODE but LINEMODE is never defined within the code.
Additionally to this,the Telnet server is disabled by default so that you can’t exploit any random Haiku installation,even if it was affected by the bug.
I really don’t understand calls for removing existing functionality that works perfectly fine or replacing the whole telnetd with another implementation when there are zero reasons for that.
Fixing our current telnetd implementation if it’s built with LINEMODE support is a matter of adding a single if statement in the code,and the article even links directly to the line where that if statement needs to be.
Still testing a few things,will compile haiku.hpkg with LINEMODE enabled to see if I can reproduce the vulnerability then,and will then push a fix soon.
If the Haiku version is not affected, there is indeed no need for replacing. Thanks for testing.
The fix is located in a GPL source code, thus I don’t know whether it can simply picked up.
It’s a single if line that can be written purely based on the descriptions of the article without directly reading the GPL code.
Thinking of threshold of originality,I doubt a single-line patch that’s so simple can be copyrighted.
Nevermind,one can’t even easily build telnetd with LINEMODE enabled because that leads to other errors.
We don’t have the termios c_lflag called EXTPROC needed in sys_term.c line 434.
Neither do we have the TIOCPKT_IOCTL needed in telnetd.c line 1101.
That all first needs to be fixed before we can enable the code that makes Haiku vulnerable to the CVE,therefore I’d say we’re pretty safe.
So, what should we do? Tell watchtowr they’re wrong and they should remove Haiku from the list of affected systems? Or enjoy the exposure?
Definitely enjoy the exposure. We’re in some illustrious company here.
We don’t maintain it, upstream doesn’t maintain it. Haiku used to have almost everything “In-Tree”, that was before ports and such. Now that we have a working package manager it is perfectly fine to remove functionality we can’t or won’t maintain, and instead ship “whatever ‘upstream’ thinks a telnetd does”
The basic flow is just removing this server, and then the three people who need this for some reason can install it from HaikuDepot, and enjoy having an actually mantained version.
Don’t we? Someone looked into it and it turns out there is no bug in our case since the affected code is not compiled in.
And it’s working.
So there is no reason to touch the code.
Korli mentioned above that this code is from FreeBSD and they don’t maintain it anymore. Unless we have developers who do want to maintain it I don’t see a reason why we shouldn’t let the people who actually maintain a telnetd have it in haikuports 
Usually most of our maintenance of imported code involves irregularily syncing with Upstream, here we can’t do that anymore.
There are no known bugs. What kind of maintenance do you expect? Should we change the copyright year and make a few tweaks to the code for no reason?
This part of Haiku is done and complete until proven otherwise.
Ongoing maintenance would mean making sure this continues to work, testing it, making sure it works in the next release etc.
Are you doing that? Is anyone else doing that?
Would you fix a bug in telnetd if it broke for beta6? If the answer is no, and other developers wouldn’t either then it would be a candidate for haikuports.
And in any case, I quoted niposes post to explain the reaction, not because I believe that we have to do this, but rather where the consideration comes from to potentially do it.
It’s part of Haiku code and I will handle any bug reports to the best of my abilities, with the same care as I would do for any other parts of Haiku codebase.
For what it’s worth, I’d argue that replacing telnetd with sshd in the core OS but allowing it to be installed from ports is the correct security posture.
If y’all think a patch to do that would be acceptable, I can look into how to do that.
But I still can’t login to the review site, so I’ll need to deal with that first anyway. 
sshd is already available through the openssh package and available in network preferences.
Both are disabled by default and require configuration in the network preferences, so, from the security point of view, this is a pretty low attack surface. Especially for Haiku, which is designed to run in local network, probably behind a firewall, and not open to all of the internet.
Oh, I totally agree that it’s not a big deal or urgent; given my sysadmin-not-actually-a-developer level of expertise, I wouldn’t volunteer if I thought it were
I just think that the way it is now is incorrect, since I think bundling anything that does plaintext authentication is the incorrect approach, and I’m willing to put the effort in to (as I see it) fix it.
but it’s a small thing, though, so if y’all think it wouldn’t be worth the time to review, I’ll shut up about it.