[From nobody Sat Oct 17 17:09:07 2026
Received: (at submit) by bugs.debian.org; 14 Oct 2026 14:25:03 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
 (2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=4.0 tests=BAYES_00, FOURLA, MD5_SHA1_SUM,
 SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no
 version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 52; hammy, 150; neutral, 101; spammy,
 0. spammytokens:
 hammytokens:0.000-+--UD:security-tracker.debian.org, 
 0.000-+--security-tracker.debian.org,
 0.000-+--securitytrackerdebianorg, 0.000-+--H*r:jmm, 0.000-+--sk:teamse
Return-path: &lt;jmm@inutil.org&gt;
Received: from inutil.org ([51.38.114.215]:59486 helo=vps-b7ad3695.vps.ovh.net)
 by buxtehude.debian.org with esmtp (Exim 4.96)
 (envelope-from &lt;jmm@inutil.org&gt;) id 1xGzuf-007SCq-2c
 for submit@bugs.debian.org; Wed, 14 Oct 2026 14:25:03 +0000
Received: from soju.fritz.box (p548dc0ed.dip0.t-ipconnect.de [84.141.192.237])
 by vps-b7ad3695.vps.ovh.net (Postfix) with ESMTPSA id A25B04D2
 for &lt;submit@bugs.debian.org&gt;; Wed, 14 Oct 2026 14:25:00 +0000 (UTC)
Received: from jmm by soju.fritz.box with local (Exim 4.100.1)
 (envelope-from &lt;jmm@soju.westfalen.local&gt;) id 1xGzud-000000003Wk-1Frc
 for submit@bugs.debian.org; Wed, 14 Oct 2026 16:24:59 +0200
Date: Wed, 14 Oct 2026 16:24:59 +0200
To: submit@bugs.debian.org
Subject: rebar3: CVE-2026-105274
Message-ID: &lt;as-Quy-vS8iUy0RV@pisco.westfalen.local&gt;
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
From: =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= &lt;jmm@inutil.org&gt;
Delivered-To: submit@bugs.debian.org

Source: rebar3
X-Debbugs-CC: team@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for rebar3.

CVE-2026-105274[0]:
| Improper Handling of Highly Compressed Data (Data Amplification)
| vulnerability in hexpm hex_core allows an untrusted repository
| mirror, or a server answering hex_core's API requests, to exhaust
| the memory of the Erlang VM running hex_core. The same code is
| vendored in Hex (mix_hex_repo, mix_hex_api) and rebar3 (r3_hex_repo,
| r3_hex_api).  hex_repo:get_names/1, hex_repo:get_versions/1,
| hex_repo:get_package/2 and hex_repo:get_policy/2 decompress the
| registry response with zlib:gunzip/1 and decode the signed envelope
| before verifying its signature. A mirror doesn't have the
| repository's private key, but it chooses the compressed bytes, so a
| small response decompresses into an envelope of any size before the
| signature check rejects it.  hex_api decodes responses with the
| application/vnd.hex+erlang content type through
| hex_safe_binary_to_term:safe_binary_to_term/1, which calls
| binary_to_term(Binary, [safe]). The safe option prevents atom
| creation, but it accepts compressed terms and doesn't limit the size
| of the decoded term, and the check that rejects functions and ports
| runs after the term has been built. The fix for CVE-2026-21619 added
| the safe option and that check without bounding the decoded size.
| This issue affects rebar3: from 3.9.1 before 3.27.3; hex: from 2.1.0
| before 2.5.2; hex_core: from 0.1.0 before 0.20.0.

https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq
https://cna.erlef.org/cves/CVE-2026-105274.html
https://osv.dev/vulnerability/EEF-CVE-2026-105274

Fixed by: https://github.com/erlang/rebar3/commit/360838a22f5b3a88c0358207f2923059bcbb3afb (3.27.3)

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities &amp; Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-105274
    https://www.cve.org/CVERecord?id=CVE-2026-105274

Please adjust the affected versions in the BTS as needed.
]