Red Hat Satellite CVE-2026-12515

Exploitation requires a valid authenticated Satellite user account with the edit_products permission assigned. The attacker must also know or enumerate the numeric repository IDs of out-of-scope repositories - these are sequential database integers and may be predictable or derivable from legitimate API responses. The vulnerable code path is exercised via the ContentUploadsController API, specifically the destroy action which performs the unscoped repository lookup. Limiting factors: authentication is mandatory with no unauthenticated path; the edit_products permission is not granted to default unprivileged users; the impact is strictly read-only content-existence disclosure with no capability to read content data, modify, import, or publish; and the attacker must already be a provisioned Satellite user with meaningful system access.

The CVSS 4.3 Medium score with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N accurately reflects the bounded nature of this flaw: network-accessible, low complexity, but requiring authenticated access with a specific permission. The impact is strictly limited to read-only content-existence metadata disclosure with no integrity or availability consequence. No EPSS score was provided in the available intelligence data, so exploitation probability cannot be quantified from that signal. The vulnerability is absent from CISA KEV and no public exploit code has been identified, indicating no known active exploitation. Real-world prioritization should be low-to-moderate: an attacker must already hold a valid Satellite account with the edit_products permission - a non-trivial prerequisite that significantly reduces the exploitable population. The information gained (whether specific content exists in an otherwise inaccessible repository) is low-value for most threat actors. Organizations with strict multi-tenant Satellite deployments or sensitive content partitioning should treat this with higher urgency.

An authenticated Satellite operator with edit_products rights scoped only to Product A crafts a direct API request to the content-upload endpoint, substituting the repository ID of an unrelated Product B - an integer ID that may be guessed sequentially or inferred from other API responses. Because the controller performs no permission-scoped lookup, the API returns content metadata confirming whether a specific RPM or file exists in Product B's repository, leaking information about a product the user should have no visibility into. No public exploit code exists; the attack requires only API knowledge and a valid session token.