ECDSA signatures consist of two values, usually called r and s. The issue is that ECDSA signature validation compares r to the product of the inverse of s multiplied with other values. Depending on how the inverse of s is calculated, the inverse of zero may also be evaluated to zero.
In Java this is the case, so zero gets compared to zero—independent of the message to be validated. Thus a signature where the r and s values are set to zero will always pass.
This is generally a known property of ECDSA. It is therefore required to check that the r and s values are not zero, which is supposed to be the first step of the signature verification algorithm. However, Java failed to implement that check.
Madden noted in a later blog post that two zeros are not the only way to bypass the signature check.
The vulnerability was introduced in Java version 15, where the previous ECDSA implementation written in C++ was replaced by one written in native Java. Oracle fixed the vulnerability in its April update, and the vulnerability was assigned the ID CVE-2022-21449. OpenJDK, the open-source distribution of Java, also published an advisory.
It is noteworthy that this vulnerability was not caught earlier. Neil Madden points out that Project Wycheproof, a cryptographic test suite published by Google, would have caught this vulnerability.