In non-CA mode, an attacker who has access to the private key of a pinned certificate can:
Present a certificate with the correct public key
Modify the CN in the client certificate to any arbitrary value
Cause Vault to assign the resulting alias.Name to that CN
You have access to the private key of the public key in a certificate. The certificate is making an attestation that the signer has verified that this canonical name belongs to this public key.
You as the holder of the private key that matches the public key in the certificate should not allow you to change what the signer has attested about you.
When you lose your private key, you have lost the war to protect your identity - anyone else can now be you. But in a properly designed system, that should not also compromise the signer.
If I steal your license I can pretend to be you, but I can't make the government say you are 7 feet tall.
You may be making the point that a compromised keystore holding all users public keys may leak the signers private key at the same time it has leaked the victim's private key, but there are many ways the victim's private key can be leaked in most cryptosystems (eg, the victim's private key on their device may be stolen).
So maybe one step down in severity, though I do not know the details of what HCSEC-2024-05 was fixed with as that was after the fork point. OpenBao moved to full cert pinning (constant-time cert.Raw comparisons) when remediating that one, which meant we were not affected by this variant.