Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2026-84838

  • rpm’s filename-to-shell path draws three more command-injection CVEs, and escaping the shell would not have stopped one of them

    rpm’s filename-to-shell path draws three more command-injection CVEs, and escaping the shell would not have stopped one of them

    Red Hat published three command-injection records in rpm’s build and extraction tooling on September 1 and 2, all credited to the same AI-driven research effort that produced a fourth in May.

    What happened

    Three CVE records naming Red Hat as the assigning authority landed in the National Vulnerability Database on September 1 and September 2, 2026. All three are command injection in rpm. All three are credited, in Red Hat’s own wording, to “AISLE in partnership with Red Hat.” All three carry Red Hat’s Moderate classification alongside a CVSS v3.1 base score in the High band.

    CVE-2026-84837, published September 2, is in rpmbuild‘s tarball mode. An attacker who can influence the path or filename of a tarball that a build later processes with -ta, -tb, or -ts can put shell metacharacters in that name and get command execution as the build user. Red Hat scores it 7.8 with the vector AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, and explains the rating directly: “This issue is considered Moderate severity because, although successful exploitation can result in arbitrary command execution with the privileges of the user running rpmbuild, exploitation requires an attacker to influence the path or filename of a tarball that is subsequently processed by rpmbuild in tarball mode (-ta/-tb/-ts).” Red Hat Enterprise Linux 7, 8, 9, and 10 are listed as affected, along with Red Hat Hardened Images.

    CVE-2026-84838, also September 2 and also 7.8 on the same vector, is in rpmuncompress. The record describes “improper escaping of shell metacharacters before passing filenames to popen().” Here the scope is narrower: Red Hat Enterprise Linux 10 and Hardened Images are affected; 6 through 9 are not.

    CVE-2026-84233, published September 1 at 7.0 with AC:H, is the one that does not fit the pattern. It is also in rpmuncompress, reached through rpmuncompress -x on a .gem file, but the injection is not through the shell. It is through rpm’s own macro language: a filename containing RPM macro syntax gets expanded during command construction. Red Hat’s mitigation says so explicitly — “avoid using rpmuncompress -x on .gem files from untrusted sources. Before extraction, rename .gem files to remove any RPM macro syntax (e.g., %(...)).” Affected scope matches CVE-2026-84838: RHEL 10 and Hardened Images.

    The background is a fourth record. CVE-2026-44604 was published May 28, 2026, and describes command injection in rpmuncompress‘s doUntar() function, where an archive’s top-level directory name was inserted into a popen() shell command without sanitization when extracting ZIP, 7z, or GEM archives. It is classified CWE-78, scored 7.0, and credited to AISLE as well. Red Hat fixed it for Red Hat Hardened Images in RHSA-2026:28491, issued June 23, 2026, moving rpm to 6.0.1-6.1.hum1. On that record, RHEL 6 through 10 are all marked unaffected. Its record was last updated September 1, 2026 — the same day the new batch began arriving.

    No exploitation is claimed by Red Hat for any of the four, and none carries a CISA KEV entry.

    Why it matters

    The shortest version: rpm has now produced four command-injection CVEs in four months in the same narrow area — filenames reaching a shell — and a fix shipped in June for one of them did not prevent the next.

    That is worth being precise about rather than dramatic. CVE-2026-44604 and CVE-2026-84838 are not the same bug. The first was an archive’s top-level directory name; the second is filenames generally. But they are the same construction in the same utility: a name the program did not choose, concatenated into a string, handed to popen(). Fixing the first by escaping that one input is a per-instance fix. It leaves the design decision — that untrusted names transit a shell at all — in place, and the next audit of the same function finds the next one.

    CVE-2026-84233 is the sharper lesson, because it shows the limits of the obvious remedy. If you responded to the first three findings by hardening filename handling against shell metacharacters, you would not have closed this one. RPM macros are a second interpreter reading the same string, and %(...) in rpm’s macro language runs a shell command by design. A filename is therefore being parsed as two different languages, and a sanitizer written for one of them is silent about the other. Anyone writing the validation Red Hat recommends needs to reject % syntax as well as shell metacharacters, and Red Hat’s own mitigation text for the two flaws asks for exactly those two different things.

    The UI:R in all four vectors deserves a note too, because it is the metric most likely to be read as reassurance. User interaction required, in this context, means a person runs a build. In a continuous integration pipeline, that person is a schedule, and the artifact whose name carries the payload arrived from a registry, a mirror, an upstream release, or a contributor. The interaction requirement is satisfied by the pipeline working as designed. Red Hat’s own description of CVE-2026-84837 names automated CI/CD workflows as the exposure, and its mitigation is written for build pipelines rather than for people at a terminal.

    Scope is the other thing not to skim. CVE-2026-44604 marked RHEL 6 through 10 unaffected; CVE-2026-84837 marks RHEL 7 through 10 affected; the other two land only on RHEL 10 and Hardened Images. Four records, three different answers to “does this apply to me,” in the same package family. There is no shortcut here, and a team that concluded in June that its RHEL 9 estate was outside rpm’s problem would be wrong in September.

    Finally, the credit line on all four is the same, and it is part of the story. AISLE describes itself as finding, fixing, and verifying “vulnerabilities autonomously,” and claims more than 350 CVEs discovered. Whatever one makes of the marketing, the operational consequence for defenders is concrete: when re-auditing a function is cheap, findings in a given area arrive in batches, and they keep arriving after each fix. “We patched that function in June” was always weak evidence about the function’s neighbors. It is weaker now.

    What to do

    • Determine your scope per CVE, not per product. CVE-2026-84837 reaches RHEL 7, 8, 9, and 10. CVE-2026-84838 and CVE-2026-84233 reach RHEL 10 and Red Hat Hardened Images only.
    • Track rpm errata. RHSA-2026:28491 (June 23, 2026, rpm 6.0.1-6.1.hum1, Red Hat Hardened Images) addresses CVE-2026-44604 only. Fixed package versions for the three new records could not be confirmed at the time of this check — see the sourcing note — so treat the mitigations below as the current control rather than an interim one.
    • In build pipelines, normalize names before rpm tooling sees them. Red Hat’s guidance for CVE-2026-84837: “avoid using rpmbuild -t* with tarballs whose paths or filenames can be influenced by untrusted input. In automated build pipelines, ensure tarballs are staged into a trusted local directory and their names are normalized or validated to reject shell metacharacters before rpmbuild is invoked.”
    • Reject two grammars, not one. A validator that strips shell metacharacters does not stop CVE-2026-84233. Reject RPM macro syntax — % and %(...) — in filenames as well.
    • Constrain rpmuncompress input. Red Hat advises avoiding untrusted archive filenames with rpmuncompress and renaming source archives to remove shell metacharacters before processing.
    • Check where your build inputs come from. The exposure is not “someone attacked our build server”; it is “a name we did not choose reached a command line.” Registries, mirrors, and contributor-supplied archives all qualify.

    Sourcing note

    All four CVE identifiers, descriptions, scores, vectors, severity classifications, credits, and mitigation quotations come from the CVE Program record API at cveawg.mitre.org and from Red Hat’s customer portal CVE pages, read on September 2, 2026. Red Hat is the assigning authority for all four, so every score and every severity word here is Red Hat grading its own package; there is no independent NVD analysis on the new records.

    Fix state for CVE-2026-84837, CVE-2026-84838, and CVE-2026-84233 is not confirmed. Red Hat’s machine-readable security data endpoint returned HTTP 404 for all three, the CVE records carry mitigations rather than fixed versions, and no errata are named in them. This is reported as unresolved rather than as an absent patch: errata may exist and simply not be reachable by the routes used here. RHSA-2026:28491 was read directly and does confirm the June fix for CVE-2026-44604.

    No upstream rpm fixed version is asserted. The rpm.org releases page returned 404, and the project’s GitHub releases listing returned release years inconsistent with the CVE dates, so nothing was taken from it.

    Red Hat’s portal page for CVE-2026-44604 did not render a severity word to automated fetching; the Moderate classification cited is from the CVE Program record. Bugzilla 2460967 was read for CVE-2026-44604 and reports the issue in NEW status with “Version fixed (if any already): unknown,” which conflicts with RHSA-2026:28491 having shipped — a bug-tracker status lagging an advisory is ordinary, but both are shown here rather than reconciled. AISLE’s self-description is quoted from its own site. No exploitation is claimed or observed as of publication.