Nautobot vulnerabilities

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.

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.

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.

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.