On Wed, Jul 22, 2026 at 12:01:23PM -0000, Stuart Henderson wrote: > On 2026-07-22, Raimo Niskanen <[email protected]> wrote: > > Hello misc@! > > > > I have some security department in my Company breathing down my neck because > > I run an OpenBSD 7.9 public server that has got OpenSSH 10.3, and their > > vulnerability scanning tool Black Kite reports that it is vulnerable to > > CVE-2026-59999 (high), CVE-2026-60000 (high), and CVE-2026-6002 (critical). > > > > I can find matching descriptions on > > https://openssh.org/releasenotes.html, but those OpenSSH release > > notes do not list the CVE numbers: > > > > CVE-2026-59999 (high), should be: > > * sshd(8): DisableForwarding=yes didn't override PermitTunnel=yes > > as it was documented to do. Note that PermitTunnel is not enabled > > by default. Reported independently by Huzaifa Sidhpurwala of > > Redhat and Marko Jevtic. > > not relevant unless you have PermitTunnel enabled, DisableForwarding > enabled, and were expecting the latter to override the former. > > > CVE-2026-60000 (high), should be: > > * sshd(8): avoid a potential pre-authentication denial of service > > when GSSAPIAuthentication was enabled (this feature is off by > > default). This was not mitigated by MaxAuthTries, but would be > > penalised by PerSourcePenalties. This was reported by Manfred Kaiser > > of the milCERT AT (Austrian Ministry of Defence). > > not relevant to OpenBSD's builds which are done without GSSAPI > (ypu would need to build yourself with KERBEROS5=yes). > > > CVE-2026-60002 (critical), should be: > > * ssh(1): fix a possible client-side use-after-free if the server > > changes its host key during a key reexchange. This was reported by > > Zhenpeng (Leo) Lin of Depthfirst. > > ssh(1) i.e. cloent-sode.only. I think that's this one, > > Date: 2026/07/06 08:49:58 > Author: djm > Branch: HEAD > Tag: (none) > Log: > fix ownership and lifetime of several bits of client state that > need to persist for the life of the connection, especially the > cached hostkey that was being incorrectly freed early on some > paths, possibly allowing its use after free. > > Reported by Zhenpeng (Leo) Lin from depthfirst.com > > Members: > ssh.c:1.633->1.634 > sshconnect.c:1.383->1.384 > sshconnect.h:1.50->1.51 > sshconnect2.c:1.387->1.388 > > > > From what I see none of these fixes has been backported to a syspatch for > > OpenBSD 7.9, so I guess they are not deemed severe enough. > > > > Still, Black Kite dares to call them "high" and "critical", and my Company's > > security department gives me 30 business days for the "high" and 10 for the > > "critical" to remedy by upgrading to OpenSSH 10.4. > > > > I suppose neither of these will be backported to OpenBSD 7.9, and I dare > > say that none of these bugs is one that the server will encounter... > > > > Does misc@ have any advice on how I should handle my security department, > > or possibly on how to "remedy these CVE:s"...? > > https://www.openssh.org/openbsd.html
That looks promising! If I follow that HowTo and upgrade to OpenSSH 10.4 by updating the openssh source tree and compile - could that conflict with future syspatch:es? Should I then skip all syspatches that target OpenSSH and continue doing manual source code upgrades until the next release? Just want to be sure... / Raimo > > > -- > Please keep replies on the mailing list. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
