CVE-2026-86323 in Foreman
Summary
by MITRE • 11/12/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/12/2026
The vulnerability identified in Foreman's Api::V2::MailNotificationsController represents a critical failure in access control mechanisms within the application's API layer. This flaw specifically affects endpoints responsible for managing mail notifications associated with individual users. The core issue stems from an insufficient authorization check when handling requests to retrieve or modify user-specific resources. In secure web applications, every request that accesses sensitive data or performs state-changing operations must verify that the authenticated principal has explicit permission to act upon the specific resource identified in the request parameters. Here, the system fails to enforce this principle rigorously across all HTTP methods supported by the controller.
The GET endpoint for retrieving mail notifications exhibits a direct object reference weakness where the application resolves the target user account using User.find(params[:id]) based solely on the identifier provided in the URL path. Crucially, there is no subsequent verification step to confirm that the currently authenticated session belongs to the same entity as the requested resource or possesses administrative privileges over it. This allows any validly authenticated user to enumerate and view the mail notification configurations of other users by simply altering the ID parameter in the API call. The disclosed information includes sensitive details such as mail_query values, which may contain internal logic, recipient lists, or filtering criteria that could aid an attacker in further reconnaissance or social engineering attacks against specific organizational units.
The severity of this vulnerability is compounded by critical flaws in how write operations are handled for POST and PUT requests targeting the same resource paths. When a user attempts to create or modify mail notifications for another account without proper authorization, the application correctly identifies the lack of permission and invokes deny_access. However, instead of terminating the request processing pipeline immediately after denying access, the execution flow continues. This architectural oversight means that despite the API returning an HTTP 403 Forbidden status code to indicate rejection, the underlying logic proceeds to persist the unauthorized changes to the database. Consequently, a malicious actor can successfully alter or create notification settings for other users even though they receive an error response indicating failure.
This behavior creates two distinct but related security impacts: information disclosure and privilege escalation through data manipulation. The ability to read another user's mail configuration exposes internal operational details that should remain private between the system administrator and the specific end-user. Furthermore, the ability to write unauthorized changes allows attackers to disrupt service delivery for targeted users by modifying their notification preferences or inject malicious configurations if those settings influence downstream processes. This aligns with CWE-284 Improper Access Control, as the application does not properly restrict access to resources based on user roles and permissions. It also reflects aspects of CWE-601 URL Redirection Through Unvalidated Input in terms of trusting input identifiers without validation against session context.
From an offensive security perspective, this vulnerability maps directly to MITRE ATT&CK technique T1530 Data from Cloud Storage Object or more generally T1078 Valid Accounts if the attacker uses stolen credentials, and specifically relates to data exfiltration via unauthorized API access. The persistence of changes despite error responses indicates a deeper issue in how exceptions and authorization failures are managed within the controller's lifecycle methods. Attackers can automate this process using scripts that iterate through user IDs or exploit predictable ID sequences to systematically harvest configuration data across the entire tenant population, potentially leading to large-scale compromise of notification integrity for all users on the instance.
Mitigation strategies must address both the read and write aspects of this flaw immediately. The primary fix involves implementing strict authorization checks at the beginning of each action within the MailNotificationsController. For GET requests, a check must be performed after resolving the user object to ensure that current_user.id matches params[:id] or that the current_user holds an administrative role with permission to view other users' settings. For POST and PUT operations, it is imperative to halt execution immediately upon detecting unauthorized access rather than allowing the request body processing to continue. This can be achieved by ensuring that deny_access raises a proper exception that aborts the controller action before any model save or update methods are invoked.
Additionally, developers should review other API controllers for similar patterns where authorization checks might not effectively stop request processing. Implementing centralized middleware or using framework-specific features like Pundit policies with strict policy enforcement can help standardize access control logic and prevent such oversights in the future. Regular security audits focusing on RESTful endpoint permissions are recommended to ensure that all resource endpoints adhere to the principle of least privilege, ensuring users only interact with data they are explicitly permitted to view or modify.