REDHAT-BUG-2571729: Medium severity vulnerability

Published Nov 11, 2026
·
Updated

The API access classes for JobTemplate and WorkflowJobTemplate do not check the caller's Credential userole when assigning the single-valued webhookcredential foreign key. The serializer checks only that this credential is a token for the selected webhook service. A user who may administer their own template and use its Project and Inventory appears able to attach a GitLab token credential that they are not allowed to use. The template's webhook key is available to that administrator. A GitLab webhook event then causes AWX to decrypt the attached token and send it in the PRIVATE-TOKEN header to the event-derived status URL. Confirmed in source for release tag 24.6.1 and devel commit 8565291e43e17cd1ee5333e82e57aeb230e6574e. Source-level root cause: (1) awx/api/permissions.py ModelAccessPermission.checkputpermissions delegates the PATCH authorization decision to JobTemplateAccess.canchange or WorkflowJobTemplateAccess.canchange. (2) awx/main/access.py JobTemplateAccess.canadd and canchange check the caller's permissions on the template, Project, Inventory and Execution Environment, but do not call checkrelated('webhookcredential', Credential, ..., rolefield='userole'); WorkflowJobTemplateAccess.canchange has the same omission, whereas UnifiedCredentialsMixin.canattach enforces userole for the normal many-to-many credentials relationship. (3) awx/api/serializers.py JobTemplateMixin.validate checks webhookcredential.credentialtype.kind and namespace but not caller authorization for that Credential. (4) awx/api/views/webhooks.py WebhookKeyView.get returns a template's webhook key to its administrator; GitlabWebhookReceiver authenticates with that key then constructs a status URL from request.data['project']['weburl']; WebhookReceiverBase.post copies obj.webhookcredential and the status URL into the new job before signalstart. (5) awx/main/models/mixins.py WebhookMixin.updatewebhookstatus decrypts and sends the token. Reporter notes they verified the permission branch and outbound header construction by executing functions extracted from the official source snapshots and sent a dummy token to a loopback receiver through updatewebhookstatus; they did not deploy a full AWX instance.

Affected Software

0 affected components

Event History

Nov 11, 2026
Data Sourced
via Red Hat·02:25 PM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

Which users are realistically able to trigger this issue?

A user who can administer their own JobTemplate or WorkflowJobTemplate and has use access to its Project and Inventory appears able to attach a GitLab token credential even when they do not have use permission for that credential.

2

What is required for the credential to be exposed?

The attached credential must be a token for the selected webhook service, and a GitLab webhook event must occur. AWX then decrypts the credential and sends it in the PRIVATE-TOKEN header to the status URL derived from the event.

3

Which releases were confirmed to contain the issue?

The issue was confirmed in source for release tag 24.6.1 and development commit 8565291e43e17cd1ee5333e82e57aeb230e6574e.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203