Hexpm
Monthly
Path traversal in the Hex package manager for the Elixir/Erlang (Mix) ecosystem, versions 0.6.0 through 2.5.1, lets a malicious package publisher delete a directory outside the project's deps/ folder and write the package's files into that location when a developer runs mix deps.get or mix deps.update. The attacker abuses a dependency's OTP application label, which Hex copies from the signed registry without validation and Mix joins onto deps/ as the checkout path, so a crafted label such as '../../target' escapes the project tree through File.rm_rf!/1 before any dependency code is compiled. Exploitation requires the victim project to depend directly or transitively on the attacker-controlled release and the developer to explicitly fetch dependencies, so no victim-side authentication is needed (PR:N) but user interaction is required; no public exploit identified at time of analysis, and the vendor rates it CVSS 7.5.
Hex, the package manager used by Elixir and Erlang projects, fails to properly scope its 'release-age cooldown' protection in versions 2.5.0 through 2.5.1, allowing an authenticated package owner to slip a freshly published, malicious release past the cooldown. The attacker must already hold package-owner permission on the target package, retire (or rely on a security advisory for) the release locked in the victim's mix.lock, and then wait for the victim to run mix deps.update - at which point Hex.RemoteConverger.build_cooldown_bypass/3 and unsafe_lock_bypass/1 lift the cooldown for every version of that package and its dependencies, so the new release is selected regardless of age. A secondary scoping defect causes the bypass to be keyed on package name alone, extending it to identically named packages in other repositories; cooldown configured through an organization dependency policy is not affected. This is a conditional supply-chain weakness rather than a broadly dangerous remote flaw, and no public exploit or in-the-wild activity has been identified at time of analysis. Patches are available from the vendor in Hex 2.5.2.
Incorrect authorization in the hex.pm OAuth `client_credentials` endpoint allows any API key bearing the `repositories` permission to mint tokens scoped to arbitrary organizations' private packages. The flaw in `validate_scopes_against_key/2` accepted any scope string prefixed with `repository:` without resolving the organization name against the authenticated principal's actual memberships; because CDN edges evaluate repository access from token claims alone without querying the database, a minted token grants persistent read access to the targeted organization's private packages until expiration. No public exploit code has been identified at time of analysis, but the vulnerability mechanics are fully disclosed in the public advisory and patch diff.
Silent dependency checksum bypass in hexpm/hex package manager (versions 0.16.0 through 2.4.1) allows attackers to substitute malicious dependencies without detection. The Hex.RemoteConverger module fails to verify lockfile checksums due to a string-versus-atom type mismatch in the verification logic, causing the security check to be silently skipped. Attackers who can poison local package caches or compromise registry responses can deliver modified packages that overwrite mix.lock without raising alerts. SSVC framework indicates proof-of-concept exists, attack is non-automatable (requires user interaction and precise timing), with total technical impact. Fixed in version 2.4.2 (commit d7528c8).
An uncontrolled resource consumption vulnerability in the Hex.pm package manager allows authenticated attackers to cause denial of service by uploading oversized packages that exhaust server memory during extraction. The vulnerability affects hexpm versions before commit 495f01607d3eae4aed7ad09b2f54f31ec7a7df01 and hex.pm installations before March 10, 2026, with a CVSS 4.0 score of 7.1 indicating high availability impact. No active exploitation has been reported (not in KEV), no public proof-of-concept exists, and EPSS data is not available.
Insufficient session expiration in hexpm. Password reset tokens never expire, enabling persistent account takeover.
Hexpm's OAuth implementation fails to enforce read-only API key restrictions during token exchange, allowing an attacker with a victim's read-only API key and valid 2FA code to obtain a full-access API key with unrestricted permissions. This privilege escalation vulnerability affects users of the Hexpm package repository and enables unauthorized modification of packages and account settings. No patch is currently available.
Improper input sanitization in hexpm's SharedAuthorizationView module allows unauthenticated attackers to inject malicious scripts into web pages through the render_grouped_scopes function, enabling cross-site scripting (XSS) attacks against hex.pm users. The vulnerability affects hexpm versions from October 2025 through January 19, 2026, and currently has no available patch. Attackers can exploit this via a simple network request requiring only user interaction, potentially compromising user sessions or stealing sensitive data.
Denial of service in Erlang OTP's stdlib erl_tar module (OTP 29.0 before 29.1.2, stdlib 8.0 before 8.1.1) allows an attacker who supplies a tar archive to be extracted to disk to hang the extracting process and consume a scheduler indefinitely, using a crafted GNU sparse member with a sparse map that ends before its declared real size. The same vulnerable code is vendored as hex_erl_tar in hex_core 0.14.0 and later, as mix_hex_erl_tar in Hex 2.4.2 and later, and as r3_hex_erl_tar in rebar3 3.27.1 and later, so those components remain exploitable on any OTP release including OTP 28. The assessed vector is local and unauthenticated (AV:L/AC:L/PR:N/UI:N) with availability-only impact on a single process/scheduler; no public exploit identified at time of analysis, and extraction using the memory output option is not affected.
Memory exhaustion in hex_core (a library vendored into Hex/mix and rebar3) lets an untrusted repository mirror or a malicious server answering hex_core API requests abort the client-side Erlang VM by returning a tiny, highly compressed response that expands into a very large term or signed envelope. The vulnerable code paths decompress and decode attacker-controlled bytes before the registry signature is verified, and the Erlang safe-binary decoder used for application/vnd.hex+erlang responses accepts compressed terms without bounding the decoded size. Exploitation requires the attacker to control the served data (malicious/compromised mirror, hostile API server, or TLS MITM) and the victim to actively run a fetch operation; this is an unauthenticated remote issue per the assessed vector (CVSS:4.0 PR:N, UI:A, AT:P), but it is a low-severity availability-only problem with no code execution or data exposure, and no public exploit identified at time of analysis.
Terminal-output injection in the Elixir Hex package manager (all versions from 0.0.1 up to, but not including, 2.5.2) allows a malicious package publisher or a hostile repository server to smuggle ANSI escape sequences and Unicode bidirectional overrides into what Mix prints, forging displayed URLs, package descriptions and suggested commands, hiding real output, or writing attacker-chosen text to the victim's clipboard via OSC 52. Exploitation is unauthenticated (CVSS:4.0 PR:N) but requires the victim to run one of the affected interactive Mix tasks - such as mix hex.info, mix hex.package search, mix hex.search, mix hex.user or mix hex.policy - against data the attacker controls, and it depends on the victim's terminal emulator interpreting the injected sequences; impact is confined to output forgery and clipboard manipulation, with no code execution, file access or privilege gain, and the assessed severity is low (CVSS 4.0 base 2.3). No public exploit code was identified at time of analysis and there is no indication of active exploitation; the vendor has released a fix in Hex 2.5.2.
Integrity-check bypass in the Hex package manager (hexpm hex) allows a compromised or attacker-controlled package mirror to substitute package contents when a developer runs `mix hex.package fetch PACKAGE VERSION --output -` and pipes standard output into an unpacker. The stdout code path writes the raw bytes returned by Hex.SCM.fetch/3 without the inner/outer checksum comparison that the default file-output path performs against the signed registry, and Hex's own diagnostics (a failed HTTP response body or an x-hex-message API warning) can likewise land on stdout as a tar archive ahead of any verified tarball. Hex versions from 0.20.2 up to but excluding 2.5.2 are affected; no public exploit code has been identified at time of analysis, and exploitation additionally requires a non-default mirror (HEX_MIRROR_URL or mirror_url) plus the specific stdout-piping command run by an unauthenticated remote attacker's victim, making this a genuine but conditionally gated supply-chain integrity flaw rather than a drop-everything emergency.
Resource exhaustion in the Hex package manager for Elixir (0.11.2 up to, but not including, 2.5.2) lets an untrusted, attacker-controlled package mirror consume unbounded memory or disk on the machine running mix deps.get, mix deps.update, mix hex.package fetch, or mix hex.docs fetch. Hex decompresses gzip response bodies and downloads/extracts package and docs tarballs before any signature, checksum, or 16 MiB/128 MiB size limits are applied, so the mirror's own payload size dictates consumption. Exploitation is narrow: it requires a non-default attacker-controlled mirror configured via HEX_MIRROR_URL, HEX_MIRROR, or the mirror_url option plus explicit user action to run a fetch, the default hex.pm CDN is not affected, and no public exploit has been identified at time of analysis (unauthenticated per CVSS PR:N, but user interaction is required and impact is availability-only, assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:R/C:N/I:N/A:L).
Improper certificate validation in Hex (the Elixir/Erlang package manager client, versions 0.20.2 through 2.5.1) allows a man-in-the-middle attacker to impersonate a Hex host under a narrow set of conditions: the attacker must intercept the victim's HTTPS traffic, must hold a certificate for the target host issued by a CA present in Hex's bundled CA store, and the victim must have pointed cacerts_path (HEX_CACERTS_PATH) at a custom store that deliberately excludes that CA. Under those preconditions the attacker can present a chain that reaches a bundled CA and have it accepted, defeating the operator's explicit trust configuration and potentially exposing package metadata, tarballs, and credentials transmitted to the impersonated host, although hostname verification still applies and reduces the attack surface. Assessed risk is medium (CVSS 4.0 base 5.9; CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N) and is constrained by the non-default configuration requirement and the privileged network position needed; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV. A vendor patch is available in Hex 2.5.2.
Improper TLS server-certificate validation in hex_core (0.1.0 through versions before 0.20.0) lets an attacker who already holds an on-path/Man-in-the-Middle position impersonate hex.pm, repo.hex.pm, or any other repository or API endpoint to any Erlang/Elixir program using the library's built-in hex_http_httpc adapter selected by hex_core:default_config/0. The adapter is affected when it cannot obtain a CA trust store: all HTTPS requests fall back to insecure ssl defaults on Erlang/OTP 24 (public_key:cacerts_get/0 does not exist), hex_core before 0.11.0 never set ssl options at all, and on OTP 25 the fallback triggers whenever the OS certificate store cannot be loaded - although the CVSS 4.0 vector still requires user interaction because a Hex fetch must actually be triggered, and OTP 26+ verifies certificates by default even without the fix. No confirmed in-the-wild exploitation and no public exploit code were identified at time of analysis, and the primary risk is data/registry-response disclosure and package-fetch integrity (CWE-295, tagged Information Disclosure) rather than remote code execution.
Retained OAuth refresh tokens on hex.pm allow a user whose organization membership or session has ended to keep reading that organization's private packages and documentation tarballs. Refresh tokens are issued with the same issuer, audience and repository:<org> scope claims as access tokens, and the CDN that serves private repositories validates only the JWT signature and time claims, performing no membership lookup and unable to tell the two token types apart, so revocation takes effect only when the 30-day refresh token expires instead of at the 30-minute access-token lifetime. The actor must be an authenticated party who was a member when the token was granted, access is read-only and limited to organizations the account belonged to at grant time, and no public exploit has been identified at time of analysis; CVSS 4.0 base score is 2.3 (independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
OAuth token refresh in hex.pm (Elixir's package registry) fails to re-validate organizational membership when issuing new access tokens, allowing users removed from a private organization to retain read access to its packages. Affected are hex.pm deployments from 2025-10-10 through 2026-08-24. An authenticated former member can repeatedly refresh a token carrying an explicit repository:<org> or docs:<org> scope - bypassing revocation entirely for up to 30 days - because CDN edges authorize access from token claims without querying the database. No public exploit exists and this is not in CISA KEV.
Path traversal in hexpm's Local Storage backend allows unauthenticated attackers to read sensitive files through relative path manipulation in the file storage routines. Only self-hosted hexpm deployments using Local Storage are affected; the managed hex.pm service is not vulnerable. An attacker can access arbitrary files accessible to the hexpm process without authentication or user interaction.
Path traversal in the Hex package manager for the Elixir/Erlang (Mix) ecosystem, versions 0.6.0 through 2.5.1, lets a malicious package publisher delete a directory outside the project's deps/ folder and write the package's files into that location when a developer runs mix deps.get or mix deps.update. The attacker abuses a dependency's OTP application label, which Hex copies from the signed registry without validation and Mix joins onto deps/ as the checkout path, so a crafted label such as '../../target' escapes the project tree through File.rm_rf!/1 before any dependency code is compiled. Exploitation requires the victim project to depend directly or transitively on the attacker-controlled release and the developer to explicitly fetch dependencies, so no victim-side authentication is needed (PR:N) but user interaction is required; no public exploit identified at time of analysis, and the vendor rates it CVSS 7.5.
Hex, the package manager used by Elixir and Erlang projects, fails to properly scope its 'release-age cooldown' protection in versions 2.5.0 through 2.5.1, allowing an authenticated package owner to slip a freshly published, malicious release past the cooldown. The attacker must already hold package-owner permission on the target package, retire (or rely on a security advisory for) the release locked in the victim's mix.lock, and then wait for the victim to run mix deps.update - at which point Hex.RemoteConverger.build_cooldown_bypass/3 and unsafe_lock_bypass/1 lift the cooldown for every version of that package and its dependencies, so the new release is selected regardless of age. A secondary scoping defect causes the bypass to be keyed on package name alone, extending it to identically named packages in other repositories; cooldown configured through an organization dependency policy is not affected. This is a conditional supply-chain weakness rather than a broadly dangerous remote flaw, and no public exploit or in-the-wild activity has been identified at time of analysis. Patches are available from the vendor in Hex 2.5.2.
Incorrect authorization in the hex.pm OAuth `client_credentials` endpoint allows any API key bearing the `repositories` permission to mint tokens scoped to arbitrary organizations' private packages. The flaw in `validate_scopes_against_key/2` accepted any scope string prefixed with `repository:` without resolving the organization name against the authenticated principal's actual memberships; because CDN edges evaluate repository access from token claims alone without querying the database, a minted token grants persistent read access to the targeted organization's private packages until expiration. No public exploit code has been identified at time of analysis, but the vulnerability mechanics are fully disclosed in the public advisory and patch diff.
Silent dependency checksum bypass in hexpm/hex package manager (versions 0.16.0 through 2.4.1) allows attackers to substitute malicious dependencies without detection. The Hex.RemoteConverger module fails to verify lockfile checksums due to a string-versus-atom type mismatch in the verification logic, causing the security check to be silently skipped. Attackers who can poison local package caches or compromise registry responses can deliver modified packages that overwrite mix.lock without raising alerts. SSVC framework indicates proof-of-concept exists, attack is non-automatable (requires user interaction and precise timing), with total technical impact. Fixed in version 2.4.2 (commit d7528c8).
An uncontrolled resource consumption vulnerability in the Hex.pm package manager allows authenticated attackers to cause denial of service by uploading oversized packages that exhaust server memory during extraction. The vulnerability affects hexpm versions before commit 495f01607d3eae4aed7ad09b2f54f31ec7a7df01 and hex.pm installations before March 10, 2026, with a CVSS 4.0 score of 7.1 indicating high availability impact. No active exploitation has been reported (not in KEV), no public proof-of-concept exists, and EPSS data is not available.
Insufficient session expiration in hexpm. Password reset tokens never expire, enabling persistent account takeover.
Hexpm's OAuth implementation fails to enforce read-only API key restrictions during token exchange, allowing an attacker with a victim's read-only API key and valid 2FA code to obtain a full-access API key with unrestricted permissions. This privilege escalation vulnerability affects users of the Hexpm package repository and enables unauthorized modification of packages and account settings. No patch is currently available.
Improper input sanitization in hexpm's SharedAuthorizationView module allows unauthenticated attackers to inject malicious scripts into web pages through the render_grouped_scopes function, enabling cross-site scripting (XSS) attacks against hex.pm users. The vulnerability affects hexpm versions from October 2025 through January 19, 2026, and currently has no available patch. Attackers can exploit this via a simple network request requiring only user interaction, potentially compromising user sessions or stealing sensitive data.
Denial of service in Erlang OTP's stdlib erl_tar module (OTP 29.0 before 29.1.2, stdlib 8.0 before 8.1.1) allows an attacker who supplies a tar archive to be extracted to disk to hang the extracting process and consume a scheduler indefinitely, using a crafted GNU sparse member with a sparse map that ends before its declared real size. The same vulnerable code is vendored as hex_erl_tar in hex_core 0.14.0 and later, as mix_hex_erl_tar in Hex 2.4.2 and later, and as r3_hex_erl_tar in rebar3 3.27.1 and later, so those components remain exploitable on any OTP release including OTP 28. The assessed vector is local and unauthenticated (AV:L/AC:L/PR:N/UI:N) with availability-only impact on a single process/scheduler; no public exploit identified at time of analysis, and extraction using the memory output option is not affected.
Memory exhaustion in hex_core (a library vendored into Hex/mix and rebar3) lets an untrusted repository mirror or a malicious server answering hex_core API requests abort the client-side Erlang VM by returning a tiny, highly compressed response that expands into a very large term or signed envelope. The vulnerable code paths decompress and decode attacker-controlled bytes before the registry signature is verified, and the Erlang safe-binary decoder used for application/vnd.hex+erlang responses accepts compressed terms without bounding the decoded size. Exploitation requires the attacker to control the served data (malicious/compromised mirror, hostile API server, or TLS MITM) and the victim to actively run a fetch operation; this is an unauthenticated remote issue per the assessed vector (CVSS:4.0 PR:N, UI:A, AT:P), but it is a low-severity availability-only problem with no code execution or data exposure, and no public exploit identified at time of analysis.
Terminal-output injection in the Elixir Hex package manager (all versions from 0.0.1 up to, but not including, 2.5.2) allows a malicious package publisher or a hostile repository server to smuggle ANSI escape sequences and Unicode bidirectional overrides into what Mix prints, forging displayed URLs, package descriptions and suggested commands, hiding real output, or writing attacker-chosen text to the victim's clipboard via OSC 52. Exploitation is unauthenticated (CVSS:4.0 PR:N) but requires the victim to run one of the affected interactive Mix tasks - such as mix hex.info, mix hex.package search, mix hex.search, mix hex.user or mix hex.policy - against data the attacker controls, and it depends on the victim's terminal emulator interpreting the injected sequences; impact is confined to output forgery and clipboard manipulation, with no code execution, file access or privilege gain, and the assessed severity is low (CVSS 4.0 base 2.3). No public exploit code was identified at time of analysis and there is no indication of active exploitation; the vendor has released a fix in Hex 2.5.2.
Integrity-check bypass in the Hex package manager (hexpm hex) allows a compromised or attacker-controlled package mirror to substitute package contents when a developer runs `mix hex.package fetch PACKAGE VERSION --output -` and pipes standard output into an unpacker. The stdout code path writes the raw bytes returned by Hex.SCM.fetch/3 without the inner/outer checksum comparison that the default file-output path performs against the signed registry, and Hex's own diagnostics (a failed HTTP response body or an x-hex-message API warning) can likewise land on stdout as a tar archive ahead of any verified tarball. Hex versions from 0.20.2 up to but excluding 2.5.2 are affected; no public exploit code has been identified at time of analysis, and exploitation additionally requires a non-default mirror (HEX_MIRROR_URL or mirror_url) plus the specific stdout-piping command run by an unauthenticated remote attacker's victim, making this a genuine but conditionally gated supply-chain integrity flaw rather than a drop-everything emergency.
Resource exhaustion in the Hex package manager for Elixir (0.11.2 up to, but not including, 2.5.2) lets an untrusted, attacker-controlled package mirror consume unbounded memory or disk on the machine running mix deps.get, mix deps.update, mix hex.package fetch, or mix hex.docs fetch. Hex decompresses gzip response bodies and downloads/extracts package and docs tarballs before any signature, checksum, or 16 MiB/128 MiB size limits are applied, so the mirror's own payload size dictates consumption. Exploitation is narrow: it requires a non-default attacker-controlled mirror configured via HEX_MIRROR_URL, HEX_MIRROR, or the mirror_url option plus explicit user action to run a fetch, the default hex.pm CDN is not affected, and no public exploit has been identified at time of analysis (unauthenticated per CVSS PR:N, but user interaction is required and impact is availability-only, assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:R/C:N/I:N/A:L).
Improper certificate validation in Hex (the Elixir/Erlang package manager client, versions 0.20.2 through 2.5.1) allows a man-in-the-middle attacker to impersonate a Hex host under a narrow set of conditions: the attacker must intercept the victim's HTTPS traffic, must hold a certificate for the target host issued by a CA present in Hex's bundled CA store, and the victim must have pointed cacerts_path (HEX_CACERTS_PATH) at a custom store that deliberately excludes that CA. Under those preconditions the attacker can present a chain that reaches a bundled CA and have it accepted, defeating the operator's explicit trust configuration and potentially exposing package metadata, tarballs, and credentials transmitted to the impersonated host, although hostname verification still applies and reduces the attack surface. Assessed risk is medium (CVSS 4.0 base 5.9; CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N) and is constrained by the non-default configuration requirement and the privileged network position needed; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV. A vendor patch is available in Hex 2.5.2.
Improper TLS server-certificate validation in hex_core (0.1.0 through versions before 0.20.0) lets an attacker who already holds an on-path/Man-in-the-Middle position impersonate hex.pm, repo.hex.pm, or any other repository or API endpoint to any Erlang/Elixir program using the library's built-in hex_http_httpc adapter selected by hex_core:default_config/0. The adapter is affected when it cannot obtain a CA trust store: all HTTPS requests fall back to insecure ssl defaults on Erlang/OTP 24 (public_key:cacerts_get/0 does not exist), hex_core before 0.11.0 never set ssl options at all, and on OTP 25 the fallback triggers whenever the OS certificate store cannot be loaded - although the CVSS 4.0 vector still requires user interaction because a Hex fetch must actually be triggered, and OTP 26+ verifies certificates by default even without the fix. No confirmed in-the-wild exploitation and no public exploit code were identified at time of analysis, and the primary risk is data/registry-response disclosure and package-fetch integrity (CWE-295, tagged Information Disclosure) rather than remote code execution.
Retained OAuth refresh tokens on hex.pm allow a user whose organization membership or session has ended to keep reading that organization's private packages and documentation tarballs. Refresh tokens are issued with the same issuer, audience and repository:<org> scope claims as access tokens, and the CDN that serves private repositories validates only the JWT signature and time claims, performing no membership lookup and unable to tell the two token types apart, so revocation takes effect only when the 30-day refresh token expires instead of at the 30-minute access-token lifetime. The actor must be an authenticated party who was a member when the token was granted, access is read-only and limited to organizations the account belonged to at grant time, and no public exploit has been identified at time of analysis; CVSS 4.0 base score is 2.3 (independent assessment CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).
OAuth token refresh in hex.pm (Elixir's package registry) fails to re-validate organizational membership when issuing new access tokens, allowing users removed from a private organization to retain read access to its packages. Affected are hex.pm deployments from 2025-10-10 through 2026-08-24. An authenticated former member can repeatedly refresh a token carrying an explicit repository:<org> or docs:<org> scope - bypassing revocation entirely for up to 30 days - because CDN edges authorize access from token claims without querying the database. No public exploit exists and this is not in CISA KEV.
Path traversal in hexpm's Local Storage backend allows unauthenticated attackers to read sensitive files through relative path manipulation in the file storage routines. Only self-hosted hexpm deployments using Local Storage are affected; the managed hex.pm service is not vulnerable. An attacker can access arbitrary files accessible to the hexpm process without authentication or user interaction.