Bug 2553939 (CVE-2026-111456) - CVE-2026-111456 candlepin: Consumer certificate can register systems in another organization
Summary: CVE-2026-111456 candlepin: Consumer certificate can register systems in anoth...
Keywords:
Status: NEW
Alias: CVE-2026-111456
Deadline: 2026-10-27
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-10-16 04:41 UTC by OSIDB Bzimport
Modified: 2026-11-12 18:51 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-10-16 04:41:37 UTC
ConsumerResource.setupOwner() allows a consumer to be created only after an organization create check, and that check runs only when the caller is a UserPrincipal. POST /candlepin/consumers is annotated SecurityHole, so the normal authorization filter does not run. A caller that authenticates with a consumer identity certificate is a ConsumerPrincipal. The owner query parameter selects the organization, the consumer is stored there, and the API defaults identity-certificate creation to true.

The caller needs a valid consumer identity certificate and the key of the target organization. SSL client authentication is enabled by default.

The report states that a certificate from one organization created a consumer in another, and that the new consumer shows up in the target organization's consumer list. The shipped source confirms that path. The new certificate has the normal permissions of a consumer in the target organization, including listing that organization's pools and attaching its entitlements when the organization is not using simple content access. Those follow-on calls were not demonstrated.

The check was limited to user principals in candlepin 0.4.7 by commit 6f856359b1 on 2011-07-15. Before that commit, setupOwner() called canAccess() for every principal.

The same guard also skips cloud-registration principals when cloud authentication is enabled. Activation-key registration still requires a key that exists in the requested organization.


Note You need to log in before you can comment on or make changes to this bug.