Java vulnerabilities of the week: 12 to 18 August 2026
The previous post covered 5 to 11 August, this one covers 12 to 18. Same format: the five things worth knowing, then two taken apart, because the mechanism is the part you can generalise from.
The previous post covered 5 to 11 August, this one covers 12 to 18. Same format: the five things worth knowing, then two taken apart, because the mechanism is the part you can generalise from.
This one covers 5 to 11 August, the next one covers 12 to 18. Same idea as always: what caught my attention in the Java ecosystem, then two items looked at properly, because the CVE number and the score are the least useful part of any of this. The mechanism is what you can carry to your own code.
Second week of this. The idea is the same as last time: list what caught my attention in the Java ecosystem, then pick two and look at the mechanism, because the CVE number and the score never tell you anything you can use.
I read a lot of security news and most of it is useless. Not wrong, just useless: a CVE number, a CVSS score, a vendor advisory link, “patch immediately”. You close the tab and you have learned nothing. The interesting part of a vulnerability is almost never the score, its the mechanism. How does a broker end up skipping an ACL check because you gave a destination the right kind of name? What happens when the library whose entire job is to answer yes or no gets equals() backwards?
Post-Quantum Cryptography has moved from research papers to production standards. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024, and the Java ecosystem is catching up fast. JDK 24 shipped with native ML-KEM support via the javax.crypto.KEM API (JEP 496), and JDK 27 will bring PQC directly into TLS with JEP 527.