CVE-2025-25193

What it actually does

This flaw is a local denial-of-service condition in Netty on Windows. A vulnerable Netty-based application may attempt to read a Unix-style environment or operating-system metadata file path that normally does not exist on Windows. If an attacker with local file-write capability creates that expected file as an extremely large file, Netty can read it unsafely and exhaust memory or otherwise crash the Java process. The impact is availability loss only; the issue does not directly provide remote code execution, privilege escalation, or data disclosure.

Why it matters to the business

Applications that depend on vulnerable Netty builds can be crashed by someone who can write files to the affected Windows filesystem location, causing service downtime, failed transactions, degraded customer-facing availability, or disruption to internal systems that rely on Netty-based networking. The public exploitation signal is currently low, with EPSS at 0.00384, no known CISA KEV listing, no known ransomware association, and no reported exploit maturity, but Netty is widely embedded in Java applications and frameworks, so exposure may exist indirectly through packaged dependencies.

How an attack unfolds

An attacker first needs local or equivalent file-write access to a Windows system running a vulnerable Netty-based Java application. The attacker identifies the Unix-style environment file path that Netty will try to read on Windows and creates the missing path and file, such as a drive-rooted etc/os-release-style file, with an abnormally large size. When the vulnerable application starts, restarts, initializes the affected Netty code path, or otherwise triggers environment detection, Netty attempts to read the attacker-created file. Because the file is read unsafely, the Java process can consume excessive memory and terminate with an out-of-memory error or crash, resulting in denial of service until the file is removed and the application is restarted or Netty is upgraded.

How to fix it

Upgrade Netty to a version that includes the upstream fix commit d1fbda62d3a47835d3fb35db8bd42ecc205a5386 or any later official release containing that change. Because Netty is often bundled transitively, inspect all Java dependency manifests, lockfiles, shaded JARs, container images, vendor packages, and application servers for vulnerable Netty components, including io.netty modules. If an immediate upgrade is not possible, mitigate by preventing untrusted users and service accounts from creating drive-rooted etc/os-release-style files on Windows hosts, removing any unexpected environment metadata files from Windows drive roots, enforcing least-privilege filesystem permissions, and monitoring for creation of unusually large files at those paths. Restart affected applications only after the malicious or oversized file has been removed or the dependency has been patched.

How to confirm the fix worked

Confirm the deployed Netty source or binary includes commit d1fbda62d3a47835d3fb35db8bd42ecc205a5386 or a later release that incorporates it. Validate software composition analysis results for all direct and transitive Netty dependencies, including shaded or repackaged copies. On Windows systems, verify that unexpected drive-rooted etc/os-release-style files do not exist and that normal application users cannot create them. In a controlled non-production environment, test startup or initialization behavior with a safely bounded test file at the relevant path and confirm the patched application does not perform unsafe unbounded reads or crash. Review recent crash logs before and after remediation to ensure OutOfMemoryError or abnormal Java process exits associated with os-release/environment-file reads no longer occur.

Typical attack path

1. Gain local access, malware execution, misconfigured file-write access, or another foothold that permits creating files on the Windows host filesystem.
2. Create the expected Unix-style environment metadata path on Windows, commonly resembling an etc/os-release path at the drive root.
3. Populate the file with excessive data intended to force high memory consumption during Netty initialization or environment detection.
4. Wait for or trigger restart/initialization of the vulnerable Netty-based application.
5. The application reads the large file, exhausts memory or crashes, and the dependent service becomes unavailable.
6. Repeat the crash by leaving the file in place until the vulnerable Netty dependency is patched or the malicious file is removed.

How to detect it

Look for evidence that a large environment metadata file was created on Windows shortly before Java or Netty-based services crashed. Useful sources include Windows Security file auditing events if enabled, Sysmon file creation events, EDR file telemetry, application logs, JVM crash logs, Windows Application event logs, service manager restart events, container runtime logs, and SIEM records for process termination or memory exhaustion. Correlate creation or modification of drive-rooted etc/os-release-style files with java.exe or javaw.exe OutOfMemoryError messages, abnormal exits, repeated service restarts, or high memory consumption. Investigate the user, process, or parent process that created the file, especially if it was not an installer, administrator maintenance task, or expected configuration management activity. Since this issue is a denial-of-service flaw rather than code execution, the strongest indicators are suspicious file creation at the relevant path plus temporally related Netty/Java application crashes.

• C:\etc\os-release
• D:\etc\os-release
• \etc\os-release
• /etc/os-release
• OutOfMemoryError
• java.lang.OutOfMemoryError
• java.exe
• javaw.exe
• io.netty
• Netty
• os-release

What your security team should do

• Inventory applications, services, containers, and vendor products that include Netty, prioritizing Windows deployments.
• Upgrade all affected Netty components to builds containing commit d1fbda62d3a47835d3fb35db8bd42ecc205a5386 or later fixed releases.
• Search Windows hosts for unexpected or oversized etc/os-release-style files at drive roots and remove suspicious instances after preserving forensic evidence where appropriate.
• Harden filesystem permissions so non-administrative users and application identities cannot create arbitrary files or directories at drive roots.
• Add endpoint and SIEM detections for creation or modification of drive-rooted etc/os-release files and for Java crashes associated with OutOfMemoryError near Netty initialization.
• For critical services, perform dependency verification on shaded JARs and vendor-supplied packages because Netty may not appear as an obvious top-level dependency.
• Treat this as a moderate-priority availability issue: exploit likelihood is currently low, but remediation should be included in routine dependency patch cycles, especially for Windows-hosted production services.