Where
-Infinity
0

Vendor Risk Score

See how nautobot compares to other vendors in security performance

View Risk Score →
Severity
5.4
XSS
AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

Impact 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 helptext, which is rendered with Django's |safe filter (renderfield.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 in the victim's authenticated session, it can lead to actions performed as the victim, session/token theft, and further privilege escalation. Exploitation requires the victim to open an affected form.

Relationship description

A user who holds the add/change permission for Relationships (extras.addrelationship / extras.changerelationship) can set a Relationship's description to an HTML/JavaScript payload. That description is used as the help text of the relationship's form field and is rendered on the create/edit page of every object type the relationship applies to.

Module Family name

A user who holds the add/change permission for Module Families (dcim.addmodulefamily / dcim.changemodulefamily) can put a payload in a Module Family name, which is interpolated into the modulefamily field's help text on the Module "Install module" form for any module bay assigned to that family.

Patches Has the problem been patched? What versions should users upgrade to?

Fixes are available in Nautobot v2.4.37+ & v3.1.8+

Note: The underlying weakness exists in earlier EOL versions of Nautobot (v1.x). Users on those older EOL versions are highly encouraged to upgrade to a supported version.

Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading?

There is no configuration-only fix. To remediate without upgrading:

- Restrict the extras.addrelationship / extras.changerelationship and dcim.addmodulefamily / dcim.changemodulefamily permissions to fully trusted administrators only. - Audit existing Relationship description values and Module Family name values for embedded HTML / <script> content and remove any payloads.

Note that limiting who can open create/edit forms does not fully mitigate the issue, since the payload targets any user (including admins) who opens an affected form.

Credit

Credit for this discovery goes to Habibullo Izzatilloyev.

1 / 2
Source: GitHub
First published (updated )
Severity
6.4
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
6.5
Infoleak
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Impact When credentials are provided while creating an OnboardingTask they may be visible via the Job Results view under the Additional Data tab as args for the Celery Task execution. This only applies to OnboardingTasks that are created with credentials specified while on v2.0.0-2.0.2 of Nautobot Device Onboarding. This advisory does not apply earlier version or when using NAPALMUSERNAME & NAPALMPASSWORD from nautobotconfig.py

Patches v3.0.0

Workarounds None

Recommendations Delete all Job Results for any onboarding task to remove clear text credentials from database entries that were run while on v2.0.X Upgrade to v3.0.0 Rotate any exposed credential

1 / 2
Source: GitHub
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203