A Read-Only Account Reads the Root Password — Foreman’s Template Sandbox Fails Twice in One Advisory

Red Hat published two Foreman flaws on 1 October 2026 that break the same security boundary from opposite ends. CVE-2026-96658 — rated Critical by Red Hat Product Security, CVSS 3.1 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) — lets an authenticated low-privilege user escape Foreman's safemode template sandbox and run arbitrary commands on the host. CVE-2026-96659 — rated Important, CVSS 3.1 9.1, CWE-267 — lets a user holding nothing but the Viewer role query template preview endpoints and pull back sensitive host attributes, Red Hat's advisory says explicitly, "such as host root passwords."

Both are fixed. Red Hat Satellite 6.19 gets RHSA-2026:74503 (initial release 15:04 UTC, 1 October), 6.18 gets RHSA-2026:74504, and 6.16 on RHEL 8 and 9 gets RHSA-2026:74506. The 6.19 errata is the one to read: it is rated Critical and it carries 31 CVEs, of which CVE-2026-96658 and CVE-2026-96659 are only the headline pair.

Two ways through one wall

Foreman renders provisioning and job templates — the things that describe how a machine gets built — inside a restricted evaluator called safemode. The sandbox exists because templates are, by design, written by humans with varying privilege and executed by a service account with very high privilege. Red Hat's description of CVE-2026-96658 is precise about how that broke: "Due to improper handling of delegated methods, an attacker can append unauthorized functions to the allowed execution list, enabling them to run arbitrary commands on the hosting server." The allow-list was not a wall; it was a list the caller could extend. The fix ships as rubygem-safemode-1.5.0-2 on 6.16, which tells you the defect lived in the sandbox library itself rather than in any one template.

CVE-2026-96659 never touches the sandbox. It is an authorization bug: the template preview endpoints did not check that the requesting role was entitled to the data the preview renders. Red Hat's statement is blunt about the consequence — "authenticated users assigned restricted Viewer permissions can bypass role-based access controls to retrieve sensitive host credentials." And the two flaws compose in the obvious direction: Red Hat notes that where safemode is disabled or circumvented, the authorization flaw "may allow the user to execute arbitrary commands as the Foreman system account." CVE-2026-96658 is precisely a way to circumvent safemode.

The scope metric on both records — S:C, scope changed — is the part worth dwelling on. Satellite is not an application server; it is the thing that provisions and configures the rest of the estate. A root password read out of a Satellite template preview is not a Satellite secret. It is a secret about every host Satellite builds.

The pattern, not the product

We keep writing this bug. The restricted-evaluator-that-isn't has shown up in unsandboxed Jinja2 in an LLM prompt-template library, in two expression-engine sandbox escapes in an agentic workflow platform, and in a shipped agent harness that fell to a single spoofed header. Foreman's safemode predates all of it by a decade and still failed on the same primitive: a dynamic language's method dispatch offers more surface than an allow-list can enumerate.

That matters here beyond Ruby trivia, because Satellite is increasingly the machine that automation — human or agentic — is pointed at. A low-privilege read-only account is exactly the credential an operator hands to a monitoring integration, a reporting script, or an AI assistant asked to "summarise our host inventory." CVE-2026-96659's precondition is not a compromise; it is the least-privilege account working as intended. The Zammad pair we covered yesterday made the same point from the ticket queue: the low-trust entry point is now the one with a robot behind it, and the privilege model has to hold against a caller that will try every endpoint.

There is no evidence of exploitation in Red Hat's records for either CVE, no public proof-of-concept we could find, and neither has been added to CISA's KEV catalog. CVE-2026-96658 was still Awaiting Analysis in NVD at the time of writing, carrying Red Hat's 9.9 as its only scored metric.

What to do

  • Apply the errata for your actual stream, not just the newest one. RHSA-2026:74503 (Satellite 6.19.5), RHSA-2026:74504 (6.18.10) and RHSA-2026:74506 (6.16, RHEL 8 and 9) all carry fixes. 6.19 pulls foreman-3.18.0.14-1; 6.16 additionally pulls rubygem-safemode-1.5.0-2. Patching one stream in a mixed estate leaves the others exposed.
  • Read the whole 6.19 advisory, not the two CVEs that made the news. Thirty-one CVEs is not a rollup of noise: it includes command injection in job invocations via effective_user (CVE-2026-12405), unauthenticated information disclosure via provisioning token validation (CVE-2026-12423), three separate foreman-rake/foreman-tail command injections, and SSTI with insecure deserialisation in configuration handling (CVE-2026-12544).
  • Audit who actually holds Viewer, and treat those accounts as having read host credentials. The exploitation precondition for CVE-2026-96659 is an ordinary read-only login. If service integrations, dashboards or assistants hold one, rotate the host root passwords they could have rendered and check template preview access in your logs.
  • Do not rely on safemode as the boundary you're betting on. It was bypassable, and the companion CVE's severity is conditioned on it being intact. Treat template authorship as a privileged operation enforced by roles and review, with the sandbox as defence in depth rather than the control itself.

Our verification was documentary: we pulled both CVE records from Red Hat's security data API (securitydata/cve/CVE-2026-96658.json and CVE-2026-96659.json) for severity, CVSS vectors, Bugzilla IDs, affected releases and package NEVRAs, retrieved the CSAF documents for RHSA-2026:74503 and RHSA-2026:74504 for release timestamps and the full CVE manifest, and confirmed CVE-2026-96658's NVD status and score via the NVD 2.0 API. Quoted phrasing is Red Hat's own advisory text, attributed as such. We did not test any Satellite or Foreman instance and sent no traffic to any third-party deployment.

Sources: