CVE-2025-11579: Nwaples Rardecode DOS Vulnerability

CVE-2025-11579 Overview

CVE-2025-11579 affects the github.com/nwaples/rardecode Go library through version 2.1.1. The library fails to restrict the dictionary size when parsing RAR archives, allowing an attacker to craft a malicious RAR file that triggers excessive memory allocation. Processing the file causes an Out-Of-Memory (OOM) crash in the host application, resulting in Denial of Service. The flaw is classified under [CWE-789: Memory Allocation with Excessive Size Value]. Applications that accept untrusted RAR uploads and decode them with rardecode are directly exposed. The maintainer addressed the issue by introducing a configurable maximum dictionary size, defaulting to 4GB.

Critical Impact
A single crafted RAR file can exhaust host memory and crash any Go application that decodes untrusted RAR archives using nwaples/rardecode versions 2.1.1 and earlier.

Affected Products

github.com/nwaples/rardecode versions <= 2.1.1
Go applications embedding rardecode for RAR archive extraction
Services or tools that accept and process user-supplied RAR files

Discovery Timeline

2025-10-10 - CVE-2025-11579 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-11579

Vulnerability Analysis

The rardecode library parses RAR archive headers, including a winSize field that specifies the decompression dictionary size. Prior to the fix, the library validated winSize only against an internal maxDictSize constant. A specially crafted RAR file can declare a dictionary size that passes the internal check but forces the decoder to allocate an unbounded buffer. The Go runtime attempts to satisfy the allocation, exhausting available memory and terminating the process. Because RAR parsing typically runs in-process, the crash takes down the entire host application, not just the decoding goroutine. This affects backend services, malware scanners, and archive utilities that operate on untrusted content.

Root Cause

The root cause is missing caller-configurable bounds on dictionary size allocation. The library exposed no API for downstream consumers to cap memory usage during header processing. Attackers control the winSize value directly through the archive header.

Attack Vector

Exploitation requires an attacker to deliver a malicious RAR file to a service that decodes it. User interaction, such as uploading a file or opening an attachment, is required. No authentication is needed when the target exposes public upload or extraction functionality.

// Patch: reader.go - enforce caller-configurable max dictionary size
		if !h.UnKnownSize && h.winSize > h.UnPackedSize {
			h.winSize = h.UnPackedSize
		}
-		if h.winSize > maxDictSize {
+		if h.winSize > maxDictSize || h.winSize > pr.opt.maxDictSize {
			return nil, ErrDictionaryTooLarge
		}
		if h.winSize > math.MaxInt {

// Patch: volume.go - introduce DefaultMaxDictionarySize constant
+const (
+	DefaultMaxDictionarySize = 4 << 30 // default max dictionary size of 4GB
+)

 type options struct {
-	bsize     int     // size to be use for bufio.Reader
+	bsize       int     // size to be use for bufio.Reader
+	maxDictSize int64   // max dictionary size
	fs          fs.FS   // filesystem to use to open files
	pass        *string // password for encrypted volumes
	skipCheck   bool
	openCheck   bool
 }
// Source: https://github.com/nwaples/rardecode/commit/52fb4e825c936636f251f7e7deded39ab11df9a9

Detection Methods for CVE-2025-11579

Indicators of Compromise

Sudden process termination logs from Go services that decode RAR files, often preceded by runtime: out of memory messages.
Rapid resident-set-size (RSS) growth in archive-processing workers immediately after receiving a RAR upload.
RAR archive submissions where the declared dictionary window size exceeds typical RAR values (RAR5 max is 4GB, most legitimate files use 4MB–256MB).

Detection Strategies

Perform Software Composition Analysis (SCA) on Go modules to flag any dependency on github.com/nwaples/rardecode at version <= 2.1.1.
Inspect RAR headers at the network or proxy layer and reject archives declaring dictionary sizes above an organizational threshold.
Correlate OOM kill events (oom_reaper, exit code 137) with recent file-upload activity in application logs.

Monitoring Recommendations

Track memory ceiling breaches and container restarts on workers that ingest user-supplied archives.
Alert on repeated crashes of the same service tied to specific client IP addresses or upload sessions.
Log the SHA-256 hash and declared metadata of each processed RAR file to support post-incident analysis.

How to Mitigate CVE-2025-11579

Immediate Actions Required

Upgrade github.com/nwaples/rardecode to the patched release containing commit 52fb4e825c936636f251f7e7deded39ab11df9a9 and rebuild dependent binaries.
Set an explicit maxDictSize option well below DefaultMaxDictionarySize (4GB) that matches the largest legitimate archive your application must handle.
Enforce cgroup or container memory limits on any process that decodes untrusted RAR files so an OOM condition contains the blast radius.

Patch Information

The fix is available in the nwaples/rardecode commit 52fb4e8. It adds a DefaultMaxDictionarySize constant (4GB) and a new maxDictSize option, and enforces the caller-supplied limit in reader.go before allocating decompression buffers. Consumers must both upgrade the module and pass the option to receive protection tighter than the 4GB default.

Workarounds

Reject RAR uploads at the application gateway when downgrade is not immediately possible.
Decode RAR archives in an isolated subprocess with a hard memory limit (ulimit -v or container --memory) so crashes do not affect the parent service.
Pre-validate RAR headers with a lightweight parser and drop files whose declared window size exceeds a conservative bound before invoking rardecode.

bash

# Update the module in your Go project to the patched version
go get -u github.com/nwaples/rardecode
go mod tidy

# Verify the resolved version is above 2.1.1
go list -m github.com/nwaples/rardecode

# Example: enforce a 256MB dictionary cap when opening an archive
# (pseudocode — refer to package docs for the exact option constructor)
# reader, err := rardecode.OpenReader(path, rardecode.MaxDictionarySize(256<<20))