What kind of vulnerability is it? Who is impacted? It has two related instances that share the same root cause: a user-controlled model field is assigned verbatim to a form field's help_text, which is rendered with Django's |safe filter (render_field.html), bypassing auto-escaping. In both cases the script executes in the browser of any user who opens an affected create or edit form, including administrators and superusers. Because the payload runs …
This is an authorization bypass that escalates into unauthorized server-side job execution. 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.add_approvalworkflowstageresponse can POST approved responses directly and drive a stage past its min_approvers threshold with no legitimate approver …
Nautobot's Webhook data model and associated feature set could be configured by users with sufficient access to perform requests to various hosts and IP addresses that should not be permitted, allowing for various behaviors similar to server-side request forgery (SSRF).
In the case of inter-object references via GenericForeignKey (a pattern allowing an object to reference another object that may belong to one of several different "content types" or database tables), when creating or updating an object containing a GenericForeignKey, Nautobot's REST API failed to enforce user "view" permissions when determining whether a given reference to another object would be valid. As a concrete example, a user: who has permission to …
Nautobot UI object-bulk-rename endpoints (for example, /dcim/interfaces/rename/) were vulnerable to application-wide denial of service via maliciously crafted regular expressions in the find field in combination with the use_regex flag.
A user with access to add/change a GitRepository record could use the REST API to directly set the current_head field on the record, which was not intended to be user-editable. Doing so could cause Nautobot's local clone(s) of the relevant repository to checkout a commit other than the latest commit on the specified branch (resulting in misleading state), or potentially to be unable to make use of the repository at …
In Nautobot versions prior to 2.4.30 or prior to 3.0.10, user creation and editing via the REST API fails to apply the password validation rules defined by Django's AUTH_PASSWORD_VALIDATORS setting (which defaults to an empty list, i.e., no specific rules, but can be configured in Nautobot's nautobot_config.py to apply various rules if desired). This can potentially allow for the creation or modification of users to have passwords that are weak …