CVE-2025-24970

What it actually does

This vulnerability is an improper input validation flaw in Netty's SslHandler. A specially crafted TLS/SSL packet can reach validation paths that are not handled correctly in all cases, causing a native crash in the process using Netty. The primary security impact is remote denial of service against applications, brokers, gateways, API services, or other network-facing Java services that terminate TLS using affected Netty code paths. The available information supports service crash/availability impact, not code execution or data disclosure.

Why it matters to the business

Applications that expose TLS endpoints through affected Netty versions may be remotely crashed by malformed network traffic, causing outages, failed requests, degraded service reliability, and possible cascading failures in systems that depend on those services. The CVSS score is high at 7.5 because exploitation can be network-based and affect availability, but current public exploit maturity is listed as none, EPSS is low at 0.02112, and it is not in the CISA Known Exploited Vulnerabilities catalog, so remediation should be prioritized for internet-facing and business-critical services rather than treated as confirmed active mass exploitation.

How an attack unfolds

An attacker first identifies a service that accepts TLS connections and is implemented with an affected Netty build. The attacker then opens a network connection and sends a specially crafted SSL/TLS packet that exercises SslHandler validation behavior. Instead of rejecting the malformed packet cleanly, the affected code path can trigger a native crash. If the application process terminates or its event loop is destabilized, the service becomes unavailable until restarted by a supervisor, container orchestrator, or operator. Repeated delivery of the crafted packet can turn a single crash into a sustained denial-of-service condition. No authentication is implied by the vulnerability description, and exploitation is most relevant where the vulnerable TLS listener is reachable by untrusted clients.

How to fix it

Upgrade affected Netty code to a version that includes the upstream fix. For source-based consumers of netty/netty, ensure the codebase includes commit 87f40725155b2f89adfde68c7732f97c153676c4 or a later release containing that change. For packaged dependencies, update all Netty artifacts consistently rather than mixing patched and unpatched modules; pay particular attention to applications that include Netty transitively through frameworks, RPC stacks, API gateways, message brokers, service meshes, or embedded servers. Rebuild and redeploy affected services after dependency updates. Where immediate patching is not possible, reduce exposure by limiting access to affected TLS listeners, placing services behind load balancers or proxies that normalize or reject malformed TLS traffic, enabling process supervision and restart limits, and applying rate limiting for repeated failed TLS handshakes from the same source. Mitigations should be treated as temporary because the vulnerability is in packet handling logic inside the application dependency.

How to confirm the fix worked

Confirm exposure by generating a software bill of materials or dependency inventory and checking for Netty components built from affected netty/netty code prior to commit 87f40725155b2f89adfde68c7732f97c153676c4. Validate remediation by confirming the deployed artifact, container image, or runtime classpath contains patched Netty modules and no older duplicate Netty JARs are shadowing the fixed version. In source builds, verify the fix commit is present with source-control tooling. In runtime validation, review application startup logs or dependency reports for Netty versions, then perform normal TLS handshake and negative malformed-input testing in a controlled environment to ensure malformed TLS traffic is rejected without process crash. Finally, verify orchestration logs show no new native crash loops, JVM fatal error files, or unexplained restarts after deployment.

Typical attack path

1. Scan or enumerate externally reachable TLS services that may be implemented with Netty.
2. Confirm service behavior consistent with a Java/Netty-based TLS endpoint, where feasible from banners, protocol behavior, dependency disclosures, or application fingerprinting.
3. Establish a TLS connection attempt to the target service.
4. Send a specially crafted malformed SSL/TLS packet that reaches the vulnerable SslHandler validation path.
5. Trigger a native crash in the process handling the connection.
6. Repeat the malformed connection attempts to sustain service disruption or defeat automatic restart mechanisms.

How to detect it

To determine whether exploitation may already have occurred, correlate network, application, JVM, operating system, and orchestration telemetry around service restarts. Review application logs for Netty SslHandler exceptions, abrupt connection closures during TLS negotiation, and bursts of failed handshakes. Review JVM crash artifacts such as hs_err_pid files, fatal error logs, core dumps, and container termination events that occurred shortly after inbound TLS connection attempts. In Linux environments, check syslog, journald, kernel logs, and container runtime events for SIGSEGV, SIGABRT, core dumped, or abnormal Java process exits. In Kubernetes or similar platforms, review pod restart counts, CrashLoopBackOff events, OOM-independent restarts, and previous container logs. In network telemetry, look for repeated short-lived TLS connections, malformed ClientHello or TLS record parsing failures, handshake failures concentrated from a small set of source IPs, and spikes in TLS negotiation errors immediately preceding crashes. Because no public exploit signature or unique packet bytes are provided, detection should focus on crash artifacts plus temporal correlation with malformed TLS traffic rather than a single definitive IOC.

• io.netty.handler.ssl.SslHandler
• javax.net.ssl.SSLException
• javax.net.ssl.SSLHandshakeException
• not an SSL/TLS record
• failed to decode packet
• fatal error detected by the Java Runtime Environment
• hs_err_pid
• SIGSEGV
• SIGABRT
• core dumped
• Problematic frame:
• java.lang.Error: Cleaner terminated abnormally
• CrashLoopBackOff
• Back-off restarting failed container
• Container exited with status 134
• Container exited with status 139
• SSL routines
• tlsv1 alert decode error
• bad record mac
• wrong version number

What your security team should do

• Inventory all externally reachable and business-critical services that use Netty for TLS handling, including transitive dependency use through Java frameworks and embedded servers.
• Prioritize patching internet-facing TLS listeners and high-availability backend services to Netty builds containing commit 87f40725155b2f89adfde68c7732f97c153676c4 or later fixed releases.
• Search build artifacts, container images, and runtime classpaths for duplicate or stale Netty JARs that could keep vulnerable code in production despite a declared dependency update.
• Add monitoring for JVM fatal errors, native crashes, container restarts, and spikes in failed TLS handshakes on Netty-based services.
• Use edge controls such as reverse proxies, load balancers, ACLs, and rate limiting to reduce direct exposure of vulnerable TLS listeners until all affected services are patched.
• Treat repeated malformed TLS handshake failures followed by Java process termination as suspicious and investigate for denial-of-service attempts.
• Track upstream Netty advisories and framework vendor updates, because many organizations consume Netty indirectly and may need patched framework releases rather than only direct dependency changes.