Publish Advisories

GHSA-qcx9-j53g-ccgf
GHSA-59hw-j9g6-mfg3
GHSA-xq59-7jf3-rjc6
GHSA-vf5m-xrhm-v999
GHSA-h24r-m9qc-pvpg
GHSA-jmp3-39vp-fwg8
GHSA-q3m2-crgq-5p3q

Author: advisory-database[bot]

advisories/github-reviewed/2021/08/GHSA-qcx9-j53g-ccgf/GHSA-qcx9-j53g-ccgf.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-qcx9-j53g-ccgf",
-  "modified": "2024-09-03T21:13:35Z",
+  "modified": "2026-06-09T13:03:00Z",
   "published": "2021-08-05T17:01:30Z",
   "aliases": [
     "CVE-2021-32807"
   ],
   "summary": "Remote Code Execution via unsafe classes in otherwise permitted modules",
-  "details": "### Impact\nThe module `AccessControl` defines security policies for Python code used in restricted code within Zope applications. Restricted code is any code that resides in Zope's object database, such as the contents of `Script (Python)` objects. \n\nThe policies defined in `AccessControl` severely restrict access to Python modules and only exempt a few that are deemed safe, such as Python's `string` module. However, full access to the `string` module also allows access to the class `Formatter`, which can be overridden and extended within `Script (Python)` in a way that provides access to other unsafe Python libraries. Those unsafe Python libraries can be used for remote code execution.\n\nBy default, you need to have the admin-level Zope \"Manager\" role to add or edit `Script (Python)` objects through the web. Only sites that allow untrusted users to add/edit these scripts through the web - which would be a very unusual configuration to begin with - are at risk.\n\n### Patches\nThe problem has been fixed in AccessControl 4.3 and 5.2.\nOnly AccessControl versions 4 and 5 are vulnerable, and only on Python 3, not Python 2.7.\n\n### Workarounds\nA site administrator can restrict adding/editing `Script (Python)` objects through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing these scripts through the web should be restricted to trusted users only. This is the default configuration in Zope.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in the [AccessControl issue tracker](https://github.com/zopefoundation/AccessControl/issues)\n* Email us at [security@plone.org](mailto:security@plone.org)\n",
+  "details": "### Impact\nThe module `AccessControl` defines security policies for Python code used in restricted code within Zope applications. Restricted code is any code that resides in Zope's object database, such as the contents of `Script (Python)` objects. \n\nThe policies defined in `AccessControl` severely restrict access to Python modules and only exempt a few that are deemed safe, such as Python's `string` module. However, full access to the `string` module also allows access to the class `Formatter`, which can be overridden and extended within `Script (Python)` in a way that provides access to other unsafe Python libraries. Those unsafe Python libraries can be used for remote code execution.\n\nBy default, you need to have the admin-level Zope \"Manager\" role to add or edit `Script (Python)` objects through the web. Only sites that allow untrusted users to add/edit these scripts through the web - which would be a very unusual configuration to begin with - are at risk.\n\n### Patches\nThe problem has been fixed in AccessControl 4.3 and 5.2.\nOnly AccessControl versions 4 and 5 are vulnerable, and only on Python 3, not Python 2.7.\n\n### Workarounds\nA site administrator can restrict adding/editing `Script (Python)` objects through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing these scripts through the web should be restricted to trusted users only. This is the default configuration in Zope.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in the [AccessControl issue tracker](https://github.com/zopefoundation/AccessControl/issues)\n* Email us at [security@plone.org](mailto:security@plone.org)",
   "severity": [
     {
       "type": "CVSS_V3",
@@ -56,6 +56,44 @@
           ]
         }
       ]
+    },
+    {
+      "package": {
+        "ecosystem": "PyPI",
+        "name": "zope"
+      },
+      "ranges": [
+        {
+          "type": "ECOSYSTEM",
+          "events": [
+            {
+              "introduced": "4.0"
+            },
+            {
+              "fixed": "4.3"
+            }
+          ]
+        }
+      ]
+    },
+    {
+      "package": {
+        "ecosystem": "PyPI",
+        "name": "zope"
+      },
+      "ranges": [
+        {
+          "type": "ECOSYSTEM",
+          "events": [
+            {
+              "introduced": "5.0"
+            },
+            {
+              "fixed": "5.2"
+            }
+          ]
+        }
+      ]
     }
   ],
   "references": [
@@ -99,6 +137,10 @@
       "type": "WEB",
       "url": "https://github.com/pypa/advisory-database/tree/main/vulns/zope/PYSEC-2021-368.yaml"
     },
