CVE-2024-0241 is a high severity (CVSS 7.5) denial of service flaw in the encoded_id-rails Ruby gem. An unauthenticated remote request with an extremely long id parameter can exhaust CPU and memory. Versions through 1.0.0.beta1 are affected, so upgrade to 1.0.0.beta2 or later.
What's affected
The GitHub advisory says affected versions are 1.0.0.beta1 and earlier, and the patched version is 1.0.0.beta2 or later. The record agrees: versions before 1.0.0.beta2.
The advisory explains the mechanism. Web servers such as Puma limit URI and path length, but an extremely long encoded id can still burn a lot of CPU when decoded with the hashids library, and can allocate more than 200MB of objects. The patch adds an option to limit the length of ids that can be decoded. The advisory does not name the option, so read the gem's release notes when you upgrade.
One difference to note: the GitHub advisory page we fetched states that no CVE ID is assigned, while the record is filed under CVE-2024-0241. Treat them as the same issue, since the record references the same advisory (GHSA-3px7-jm2p-6h2c).
How to check if you're exposed
Search your Ruby projects for the gem. In a project directory:
bundle list | grep encoded_id
grep -n encoded_id Gemfile.lock
If the version printed is 1.0.0.beta1 or lower, you are in range. Run the check in every repository and every deployed application, since the gem is small and easy to forget. The free in-browser dependency scan can read a Gemfile.lock and list this advisory if it matches.
Then ask whether the application accepts encoded ids from the outside. If routes or controllers decode ids taken from URLs or request parameters without authentication, the denial of service can be triggered by anyone who can reach the app. If decoding only happens on authenticated, rate limited endpoints, the exposure is smaller.
What to do now
- Find every application that depends on encoded_id-rails and record the locked version.
- Upgrade to 1.0.0.beta2 or later and run your test suite.
- Read the release notes to find and set the new option that limits decoded id length.
- Add or confirm rate limiting and request size limits at your proxy or load balancer.
- Redeploy and verify the new version in Gemfile.lock.
Why it matters
The record lists CWE-400 (uncontrolled resource consumption) and CWE-770 (allocation of resources without limits). The cause is simple: the decoding step accepts input of any length and does work proportional to it, with heavy memory allocation. A single request can tie up a worker. A few requests can take the application down.
The CVSS vector says network reachable, low complexity, no privileges and no user interaction, with impact limited to availability. That is a common profile for resource exhaustion bugs. They do not leak data, but they are cheap for an attacker and awkward to filter after the fact.
Defence in depth helps here: limits at the proxy on request line length and rate, plus a limit in the library. The record's KEV flag is false and we found no mention of exploitation.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is a CVE assigned to this advisory?
The record carries CVE-2024-0241, but the GitHub advisory page we fetched said no CVE ID was assigned. They describe the same issue.
Is there a workaround besides upgrading?
The advisory names none. Limits at your proxy can reduce the impact.
Sources
Last reviewed: 19 October 2026.
