Bug 2527197 (CVE-2026-84713) - 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
Summary: CVE-2026-84713 automation-controller: automation-controller: Notification.rec...
Keywords:
Status: NEW
Alias: CVE-2026-84713
Deadline: 2026-10-01
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-02 00:55 UTC by Thomas Eagle
Modified: 2026-09-23 19:09 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.