### Impact When submitting a Job to run via a Job Button, only the model-level `extras.run_job` 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.run_job` permission and `extras.run_jobbutton` permission must be granted to a user in order to run Jobs via JobButton, the `extras.run_jobbutton` permission is not actually enforced by the view code, only by the UI by disabling the button from being clicked normally. Furthermore, the `extras.run_jobbutton` permission never prevented invoking Jobs (including `JobButtonReceiver` subclasses) via the normal "Job Run" UI, so after some discussion, we've decided that the `extras.run_jobbutton` permission is redundant, and as it never achieved its stated/documented purpose, the fixes below will remove the UI check for `extras.run_jobbutton` and all other references to the `extras.run_jobbutton` permission, rather than adding enforcement of this previously unenforced permission. ### Patches _Has the problem been patched? What versions should users upgrade to?_ Fix will be available in Nautobot 1.6.8 (https://github.com/nautobot/nautobot/pull/4995) and 2.1.0 (https://github.com/nautobot/nautobot/pull/4993) ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ Partial mitigation can be achieved by auditing `JobButtonReceiver` subclasses defined in the system and restricting which users are permitted to create or edit JobButton records. ### References - https://github.com/nautobot/nautobot/issues/4988 - https://github.com/nautobot/nautobot/pull/4993 - https://github.com/nautobot/nautobot/pull/4995
### Impact When submitting a Job to run via a Job Button, only the model-level `extras.run_job` 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.run_job` permission and `extras.run_jobbutton` permission must be granted to a user in order to run Jobs via JobButton, the `extras.run_jobbutton` permission is not actually enforced by the view code, only by the UI by disabling the button from being clicked normally. Furthermore, the `extras.run_jobbutton` permission never prevented invoking Jobs (including `JobButtonReceiver` subclasses) via the normal "Job Run" UI, so after some discussion, we've decided that the `extras.run_jobbutton` permission is redundant, and as it never achieved its stated/documented purpose, the fixes below will remove the UI check for `extras.run_jobbutton` and all other references to the `extras.run_jobbutton` permission, rather than adding enforcement of this previously unenforced permission. ### Patches _Has the problem been patched? What versions should users upgrade to?_ Fix will be available in Nautobot 1.6.8 (https://github.com/nautobot/nautobot/pull/4995) and 2.1.0 (https://github.com/nautobot/nautobot/pull/4993) ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ Partial mitigation can be achieved by auditing `JobButtonReceiver` subclasses defined in the system and restricting which users are permitted to create or edit JobButton records. ### References - https://github.com/nautobot/nautobot/issues/4988 - https://github.com/nautobot/nautobot/pull/4993 - https://github.com/nautobot/nautobot/pull/4995
Update nautobot to 1.6.8; nautobot to 2.1.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanNautobot missing object-level permissions enforcement when running Job Buttons affects nautobot (pip), nautobot (pip). Severity is low. ### Impact When submitting a Job to run via a Job Button, only the model-level `extras.run_job` 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.run_job` permission and `extras.run_jobbutton` permission must be granted to a user in order to run Jobs via JobButton, the `extras.run_jobbutton` permission is not actually enforced by the view code, only by the UI by disabling the button from being clicked normally. Furthermore, the `extras.run_jobbutton` permission never prevented invoking Jobs (including `JobButtonReceiver` subclasses) via the normal "Job Run" UI, so after some discussion, we've decided that the `extras.run_jobbutton` permission is redundant, and as it never achieved its stated/documented purpose, the fixes below will remove the UI check for `extras.run_jobbutton` and all other references to the `extras.run_jobbutton` permission, rather than adding enforcement of this previously unenforced permission. ### Patches _Has the problem been patched? What versions should users upgrade to?_ Fix will be available in Nautobot 1.6.8 (https://github.com/nautobot/nautobot/pull/4995) and 2.1.0 (https://github.com/nautobot/nautobot/pull/4993) ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ Partial mitigation can be achieved by auditing `JobButtonReceiver` subclasses defined in the system and restricting which users are permitted to create or edit JobButton records. ### References - https://github.com/nautobot/nautobot/issues/4988 - https://github.com/nautobot/nautobot/pull/4993 - https://github.com/nautobot/nautobot/pull/4995
AI coding agents often install or upgrade packages automatically in pip. A low 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 | >=1.5.14,<1.6.8 | 1.6.8 |
| nautobotpip | >=2.0.0,<2.1.0 | 2.1.0 |
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 1.6.8; nautobot to 2.1.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanNautobot missing object-level permissions enforcement when running Job Buttons affects nautobot (pip), nautobot (pip). Severity is low. ### Impact When submitting a Job to run via a Job Button, only the model-level `extras.run_job` 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.run_job` permission and `extras.run_jobbutton` permission must be granted to a user in order to run Jobs via JobButton, the `extras.run_jobbutton` permission is not actually enforced by the view code, only by the UI by disabling the button from being clicked normally. Furthermore, the `extras.run_jobbutton` permission never prevented invoking Jobs (including `JobButtonReceiver` subclasses) via the normal "Job Run" UI, so after some discussion, we've decided that the `extras.run_jobbutton` permission is redundant, and as it never achieved its stated/documented purpose, the fixes below will remove the UI check for `extras.run_jobbutton` and all other references to the `extras.run_jobbutton` permission, rather than adding enforcement of this previously unenforced permission. ### Patches _Has the problem been patched? What versions should users upgrade to?_ Fix will be available in Nautobot 1.6.8 (https://github.com/nautobot/nautobot/pull/4995) and 2.1.0 (https://github.com/nautobot/nautobot/pull/4993) ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ Partial mitigation can be achieved by auditing `JobButtonReceiver` subclasses defined in the system and restricting which users are permitted to create or edit JobButton records. ### References - https://github.com/nautobot/nautobot/issues/4988 - https://github.com/nautobot/nautobot/pull/4993 - https://github.com/nautobot/nautobot/pull/4995
AI coding agents often install or upgrade packages automatically in pip. A low 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 | >=1.5.14,<1.6.8 | 1.6.8 |
| nautobotpip | >=2.0.0,<2.1.0 | 2.1.0 |
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