Hi Agostino, On Fri, Apr 03, 2026 at 09:43:49AM +0200, Agostino Sarubbo wrote: > On giovedì 2 aprile 2026 11:25:08 Ora legale dell’Europa centrale Damien > Miller wrote: > > Security > > ======== > > > > * ssh(1): validation of shell metacharacters in user names supplied > > on the command-line was performed too late to prevent some > > situations where they could be expanded from %-tokens in > > ssh_config. For certain configurations, such as those that use a > > "%u" token in a "Match exec" block, an attacker who can control > > the user name passed to ssh(1) could potentially execute arbitrary > > shell commands. Reported by Florian Kohnhäuser. > > > > We continue to recommend against directly exposing ssh(1) and > > other tools' command-lines to untrusted input. Mitigations such > > as this can not be absolute given the variety of shells and user > > configurations in use. > > > > * sshd(8): when matching an authorized_keys principals="" option > > against a list of principals in a certificate, an incorrect > > algorithm was used that could allow inappropriate matching in > > cases where a principal name in the certificate contains a > > comma character. Exploitation of the condition requires an > > authorized_keys principals="" option that lists more than one > > principal *and* a CA that will issue a certificate that encodes > > more than one of these principal names separated by a comma > > (typical CAs stronly constrain which principal names they will > > place in a certificate). This condition only applies to user- > > trusted CA keys in authorized_keys, the main certificate > > authentication path (TrustedUserCAKeys/AuthorizedPrincipalsFile) > > is not affected. Reported by Vladimir Tokarev. > > > > * scp(1): when downloading files as root in legacy (-O) mode and > > without the -p (preserve modes) flag set, scp did not clear > > setuid/setgid bits from downloaded files as one might typically > > expect. This bug dates back to the original Berkeley rcp program. > > Reported by Christos Papakonstantinou of Cantina and Spearbit. > > > > * sshd(8): fix incomplete application of PubkeyAcceptedAlgorithms > > and HostbasedAcceptedAlgorithms with regard to ECDSA keys. > > Previously if one of these directives contains any ECDSA algorithm > > name (say "ecdsa-sha2-nistp384"), then any other ECDSA algorithm > > would be accepted in its place regardless of whether it was > > listed or not. Reported by Christos Papakonstantinou of Cantina > > and Spearbit. > > > > * ssh(1): connection multiplexing confirmation (requested using > > "ControlMaster ask/autoask") was not being tested for proxy mode > > multiplexing sessions (i.e. "ssh -O proxy ..."). Reported by > > Michalis Vasileiadis. > > Hello Damien, > > thank you for bringing this to oss-security so that everyone is aware of it. > > Regarding the security changes, we do not see any CVE assigned. Could you > please clarify > your perspective on this? Are these changes considered simply hardening > improvements, > or do they have a security impact that would warrant a CVE?
I think since yesterday there were CVE assigned actually by MITRE, they should be: https://www.cve.org/CVERecord?id=CVE-2026-35414 https://www.cve.org/CVERecord?id=CVE-2026-35385 https://www.cve.org/CVERecord?id=CVE-2026-35386 https://www.cve.org/CVERecord?id=CVE-2026-35387 https://www.cve.org/CVERecord?id=CVE-2026-35388 Regards, Salvatore
