GHSA-3pxh-h8hw-mj8w CVE-2013-0183

Rack rubygems receiving excessively long lines triggers out-of-memory error

Medium RubyGems

Severity: Medium; The publisher's own rating, not a CVSS score
Exploit chance (EPSS): 3.78%; Chance of exploitation in the next 30 days. Higher than 89.95% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer; CWE-400 Uncontrolled Resource Consumption
Fix: 1.3.8; Upgrade rack to this version or later

Description

multipart/parser.rb in Rack 1.3.x before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to cause a denial of service (memory consumption and out-of-memory error) via a long string in a Multipart HTTP packet.

Affected versions

RubyGems

Package	Vulnerable	Fixed in
rack	`>= 1.3.0, < 1.3.8`	`1.3.8`
rack	`>= 1.4.0, < 1.4.3`	`1.4.3`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

rack RubyGems → `1.3.8`

bundler

bundle update rack # Gemfile: gem "rack", ">= 1.3.8"

Weakness

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.

How to prevent it

Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.
Operation, Build and Compilation: Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.
Implementation: Consider adhering to the following rules when allocating and managing an application's memory: Double check that the buffer is as large as specified. When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string. Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space. If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.
Operation, Build and Compilation: Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
Operation: Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment. For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].
Implementation: Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

CWE-400: Uncontrolled Resource Consumption

The product does not properly control the allocation and maintenance of a limited resource.

How to prevent it

Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
Implementation: Ensure that all failures in resource allocation place the system into a safe posture.

References

Advisories

nvd.nist.gov/vuln/detail/CVE-2013-0183

Packages

github.com/rack/rack

Timeline

Oct 24, 2017 Published
Dec 3, 2024 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-g2pf-xv49-m2h5 Rack::Request accepts invalid Host characters, enabling host allowlist bypass	Medium	Also affects rack
GHSA-v6x5-cg8r-vv6x Rack's multipart header parsing allows Denial of Service via escape-heavy quoted parameters	High	Also affects rack
GHSA-qfgr-crr9-7r49 Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing	Medium	Also affects rack
GHSA-rx22-g9mx-qrhv Rack's improper unfolding of folded multipart headers preserves CRLF in parsed parameter values	Medium	Also affects rack
GHSA-q2ww-5357-x388 Rack has Content-Length mismatch in Rack::Files error responses	Medium	Also affects rack
GHSA-qv7j-4883-hwh7 Rack::Sendfile header-based X-Accel-Mapping regex injection enables unauthorized X-Accel-Redirect	High	Also affects rack
GHSA-8vqr-qjwx-82mw Rack's multipart parsing without Content-Length header allows unbounded chunked file uploads	High	Also affects rack
GHSA-x8cg-fq8g-mxfx Rack's multipart byte range processing allows denial of service via excessive overlapping ranges	High	Also affects rack

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor