Bug 2527197 (CVE-2026-84713)

Summary:	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
Product:	[Other] Security Response	Reporter:	Thomas Eagle <teagle>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	dschmidt, jlanda, kshier, security-response-team, simaishi, stcannon, teagle, yguenane
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	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.	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-10-01

Description Thomas Eagle 2026-09-02 00:55:25 UTC

An authorization-bypass information-disclosure flaw was found in the
  automation-controller notification subsystem. A NotificationTemplate's
  notification_configuration field, which holds the notification's secret
  parameters, is correctly protected by prevent_search 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 prevent_search 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.