On 2026-07-22, Raimo Niskanen <[email protected]> wrote: > 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...
syspatches affecting openssh would overwrite, you could either rebuild (from same or newer unpacked source) or just go with the syspatches if they fix the problems you care about anyway. (I tend to just rebuild openssh from -current cvs on release/stable systems if I really want the update, it usually works and I find it less trouble than downloading a separate tar, but you do have to be a bit more careful with that).
