GPU VulnDB

Database/Kernel, userspace & hypervisor

Apache MINA SSHD: server ignores force-command and verify-required in OpenSSH user certificates

CVSS 7.3CVE-2026-56624Kernel, userspace & hypervisorcurated

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

All Kernel, userspace & hypervisor entries

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.