Bug 2529289 (CVE-2026-86322)

Summary: CVE-2026-86322 foreman: authorization flaw in the Foreman::Controller::UserAware#find_user handling used by Api::V2::PersonalAccessTokensController
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: anthomas, ehelms, ggainey, jpasqual, juwatts, lblicha, mdellweg, mhulan, nmoumoul, ogajduse, osousa, pcreech, rchan, security-response-team, smallamp, tmalecek, zhunting
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Foreman’s Api::V2::PersonalAccessTokensController, where Foreman::Controller::UserAware#find_user resolves the target account using User.find(params[:user_id]) without applying the required parent-user authorization check. An attacker with the create_personal_access_tokens permission can therefore invoke POST /api/v2/users/:user_id/personal_access_tokens with another user’s ID and create a Personal Access Token on their behalf. The resulting plaintext token is returned in the API response, while PersonalAccessToken#check_permissions_after_save only validates create_personal_access_tokens on the token and does not enforce edit_users authorization on the target user. The attacker can then use the forged token to authenticate as the victim, potentially resulting in complete account takeover, including administrator accounts.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Deadline: 2026-12-15   

Description OSIDB Bzimport 2026-09-07 06:27:03 UTC 
Foreman contains an authorization flaw in the Foreman::Controller::UserAware#find_user handling used by Api::V2::PersonalAccessTokensController. The controller resolves the target account directly with User.find(params[:user_id]) without enforcing the parent-user authorization that normally restricts access to the target user. As a result, a user who has the create_personal_access_tokens permission can create a Personal Access Token for another user whose account is accessible by ID within the user's taxonomy scope.

The vulnerable endpoint is POST /api/v2/users/:user_id/personal_access_tokens. During token creation, the controller builds the Personal Access Token from the attacker-supplied user_id and returns the plaintext token value in the API response. 

The PersonalAccessToken#check_permissions_after_save model validation does not prevent this cross-user operation: when the token belongs to another user, it verifies the create_personal_access_tokens permission on the token itself but does not require edit_users authorization on the target user.

An attacker with the required create_personal_access_tokens permission can therefore forge a valid PAT belonging to another user and subsequently authenticate as that user using the generated token. This can result in complete account takeover, including takeover of administrator accounts that are visible within the attacker's taxonomy scope.