Publish Advisories

GHSA-hg4c-rgvm-964g
GHSA-5jqp-qgf6-3pvh
GHSA-q2q7-5pp4-w6pg
GHSA-rpcg-f9q6-2mq6
GHSA-xfrw-hxr5-ghqf

Author: advisory-database[bot]

advisories/github-reviewed/2018/08/GHSA-hg4c-rgvm-964g/GHSA-hg4c-rgvm-964g.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-hg4c-rgvm-964g",
-  "modified": "2024-10-21T20:20:55Z",
+  "modified": "2026-06-09T13:00:02Z",
   "published": "2018-08-15T20:02:53Z",
   "aliases": [
     "CVE-2016-8640"

advisories/github-reviewed/2021/05/GHSA-5jqp-qgf6-3pvh/GHSA-5jqp-qgf6-3pvh.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-5jqp-qgf6-3pvh",
-  "modified": "2024-10-21T20:16:10Z",
+  "modified": "2026-06-09T13:01:00Z",
   "published": "2021-05-13T20:23:17Z",
   "aliases": [
     "CVE-2021-29510"
   ],
   "summary": "Use of \"infinity\" as an input to datetime and date fields causes infinite loop in pydantic",
-  "details": "\nImpact\n\nPassing either 'infinity', 'inf' or float('inf') (or their negatives) to datetime or date fields causes validation to run forever with 100% CPU usage (on one CPU).\nPatches\n\nPydantic is be patched with fixes available in the following versions:\n\n    v1.8.2\n    v1.7.4\n    v1.6.2\n\nAll these versions are available on pypi, and will be available on conda-forge soon.\n\nSee the changelog for details.\nWorkarounds\n\nIf you absolutely can't upgrade, you can work around this risk using a validator to catch these values, brief demo:\n\nfrom datetime import date\nfrom pydantic import BaseModel, validator\n\nclass DemoModel(BaseModel):\n    date_of_birth: date\n\n    @validator('date_of_birth', pre=True)\n    def skip_infinite_values(cls, v):\n        try:\n            seconds = float(v)\n        except (ValueError, TypeError):\n            return v\n        else:\n            if seconds == float('inf'):\n                return date.max\n            elif seconds == float('-inf'):\n                return date.min\n            else:\n                return seconds\n\nNote: this is not an ideal solution (in particular you'll need a slightly different function for datetimes), instead of a hack like this you should upgrade pydantic.\n\nIf you are not using v1.8.x, v1.7.x or v1.6.x and are unable to upgrade to a fixed version of pydantic, please create an issue requesting a back-port, and we will endeavour to release a patch for earlier versions of pydantic.\nReferences\n\nThis was fixed in commit 7e83fdd.\n",
+  "details": "Impact\n\nPassing either 'infinity', 'inf' or float('inf') (or their negatives) to datetime or date fields causes validation to run forever with 100% CPU usage (on one CPU).\nPatches\n\nPydantic is be patched with fixes available in the following versions:\n\n    v1.8.2\n    v1.7.4\n    v1.6.2\n\nAll these versions are available on pypi, and will be available on conda-forge soon.\n\nSee the changelog for details.\nWorkarounds\n\nIf you absolutely can't upgrade, you can work around this risk using a validator to catch these values, brief demo:\n\nfrom datetime import date\nfrom pydantic import BaseModel, validator\n\nclass DemoModel(BaseModel):\n    date_of_birth: date\n\n    @validator('date_of_birth', pre=True)\n    def skip_infinite_values(cls, v):\n        try:\n            seconds = float(v)\n        except (ValueError, TypeError):\n            return v\n        else:\n            if seconds == float('inf'):\n                return date.max\n            elif seconds == float('-inf'):\n                return date.min\n            else:\n                return seconds\n\nNote: this is not an ideal solution (in particular you'll need a slightly different function for datetimes), instead of a hack like this you should upgrade pydantic.\n\nIf you are not using v1.8.x, v1.7.x or v1.6.x and are unable to upgrade to a fixed version of pydantic, please create an issue requesting a back-port, and we will endeavour to release a patch for earlier versions of pydantic.\nReferences\n\nThis was fixed in commit 7e83fdd.",
   "severity": [
     {
       "type": "CVSS_V3",
@@ -102,6 +102,10 @@
       "type": "WEB",
       "url": "https://github.com/samuelcolvin/pydantic/commit/7e83fdd2563ffac081db7ecdf1affa65ef38c468"
     },
+    {
+      "type": "PACKAGE",
+      "url": "https://github.com/pydantic/pydantic"
+    },
     {
       "type": "WEB",
       "url": "https://github.com/pypa/advisory-database/tree/main/vulns/pydantic/PYSEC-2021-47.yaml"

advisories/github-reviewed/2021/06/GHSA-q2q7-5pp4-w6pg/GHSA-q2q7-5pp4-w6pg.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-q2q7-5pp4-w6pg",
-  "modified": "2024-11-18T22:43:15Z",
+  "modified": "2026-06-09T13:01:45Z",
   "published": "2021-06-01T21:19:32Z",
   "aliases": [
     "CVE-2021-33503"
   ],
   "summary": "Catastrophic backtracking in URL authority parser when passed URL containing many @ characters",
-  "details": "### Impact\n\nWhen provided with a URL containing many `@` characters in the authority component the authority regular expression exhibits catastrophic backtracking causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.\n\n\n### Patches\n\nThe issue has been fixed in urllib3 v1.26.5.\n\n### References\n\n- [CVE-2021-33503](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33503)\n- [JVNVU#92413403 (English)](https://jvn.jp/en/vu/JVNVU92413403/)\n- [JVNVU#92413403 (Japanese)](https://jvn.jp/vu/JVNVU92413403/)\n- [urllib3 v1.26.5](https://github.com/urllib3/urllib3/releases/tag/1.26.5)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Ask in our [community Discord](https://discord.gg/urllib3)\n* Email [sethmichaellarson@gmail.com](mailto:sethmichaellarson@gmail.com)\n",
+  "details": "### Impact\n\nWhen provided with a URL containing many `@` characters in the authority component the authority regular expression exhibits catastrophic backtracking causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.\n\n\n### Patches\n\nThe issue has been fixed in urllib3 v1.26.5.\n\n### References\n\n- [CVE-2021-33503](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33503)\n- [JVNVU#92413403 (English)](https://jvn.jp/en/vu/JVNVU92413403/)\n- [JVNVU#92413403 (Japanese)](https://jvn.jp/vu/JVNVU92413403/)\n- [urllib3 v1.26.5](https://github.com/urllib3/urllib3/releases/tag/1.26.5)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Ask in our [community Discord](https://discord.gg/urllib3)\n* Email [sethmichaellarson@gmail.com](mailto:sethmichaellarson@gmail.com)",
   "severity": [
     {
       "type": "CVSS_V3",
@@ -56,6 +56,10 @@
       "type": "WEB",
       "url": "https://github.com/urllib3/urllib3/commit/5b047b645f5f93900d5e2fc31230848c25eb1f5f#diff-52026d639119bf1e0364836b4e8a18bd9ed3c95c6ba39b26534a5057a65e35bbR65"
     },
+    {
+      "type": "ADVISORY",
+      "url": "https://github.com/advisories/GHSA-q2q7-5pp4-w6pg"
+    },
     {
       "type": "WEB",
       "url": "https://github.com/pypa/advisory-database/tree/main/vulns/urllib3/PYSEC-2021-108.yaml"

advisories/github-reviewed/2021/06/GHSA-rpcg-f9q6-2mq6/GHSA-rpcg-f9q6-2mq6.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-rpcg-f9q6-2mq6",
-  "modified": "2024-11-19T18:30:42Z",
+  "modified": "2026-06-09T13:02:32Z",
   "published": "2021-06-08T18:45:52Z",
   "aliases": [
     "CVE-2021-32674"
   ],
   "summary": "Remote Code Execution via traversal in TAL expressions",
-  "details": "This advisory extends the previous advisory at https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36 with additional cases of TAL expression traversal vulnerabilities.\n\n### Impact\nMost Python modules are not available for using in TAL expressions that you can add through-the-web, for example in Zope Page Templates. This restriction avoids file system access, for example via the 'os' module. But some of the untrusted modules are available indirectly through Python modules that are available for direct use.\n\nBy default, you need to have the Manager role to add or edit Zope Page Templates through the web. Only sites that allow untrusted users to add/edit Zope Page Templates through the web are at risk.\n\n### Patches\nThe problem has been fixed in Zope 5.21 and 4.6.1.\n\n### Workarounds\nThe workaround is the same as for https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36: A site administrator can restrict adding/editing Zope Page Templates through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing Zope Page Templates through the web should be restricted to trusted users only.\n\n### References\n* [The previous advisory (GHSA-5pr9-v234-jw36)](https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in the [Zope issue tracker](https://github.com/zopefoundation/Zope/issues)\n* Email us at [security@plone.org](mailto:security@plone.org)\n",
+  "details": "This advisory extends the previous advisory at https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36 with additional cases of TAL expression traversal vulnerabilities.\n\n### Impact\nMost Python modules are not available for using in TAL expressions that you can add through-the-web, for example in Zope Page Templates. This restriction avoids file system access, for example via the 'os' module. But some of the untrusted modules are available indirectly through Python modules that are available for direct use.\n\nBy default, you need to have the Manager role to add or edit Zope Page Templates through the web. Only sites that allow untrusted users to add/edit Zope Page Templates through the web are at risk.\n\n### Patches\nThe problem has been fixed in Zope 5.21 and 4.6.1.\n\n### Workarounds\nThe workaround is the same as for https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36: A site administrator can restrict adding/editing Zope Page Templates through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing Zope Page Templates through the web should be restricted to trusted users only.\n\n### References\n* [The previous advisory (GHSA-5pr9-v234-jw36)](https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in the [Zope issue tracker](https://github.com/zopefoundation/Zope/issues)\n* Email us at [security@plone.org](mailto:security@plone.org)",
   "severity": [
     {
       "type": "CVSS_V3",
@@ -75,6 +75,10 @@
       "type": "WEB",
       "url": "https://github.com/zopefoundation/Zope/commit/1d897910139e2c0b11984fc9b78c1da1365bec21"
     },
+    {
+      "type": "ADVISORY",
+      "url": "https://github.com/advisories/GHSA-5vq5-pg3r-9ph3"
+    },
     {
       "type": "WEB",
       "url": "https://github.com/pypa/advisory-database/tree/main/vulns/zope/PYSEC-2021-104.yaml"

advisories/github-reviewed/2021/06/GHSA-xfrw-hxr5-ghqf/GHSA-xfrw-hxr5-ghqf.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-xfrw-hxr5-ghqf",
-  "modified": "2024-11-19T16:03:13Z",
+  "modified": "2026-06-09T13:02:48Z",
   "published": "2021-06-17T20:10:42Z",
   "aliases": [
     "CVE-2021-32681"
   ],
   "summary": "Cross-site Scripting in wagtail",
-  "details": "### Impact\nWhen the `{% include_block %}` template tag is used to output the value of a plain-text StreamField block (`CharBlock`, `TextBlock` or a similar user-defined block derived from `FieldBlock`), and that block does not specify a template for rendering, the tag output is not properly escaped as HTML. This could allow users to insert arbitrary HTML or scripting. This vulnerability is only exploitable by users with the ability to author StreamField content (i.e. users with 'editor' access to the Wagtail admin).\n\n### Patches\nPatched versions have been released as Wagtail 2.11.8 (for the LTS 2.11 branch), Wagtail 2.12.5, and Wagtail 2.13.2 (for the current 2.13 branch).\n\nSite implementors who wish to retain the existing behaviour of allowing editors to insert HTML content in these blocks (and are willing to accept the risk of untrusted editors inserting arbitrary code) may disable the escaping by surrounding the relevant `{% include_block %}` tag in `{% autoescape off %}...{% endautoescape %}`.\n\n### Workarounds\nSite implementors who are unable to upgrade to a current supported version should audit their use of `{% include_block %}` to ensure it is not used to output `CharBlock` / `TextBlock` values with no associated template. Note that this only applies where `{% include_block %}` is used directly on that block (uses of `include_block` on a block _containing_ a CharBlock / TextBlock, such as a StructBlock, are unaffected). In these cases, the tag can be replaced with Django's `{{ ... }}` syntax - e.g. `{% include_block my_title_block %}` becomes `{{ my_title_block }}`.\n\n### Acknowledgements\nMany thanks to Karen Tracey 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.io (if you wish to send encrypted email, the public key ID is `0x6ba1e1a86e0f8ce8`)\n",
+  "details": "### Impact\nWhen the `{% include_block %}` template tag is used to output the value of a plain-text StreamField block (`CharBlock`, `TextBlock` or a similar user-defined block derived from `FieldBlock`), and that block does not specify a template for rendering, the tag output is not properly escaped as HTML. This could allow users to insert arbitrary HTML or scripting. This vulnerability is only exploitable by users with the ability to author StreamField content (i.e. users with 'editor' access to the Wagtail admin).\n\n### Patches\nPatched versions have been released as Wagtail 2.11.8 (for the LTS 2.11 branch), Wagtail 2.12.5, and Wagtail 2.13.2 (for the current 2.13 branch).\n\nSite implementors who wish to retain the existing behaviour of allowing editors to insert HTML content in these blocks (and are willing to accept the risk of untrusted editors inserting arbitrary code) may disable the escaping by surrounding the relevant `{% include_block %}` tag in `{% autoescape off %}...{% endautoescape %}`.\n\n### Workarounds\nSite implementors who are unable to upgrade to a current supported version should audit their use of `{% include_block %}` to ensure it is not used to output `CharBlock` / `TextBlock` values with no associated template. Note that this only applies where `{% include_block %}` is used directly on that block (uses of `include_block` on a block _containing_ a CharBlock / TextBlock, such as a StructBlock, are unaffected). In these cases, the tag can be replaced with Django's `{{ ... }}` syntax - e.g. `{% include_block my_title_block %}` becomes `{{ my_title_block }}`.\n\n### Acknowledgements\nMany thanks to Karen Tracey 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.io (if you wish to send encrypted email, the public key ID is `0x6ba1e1a86e0f8ce8`)",
   "severity": [
     {
       "type": "CVSS_V3",