GHSA-q4c5-2j6f-r476: Medium severity pip/nautobot vulnerability
Impact This is an authorization bypass that escalates into unauthorized server-side job execution.
1. Primary impact - self-approval: The approver checks (approver-group membership, change permission on the object under review, one-response-per-user) are enforced only in the approve/deny actions on ApprovalWorkflowStage. The generic ApprovalWorkflowStageResponse create endpoint enforces none of them, so a user holding only extras.addapprovalworkflowstageresponse can POST approved responses directly and drive a stage past its minapprovers threshold with no legitimate approver involved. The serializer also exposes user and state as writable, letting the attacker attribute responses to arbitrary users.
2. Escalated impact job activation: Because the approval workflow gates a ScheduledJob, self-approval does not stop at the approval record. Stage approval cascades through ApprovalWorkflow.save() to onworkflowapproved(), which sets the target job to enabled/active.
Patches
Fixed in Nautobot v3.1.8
Workarounds Restrict the extras.addapprovalworkflowstageresponse permission so that no untrusted user holds it; approval responses should only ever be created via the stage approve/deny actions. There is no configuration flag that disables the generic create endpoint prior to the patch.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/nautobotto a version that resolves this vulnerability.Fixed in 3.1.8 - Upgrade
Upgrade
Nautobotto a version that resolves this vulnerability.Fixed in 3.1.8 - Configuration
Restrict the extras.add_approvalworkflowstageresponse permission so that no untrusted user holds it; approval responses should only be created via the ApprovalWorkflowStage approve/deny actions.
Nautobot approval workflows extras.add_approvalworkflowstageresponse permission = restricted to trusted users; no untrusted user holds it
Event History
Frequently Asked Questions
Who is exposed to exploitation?
Any user granted the extras.add_approvalworkflowstageresponse permission is able to submit approval responses without the normal approver-group, change-permission, or one-response-per-user checks. The issue is especially significant where approval workflows gate ScheduledJob activation.
What does an attacker need to do?
The attacker needs an account with extras.add_approvalworkflowstageresponse and network access to the generic ApprovalWorkflowStageResponse create endpoint. They can POST approved responses directly, including writable user and state values, to meet a stage's min_approvers threshold without legitimate approval.
What happens after a workflow stage is bypassed?
Once the approval threshold is reached, approval processing can cascade through ApprovalWorkflow.save() and on_workflow_approved(). For workflows that gate a ScheduledJob, this enables or activates the target job, resulting in unauthorized server-side job execution.
What should be done if upgrading is not immediately possible?
Restrict extras.add_approvalworkflowstageresponse so that no untrusted user has it. Approval responses should only be created by trusted users until the affected installation can be updated to Nautobot v3.1.8.