Nautobot CVE-2026-83805

Requires an authenticated Nautobot account (versions 3.0.0 through 3.1.7) that has been granted the extras.add_approvalworkflowstageresponse object permission and network access to the REST API; the approval-workflow feature must be in use to gate ScheduledJobs. Exploitation is limited to insiders or compromised accounts with that specific permission - it is NOT unauthenticated and NOT exploitable against default installs that do not use approval workflows or that do not grant this add permission. No user interaction is needed. The flaw is that the generic create endpoint omits approver-group membership, change-permission-on-the-object, and one-response-per-user checks, and exposes writable user/state fields allowing attribution to arbitrary users.

This is a moderate-priority authorization flaw whose real-world risk is bounded by its access prerequisite. The vendor CVSS of 6.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) is internally consistent: it is network-reachable and low-complexity, but requires an authenticated account (PR:L) that has been granted the extras.add_approvalworkflowstageresponse permission. No EPSS score, CISA KEV listing, or public exploit code is present in the provided data, so exploitation status is 'no public exploit identified at time of analysis' - there is no signal of active or automated exploitation. The genuine severity driver is not memory-level impact but a broken security control: the approval-workflow gate is defeated, letting a low-privileged insider self-approve workflows and activate gated ScheduledJobs. The S:C (scope change) reflects that bypassing the approval component affects a separate component (job execution). The vendor's C:L/I:L rating is defensible but arguably understates integrity, since forging approvals to launch otherwise-gated automation jobs could have larger downstream effect than a single low-integrity write; verify against the specific jobs a deployment gates. Overall: a real but insider-gated authorization bypass, not an internet-facing unauthenticated RCE - treat as elevated-but-not-emergency, prioritized higher where the approval-workflow feature actually governs sensitive automation.

A user holding only the extras.add_approvalworkflowstageresponse permission (e.g. an over-provisioned automation operator) sends a REST API POST to the standalone ApprovalWorkflowStageResponse create endpoint, submitting a response with state='approved' and the writable user/state fields set to impersonate a legitimate approver. By repeating this they satisfy min_approvers and approve the workflow, activating its gated ScheduledJob with no genuine approver involved. No public PoC is referenced, but the fix commit and advisory describe the exact API path, making the technique straightforward to reproduce.