Loading story…
OpenJDK published JEP 538, a third preview of APIs for encoding and decoding cryptographic objects using Privacy-Enhanced Mail (PEM) text formats. The proposed capability is intended to make it easier for Java applications to import, export, and exchange objects such as keys, certificates, and certificate requests in the widely used PEM representation.
The feature aligns Java’s cryptographic tooling with common public-key infrastructure workflows built around X.509 certificates and certificate revocation lists (CRLs), whose profiles and validation requirements are defined by RFC 5280. Organizations testing the preview should validate PEM parsing, certificate-chain handling, trust-store integration, and rejection of malformed or untrusted certificate material before deploying applications that use the new APIs.
See real exploitation activity before you spend the cycle.
1 event from the most recent confirmed update back to the earliest known activity.
RFC 5280 was published as an Internet Standards Track specification profiling X.509 version 3 certificates and version 2 certificate revocation lists for Internet PKI. It obsoleted RFC 3280, RFC 4325, and RFC 4630.
See real exploitation activity behind this advisory so you can triage it against everything else in the queue.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Oracle released **Java 26 / JDK 26** as part of its six-month cadence, delivering 10 JDK Enhancement Proposals and a set of incremental changes across performance, networking, language behavior, and security. Security-relevant additions include a preview **PEM encoding API** in `JEP 524` for handling keys, certificates, and certificate revocation lists, plus support for **hybrid public key encryption**, **post-quantum-ready JAR signing**, and stronger controls for cryptographic algorithms and legacy keystores. The release also adds **HTTP/3** support to the standard HTTP Client API through `JEP 517`, enabling applications to communicate with HTTP/3 servers with minimal code changes. Coverage of the release emphasizes that Java 26 is **not an LTS release**, but still introduces changes intended to keep the platform current for developers adopting newer builds. Additional updates include `JEP 500`, which warns when deep reflection is used to mutate final fields as part of Java’s “integrity by default” direction, along with performance work such as reduced synchronization in the **G1 garbage collector** and broader ahead-of-time object caching. The reporting consistently characterizes Java 26 as an incremental platform update with meaningful improvements in **cryptography, transport security, and runtime performance**, rather than a specific security incident or vulnerability disclosure.
Jun 29, 2026
Oracle has released **Java 27** and OpenJDK 27, introducing JEP 527 hybrid key exchange for TLS 1.3 to protect encrypted traffic against “harvest now, decrypt later” attacks enabled by future quantum computing. The release also makes the Garbage-First (**G1**) collector the default across all deployment environments, replacing the Serial collector in constrained deployments, and enables compact object headers by default, reducing headers from 96 to 64 bits to improve memory efficiency and deployment density. Java 27 further advances the Vector API, structured concurrency, pattern matching, primitive-type support, and lazy constants through preview or incubator features. Oracle also issued an early-access JDK 28 build with initial Project Valhalla components, updated Helidon and JavaFX, and added the FIPS 140-3-certified Oracle Jipher 20 cryptographic module to its Java Verified Portfolio; it said these capabilities will progressively reach long-term-support releases.
Sep 17, 2026
Let's Encrypt said it will use **Merkle Tree Certificates (MTCs)** as its preferred approach for post-quantum authentication on the public web, arguing that conventional post-quantum signatures such as `ML-DSA` would make standard TLS certificate chains too large for reliable internet-scale handshakes. The model batches certificate issuance under a single signed Merkle tree head and delivers compact inclusion proofs, reducing handshake overhead while making Certificate Transparency inherent to issuance. Let’s Encrypt said current subscribers do not need to take immediate action, but future ACME clients and related tooling will need updates as the ecosystem moves toward the new format. The move aligns Let’s Encrypt with broader work by **Google, Cloudflare, Chrome, DigiCert, and the IETF**, as browser and infrastructure vendors push for scalable post-quantum TLS ahead of government migration deadlines from the NSA, NIST, and the EU. Let’s Encrypt plans a staging environment for MTC issuance in late 2026 and a production-ready deployment in 2027, while continuing to track `ML-DSA` support for traditional X.509 use cases outside the browser ecosystem. It also said the more urgent near-term defense remains post-quantum encryption against harvest-now-decrypt-later threats, urging operators to enable hybrid key exchange such as: ```text X25519MLKEM768 ```
Jun 29, 2026