REDHAT-BUG-2571729: Medium severity vulnerability
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
Event History
Frequently Asked Questions
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.
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.
Which releases were confirmed to contain the issue?
The issue was confirmed in source for release tag 24.6.1 and development commit 8565291e43e17cd1ee5333e82e57aeb230e6574e.