Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAN_LGv3uxE6EjPPbRreaQPL-UTOwLmmZ8NxxiZBx-wcaAF1Ykw@mail.gmail.com>
Date: Mon, 13 Apr 2026 10:28:31 +0800
From: Alexander Patrakov <patrakov@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Security Audit of Hex, the Erlang package manager

Hello Alan,

How am I, as a user, supposed to authenticate these PDFs as materials
really produced by the parties Hex claims they are from? The PDFs are
offered for download from the audited-party domain, not from the auditors'
domains, and do not contain any digital signatures.

On Mon, Apr 13, 2026 at 4:16 AM Alan Coopersmith <
alan.coopersmith@...cle.com> wrote:

> https://hex.pm/blog/security-audit announces the completion of a
> security audit & penetration testing of Hex, the Erlang package manager,
> funded by the OpenSSF and overseen by the Erlang Ecosystem Foundation.
>
> This work was done by two independent security firms, Paraxial.io and
> zentrust partners GmbH, who each produced their own reports:
>   - https://hex.pm/reports/2026/paraxial.pdf
>   - https://hex.pm/reports/2026/zentrust.pdf
>
> The announcement reports:
>
> > What was found
> > --------------
> >
> > Across both audits, a number of issues were identified, ranging from high
> > severity vulnerabilities to low-severity hardening gaps.
> >
> > Examples include:
> >
> >  * Unsafe deserialization in hex_core that could lead to RCE under
> certain
> >    conditions
> >  * A denial of service condition during package uploads
> >  * Weaknesses in authentication flows and API key handling
> >  * Gaps in CI/CD hardening (GitHub Actions)
> >  * Missing or incomplete security controls in some areas
> >
> > Importantly, the audits focused on realistic attack scenarios such as:
> >
> >  * cross-account package tampering
> >  * bypassing integrity checks
> >  * injection in public-facing features
> >  * CI/CD compromise
> >
> > What we fixed
> > -------------
> >
> > Most findings have been remediated during the engagement and confirmed in
> > re-tests.
> >
> > Highlights:
> >
> >  * Fixed unsafe deserialization in hex_core (CVE-2026-21619)
> >  * Fixed API key privilege escalation (CVE-2026-21621)
> >  * Fixed password reset issues (CVE-2026-21622)
> >  * Fixed XSS in OAuth device flow (CVE-2026-21618)
> >  * Fixed denial of service in package upload (CVE-2026-23940)
> >  * Removed sensitive credentials from repositories
> >  * Hardened authentication flows (including "sudo mode" for sensitive
> actions)
> >  * Disabled legacy TLS versions
> >  * Improved CSP and other browser security controls
> >
> > Re-tests by both firms confirmed that the majority of vulnerabilities
> were
> > successfully remediated.
> >
> > Several remaining items are either:
> >
> >  * accepted risks with clear rationale (for example UX trade-offs or
> staged
> >    migrations), or
> >  * dependent on ecosystem-wide changes (for example client updates)
> >
> > What we decided not to change (yet)
> > -----------------------------------
> >
> > Some findings reflect intentional trade-offs or transitional states
> rather
> > than vulnerabilities.
> >
> > Examples:
> >
> >  * Basic authentication and optional 2FA are still supported for
> compatibility
> >    with existing clients. Both will be phased out once all clients
> support the
> >    OAuth2 device flow.
> >  * Certain features (like documentation hosting) intentionally allow
> >    user-provided content and are being isolated rather than restricted.
> >
> > These decisions were reviewed jointly by the Hex.pm team and the EEF.
>
> These issues appear to be reported against the hexpm server side, not the
> client
> side that end users & distros are likely to be running:
>
>   - Cross-site scripting (XSS) in OAuth Device Authorization screen
> (CVE-2026-21618)
>     https://github.com/hexpm/hexpm/security/advisories/GHSA-6cw9-5gg4-rhpj
>
>   - Improper Scope Enforcement in OAuth client_credentials Flow Allows
> Read-Only
>     API Key to Escalate to Full Access with Valid 2FA Code (CVE-2026-21621)
>     https://github.com/hexpm/hexpm/security/advisories/GHSA-739m-8727-j6w3
>
>   - Password Reset Tokens Do Not Expire (CVE-2026-21622)
>     https://github.com/hexpm/hexpm/security/advisories/GHSA-6r94-pvwf-mxqm
>
>   - Path Traversal in Local File Store Backend (Development and Self-Hosted
>     Registry Setups) (CVE-2026-23939)
>     https://github.com/hexpm/hexpm/security/advisories/GHSA-42mv-r64p-4869
>
>   - Publishing Oversized Package Can Trigger Denial of Service
> (CVE-2026-23940)
>     https://github.com/hexpm/hexpm/security/advisories/GHSA-jp8w-gxf6-8hcr
>
> That leaves one CVE for distros and end users to worry about -
> https://github.com/hexpm/hex_core/security/advisories/GHSA-hx9w-f2w9-9g96
> reports:
> > Unsafe Deserialization of Erlang Terms in hex_core
> > --------------------------------------------------
> >
> > maennchen published GHSA-hx9w-f2w9-9g96 Feb 27, 2026
> >
> > Package:            hex (otp)
> > Affected versions:  >= 2.3.0 and <= 2.3.2
> > Patched versions:   2.3.2
> >
> > Package:            hex_core (Erlang)
> > Affected versions:  <= 0.12.1
> > Patched versions:   0.12.1
> >
> > Package:            rebar3 (otp)
> > Affected versions:  >= 3.9.1 and <= 3.27.0
> > Patched versions:   3.27.0
> >
> > Impact
> > ------
> > The Hex client (hex_core) deserializes Erlang terms received from the
> > Hex API using binary_to_term/1 without sufficient restrictions.
> >
> > If an attacker can control the HTTP response body returned by the Hex
> API,
> > this allows denial-of-service attacks such as atom table exhaustion,
> leading
> > to a VM crash. No released versions are known to allow remote code
> execution.
> >
> > Patches
> > -------
> >
> https://github.com/hexpm/hex_core/commit/cdf726095bca85ad2549d146df1e831ae93c2b13
> >
> https://github.com/hexpm/hex/commit/636739f3322514e9303ca335fb630696fcbb3c95
> >
> https://github.com/erlang/rebar3/commit/1d4478f527e373de0b225951e53115450e0d9b9d
> >
> > Workarounds
> > -----------
> > Ensure that the Hex API URL (HEX_API_URL) points only to trusted
> endpoints.
> > There is no client-side workaround that fully mitigates this issue
> without
> > applying the patch.
> >
> > References
> > ----------
> > - hex_core Module:
> https://github.com/hexpm/hex_core/blob/main/src/hex_api.erl
> > - Hex Vendored Module:
> https://github.com/hexpm/hex/blob/main/src/mix_hex_api.erl
> > - Rebar3 Vendored Module:
> https://github.com/erlang/rebar3/blob/main/apps/rebar/src/vendored/r3_hex_api.erl
> > - hex_core Patch: cdf7260
> > - Hex Vendored Patch: hexpm/hex@...739f
> > - Rebar3 Vendored Patch: erlang/rebar3@...478f
> >
> > Severity: Low - 2.0 / 10
> > CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
> > CVE ID: CVE-2026-21619
> > Weaknesses:
> > - CWE-400: Uncontrolled Resource Consumption
> > - CWE-502: Deserialization of Untrusted Data
>
>
>

-- 
Alexander Patrakov

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.