Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
19 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 3.1.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.8 or 2.4.37 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A user with access to add/change a GitRepository record could use the REST API to directly set the currenthead 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 all (until manually remediated) due to the currenthead pointing to a nonexistent commit hash or malformed value. Patches The issue has been remediated in Nautobot v2.4.33 and 3.1.2. Workarounds Note that many of the same end-result symptoms could be caused by a user with the same level of access simply changing the branch or remoteurl of a GitRepository rather than crafting the currenthead. Administrators are encouraged to carefully review which users are granted permissions to create and modify GitRepository records. References - 2.4.33 (<a…
Recommended action: Upgrade to 3.1.2 or 2.4.33 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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). Patches Fixes are available in Nautobot v2.4.33 and v3.1.2. In support of this fix, three new settings variables have been added to Nautobot: - WEBHOOKALLOWEDSCHEMES - By default new or updated Webhook records will be restricted to HTTP or HTTPS only, disallowing other schemes that may have been previously allowed. Administrators should audit existing Webhook records to identify any that are invalid, and either update/delete said records or customize WEBHOOKALLOWEDSCHEMES as appropriate. - WEBHOOKADDITIONALBLOCKEDNETWORKS - This can be used to specify additional IP networks that should be denied to Webhook sending, for example some deployments may wish to disallow RFC1918 addresses or even disallow all networks…
Recommended action: Upgrade to 3.1.2 or 2.4.33 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 useregex flag. Patches A general-purpose timeout has been added to these endpoints in Nautobot v2.4.33 and v3.1.2, which ensures that the request will fail early with an appropriate message if regular expression evaluation takes more than a short period of time, instead of continuing to execute for an indefinite duration. Workarounds No known workaround has been identified at this time. References - 2.4.33 (<a href="https://github.com/nautobot/nautobot/commit/c2b766966d814a7141f62c7bc90c85fefb7892ee"patch</a) - 3.1.2 (<a href="https://github.com/nautobot/nautobot/commit/5a30d0916953afbeedd24a784709e762cc3879cd"patch</a)
Recommended action: Upgrade to 3.1.2 or 2.4.33 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 create or update ImageAttachment records - but who lacks permission to view (some or all) Device records - but who knows (via some other mechanism) the UUID of a specific Device that they do not otherwise have access to could create via the REST API an ImageAttachment linked to that specific Device. Other models that use GenericForeignKey and may be writable via the REST API, and hence have a similar vulnerability to ImageAttachment, may include: - ApprovalWorkflow - Cable - ConfigContext - ContactAssociation -…
Recommended action: Upgrade to 3.1.2 or 2.4.33 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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 AUTHPASSWORDVALIDATORS setting (which defaults to an empty list, i.e., no specific rules, but can be configured in Nautobot's nautobotconfig.py to apply various rules if desired). This can potentially allow for the creation or modification of users to have passwords that are weak or otherwise do not comply with configured standards. Management of users via the Nautobot admin UI does correctly enforce configured password validation at this time. Patches The issue is resolved in Nautobot versions 2.4.30 and 3.0.10 and later. - https://github.com/nautobot/nautobot/pull/8778 - https://github.com/nautobot/nautobot/pull/8779 Workarounds Review which users have been granted object permissions to create and modify user accounts as well as having access tokens for the REST API, and restrict access as appropriate. It may be…
Recommended action: Upgrade to 3.0.10 or 2.4.30 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Files uploaded by users to Nautobot's MEDIAROOT directory, including DeviceType image attachments as well as images attached to a Location, Device, or Rack, are served to users via a URL endpoint that was not enforcing user authentication. As a consequence, such files can be retrieved by anonymous users who know or can guess the correct URL for a given file. For DeviceType image attachments, a mitigating factor is that no URL endpoint exists for listing the contents of the devicetype-images/ subdirectory, and the file names are as specified by the uploading user, so any given DeviceType image attachment can only be retrieved by correctly guessing its file name. Similarly, for all other image attachments, while the images can be listed by accessing the /api/extras/image-attachments/ endpoint as an authenticated user only, absent that authenticated access, accessing the files would again require guessing file names correctly. Patches Nautobot v2.4.10 and v1.6.32 will address…
Recommended action: Upgrade to 2.4.10 or 1.6.32 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? All users of Nautobot versions prior to 2.4.10 or prior to 1.6.32 are potentially affected. Due to insufficient security configuration of the Jinja2 templating feature used in computed fields, custom links, etc. in Nautobot: 1. A malicious user could configure this feature set in ways that could expose the value of Secrets defined in Nautobot when the templated content is rendered. 2. A malicious user could configure this feature set in ways that could call Python APIs to modify data within Nautobot when the templated content is rendered, bypassing the object permissions assigned to the viewing user. Patches Has the problem been patched? What versions should users upgrade to? Nautobot versions 1.6.32 and 2.4.10 will include fixes for the vulnerability. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? The vulnerability can be partially mitigated by configuring object permissions…
Recommended action: Upgrade to 2.4.10 or 1.6.32 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? A user with permissions to view Dynamic Group records (extras.viewdynamicgroup permission) can use the Dynamic Group detail UI view (/extras/dynamic-groups/<uuid/) and/or the members REST API view (/api/extras/dynamic-groups/<uuid/members/) to list the objects that are members of a given Dynamic Group. In versions of Nautobot between 1.3.0 (where the Dynamic Groups feature was added) and 1.6.22 inclusive, and 2.0.0 through 2.2.4 inclusive, Nautobot fails to restrict these listings based on the member object permissions - for example a Dynamic Group of Device objects will list all Devices that it contains, regardless of the user's dcim.viewdevice permissions or lack thereof. Patches Has the problem been patched? What versions should users upgrade to? Fixed in Nautobot 1.6.23 and 2.2.5. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? This vulnerability can be partially mitigated by…
Recommended action: Upgrade to 2.2.5 or 1.6.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A Nautobot user with admin privileges can modify the BANNERTOP, BANNERBOTTOM, and BANNERLOGIN configuration settings via the /admin/constance/config/ endpoint. Normally these settings are used to provide custom banner text at the top and bottom of all Nautobot web pages (or specifically on the login page in the case of BANNERLOGIN) but it was reported that an admin user can make use of these settings to inject arbitrary HTML, potentially exposing Nautobot users to security issues such as cross-site scripting (stored XSS). Patches Has the problem been patched? What versions should users upgrade to? Patches will be released as part of Nautobot 1.6.22 and 2.2.4. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? As described in the Nautobot documentation, these settings are only configurable through the admin UI of Nautobot if they are not explicitly set to some non-empty value in the nautobotconfig.py or equivalent Nautobot…
Recommended action: Upgrade to 2.2.4 or 1.6.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It was discovered that due to improper handling and escaping of user-provided query parameters, a maliciously crafted Nautobot URL could potentially be used to execute a Reflected Cross-Site Scripting (Reflected XSS) attack against users. All filterable object-list views in Nautobot are vulnerable, including: - /dcim/location-types/ - /dcim/locations/ - /dcim/racks/ - /dcim/rack-groups/ - /dcim/rack-reservations/ - /dcim/rack-elevations/ - /tenancy/tenants/ - /tenancy/tenant-groups/ - /extras/tags/ - /extras/statuses/ - /extras/roles/ - /extras/dynamic-groups/ - /dcim/devices/ - /dcim/platforms/ - /dcim/virtual-chassis/ - /dcim/device-redundancy-groups/ - /dcim/interface-redundancy-groups/ - /dcim/device-types/ - /dcim/manufacturers/ - /dcim/cables/ - /dcim/console-connections/ - /dcim/power-connections/ - /dcim/interface-connections/ - /dcim/interfaces/ - /dcim/front-ports/ - /dcim/rear-ports/ - /dcim/console-ports/ - /dcim/console-server-ports/ - /dcim/power-ports/ -…
Recommended action: Upgrade to 2.2.3 or 1.6.20 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A number of Nautobot URL endpoints were found to be improperly accessible to unauthenticated (anonymous) users, including the following: - /api/graphql/ (1) - /api/users/users/session/ (Nautobot 2.x only; the only information exposed to an anonymous user is which authentication backend classes are enabled on this Nautobot instance) - /dcim/racks/<uuid:pk/dynamic-groups/ (1) - /dcim/devices/<uuid:pk/dynamic-groups/ (1) - /extras/job-results/<uuid:pk/log-table/ - /extras/secrets/provider/<str:providerslug/form/ (the only information exposed to an anonymous user is the fact that a secrets provider with the given slug (e.g. environment-variable or text-file) is supported by this Nautobot instance) - /ipam/prefixes/<uuid:pk/dynamic-groups/ (1) - /ipam/ip-addresses/<uuid:pk/dynamic-groups/ (1) - /virtualization/clusters/<uuid:pk/dynamic-groups/ (1) - /virtualization/virtual-machines/<uuid:pk/dynamic-groups/ (1) (1) These endpoints will not disclose any Nautobot data to an…
Recommended action: Upgrade to 2.1.9 or 1.6.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact All users of Nautobot versions earlier than 1.6.10 or 2.1.2 are potentially impacted. Due to inadequate input sanitization, any user-editable fields that support Markdown rendering, including: - Circuit.comments - Cluster.comments - CustomField.description - Device.comments - DeviceRedundancyGroup.comments - DeviceType.comments - Job.description - JobLogEntry.message - Location.comments - Note.note - PowerFeed.comments - Provider.noccontact - Provider.admincontact - Provider.comments - ProviderNetwork.comments - Rack.comments - Tenant.comments - VirtualMachine.comments - Contents of any custom fields of type markdown - Job class description attributes - The SUPPORTMESSAGE system configuration setting are potentially susceptible to cross-site scripting (XSS) attacks via maliciously crafted data. Patches Fixed in Nautobot versions 1.6.10 and 2.1.2. References https://github.com/nautobot/nautobot/pull/5133 https://github.com/nautobot/nautobot/pull/5134
Recommended action: Upgrade to 2.1.2 or 1.6.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When submitting a Job to run via a Job Button, only the model-level extras.runjob permission is checked (i.e., does the user have permission to run Jobs in general?). Object-level permissions (i.e., does the user have permission to run this specific Job?) are not enforced by the URL/view used in this case (/extras/job-button/<uuid/run/) The effect is that a user with permissions to run even a single Job can actually run all configured JobButton Jobs. Not all Jobs can be configured as JobButtons; only those implemented as subclasses of JobButtonReceiver can be used in this way, so this vulnerability only applies specifically to JobButtonReceiver subclasses. Additionally, although the documentation states that both extras.runjob permission and extras.runjobbutton permission must be granted to a user in order to run Jobs via JobButton, the extras.runjobbutton permission is not actually enforced by the view code, only by the UI by disabling the button from being clicked normally.…
Recommended action: Upgrade to 2.1.0 or 1.6.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In Nautobot 1.x and 2.0.x, the URLs /files/get/?name=... and /files/download/?name=... are used to provide admin access to files that have been uploaded as part of a run request for a Job that has FileVar inputs. Under normal operation these files are ephemeral and are deleted once the Job in question runs. It was reported by @kircheneer that in the default implementation used in Nautobot, as provided by django-db-file-storage, these URLs do not by default require any user authentication to access; they should instead be restricted to only users who have permissions to view Nautobot's FileProxy model instances. Note that no URL mechanism is provided for listing or traversal of the available file name values, so in practice an unauthenticated user would have to guess names to discover arbitrary files for download, but if a user knows the file name/path value, they can access it without authenticating, so we are considering this a vulnerability. Patches Fixes will be included in…
Recommended action: Upgrade to 2.0.6 or 1.6.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact All users of Nautobot versions earlier than 1.6.6 or 2.0.5 are potentially affected. Due to incorrect usage of Django's marksafe() API when rendering certain types of user-authored content, including: - custom links - job buttons - computed fields it is possible that users with permission to create or edit these types of content could craft a malicious payload (such as JavaScript code) that would be executed when rendering pages containing this content. Patches Has the problem been patched? What versions should users upgrade to? We have fixed the incorrect uses of marksafe() (generally by replacing them with appropriate use of formathtml() instead) to prevent such malicious data from being executed. Users on Nautobot 1.6.x LTM should upgrade to v1.6.6 and users on Nautobot 2.0.x should upgrade to v2.0.5. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Appropriate object permissions can and should be applied to restrict which users…
Recommended action: Upgrade to 2.0.5 or 1.6.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In Nautobot 2.0.x, certain REST API endpoints, in combination with the ?depth=<N query parameter, can expose hashed user passwords as stored in the database to any authenticated user with access to these endpoints. The passwords are not exposed in plaintext. Nautobot 1.x is not affected by this vulnerability. Example: Note the "password" field present in the nested "users" data. This information is not exposed during direct access to the /api/users/users/ endpoint, but can be exposed through any endpoint which contains a nested reference to User object(s) when an appropriate ?depth=<N query parameter is specified. Known impacted endpoints include: - /api/dcim/rack-reservations/?depth=1(or any greater depth value) - /api/extras/job-results/?depth=1 (or any greater depth value) - /api/extras/notes/?depth=1 (or any greater depth value) - /api/extras/object-changes/?depth=1 (or any greater depth value) - /api/extras/scheduled-jobs/?depth=1 (or any greater depth value) -…
Recommended action: Upgrade to 2.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? All users of Nautobot versions earlier than 1.5.7 are impacted. In Nautobot 1.5.7 we have enabled sandboxed environments for the Jinja2 template engine used internally for template rendering for the following objects: - extras.ComputedField - extras.CustomLink - extras.ExportTemplate - extras.Secret - extras.Webhook While we are not aware of any active exploits, we have made this change as a preventative measure to protect against any potential remote code execution attacks utilizing maliciously crafted template code. This change forces the Jinja2 template engine to use a SandboxedEnvironment on all new installations of Nautobot. This addresses any potential unsafe code execution everywhere the helper function nautobot.utilities.utils.renderjinja2 is called. Additionally, our documentation that was previously suggesting the direct use of jinja2.Template has been revised to utilize renderjinja2. Patches Has the problem been…
Recommended action: Upgrade to 1.5.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.