Re: CVE-2026-28372: Telnetd Vulnerability Report

[Salvatore Bonaccorso <carnil () debian org>]

Hi,

On Fri, Mar 06, 2026 at 04:39:23PM +0100, Guillem Jover wrote:
> Hi!
>
> On Fri, 2026-03-06 at 16:16:49 +0100, Solar Designer wrote:
> > On Fri, Feb 27, 2026 at 01:09:57PM +0100, Guillem Jover wrote:
> > > On Tue, 2026-02-24 at 11:57:34 +0200, Ron Ben Yizhak wrote:
> > > > I’d like to ensure we follow the standard CVE process here. Standard
> > > > practice dictates that a CVE is issued per individual fix. Generally, once
> > > > a fix is merged and released, it is assigned its own CVE. Even if that fix
> > > > is later bypassed, the original merge stands as a unique event in the
> > > > codebase, meaning we should issue two separate CVEs rather than grouping
> > > > them.
> > >
> > > Salvatore Bonaccorso from the Debian Security Team got a CVE assigned
> > > for this, see <https://www.cve.org/CVERecord?id=CVE-2026-28372>. I'll
> > > update the Debian packaging on the next upload to point to that.
> >
> > The CVE description says:
> >
> > "telnetd in GNU inetutils through 2.7 allows privilege escalation that
> > can be exploited by abusing systemd service credentials support added to
> > the login(1) implementation of util-linux in release 2.40. This is
> > related to client control over the CREDENTIALS_DIRECTORY environment
> > variable, and requires an unprivileged local user to create a
> > login.noauth file."
> >
> > So is this CVE only for the attack vector reported by Ron Ben Yizhak,
> > and not also for the other attack vector and more general issue reported
> > by Justin Swartz?
> >
> > If so, are you going to assign a second CVE for the more general issue?
>
> I'm not part of the Debian Security Team (I just maintain the inetutils
> package in Debian), but I think they assigned a CVE because there didn't
> seem to be one coming from upstream. I guess the expectation would be
> that if there's a new CVE to be assigned that would be handled by
> upstream, but if it's needed and it's not forthcoming they might assign
> another one? (Although the easier way forward would be to reuse the
> existing one, and issue an update for the DSA.)

I just need to clarify one thing here: The CVE was not assigned by the
Debian CNA, but as there was no CVE assigned by the issue reported by
Ron, I requested one from MITRE. There was none assigned in time when
we released the DSA, and at that point TTBOMK the more general
issue/root cause indication by Justin Swartz was not known. So the CVE
request to MITRE was done specifically as for the issue found by Ron.

Later, after the DSA release on our end, the CVE got assigned.

This is why
https://lists.debian.org/debian-security-announce/2026/msg00053.html
does not mention any CVE.

So in short: The CVE request to mitre was back then done specific to
the issue as it is described in the CVE description, specific to
CREDENTIALS_DIRECTORY environment variable passing to login(1).

So I think just another CVE should be requested for the more general
issue.

Regards,
Salvatore