CVE-2026-23940: Hexpm Package Manager DoS Vulnerability

CVE-2026-23940 Overview

CVE-2026-23940 is an Uncontrolled Resource Consumption vulnerability (CWE-400) affecting the Hex.pm package manager platform. The vulnerability allows authenticated users to publish an oversized package that causes Hex.pm to run out of memory during the extraction of the uploaded package tarball. This memory exhaustion can terminate the affected application instance and result in a denial of service for package publishing and potentially other package-processing functionality.

Critical Impact

Attackers with package publishing privileges can crash Hex.pm application instances, disrupting the Elixir/Erlang package ecosystem and preventing legitimate developers from publishing or processing packages.

Affected Products

• hexpm/hexpm before commit 495f01607d3eae4aed7ad09b2f54f31ec7a7df01
• Hex.pm platform before 2026-03-10

Discovery Timeline

• 2026-03-13 - CVE-2026-23940 published to NVD
• 2026-03-16 - Last updated in NVD database

Technical Details for CVE-2026-23940

Vulnerability Analysis

This vulnerability falls within the Denial of Service category, specifically Resource Exhaustion. The root issue lies in how Hex.pm handles package tarball extraction during the publishing workflow. When a package is uploaded, the system extracts and processes the tarball contents in memory without adequate size constraints.

The vulnerability allows an authenticated attacker to craft an oversized package that, when processed by the server, consumes excessive memory resources. This can lead to application instance termination and service disruption across the Hex.pm platform, affecting all package publishing and processing operations.

The attack requires network access and low-privilege authentication (package publishing rights), but involves no user interaction once an attacker has the necessary credentials. The impact is limited to availability—there is no compromise of confidentiality or integrity.

Root Cause

The vulnerability stems from the application loading entire package body contents into memory during the publishing and documentation upload workflows. Functions like push_release() and publish_docs() in the Hexpm.Repository.Assets and Hexpm.Repository.Releases modules accepted the full body content as an in-memory parameter, allowing unbounded memory allocation when processing oversized tarballs.

Attack Vector

An attacker with valid Hex.pm credentials and package publishing permissions can exploit this vulnerability by:

1. Creating a maliciously large package tarball designed to exhaust server memory
2. Uploading the package through the standard Hex.pm publishing API
3. Triggering the tarball extraction process which loads the oversized content into memory
4. Causing the application instance to run out of memory and terminate
5. Repeating the attack to maintain denial of service conditions

The security patch addresses this by changing the parameter handling from in-memory body content to file path references:

 defmodule Hexpm.Repository.Assets do
   alias Hexpm.Repository.Repository
 
-  def push_release(release, body) do
+  def push_release(release, body_path) do
     meta = [
       {"surrogate-key", tarball_cdn_key(release)},
       {"surrogate-control", "public, max-age=604800"}

Source: GitHub Commit Details

The documentation publishing workflow received the same fix:

     |> publish_result(user, body)
   end
 
-  def publish_docs(package, release, body, audit: audit_data) do
-    Assets.push_docs(release, body)
+  def publish_docs(package, release, body_path, audit: audit_data) do
+    Assets.push_docs(release, body_path)
 
     now = DateTime.utc_now()
     release_changeset = Ecto.Changeset.change(release, has_docs: true)

Source: GitHub Commit Details

Detection Methods for CVE-2026-23940

Indicators of Compromise

• Sudden memory spikes on Hex.pm application servers during package upload operations
• Application instance crashes or Out-of-Memory (OOM) killer terminations during tarball extraction
• Unusually large package uploads from single accounts or IP addresses
• Failed package processing operations followed by service restarts

Detection Strategies

• Monitor memory consumption patterns during package publishing workflows for anomalous spikes
• Implement logging for package upload sizes and flag submissions exceeding normal thresholds
• Track application restart frequency and correlate with package processing activities
• Review Erlang/Elixir application crash logs for memory-related terminations

Monitoring Recommendations

• Configure memory usage alerts on servers running Hex.pm instances with thresholds appropriate for normal operation
• Implement rate limiting and size monitoring on the package upload API endpoint
• Set up automated alerting for application instance restarts and OOM events
• Monitor for patterns of repeated failed uploads that could indicate exploitation attempts

How to Mitigate CVE-2026-23940

Immediate Actions Required

• Update hexpm to commit 495f01607d3eae4aed7ad09b2f54f31ec7a7df01 or later immediately
• If running Hex.pm instances, restart services after applying the patch
• Review recent package upload logs for suspicious oversized submissions
• Consider temporarily restricting package publishing access during the update window

Patch Information

The vulnerability has been addressed in the hexpm/hexpm repository. The fix modifies the push_release() and publish_docs() functions in lib/hexpm/repository/assets.ex and lib/hexpm/repository/releases.ex to accept file paths instead of loading body content directly into memory. This allows for streaming or chunked processing of large packages without exhausting application memory.

For detailed information, refer to the GitHub Security Advisory GHSA-jp8w-gxf6-8hcr.

Workarounds

• Implement upload size limits at the web server or reverse proxy level to reject oversized packages before they reach the application
• Configure memory limits on application containers to prevent a single instance crash from affecting the entire service
• Deploy additional application instances with load balancing to maintain availability if one instance is affected
• Temporarily restrict package publishing to trusted accounts until the patch can be applied

# Example: Configure nginx upload size limit as a temporary workaround
# Add to nginx server block configuration
client_max_body_size 50m;

# Example: Set container memory limits for isolation
# Docker run example with memory constraints
docker run -m 2g --memory-swap 2g hexpm/hexpm:latest