CVE-2026-84713: Automation Controller Information Disclosure

CVE-2026-84713 Overview

A flaw in the automation-controller notification subsystem allows any authenticated user to recover secret notification recipient values across organization boundaries. The NotificationTemplate.notification_configuration field is protected from API filtering, but 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 low-privileged attacker can abuse a relational filter as a boolean count-oracle. This enables character-by-character extraction of PagerDuty service keys and Slack, Mattermost, RocketChat, and Webhook bearer-token URLs belonging to other tenants.

Critical Impact
Any authenticated user can exfiltrate cross-tenant notification secrets, including PagerDuty service keys and webhook bearer tokens, breaking multi-tenant confidentiality boundaries.

Affected Products

Red Hat Ansible Automation Platform (automation-controller component)
Notification subsystem exposing PagerDuty, Slack, Mattermost, RocketChat, and Webhook integrations
Multi-tenant deployments sharing a single automation-controller instance

Discovery Timeline

2026-09-23 - CVE-2026-84713 published to NVD
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-84713

Vulnerability Analysis

The flaw is an authorization bypass in the object-relation filter backend of automation-controller. It is classified as [CWE-639] Authorization Bypass Through User-Controlled Key. Although NotificationTemplate.notification_configuration is explicitly excluded from API filtering to protect secrets, the send path duplicates the recipient value into Notification.recipients, which lacks the same protection. This duplication defeats the field-level protection at the source.

The API filter backend compounds the issue by traversing relationships across the credential-types endpoint without enforcing per-hop authorization. An attacker with no privileges beyond a valid session can construct relational filters that return a boolean count depending on whether a prefix of another tenant's recipient string matches a guessed value. Repeating this probe character-by-character reconstructs the full secret.

Root Cause

Two defects combine to enable the disclosure. First, the notification send routine copies protected configuration data into an unprotected relational field. Second, the ORM filter backend permits traversal into related objects without re-checking authorization for each hop, treating the credential-types endpoint's listability as sufficient authority to filter across it.

Attack Vector

Exploitation requires only a valid low-privileged account on the automation-controller instance. The attacker issues repeated authenticated HTTP requests that use startswith, contains, or similar relational lookups against the Notification.recipients field, filtered through the credential-types relation. Each request returns a differing object count depending on whether the guessed character is correct, forming a boolean oracle. Extracted values include PagerDuty service keys and bearer-token-bearing webhook URLs for Slack, Mattermost, and RocketChat, which grant the attacker the ability to post as those integrations or hijack alerting channels.

No verified public proof-of-concept code is available. Refer to the Red Hat CVE Analysis for CVE-2026-84713 and Red Hat Bugzilla Report #2527197 for authoritative technical detail.

Detection Methods for CVE-2026-84713

Indicators of Compromise

High-frequency authenticated API requests containing relational filter operators such as __startswith, __contains, or __icontains targeting notification or credential-type endpoints.
Sequential, incremental query patterns from a single user or session that vary a single character position per request against notification-related resources.
Unexpected outbound activity to third-party notification services (PagerDuty, Slack, Mattermost, RocketChat) using tokens that were not rotated after disclosure.

Detection Strategies

Instrument the automation-controller access log to alert on non-admin users querying /api/v2/credential_types/ or notification endpoints with relational lookup suffixes.
Rate-limit and baseline per-user query volume; enumeration attacks generate hundreds to thousands of nearly identical requests.
Correlate authenticated session activity with response-size or result-count deltas that indicate boolean-oracle probing.

Monitoring Recommendations

Forward automation-controller audit logs to a centralized analytics platform and retain them for cross-tenant investigation.
Monitor issued PagerDuty and webhook tokens for use from unexpected source addresses or user agents.
Track configuration changes to NotificationTemplate objects following any suspected enumeration event.

How to Mitigate CVE-2026-84713

Immediate Actions Required

Apply the vendor update referenced in Red Hat Security Advisory RHSA-2026:71177 to all automation-controller nodes.
Rotate every PagerDuty service key and every Slack, Mattermost, RocketChat, and Webhook bearer token configured in notification templates.
Audit user accounts and remove or restrict low-privileged accounts that do not require API access.

Patch Information

Red Hat has published RHSA-2026:71177 addressing the flaw in automation-controller. The fix ensures the Notification.recipients field is not filterable in a way that leaks protected configuration values and enforces per-hop authorization during relational filter traversal. Consult the Red Hat CVE Analysis for CVE-2026-84713 for the exact fixed package versions applicable to your deployment.

Workarounds

Restrict authenticated API access to trusted operators until the patched packages can be deployed.
Temporarily disable notification templates that contain high-value secrets such as PagerDuty service keys.
Deploy a reverse proxy or WAF rule that blocks relational filter operators (__startswith, __contains) on notification and credential-type endpoints for non-administrative users.

bash

# Example WAF rule concept: reject relational filter probes on notification endpoints
# Adjust to your proxy syntax; this is illustrative only.
location ~ ^/api/v2/(credential_types|notification) {
    if ($args ~* "(__startswith|__contains|__icontains|__regex)=") {
        return 403;
    }
    proxy_pass http://automation_controller_upstream;
}