REDHAT-BUG-2521857: Medium severity Red Hat rpmbuild vulnerability
When rpmbuild runs in tarball mode (-ta / -tb / -ts, etc.), getTarSpec() extracts a .spec from the archive and renames it using the member name from tar’s verbose listing. That member name is concatenated into:
specFinal = rpmExpand("%{specdir}/%{basename:", tarbuf, "}", NULL);
A crafted .spec member name containing } closes %{basename:...} early. Text after the } is expanded as further RPM macros, including %{lua:} (full Lua stdlib, rpm.execute / rpm.spawn). The expanded string is used as the destination of rename() and as the spec path for the rest of the build.
This happens while locating the spec — before %prep. It is not “spec scripts run shell by design.” The victim only needs to run rpmbuild -ts (or -ta / -tb) on a crafted tarball.
This is a sibling / variant of CVE-2026-44604: untrusted archive metadata (here: tar member name; there: ZIP/7z/GEM top-level directory) is interpolated into a privileged expand/popen path. Different call site (getTarSpec vs rpmuncompress), same trust-boundary class. CVE-2026-44604 did not fix this path.
Affected Software
Event History
Frequently Asked Questions
Which rpmbuild workflows are exposed to this issue?
The affected path is used when rpmbuild operates on a tarball, including -ta, -tb, and -ts modes. The issue occurs while rpmbuild locates and extracts the spec file from the archive, before %prep runs.
What must an attacker do to trigger exploitation?
An attacker needs to provide a crafted tarball whose .spec archive member name contains RPM macro syntax that prematurely closes the %{basename:...} expansion. Exploitation requires a victim to invoke rpmbuild in a tarball mode on that archive.
Does the fix for CVE-2026-44604 address this path?
No. CVE-2026-44604 concerns a different call site, and it did not fix the getTarSpec() path involved here.
How can I determine whether a build process is exposed?
A process is exposed if it runs rpmbuild with tarball-mode options such as -ts, -ta, or -tb on tarballs that may be attacker-controlled or otherwise untrusted. The relevant archive metadata is the member name of the .spec file.