### 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` - `DataCompliance` - `Device` - `ExportTemplate` - `GraphQLQuery` - `Note` - `ObjectMetadata` - `RelationshipAssociation` - `StaticGroupAssociation` - `VirtualMachine` Additionally, any Nautobot Apps that provide models with a REST API and use GenericForeignKey may have a similar vulnerability for their models. ### Patches A general-purpose fix has been implemented in Nautobot 2.4.33 and 3.1.2, which ensures correct application of "view" permissions when creating or modifying object references via `GenericForeignKey` throughout the REST API. Individual models/views/serializers generally will not require any specific code changes to benefit from this fix. ### Workarounds No known workarounds at this time. ### References - 2.4.33 (<a href="https://github.com/nautobot/nautobot/commit/9918bdb9bcf1eb42cda72c344f420a64ef7665f1">patch</a>) - 3.1.2 (<a href="https://github.com/nautobot/nautobot/commit/36cde7148a207234de6212ec074f321dbc9d1b5b">patch</a>)
### 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` - `DataCompliance` - `Device` - `ExportTemplate` - `GraphQLQuery` - `Note` - `ObjectMetadata` - `RelationshipAssociation` - `StaticGroupAssociation` - `VirtualMachine` Additionally, any Nautobot Apps that provide models with a REST API and use GenericForeignKey may have a similar vulnerability for their models. ### Patches A general-purpose fix has been implemented in Nautobot 2.4.33 and 3.1.2, which ensures correct application of "view" permissions when creating or modifying object references via `GenericForeignKey` throughout the REST API. Individual models/views/serializers generally will not require any specific code changes to benefit from this fix. ### Workarounds No known workarounds at this time. ### References - 2.4.33 (<a href="https://github.com/nautobot/nautobot/commit/9918bdb9bcf1eb42cda72c344f420a64ef7665f1">patch</a>) - 3.1.2 (<a href="https://github.com/nautobot/nautobot/commit/36cde7148a207234de6212ec074f321dbc9d1b5b">patch</a>)
Update nautobot to 3.1.2; nautobot to 2.4.33 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanNautobot: REST API permits creation of GenericForeignKey references to objects that the user should not be able to reference affects nautobot (pip), nautobot (pip). Severity is medium. ### 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` - `DataCompliance` - `Device` - `ExportTemplate` - `GraphQLQuery` - `Note` - `ObjectMetadata` - `RelationshipAssociation` - `StaticGroupAssociation` - `VirtualMachine` Additionally, any Nautobot Apps that provide models with a REST API and use GenericForeignKey may have a similar vulnerability for their models. ### Patches A general-purpose fix has been implemented in Nautobot 2.4.33 and 3.1.2, which ensures correct application of "view" permissions when creating or modifying object references via `GenericForeignKey` throughout the REST API. Individual models/views/serializers generally will not require any specific code changes to benefit from this fix. ### Workarounds No known workarounds at this time. ### References - 2.4.33 (<a href="https://github.com/nautobot/nautobot/commit/9918bdb9bcf1eb42cda72c344f420a64ef7665f1">patch</a>) - 3.1.2 (<a href="https://github.com/nautobot/nautobot/commit/36cde7148a207234de6212ec074f321dbc9d1b5b">patch</a>)
AI coding agents often install or upgrade packages automatically in pip. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| nautobotpip | >=3.0.0a2,<3.1.2 | 3.1.2 |
| nautobotpip | <2.4.33 | 2.4.33 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate nautobot to 3.1.2; nautobot to 2.4.33 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanNautobot: REST API permits creation of GenericForeignKey references to objects that the user should not be able to reference affects nautobot (pip), nautobot (pip). Severity is medium. ### 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` - `DataCompliance` - `Device` - `ExportTemplate` - `GraphQLQuery` - `Note` - `ObjectMetadata` - `RelationshipAssociation` - `StaticGroupAssociation` - `VirtualMachine` Additionally, any Nautobot Apps that provide models with a REST API and use GenericForeignKey may have a similar vulnerability for their models. ### Patches A general-purpose fix has been implemented in Nautobot 2.4.33 and 3.1.2, which ensures correct application of "view" permissions when creating or modifying object references via `GenericForeignKey` throughout the REST API. Individual models/views/serializers generally will not require any specific code changes to benefit from this fix. ### Workarounds No known workarounds at this time. ### References - 2.4.33 (<a href="https://github.com/nautobot/nautobot/commit/9918bdb9bcf1eb42cda72c344f420a64ef7665f1">patch</a>) - 3.1.2 (<a href="https://github.com/nautobot/nautobot/commit/36cde7148a207234de6212ec074f321dbc9d1b5b">patch</a>)
AI coding agents often install or upgrade packages automatically in pip. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| nautobotpip | >=3.0.0a2,<3.1.2 | 3.1.2 |
| nautobotpip | <2.4.33 | 2.4.33 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard