CVE-2026-83805
MediumCVSS 6.4Summary
Nautobot from 3.0.0 to 3.1.8 does not enforce approver-group membership, change permission, or the one-response-per-user restriction in the generic ApprovalWorkflowStageResponse create endpoint. A user with only extras.add_approvalworkflowstageresponse can submit approved responses directly, and writable user/state fields allow attributing responses to arbitrary users. Forged responses can satisfy min_approvers, approve the workflow, and activate gated ScheduledJobs without a legitimate approver. Fixed in 3.1.8.
Risk Assessment
A user with limited privileges can bypass the approval process and trigger scheduled jobs, potentially leading to unauthorized changes in network infrastructure.
Recommendation
Upgrade Nautobot to version 3.1.8 or later to remediate the vulnerability.
Other vulnerabilities in Nautobot
See all- CVE-2026-83801Medium
Nautobot before 2.4.37 and 3.1.8 allows users with extras.add_relationship or extras.change_relationship to store HTML/JavaScript in Relationship descriptions, and users with dcim.add_modulefamily or dcim.change_modulefamily to store it in Module Family names. These values are rendered as form field help_text via Django's |safe filter without adequate neutralization. Stored content executes in the authenticated browser session of any user, including admins, opening affected forms. Fixed in 2.4.37 and 3.1.8.
- CVE-2026-44798High
In Nautobot prior to versions 2.4.33 and 3.1.2, a user with access to add/change a GitRepository record could use the REST API to directly set the current_head field, which was not intended to be user-editable. This could lead to outdated states of local clones of the repositories or prevent the use of the repository altogether.
- CVE-2026-34203Low
A vulnerability was found in Nautobot before versions 2.4.30 and 3.0.10 where password validation is not enforced when creating or editing users via the REST API. Weak passwords may be set.
Original NVD description (English source)
Nautobot is a Network Source of Truth and Network Automation Platform. From 3.0.0 until 3.1.8, the generic ApprovalWorkflowStageResponse create endpoint does not enforce approver-group membership, change permission on the object under review, or the one-response-per-user restriction applied by the intended approve and deny actions. A user with only extras.add_approvalworkflowstageresponse can submit approved responses directly, while writable user and state fields permit responses to be attributed to arbitrary users. These forged responses can satisfy min_approvers, approve the workflow, and activate its gated ScheduledJob without a legitimate approver. This issue is fixed in version 3.1.8.