CWE-212

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openbao/openbao"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260420173541-6d2e0506e2b4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42186"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T20:02:52Z",
    "nvd_published_at": "2026-05-14T15:16:46Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nWhen OpenBao\u0027s initial namespace deletion fails, subsequent retries fail to properly remove all data before marking the namespace as deleted. This can affect any outstanding leases as well as potentially leaving unrelated storage entries around. \n\n### Patches\n\nThis will be patched in OpenBao v2.5.3.\n\n### Workarounds\n\nUsers may manually remove mounts prior to deleting the namespace. \n\nAudit logs may be used to identify repeated deletion attempts against the same namespace; `sys/raw` can be used to see what leases were not correctly deleted.",
  "id": "GHSA-vv66-6rp4-wr4f",
  "modified": "2026-05-14T20:49:19Z",
  "published": "2026-05-05T20:02:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/security/advisories/GHSA-vv66-6rp4-wr4f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42186"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/commit/6d2e0506e2b41be0eaa6643bf7b4efc9a2c09445"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openbao/openbao"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openbao/openbao/releases/tag/v2.5.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenBao\u0027s Namespace Deletion May Not Delete Data Properly"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "guzzlehttp/guzzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "6.5.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "guzzlehttp/guzzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31043"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-212",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-09T23:47:23Z",
    "nvd_published_at": "2022-06-10T00:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n`Authorization` headers on requests are sensitive information. On making a request using the `https` scheme to a server which responds with a redirect to a URI with the `http` scheme, we should not forward the `Authorization` header on. This is much the same as to how we don\u0027t forward on the header if the host changes. Prior to this fix, `https` to `http` downgrades did not result in the `Authorization` header being removed, only changes to the host.\n\n### Patches\n\nAffected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4.\n\n### Workarounds\n\nAn alternative approach would be to use your own redirect middleware, rather than ours, if you are unable to upgrade. If you do not require or expect redirects to be followed, one should simply disable redirects all together.\n\n### References\n\n* [RFC9110 Section 15.4](https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx)\n\n### For more information\n\nIf you have any questions or comments about this advisory, please get in touch with us in `#guzzle` on the [PHP HTTP Slack](https://php-http.slack.com/). Do not report additional security advisories in that public channel, however - please follow our [vulnerability reporting process](https://github.com/guzzle/guzzle/security/policy).\n",
  "id": "GHSA-w248-ffj2-4v5q",
  "modified": "2022-06-20T21:59:37Z",
  "published": "2022-06-09T23:47:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-w248-ffj2-4v5q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31043"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guzzle/guzzle/commit/e3ff079b22820c2029d4c2a87796b6a0b8716ad8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/guzzlehttp/guzzle/CVE-2022-31043.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/guzzle/guzzle"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2022/dsa-5246"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-core-2022-011"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fix failure to strip Authorization header on HTTP downgrade"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "contao/core-bundle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-RC1"
            },
            {
              "fixed": "5.3.38"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "contao/core-bundle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.4.0-RC1"
            },
            {
              "fixed": "5.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "contao/contao"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-RC1"
            },
            {
              "fixed": "5.3.38"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "contao/contao"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.4.0-RC1"
            },
            {
              "fixed": "5.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-57757"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-212"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-28T14:58:00Z",
    "nvd_published_at": "2025-08-28T17:15:36Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nIf a news feed contains protected news archives, their news items are not filtered and become publicly available in the RSS feed.\n\n### Patches\n\nUpdate to Contao 5.3.38 or 5.6.1.\n\n### Workarounds\n\nDo not add protected news archives to the news feed page.\n\n### For more information\n\nIf you have any questions or comments about this advisory, open an issue in [contao/contao](https://github.com/contao/contao/issues/new/choose).",
  "id": "GHSA-w53m-gxvg-vx7p",
  "modified": "2025-08-28T18:51:43Z",
  "published": "2025-08-28T14:58:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/contao/contao/security/advisories/GHSA-w53m-gxvg-vx7p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57757"
    },
    {
      "type": "WEB",
      "url": "https://github.com/contao/contao/commit/e75f46b11974fbf7a4652e65c19ad6ca84c59271"
    },
    {
      "type": "WEB",
      "url": "https://contao.org/en/security-advisories/information-disclosure-in-the-news-module"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/contao/contao"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Contao can disclose sensitive information in the news module"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "cbor2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "5.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68131"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-31T22:01:38Z",
    "nvd_published_at": "2025-12-31T02:15:42Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nWhen a CBORDecoder instance is reused across multiple decode operations, values marked with the shareable tag (28) persist in memory and can be accessed by subsequent CBOR messages using the sharedref tag (29). This allows an attacker-controlled message to read data from previously decoded messages if the decoder is reused across trust boundaries.\n\n### Details\nThe issue is in the decoder\u0027s handling of the shareables list, which stores values tagged with CBOR tag 28 (shareable) for later reference by tag 29 (sharedref).\n\nWhen decode_from_bytes() is called or when .fp is set to a new stream, the shareables list is not cleared. This allows references to persist across separate decode operations.\n\nThe issue exists in both the C extension and the pure Python decoder.\n\nIn the C extension (source/decoder.c), the _CBORDecoder_set_fp function (line ~202) updates the file pointer but does not reset the shareables state:\n\n```\n  static int\n  _CBORDecoder_set_fp(CBORDecoderObject *self, PyObject *value, void *closure)\n  {\n      // ... validation ...\n      tmp = self-\u003eread;\n      self-\u003eread = read;\n      Py_DECREF(tmp);\n      return 0;\n      // Missing: PyList_Clear(self-\u003eshareables) or equivalent\n  }\n```\n\nIn the pure Python decoder (cbor2/_decoder.py), the fp setter similarly fails to clear self._shareables.\n\nSimilarly, decode_from_bytes() in both implementations saves and restores the read pointer but does not clear the shareables list between decodes.\n\nThe shareable/sharedref tags are defined in the CBOR value sharing extension (http://cbor.schmorp.de/value-sharing) with scope limited to a single CBOR data item, not across separate messages.\n\n### PoC\n\n```\nimport cbor2\nfrom io import BytesIO\n\n# Message from trusted source containing a shareable value\nmsg1 = cbor2.dumps(cbor2.CBORTag(28, \"secret\"))\n\n# Attacker-controlled message referencing index 0\nmsg2 = cbor2.dumps(cbor2.CBORTag(29, 0))\n\n# Decoder reused across trust boundaries\ndecoder = cbor2.CBORDecoder(BytesIO(b\u0027\u0027))\ndecoder.decode_from_bytes(msg1)\nprint(decoder.decode_from_bytes(msg2))  # prints \"secret\"\n```\nNo special configuration required. Affects any application that reuses a CBORDecoder instance to decode messages from different sources.\n\n### Impact\nInformation disclosure. Applications that reuse a CBORDecoder across trust boundaries are vulnerable if the trusted messages use value sharing (tag 28) and an attacker can send messages containing shared references (tag 29). An attacker who can send a crafted CBOR message containing a sharedref tag can read values from previously decoded messages, potentially exposing sensitive data such as credentials, tokens, or private user data.\n\n### Related\nA similar issue in the encoder could produce invalid CBOR with dangling shared references:\n\n```\nimport cbor2\nfrom io import BytesIO\n\n# Create encoder with value sharing enabled\nencoder = cbor2.CBOREncoder(BytesIO(), value_sharing=True)\n\n# Persistent object that will be encoded multiple times\nshared_obj = [\u0027hello\u0027]\n\n# First encode: array containing shared_obj twice\nencoder.encode([shared_obj, shared_obj])\nprint(f\u0027First encode: {encoder.fp.getvalue().hex()}\u0027)\n# Output: d81c82d81c816568656c6c6fd81d01\n\n# Second encode: just shared_obj\nencoder.fp = BytesIO()\nencoder.encode(shared_obj)\nresult = encoder.fp.getvalue()\nprint(f\u0027Second encode: {result.hex()}\u0027)\n# Output: d81d01  (just a shared reference to index 1!)\n\n# Try to decode the second result as standalone CBOR\ndecoder = cbor2.CBORDecoder(BytesIO(result))\ndecoded = decoder.decode()\n# FAILS: shared reference 1 not found\n```\n\nWhile primarily a correctness bug, it could cause denial of service if invalid CBOR is transmitted to downstream systems that fail to parse it, or cause silent data corruption if the dangling reference happens to resolve to an unrelated value.\n\nIt can also be considered a memory leak in both the decoder and encoder as references are held that will never be released as long as the decoder/encoder remains alive.\n\n### Suggested resolution\n\nAdd dedicated boolean flags to track when an encode/decode operation is in progress. Reset shared state only when the flag is False (top-level call). This ensures state is reset for standalone calls while preserving shared references for nested calls from hooks (which need access to the registry for cyclic structures).\n\nDecoder (_decoding flag):\n - decode(): set flag True, reset state, decode, set flag False\n - decode_from_bytes(): reset state only when flag is False\n\nEncoder (_encoding flag):\n - encode(): set flag True, reset state, encode, set flag False\n - encode_to_bytes(): reset state only when flag is False",
  "id": "GHSA-wcj4-jw5j-44wh",
  "modified": "2026-06-05T14:17:47Z",
  "published": "2025-12-31T22:01:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/agronholm/cbor2/security/advisories/GHSA-wcj4-jw5j-44wh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68131"
    },
    {
      "type": "WEB",
      "url": "https://github.com/agronholm/cbor2/pull/268"
    },
    {
      "type": "WEB",
      "url": "https://github.com/agronholm/cbor2/commit/f1d701cd2c411ee40bb1fe383afe7f365f35abf0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/agronholm/cbor2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/cbor2/PYSEC-2025-90.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CBORDecoder reuse can leak shareable values across decode calls"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-20928"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-14T18:16:42Z",
    "severity": "MODERATE"
  },
  "details": "Improper removal of sensitive information before storage or transfer in Windows Recovery Environment Agent allows an unauthorized attacker to bypass a security feature with a physical attack.",
  "id": "GHSA-wfg3-6grc-fqv3",
  "modified": "2026-04-14T18:30:36Z",
  "published": "2026-04-14T18:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20928"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20928"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "wasmtime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-39393"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212",
      "CWE-226"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-10T21:16:22Z",
    "nvd_published_at": "2022-11-10T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThere is a bug in Wasmtime\u0027s implementation of it\u0027s pooling instance allocator where when a linear memory is reused for another instance the initial heap snapshot of the prior instance can be visible, erroneously to the next instance. The pooling instance allocator in Wasmtime works by preallocating virtual memory for a fixed number of instances to reside in and then new instantiations pick a slot to use. Most conventional modules additionally have an initial copy-on-write \"heap image\" which is mapped in Wasmtime into the linear memory slot. When a heap slot is deallocated Wasmtime resets all of its contents back to the initial state but it does not unmap the image in case the next instance is an instantiation of the same module.\n\nThe bug in Wasmtime occurs when a slot in the pooling allocator previously was used for a module with a heap image, meaning that its current state of memory contains the initial heap contents of that module. If the next instantiation within that slot does not itself contain a heap image then Wasmtime would leave the old heap image in place erroneously and continue with instantiation. This means that instantiations of modules without a heap image can see the initial heap image of the prior instantiation within that slot.\n\nHeap images in Wasmtime are created by precomputing WebAssembly `data` segments into one large mapping to be placed into linear memory at a particular offset. Most modules produced by toolchains today will have a heap image and an initialization snapshot. Creating a module without a heap image would require a hand-crafted `*.wat` file or a specially crafted source program. This consequence means that this bug is highly unlikely to be accidentally triggered and would otherwise require an intentional trigger with a hand-crafted module.\n\nOne important part of this vulnerability is Wasmtime is highly likely to segfault when the slot is reused again with a module that itself has an initialization image. For example if module A has a heap initialization image and module B does not have a heap initialization image, then the following sequence of events could happen if they all are instantiated into the same instance slot:\n\n* Module A is instantiated, and then deallocated. This leaves A\u0027s heap image in place, reset to its initial contents.\n* Module B is instantiated and erroneously can see the initial heap contents of A. Module B is then deallocated and the entire heap is unmapped and reset back to zero.\n* Module A is instantiated again, but the state tracking the slot did not account for module B so it thinks the module image is still mapped and proceeds with instantiation. Any action on A\u0027s part to access linear memory will then trap and if the host accesses A\u0027s memory it will segfault because the data that\u0027s supposed to be mapped is all unmapped.\n\nAdding this all together this means that in practice modules must be deliberately crafted to not have an initial heap image to view the contents of a prior image. If this module is instantiated though then when the slot is reused the next, likely image-using, module will believe its memory is mapped when it isn\u0027t, causing the host to segfault on unmapped memory it believed was mapped. \n\n### Patches\n\nThis bug has been patched and users should upgrade to Wasmtime 2.0.2.\n\n### Workarounds\n\nTrigging this bug requires the pooling allocator to be configured and for copy-on-write heap images to also be enabled. Pooling allocation is not enabled by default but copy-on-write heap images are. Mitigations for this bug include:\n\n* Disabling the pooling allocator - note that pooling allocation is not enabled by default in Wasmtime\n* Disabling the `memory-init-cow` feature or with [`Config::memory_init_cow`](https://docs.rs/wasmtime/2.0.1/wasmtime/struct.Config.html#method.memory_init_cow)\n\n### References\n\n* [`Config::allocation_strategy`](https://docs.rs/wasmtime/2.0.1/wasmtime/struct.Config.html#method.allocation_strategy) - configuration required to enable the pooling allocator.\n* [`Config::memory_init_cow`](https://docs.rs/wasmtime/2.0.1/wasmtime/struct.Config.html#method.memory_init_cow) - configuration required to enable or disable copy-on-write (this is enabled by default).\n* [Mailing list announcement](https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/c1HBDDJwNPA)\n* [Patch for `release-2.0.0` branch](https://github.com/bytecodealliance/wasmtime/commit/2614f2e9d2d36805ead8a8da0fa0c6e0d9e428a0)\n* [Patch for `main`](https://github.com/bytecodealliance/wasmtime/commit/3535acbf3be032ef1ba0b469b8ab92538a8a18a6)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)\n* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)",
  "id": "GHSA-wh6w-3828-g9qf",
  "modified": "2025-05-02T12:51:03Z",
  "published": "2022-11-10T21:16:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-wh6w-3828-g9qf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39393"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/commit/2614f2e9d2d36805ead8a8da0fa0c6e0d9e428a0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bytecodealliance/wasmtime/commit/3535acbf3be032ef1ba0b469b8ab92538a8a18a6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bytecodealliance/wasmtime"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/a/bytecodealliance.org/g/sec-announce/c/c1HBDDJwNPA"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2022-0075.html"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2022-0098.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Wasmtime may have data leakage between instances in the pooling allocator"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.2.6.1"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0.0"
            },
            {
              "fixed": "5.2.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.4.5"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0.0"
            },
            {
              "fixed": "6.0.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.1.4.5"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.1.0.0"
            },
            {
              "fixed": "6.1.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 7.0.2.1"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0.0"
            },
            {
              "fixed": "7.0.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-23633"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-212"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-02-11T20:49:14Z",
    "nvd_published_at": "2022-02-11T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nUnder certain circumstances response bodies will not be closed, for example a [bug in a webserver](https://github.com/puma/puma/pull/2812) or a bug in a Rack middleware.  In the event a response is *not* notified of a `close`, `ActionDispatch::Executor` will not know to reset thread local state for the next request.  This can lead to data being leaked to subsequent requests, especially when interacting with `ActiveSupport::CurrentAttributes`.\n\nUpgrading to the FIXED versions of Rails will ensure mitigation of this issue even in the context of a buggy webserver or middleware implementation.\n\n### Patches\n\nThis has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.\n\n### Workarounds\n\nUpgrading is highly recommended, but to work around this problem the following middleware can be used:\n\n```ruby\nclass GuardedExecutor \u003c ActionDispatch::Executor\n  def call(env)\n    ensure_completed!\n    super\n  end\n\n  private\n\n    def ensure_completed!\n      @executor.new.complete! if @executor.active?\n    end\nend\n\n# Ensure the guard is inserted before ActionDispatch::Executor\nRails.application.configure do\n  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor\nend\n```",
  "id": "GHSA-wh98-p28r-vrc9",
  "modified": "2022-02-24T13:15:43Z",
  "published": "2022-02-11T20:49:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails/security/advisories/GHSA-wh98-p28r-vrc9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23633"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails/commit/f9a2ad03943d5c2ba54e1d45f155442b519c75da"
    },
    {
      "type": "WEB",
      "url": "https://discuss.rubyonrails.org/t/cve-2022-23633-possible-exposure-of-information-vulnerability-in-action-pack/80016"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rails/rails"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/actionpack/CVE-2022-23633.yml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/ruby-security-ann/c/FkTM-_7zSNA/m/K2RiMJBlBAAJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/09/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "https://rubyonrails.org/2022/2/11/Rails-7-0-2-2-6-1-4-6-6-0-4-6-and-5-2-6-2-have-been-released"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240119-0013"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2023/dsa-5372"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/02/11/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Exposure of information in Action Pack"
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-43384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-07T09:16:24Z",
    "severity": "HIGH"
  },
  "details": "A low privileged remote attacker can gain\u00a0the root password due to improper removal of sensitive information before storage or transfer.",
  "id": "GHSA-wqgp-h8fj-p489",
  "modified": "2026-05-07T09:31:26Z",
  "published": "2026-05-07T09:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43384"
    },
    {
      "type": "WEB",
      "url": "https://certvde.com/en/advisories/VDE-2024-039"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.trino:trino-iceberg"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "439"
            },
            {
              "fixed": "480"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34214"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212",
      "CWE-312"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-29T15:13:30Z",
    "nvd_published_at": "2026-03-31T15:16:18Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nIceberg connector REST catalog static credentials (access key) or vended credentials (temporary access key) are accessible to users that have write privilege on SQL level.\n\n### Details\n\nIceberg REST catalog typically needs access to object storage. This access can be configured in multiple different ways. When storage access is achieved by static credentials (e.g. AWS S3 access key) or vended credentials (temporary access key).\n\nQuery JSON is a query visualization and performance troubleshooting facility. It includes serialized query plan and handles for table writes or  execution of table procedures. A user that submitted a query has access to query JSON for their query. Query JSON is available from Trino UI or via `/ui/api/query/\u00abquery_id\u00bb` and `/v1/query/\u00abquery_id\u00bb` endpoints.\n\nThe storage credentials are stored in those handles when performing write operations, or table maintenance operations. They are serialized in query JSON. A user with write access to data in Iceberg connector configured to use REST Catalog with static or vended credentials can retrieve those credentials.\n\n### Impact\n\nAnyone using Iceberg REST catalog with static or vended credentials is impacted.\nThe credentials should be considered compromised. \nVended credentials are temporary in nature so they do not need to be rotated. However, underlying data could have been exposed.",
  "id": "GHSA-x27p-5f68-m644",
  "modified": "2026-03-31T18:51:27Z",
  "published": "2026-03-29T15:13:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/trinodb/trino/security/advisories/GHSA-x27p-5f68-m644"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34214"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/trinodb/trino"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trinodb/trino/releases/tag/480"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Trino: Iceberg REST catalog static and vended credentials are accessible via query JSON"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "GitHub Actions",
        "name": "m00nl1ght-dev/steam-workshop-deploy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "GitHub Actions",
        "name": "BoldestDungeon/steam-workshop-deploy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-212",
      "CWE-522",
      "CWE-527"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-13T23:03:26Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\nThe `steam-workshop-deploy` github action does not exclude the `.git` directory when packaging content for deployment and provides no built-in way to do so. If a `.git` folder exists in the target directory (e.g., due to a local Git repo, custom project structure, or via  the `actions/checkout` workflow), it is silently included in the output package. This results in leakage of sensitive repository metadata and potentially credentials, including github personal access tokens (PATs) embedded in `.git/config`.\n\nMany game modding projects require packaging from the project root as the game expects certain files (assets, configuration, metadata) to be present at specific root-level paths. Consequently, the `.git` directory often exists alongside these required files and gets packaged unintentionally, especially when using `actions/checkout`.\n\nWhile github hosted runners automatically revoke ephemeral credentials at the end of each job, the severity of this issue increases dramatically in other CI environments:\n\n- Self-hosted runners may store long-lived tokens or secrets.\n- Developers may maintain their own `.git` folders with embedded PATs or remotes tied to private repositories.\n- The workflow may run without the `actions/checkout` action, distributing the `.git` directory present on the running machine if it exists in the directory.\n\nA real example of an affected mod can be found here: https://github.com/BoldestDungeon/wildermyth-drauven-pcs/security/advisories/GHSA-7j9v-72w9-ww6w\n\n## Details\nWho is affected:\n- Any user of `steam-workshop-deploy` operating in an environment where `.git` exists in the packaging directory.\n- Any user of `steam-workshop-deploy` operating in an environment where the [actions/checkout](https://github.com/actions/checkout) workflow is used and then the `.git` directory is inadvertently generated within the packaging directory (greatly reduced severity due to the ephemeral nature of github actions).\n\n## Impact\nThe severity of this issue for downstream components can range from **0.0** (no credentials, sensitive metadata, or private source code were present in the packaging directory) to **10.0** (extremely sensitive, high privilige credentials or source code from private repositories were exposed).\n\nThe actual severity depends primarily on the permissions, scope, and nature of the exposed data:\n* **Low/none (0.0-3.9)**: Only non-sensitive repository metadata was exposed, no credentials were present, or only public facing code was included.\n* **Medium(4.0-6.9)**: Credentials with limited repository access and/or short lifespan (e.g., ephemeral tokens) were exposed, or non-sensitive private code was disclosed.\n* **High/critical (7.0-10.0)**: Long-lived tokens, organization-wide credentials, or credentials with administrative privileges were exposed, potentially enabling full repository compromise, secret extraction, code tampering, or the complete leak of private repository source code.\n\nAs such, each downstream consumer should independently assess their exposure by reviewing packaged artifacts for the presence of `.git` directories or other credentials, and evaluating both the sensitivity of any credentials found and the confidentiality of any included source code.\n\nConsequences may include:\n  - Unauthorized access to git repositories via exposed PATs.\n  - Tampering with repository code or metadata.\n  - Malicious CI behavior (triggering workflows, reading secrets).\n  - Disclosure of commit history, remote origins, or other sensitive internal structure.\n\n## Recommendation\nThis issue should be considered **severe** due to the potential exposure of sensitive tokens and repository metadata. Although most workflows that use `steam-workshop-deploy` also employ `actions/checkout`, which handles tokens and credentials more securely, there are legitimate use cases where `actions/checkout` is not used or where custom `.git` folders exist. Additionally, `actions/checkout` can accept a on-emphemeral tokens as a parameter for its workflow. In such cases, long-lived or sensitive credentials may be packaged and exposed, greatly increasing the risk of unauthorized access and repository compromise.  Therefore, this issue should be considered severe regardless of common usage patterns.\n\n**Downstream:**\n- Downstream components should revoke any credentials or PATs associated with workflows or repositories that use this github action\n\n**This Deployment Action**\n\n- [x] The action should exclude `.git/` and other common sensitive file(s) by default from all packaging operations.\n- [x] A `deployignore` or similar mechanism should be introduced to give users finer control of what files or directories are included for deployed artifacts",
  "id": "GHSA-x6gv-2rvh-qmp6",
  "modified": "2025-10-27T16:22:57Z",
  "published": "2025-08-13T23:03:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BoldestDungeon/steam-workshop-deploy/security/advisories/GHSA-x6gv-2rvh-qmp6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BoldestDungeon/steam-workshop-deploy/commit/0ba85729da32108e1cc498d1b3d6760857b5c04d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/m00nl1ght-dev/steam-workshop-deploy/commit/913f0844e2153d798189397036918f4ceb0911e0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BoldestDungeon/steam-workshop-deploy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BoldestDungeon/steam-workshop-deploy/releases/tag/V2.0.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/m00nl1ght-dev/steam-workshop-deploy/releases/tag/v4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "m00nl1ght-dev/steam-workshop-deploy: Exposure of Version-Control Repository to an Unauthorized Control Sphere and Insufficiently Protected Credentials"
}