Loading story…
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.
Track how attackers are adapting to this technology.
3 events from the most recent confirmed update back to the earliest known activity.
Java 27 introduced JEP 527 support for hybrid key exchange in TLS 1.3, intended to mitigate the risk of adversaries harvesting encrypted data for future quantum-enabled decryption.
Oracle announced general availability of OpenJDK/Java 27 and Oracle JDK 27. The release makes the G1 garbage collector the default in all environments, enables compact object headers by default, and adds previews or incubators including structured concurrency, lazy constants, and the Vector API.
Oracle released an early-access JDK 28 build containing initial Project Valhalla components. It also updated Helidon and JavaFX, and added the FIPS 140-3-certified Oracle Jipher 20 cryptographic module to its Java Verified Portfolio.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Follow how adversaries are adapting to this technology, and where it touches your stack today.
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
Google said **Android 17** will begin a broad migration to post-quantum cryptography as part of a plan to harden the platform against future quantum attacks on public-key systems. The company is introducing quantum-resistant protections across core trust components, including **Android Verified Boot**, **Remote Attestation**, **KeyMint**, and **Android Keystore**, with support centered on the NIST-standardized `ML-DSA` algorithm. Google said the move is intended to build a quantum-resistant chain of trust spanning device boot, identity verification, and hardware-backed security services. Google also said **Google Play** will support hybrid app signing that combines classical and post-quantum signatures, and will begin generating quantum-safe `ML-DSA` signing keys for new apps while allowing existing apps to opt in. The company is targeting completion of its broader post-quantum migration by **2029**, citing the risk of **store-now-decrypt-later** attacks and warning that organizations should begin adopting NIST-developed PQC standards before fault-tolerant quantum computers can break current encryption. Google added that future Play updates are expected to support hybrid key upgrades and prompt developers to rotate signing keys every two years.
Jun 29, 2026
Major hardware vendors are beginning to embed **post-quantum cryptography (PQC)** into processors and platform security features as organizations prepare for quantum-era attacks. Intel said its **Xeon 6** server chips now support PQC-capable protections, while Nvidia is integrating NIST-approved post-quantum standards into confidential computing security layers. The shift is aimed at reducing exposure to **harvest-now, decrypt-later** campaigns, in which adversaries steal encrypted data today in anticipation of breaking legacy cryptography once large-scale quantum computing becomes practical. The move follows NIST’s standardization of post-quantum algorithms, a milestone that accelerated vendor adoption and enterprise migration planning. The reporting highlights that widely used public-key schemes such as **RSA** and **ECC** are expected to be vulnerable to quantum attacks, while **AES-256** remains a stronger option for symmetric encryption and is already hardware-accelerated on some platforms. Security teams are being pushed to inventory cryptographic dependencies and identify older systems that cannot be upgraded to support quantum-resistant protections.
Aug 23, 2026