A flaw was found in the Ansible Automation Platform automation-controller. The unauthenticated
Bitbucket Data Center webhook receiver skips HMAC signature verification for diagnostics:ping
events after it has already looked up the target template, causing the endpoint to return HTTP
200 for a template that has a Bitbucket DC webhook configured and HTTP 403 otherwise. An
unauthenticated remote attacker can use this response discrepancy as an oracle to enumerate
which Job Template and Workflow Job Template IDs have Bitbucket DC webhooks configured, without
knowing the secret webhook_key.
A flaw was found in the Ansible Automation Platform automation-controller webhook receivers.
The Bitbucket Data Center webhook receiver at
POST /api/controller/v2/{job_templates,workflow_job_templates}/<pk>/bitbucket_dc/ is
intentionally unauthenticated (permission_classes=(AllowAny,), authentication_classes=()) and
authorizes requests by verifying an HMAC over the request body keyed by the per-template
webhook_key. BitbucketDcWebhookReceiver.must_check_signature() returns False when the
X-Event-Key request header is 'diagnostics:ping', because Bitbucket does not sign ping
requests. This carve-out is evaluated only after the receiver has already resolved the target
template: get_object() filters templates to those with webhook_service='bitbucket_dc' and a
non-empty webhook_key and raises PermissionDenied (HTTP 403) when no template matches, whereas
a matching template proceeds past the skipped signature check to the ping short-circuit and
returns HTTP 200 with the body "Webhook ignored". As a result, an unauthenticated remote
attacker who sends a diagnostics:ping request to each template ID observes a 200-vs-403
response discrepancy that reveals exactly which Job Template and Workflow Job Template IDs have
Bitbucket DC webhooks configured, with no credentials and no knowledge of the webhook_key. This
is unauthenticated reconnaissance: it confirms valid template IDs, reveals which automation is
wired to Bitbucket Data Center, and lets an attacker focus subsequent webhook_key brute-force
or SCM-side spoofing attempts on the small set of templates that would actually accept signed
payloads. The ping path performs no action and no secret values are disclosed.
Upstream: https://github.com/ansible/tower (awx)
Affected file: awx/api/views/webhooks.py:306-308 (BitbucketDcWebhookReceiver.must_check_signature),
with webhooks.py:69-78 (get_object) and :144-146 (post ping short-circuit)
This issue has been addressed in the following products:
Red Hat Ansible Automation Platform 2.6 for RHEL 10
Red Hat Ansible Automation Platform 2.6 for RHEL 9
Via RHSA-2026:71113 https://access.redhat.com/errata/RHSA-2026:71113
This issue has been addressed in the following products:
Red Hat Ansible Automation Platform 2.5 for RHEL 9
Red Hat Ansible Automation Platform 2.5 for RHEL 8
Via RHSA-2026:71114 https://access.redhat.com/errata/RHSA-2026:71114
A flaw was found in the Ansible Automation Platform automation-controller webhook receivers. The Bitbucket Data Center webhook receiver at POST /api/controller/v2/{job_templates,workflow_job_templates}/<pk>/bitbucket_dc/ is intentionally unauthenticated (permission_classes=(AllowAny,), authentication_classes=()) and authorizes requests by verifying an HMAC over the request body keyed by the per-template webhook_key. BitbucketDcWebhookReceiver.must_check_signature() returns False when the X-Event-Key request header is 'diagnostics:ping', because Bitbucket does not sign ping requests. This carve-out is evaluated only after the receiver has already resolved the target template: get_object() filters templates to those with webhook_service='bitbucket_dc' and a non-empty webhook_key and raises PermissionDenied (HTTP 403) when no template matches, whereas a matching template proceeds past the skipped signature check to the ping short-circuit and returns HTTP 200 with the body "Webhook ignored". As a result, an unauthenticated remote attacker who sends a diagnostics:ping request to each template ID observes a 200-vs-403 response discrepancy that reveals exactly which Job Template and Workflow Job Template IDs have Bitbucket DC webhooks configured, with no credentials and no knowledge of the webhook_key. This is unauthenticated reconnaissance: it confirms valid template IDs, reveals which automation is wired to Bitbucket Data Center, and lets an attacker focus subsequent webhook_key brute-force or SCM-side spoofing attempts on the small set of templates that would actually accept signed payloads. The ping path performs no action and no secret values are disclosed. Upstream: https://github.com/ansible/tower (awx) Affected file: awx/api/views/webhooks.py:306-308 (BitbucketDcWebhookReceiver.must_check_signature), with webhooks.py:69-78 (get_object) and :144-146 (post ping short-circuit)