Database/Kernel, userspace & hypervisor
Apache MINA SSHD: server ignores force-command and verify-required in OpenSSH user certificates
Impact
When a MINA SSHD server authenticates a user presenting an OpenSSH user certificate, it does not check for or validate the force-command and verify-required critical options embedded in that certificate. MINA SSHD implements neither, so a certificate issued deliberately restricted to a single command was accepted and the restriction simply dropped: the holder authenticates and can run whatever else the server exposes, and a verify-required certificate is accepted without the touch/PIN check its issuer intended. Which commands that actually yields depends on the embedding server's implementation. Operators feel this wherever a Java SSH or SFTP endpoint sits in the fleet's workflow - code review and artifact services, internal SFTP gateways, custom job-submission shells - and where force-command was the mechanism holding a narrow-purpose certificate to one operation. The certificate still has to be issued by a CA the server trusts, so this is an escape from an intended restriction, not an authentication bypass.
Who can reach it
A user holding a valid OpenSSH user certificate signed by a CA the MINA SSHD server trusts, where that certificate carries a force-command (or verify-required) option meant to constrain them. Authentication succeeds normally; the flaw is that the constraint is not enforced. Reachable by anyone who can connect to the SSH endpoint and holds such a certificate.
What to do
Upgrade the embedding application to Apache MINA SSHD 2.19.0 or 3.0.0-M5, which reject certificates carrying these options outright, and restart that service - a daemon restart of the Java service, no node work. If you cannot upgrade now, stop relying on force-command certificates against MINA SSHD endpoints and enforce the command restriction server-side in your own ShellFactory/CommandFactory instead.
References
Related entries
- Linux kernel (net/xfrm, net/key): No memory corruption here, but a clean namespace boundary break. SA migrationCVE-2026-63914 · Linux kernel (net/xfrm, net/key)High
- Leapp RHEL 9 to 10 upgrade: scan_mysql runs mysqld as root, letting mysql-owned state load code as UID 0CVE-2026-75092 · leapp-upgrade-el9toel10 scan_mysql actor (leapp-repository)High
- zbus_polkit: caller-supplied UID is silently discarded, leaving polkit authorization open to a PID-reuse raceCVE-2026-78422 · zbus_polkit Rust crate (Subject::new_for_owner UID encoding)High
- OpenZFS: ioctl checks accept unprivileged user-namespace capabilities, granting local pool adminCVE-2026-79619 · OpenZFS on Linux (/dev/zfs ioctl privilege checks vs. unprivileged user namespaces)High
- Linux kernel eBPF: syncookie helpers read sk_protocol on mini-sockets without a fullsock checkCVE-2026-80738 · Linux kernel eBPF (bpf_tcp_gen_syncookie / bpf_tcp_check_syncookie helpers)High
- Xen on AMD - x86 HVM pagetable height update: AMD HVM guest OS users can trigger a data-structure access during aCVE-2019-19577 · Xen on AMD - x86 HVM pagetable height updateHigh
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.