The host key check ran, and passed, on a curve the attacker chose for it

wolfSSH 1.6.0 shipped on 6 October 2026 with fixes for five flaws. The one worth reading about is CVE-2026-16516, scored 9, filed under insufficient verification of data authenticity, and present in everything up to 1.5.0.

The library did not check that the elliptic curve named in a server's host key matched the algorithm the two sides had just agreed to use.

What SSH is actually protecting

Everything SSH does against a machine-in-the-middle rests on one step. The client and server negotiate, the server presents a host key, and the client checks that this is the key it expects. If that holds, nobody in the middle can impersonate the server, because nobody in the middle has the matching private key.

Here the check ran. It did not fail. It passed — on the wrong object.

During the key exchange the server sends a reply containing its host key. An attacker sitting in the middle replaces that blob with one declaring a different curve from the one negotiated. wolfSSH did not reject the mismatch. It imported the substituted key on the curve the attacker named, verified the signature against it, and found it valid — because the attacker holds that key's private half and signed with it.

No error. No warning. A successful verification of something that was never the server.

From there the attacker is the server: it can read the traffic, inject commands into the session, and pass everything through to the real host so neither end notices.

The precondition most coverage drops

There is a second condition, and leaving it out makes this sound worse than it is.

The substitution only works if the application's public key check callback is lax. If that callback compares the full expected key — the thing a known-hosts file does — the substituted key does not match, and the attack stops there.

So the flaw is not that wolfSSH will accept any server. It is that wolfSSH removed one of the two independent checks, leaving everything resting on the other, and on an implementation detail the library does not control.

That is still a serious finding. Defence in depth means the system survives one layer failing. Here one layer was silently absent for every version up to 1.5.0, and nobody using it knew they were down to a single check.

Where this lands, and why that is the problem

wolfSSH is an embedded SSH library. It is chosen for small footprint and for running on hardware where OpenSSH will not fit — routers, industrial controllers, point-of-sale terminals, medical and automotive systems.

Two things follow, and together they are the real story.

The first is that a lax key check callback is more likely in exactly this software. Distributing and maintaining a known-hosts file across a fleet of devices with no filesystem to speak of, no user to answer a prompt, and a provisioning process that happens once in a factory is genuinely awkward. A callback that accepts the key it is given is the shortcut everyone reaches for, and it is precisely the configuration this flaw requires.

The second is that these devices do not update. A library fix published on 6 October reaches a product when the manufacturer picks it up, cuts a firmware release, and the operator installs it — which for a lot of this hardware means never. The population most exposed to this is the population least able to act on it.

It is the same shape as the Rejetto flaw we covered last week, where a weak generator and a leaky code path were each harmless and lethal together. Cryptographic code fails at the joins, not usually in the mathematics.

What to do

• Upgrade to wolfSSH 1.6.0. It carries five fixes, not only this one.
• Audit your public key check callback first, because it decides whether you were ever exposed. If it accepts an unknown key, or compares only part of one, fix that regardless of the version you run.
• If you ship hardware, work out which products embed this and what your route to a firmware update is. That answer is more useful than the CVE.
• If you operate equipment you cannot patch, treat its SSH sessions as untrusted on hostile networks and put a layer underneath them.

What is not established

• Whether this has been exploited. Nothing published says so, and a successful attack here leaves no error behind.
• How many products embed wolfSSH at an affected version.
• How common lax key check callbacks actually are in deployed firmware, which nobody has measured.
• Whether the other four flaws fixed in 1.6.0 are independently serious, which the release does not detail.