+    {
+      "type": "WEB",
+      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/zope/PYSEC-2021-875.yaml"
+    },
     {
       "type": "PACKAGE",
       "url": "https://github.com/zopefoundation/AccessControl"

advisories/github-reviewed/2023/05/GHSA-59hw-j9g6-mfg3/GHSA-59hw-j9g6-mfg3.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-59hw-j9g6-mfg3",
-  "modified": "2025-02-13T18:54:26Z",
+  "modified": "2026-06-09T13:04:11Z",
   "published": "2023-05-02T09:30:17Z",
   "aliases": [
     "CVE-2023-32007"

advisories/github-reviewed/2023/11/GHSA-xq59-7jf3-rjc6/GHSA-xq59-7jf3-rjc6.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-xq59-7jf3-rjc6",
-  "modified": "2024-10-09T20:49:23Z",
+  "modified": "2026-06-09T13:04:23Z",
   "published": "2023-11-12T15:57:28Z",
   "aliases": [
     "CVE-2023-47128"

advisories/github-reviewed/2023/12/GHSA-vf5m-xrhm-v999/GHSA-vf5m-xrhm-v999.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-vf5m-xrhm-v999",
-  "modified": "2024-11-22T18:15:15Z",
+  "modified": "2026-06-09T13:05:09Z",
   "published": "2023-12-22T19:51:53Z",
   "aliases": [
     "CVE-2023-51649"
   ],
   "summary": "Nautobot missing object-level permissions enforcement when running Job Buttons",
-  "details": "### Impact\n\nWhen 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.\n\n> 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.\n\nAdditionally, 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.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nFix 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)\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nPartial mitigation can be achieved by auditing `JobButtonReceiver` subclasses defined in the system and restricting which users are permitted to create or edit JobButton records. \n\n### References\n\n- https://github.com/nautobot/nautobot/issues/4988\n- https://github.com/nautobot/nautobot/pull/4993\n- https://github.com/nautobot/nautobot/pull/4995\n",
+  "details": "### Impact\n\nWhen 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.\n\n> 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.\n\nAdditionally, 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.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nFix 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)\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nPartial mitigation can be achieved by auditing `JobButtonReceiver` subclasses defined in the system and restricting which users are permitted to create or edit JobButton records. \n\n### References\n\n- https://github.com/nautobot/nautobot/issues/4988\n- https://github.com/nautobot/nautobot/pull/4993\n- https://github.com/nautobot/nautobot/pull/4995",
   "severity": [
     {
       "type": "CVSS_V3",

advisories/github-reviewed/2024/02/GHSA-h24r-m9qc-pvpg/GHSA-h24r-m9qc-pvpg.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-h24r-m9qc-pvpg",
-  "modified": "2025-11-04T22:12:32Z",
+  "modified": "2026-06-09T13:05:25Z",
   "published": "2024-02-06T12:30:31Z",
   "aliases": [
     "CVE-2024-0690"

advisories/github-reviewed/2024/07/GHSA-jmp3-39vp-fwg8/GHSA-jmp3-39vp-fwg8.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-jmp3-39vp-fwg8",
-  "modified": "2024-11-18T16:26:51Z",
+  "modified": "2026-06-09T13:05:34Z",
   "published": "2024-07-11T13:21:42Z",
   "aliases": [
     "CVE-2024-39317"
   ],
   "summary": "Wagtail regular expression denial-of-service via search query parsing",
-  "details": "### Impact\n\nA bug in Wagtail's [`parse_query_string`](https://docs.wagtail.org/en/stable/topics/search/searching.html#wagtailsearch-query-string-parsing) would result in it taking a long time to process suitably crafted inputs. When used to parse sufficiently long strings of characters without a space, `parse_query_string` would take an unexpectedly large amount of time to process, resulting in a denial of service.\n\nIn an initial Wagtail installation, the vulnerability can be exploited by any Wagtail admin user. It cannot be exploited by end users. If your Wagtail site has a custom search implementation which uses `parse_query_string`, it may be exploitable by other users (e.g. unauthenticated users).\n\n### Patches\n\nPatched versions have been released as Wagtail 5.2.6, 6.0.6 and 6.1.3.\n\nThis vulnerability affects all unpatched versions from Wagtail 2.0 onwards.\n\n### Workarounds\n\nSite owners who are unable to upgrade to a patched version can limit the length of search terms passed to `parse_query_string`. Whilst the performance characteristics will depend on your hosting environment, 1000 characters has been shown to still be fairly fast, without triggering this vulnerability.\n\nNo workaround is available for the Wagtail admin usage.\n\n### Acknowledgements\n\nMany thanks to [Jake Howard](https://github.com/RealOrangeOne) for reporting this issue.\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n* Visit Wagtail's [support channels](https://docs.wagtail.io/en/stable/support.html)\n* Email us at [security@wagtail.org](mailto:security@wagtail.org) (view our [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).\n",
+  "details": "### Impact\n\nA bug in Wagtail's [`parse_query_string`](https://docs.wagtail.org/en/stable/topics/search/searching.html#wagtailsearch-query-string-parsing) would result in it taking a long time to process suitably crafted inputs. When used to parse sufficiently long strings of characters without a space, `parse_query_string` would take an unexpectedly large amount of time to process, resulting in a denial of service.\n\nIn an initial Wagtail installation, the vulnerability can be exploited by any Wagtail admin user. It cannot be exploited by end users. If your Wagtail site has a custom search implementation which uses `parse_query_string`, it may be exploitable by other users (e.g. unauthenticated users).\n\n### Patches\n\nPatched versions have been released as Wagtail 5.2.6, 6.0.6 and 6.1.3.\n\nThis vulnerability affects all unpatched versions from Wagtail 2.0 onwards.\n\n### Workarounds\n\nSite owners who are unable to upgrade to a patched version can limit the length of search terms passed to `parse_query_string`. Whilst the performance characteristics will depend on your hosting environment, 1000 characters has been shown to still be fairly fast, without triggering this vulnerability.\n\nNo workaround is available for the Wagtail admin usage.\n\n### Acknowledgements\n\nMany thanks to [Jake Howard](https://github.com/RealOrangeOne) for reporting this issue.\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n* Visit Wagtail's [support channels](https://docs.wagtail.io/en/stable/support.html)\n* Email us at [security@wagtail.org](mailto:security@wagtail.org) (view our [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).",
   "severity": [
     {
       "type": "CVSS_V3",

advisories/github-reviewed/2025/05/GHSA-q3m2-crgq-5p3q/GHSA-q3m2-crgq-5p3q.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-q3m2-crgq-5p3q",
-  "modified": "2025-05-08T22:07:14Z",
+  "modified": "2026-06-09T13:05:48Z",
   "published": "2025-05-08T18:30:42Z",
   "aliases": [
     "CVE-2025-44021"