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.