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)