Bug 2529290 (CVE-2026-86323)

Summary: CVE-2026-86323 foreman: authorization flaw in the mail-notification endpoints implemented by Api::V2::MailNotificationsController
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
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::MailNotificationsController, where authorization checks on user-specific mail-notification resources are insufficient. The GET /api/v2/users/:id/mail_notifications endpoint resolves the target account using User.find(params[:id]) without verifying that the authenticated user is authorized to access that user’s notification configuration. Additionally, the POST and PUT /api/v2/users/:user_id/mail_notifications paths call deny_access when the requester is unauthorized but fail to halt execution, allowing the request to continue and persist the unauthorized change despite a 403 response or subsequent DoubleRenderError. This can allow a user to disclose another user’s mail-notification configuration, including mail_query values, and, where write permissions apply, modify or create notification settings for another user.
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:05 UTC
Foreman contains an authorization flaw in the mail-notification endpoints implemented by Api::V2::MailNotificationsController. The controller resolves the target user directly from the request parameter without verifying that the authenticated user is authorized to access or modify that user's mail-notification configuration.

For the read operation, GET /api/v2/users/:id/mail_notifications assigns @user = User.find(params[:id]) without an ownership or parent-user authorization check. Because the view_mail_notifications permission is included in the default Viewer role, a user with Viewer privileges can retrieve another user's mail-notification subscriptions, including configured mail_query search strings. This results in cross-user disclosure of notification configuration and potentially sensitive information about the resources or activity being monitored by the victim.
The same controller also fails to correctly enforce authorization for mail-notification creation and modification through POST and PUT /api/v2/users/:user_id/mail_notifications. The validate_params method invokes deny_access when the requester is neither the target user nor an administrator, but does not halt execution after denying access. Consequently, the controller action continues and may persist the unauthorized notification configuration despite returning a 403 response or subsequently triggering a DoubleRenderError (HTTP 500).

An attacker can therefore use the affected API to read another user's mail-notification configuration and, with the required permissions for the write path, modify or create mail-notification records for that user. The underlying issue is improper authorization of the target user combined with failure to terminate request processing after an authorization denial.