CVE-2026-12515: Katello Authorization Flaw Allows Repository Content Enumeration

Technical summary

The vulnerability stems from insufficient authorization checks in Katello's ContentUploadsController. Users granted the edit_products permission are intended to manage only their assigned products, but the content upload API does not properly validate that query requests are scoped to authorized repositories. An authenticated attacker can therefore craft requests to probe repository contents outside their permission boundary, leveraging missing authorization logic to enumerate what content is present. This is classified as an authorization/access control flaw (CWE-862) with low attack complexity—the exploitation requires only standard API calls and valid authentication credentials.

Business impact

For Red Hat Satellite deployments, this vulnerability enables internal reconnaissance and competitive intelligence gathering by privileged-but-restricted users. An employee or contractor with product-management rights could discover confidential content (package versions, security patches, proprietary software) in repositories they're not meant to see. While direct data exfiltration or modification isn't possible, the information disclosure can inform lateral movement, privilege escalation, or supply-chain attacks. Organizations using fine-grained repository access controls to segregate products or customers are most at risk, as the flaw undermines the assumed security boundaries.

Affected systems

Red Hat Satellite deployments running Katello are affected. This includes customers using Satellite for content management, patching, and lifecycle management across their infrastructure. The vulnerability applies to any Katello instance where users have been assigned edit_products permissions and repository access should be restricted by product assignment.

Exploitability

The vulnerability requires authentication and edit_products permission—a non-trivial barrier. However, the attack surface is wide: any user with product-editing rights (not uncommon in medium to large Satellite deployments) can execute the reconnaissance. The API call is straightforward with low complexity (no multi-step exploitation, no race conditions). An attacker must simply issue queries to the ContentUploadsController with repository identifiers they're testing. No CVSS score indicates this vulnerability is not on the CISA Known Exploited Vulnerabilities (KEV) catalog, suggesting limited public weaponization to date.

Remediation

Organizations should prioritize patching Katello to the version that corrects authorization checks in ContentUploadsController. Until patching is complete, restrict edit_products permission to only trusted users and implement auditing of content-upload API calls to detect suspicious enumeration patterns. Review Satellite RBAC configurations to ensure permissions align with actual job functions and limit the blast radius if an account is compromised.

Patch guidance

Consult the Red Hat Satellite security advisory for the fixed Katello version. Test patches in a staging environment before production deployment, particularly if your Satellite instance manages critical infrastructure content. Red Hat typically releases advisories with specific version numbers and may provide guidance on incremental vs. major updates. Verify the patch resolves authorization checks in the ContentUploadsController against your custom automation if you have integrated content-upload workflows.

Detection guidance

Monitor Satellite audit logs for repeated or suspicious queries to the ContentUploadsController API, especially from users querying repositories outside their assigned product scope. Look for patterns such as rapid enumeration of repository IDs, queries from unexpected source IPs, or off-hours API activity by edit_products users. Implement alerting on failed authorization attempts if Satellite logs them. Network-level detection is difficult since the flaw exploits legitimate API endpoints; focus on behavioral analysis and access log correlation.

Why prioritize this

Although the CVSS score is medium (4.3) and the vulnerability is information-disclosure only, prioritization depends on your deployment model and user base. If your Satellite instance serves segregated customers or products with strict access boundaries, the reconnaissance capability is operationally significant and warrants timely patching. If Satellite is used primarily in an internal, single-tenant environment with fewer trust boundaries, the risk is lower. The lack of KEV status suggests this is not yet a major attack vector in the wild.

Risk score, explained

The CVSS 3.1 score of 4.3 reflects low impact (information disclosure, confidentiality impact only), low attack complexity, and the requirement for prior authentication and edit_products permission. The score accurately penalizes the vulnerability for not enabling modification or availability impact, but it may underweight the strategic value of repository enumeration in multi-tenant or segregated-product deployments. Organizations with strict data compartmentalization should consider their business context when mapping this score to internal risk ratings.

Frequently asked questions