CVE-2026-84713: Automation-controller: automation-controller: notification.recipients/subject/error lack prevent_search, allowing zero-privilege cross-tenant recovery of notification recipient secrets via filter oracle
A flaw was found in the automation-controller notification subsystem. Although NotificationTemplate.notification configuration is protected from API filtering, its recipient value is copied in clear text into the unprotected Notification.recipients field on every send. Because the credential-types endpoint is listable by any authenticated user and the API filter backend traverses object relations without per-hop authorization, a user with no privileges can use a relational filter as a boolean count-oracle to recover, character by character and across organizations, the secret recipient values of other tenants' notifications — including PagerDuty service keys and Slack/Mattermost/RocketChat/Webhook bearer-token URLs. This flaw affects confidentiality.
Other sources
An authorization-bypass information-disclosure flaw was found in the automation-controller notification subsystem. A NotificationTemplate's notificationconfiguration field, which holds the notification's secret parameters, is correctly protected by preventsearch so it cannot be used as a target of the API's relational filter backend. However, each time a notification is sent, the controller copies the recipient parameter from the configuration verbatim into the recipients column of a new Notification row, and the Notification model's recipients, subject, and error columns are plain text fields with no preventsearch protection. For the notification backends whose recipient is itself a secret — PagerDuty (the Events-API service key), and Mattermost, RocketChat, and generic Webhook backends (incoming-webhook URLs that embed a bearer token) — the copied value is stored in clear text because those parameters are not encrypted password fields. Because the credential-types API endpoint is listable by any authenticated user regardless of roles, and the filter backend traverses object relations without enforcing per-hop access control, a user with no privileges and no organization membership can construct a filter that walks from credential types through credentials, organizations, notification templates, and notifications to the unprotected recipients field, and use the returned result count as a boolean oracle. Using case-insensitive, case-sensitive, and regular-expression match operators, the attacker recovers the exact secret value one character at a time, for organizations they have no access to. The same relation chain also exposes each notification's subject and error text. The result is cross-tenant disclosure of live notification credentials to an unprivileged user. The root cause is that a value stripped of search protection at the source is copied into a sink that lacks the same protection; the deeper contributing weakness is that the filter backend performs relation traversal without per-hop authorization.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
What level of access does an attacker need?
Any authenticated user can exploit the issue; no additional privileges are required. The attacker uses the listable credential-types endpoint and relational API filters as a boolean count oracle.
Which data may be exposed?
Recipient values copied into Notification.recipients when notifications are sent may be recovered character by character across organizations. This can include PagerDuty service keys and bearer-token URLs for Slack, Mattermost, RocketChat, and webhooks.
When is a notification recipient at risk?
The recipient becomes exposed after a notification is sent, because its value is copied from the protected notification configuration into the unprotected Notification.recipients field. The issue affects confidentiality rather than integrity or availability.