KB5033910: Windows Server 2016 Security Update (January 2024)

An attacker who can present a malformed certificate to a .NET / PowerShell / Visual Studio application that does its own chain-building logic — typically a custom authentication or signature-verification flow, common in internal LOB applications — can be authenticated despite the failed chain-build. The result is authentication bypass: the attacker gets in as a legitimate user without a valid certificate.

.NET Framework, .NET (Core), PowerShell, and Visual Studio 2022 ship the X.509 chain-building APIs that applications call to validate TLS certificates and code-signing certificates. A logic flaw causes the framework to correctly report that chain-building failed for a certificate with a malformed signature — but it returns an incorrect reason code. Applications that use the reason code (rather than the boolean failure result) to make trust decisions may treat the failure as success and accept the untrusted certificate.

Probably yes if any of these apply:

A custom internal application uses .NET's chain-building API to verify client certificates. The application checks the returned reason code rather than the boolean overall-success — a common but subtly wrong pattern. An attacker presents an untrusted certificate with a malformed signature; the framework reports failure-with-wrong-reason, the application treats it as success, and the attacker authenticates. The bug is in the framework but the impact is application-specific.