In case you haven't seen one of the SSH security advisory it is is here.

Why this reached a release. The code that compares a presented host key against the pinned one was correct. What was missing was a test: nothing connected with the wrong key, or with a key of an algorithm other than the one pinned, and checked that the pin refused it. An entry that had not resolved to a key, or that did not match the algorithm the server chose, accepted the key the server sent and reported nothing. That was the whole of it.

Testing a security control is testing that it refuses, and the work is in choosing the refusal that matters — the wrong key, the wrong algorithm, the key that is not loaded yet. That is not a lesson from this defect; it is how we have worked for twenty years, and how every other trust decision in the library is tested. What this defect changed is one thing: we no longer take it on faith that the negative tests are all present. We now audit the test suite against a list of every point where the library accepts or rejects a key, a certificate, a signature or a MAC, and require each to have a test that drives it with the wrong input and fails unless the input is refused. This bug was a gap in that coverage; the audit is there to find the next gap before a release does.

We would rather show you the defect and the gap than the fix on its own. The disclosure policy this advisory is published under — SECURITY.txt, new in this release — is the same posture. Please contact us if you have any questions.