Common Weakness Enumeration

CWE-212

Allowed

Improper Removal of Sensitive Information Before Storage or Transfer

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.

155 vulnerabilities reference this CWE, most recent first.

GHSA-VGJ7-895J-GPR6

Vulnerability from github – Published: 2022-05-20 00:00 – Updated: 2022-06-07 21:17
VLAI
Summary
Improper Removal of Sensitive Information Before Storage or Transfer in Strapi
Details

An authenticated user with access to the Strapi admin panel can view private and sensitive data, such as email and password reset tokens, for API users if content types accessible to the authenticated user contain relationships to API users (from:users-permissions). There are many scenarios in which such details from API users can leak in the JSON response within the admin panel, either through a direct or indirect relationship. Access to this information enables a user to compromise these users’ accounts if the password reset API endpoints have been enabled. In a worst-case scenario, a low-privileged user could get access to a high-privileged API account, and could read and modify any data as well as block access to both the admin panel and API by revoking privileges for all other users.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "strapi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.6.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@strapi/strapi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-30618"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-07T21:17:06Z",
    "nvd_published_at": "2022-05-19T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "An authenticated user with access to the Strapi admin panel can view private and sensitive data, such as email and password reset tokens, for API users if content types accessible to the authenticated user contain relationships to API users (from:users-permissions). There are many scenarios in which such details from API users can leak in the JSON response within the admin panel, either through a direct or indirect relationship. Access to this information enables a user to compromise these users\u2019 accounts if the password reset API endpoints have been enabled. In a worst-case scenario, a low-privileged user could get access to a high-privileged API account, and could read and modify any data as well as block access to both the admin panel and API by revoking privileges for all other users.",
  "id": "GHSA-vgj7-895j-gpr6",
  "modified": "2022-06-07T21:17:06Z",
  "published": "2022-05-20T00:00:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30618"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/strapi/strapi"
    },
    {
      "type": "WEB",
      "url": "https://www.synopsys.com/blogs/software-security/cyrc-advisory-strapi"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Removal of Sensitive Information Before Storage or Transfer in Strapi"
}

GHSA-VH2M-22XX-Q94F

Vulnerability from github – Published: 2024-04-12 22:54 – Updated: 2024-04-15 19:41
VLAI
Summary
Sensitive query parameters logged by default in OpenTelemetry.Instrumentation http and AspNetCore
Details

Impact

OpenTelemetry.Instrumentation.Http writes the url.full attribute/tag on spans (Activity) when tracing is enabled for outgoing http requests and OpenTelemetry.Instrumentation.AspNetCore writes the url.query attribute/tag on spans (Activity) when tracing is enabled for incoming http requests.

These attributes are defined by the Semantic Conventions for HTTP Spans.

Up until the 1.8.1 the values written by OpenTelemetry.Instrumentation.Http & OpenTelemetry.Instrumentation.AspNetCore will pass-through the raw query string as was sent or received (respectively). This may lead to sensitive information (e.g. EUII - End User Identifiable Information, credentials, etc.) being leaked into telemetry backends (depending on the application(s) being instrumented) which could cause privacy and/or security incidents.

Note: Older versions of OpenTelemetry.Instrumentation.Http & OpenTelemetry.Instrumentation.AspNetCore may use different tag names but have the same vulnerability.

Resolution

The 1.8.1 versions of OpenTelemetry.Instrumentation.Http & OpenTelemetry.Instrumentation.AspNetCore will now redact by default all values detected on transmitted or received query strings.

Example transmitted or received query sting:

?key1=value1&key2=value2

Example of redacted value written on telemetry:

?key1=Redacted&key2=Redacted

Severity
4.1 (Medium)
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "OpenTelemetry.Instrumentation.Http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "OpenTelemetry.Instrumentation.AspNetCore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-32028"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201",
      "CWE-212"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-12T22:54:09Z",
    "nvd_published_at": "2024-04-12T23:15:06Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\n\n`OpenTelemetry.Instrumentation.Http` writes the `url.full` attribute/tag on spans (`Activity`) when tracing is enabled for outgoing http requests and `OpenTelemetry.Instrumentation.AspNetCore` writes the `url.query` attribute/tag on spans (`Activity`) when tracing is enabled for incoming http requests.\n\nThese attributes are defined by the [Semantic Conventions for HTTP Spans](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/http/http-spans.md).\n\nUp until the `1.8.1` the values written by `OpenTelemetry.Instrumentation.Http` \u0026 `OpenTelemetry.Instrumentation.AspNetCore` will pass-through the raw query string as was sent or received (respectively). This may lead to sensitive information (e.g. EUII - End User Identifiable Information, credentials, etc.) being leaked into telemetry backends (depending on the application(s) being instrumented) which could cause privacy and/or security incidents.\n\nNote: Older versions of `OpenTelemetry.Instrumentation.Http` \u0026 `OpenTelemetry.Instrumentation.AspNetCore` may use different tag names but have the same vulnerability.\n\n## Resolution\n\nThe `1.8.1` versions of `OpenTelemetry.Instrumentation.Http` \u0026 `OpenTelemetry.Instrumentation.AspNetCore` will now redact by default all values detected on transmitted or received query strings.\n\nExample transmitted or received query sting:\n\n`?key1=value1\u0026key2=value2`\n\nExample of redacted value written on telemetry:\n\n`?key1=Redacted\u0026key2=Redacted`",
  "id": "GHSA-vh2m-22xx-q94f",
  "modified": "2024-04-15T19:41:05Z",
  "published": "2024-04-12T22:54:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-vh2m-22xx-q94f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32028"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet/commit/e222ecb5942d4ce1cadfd4306c39e3f4933a5c42"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-dotnet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/semantic-conventions/blob/main/docs/http/http-spans.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sensitive query parameters logged by default in OpenTelemetry.Instrumentation http and AspNetCore"
}

GHSA-VQ98-JH26-Q3X7

Vulnerability from github – Published: 2024-09-10 09:31 – Updated: 2025-08-22 09:30
VLAI
Details

A low privileged remote attacker can get access to CSRF tokens of higher privileged users which can be abused to mount CSRF attacks.

Severity
5.7 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-7698"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-201",
      "CWE-212"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-10T09:15:06Z",
    "severity": "MODERATE"
  },
  "details": "A low privileged remote attacker can\u00a0get access to CSRF tokens of higher privileged users which can be abused to mount CSRF attacks.",
  "id": "GHSA-vq98-jh26-q3x7",
  "modified": "2025-08-22T09:30:40Z",
  "published": "2024-09-10T09:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7698"
    },
    {
      "type": "WEB",
      "url": "https://cert.vde.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:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VV66-6RP4-WR4F

Vulnerability from github – Published: 2026-05-05 20:02 – Updated: 2026-05-14 20:49
VLAI
Summary
OpenBao's Namespace Deletion May Not Delete Data Properly
Details

Impact

When OpenBao's 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.

Patches

This will be patched in OpenBao v2.5.3.

Workarounds

Users may manually remove mounts prior to deleting the namespace.

Audit 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.

Severity
2.3 (Low)
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
Show details on source website
To clipboard 

{
  "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"
}

GHSA-W248-FFJ2-4V5Q

Vulnerability from github – Published: 2022-06-09 23:47 – Updated: 2022-06-20 21:59
VLAI
Summary
Fix failure to strip Authorization header on HTTP downgrade
Details

Impact

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't 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.

Patches

Affected 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.

Workarounds

An 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.

References

For more information

If you have any questions or comments about this advisory, please get in touch with us in #guzzle on the PHP HTTP Slack. Do not report additional security advisories in that public channel, however - please follow our vulnerability reporting process.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "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"
}

GHSA-W53M-GXVG-VX7P

Vulnerability from github – Published: 2025-08-28 14:58 – Updated: 2025-08-28 18:51
VLAI
Summary
Contao can disclose sensitive information in the news module
Details

Impact

If a news feed contains protected news archives, their news items are not filtered and become publicly available in the RSS feed.

Patches

Update to Contao 5.3.38 or 5.6.1.

Workarounds

Do not add protected news archives to the news feed page.

For more information

If you have any questions or comments about this advisory, open an issue in contao/contao.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "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"
}

GHSA-WCJ4-JW5J-44WH

Vulnerability from github – Published: 2025-12-31 22:01 – Updated: 2026-06-05 14:17
VLAI
Summary
CBORDecoder reuse can leak shareable values across decode calls
Details

Summary

When 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.

Details

The issue is in the decoder's handling of the shareables list, which stores values tagged with CBOR tag 28 (shareable) for later reference by tag 29 (sharedref).

When 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.

The issue exists in both the C extension and the pure Python decoder.

In the C extension (source/decoder.c), the _CBORDecoder_set_fp function (line ~202) updates the file pointer but does not reset the shareables state:

  static int
  _CBORDecoder_set_fp(CBORDecoderObject *self, PyObject *value, void *closure)
  {
      // ... validation ...
      tmp = self->read;
      self->read = read;
      Py_DECREF(tmp);
      return 0;
      // Missing: PyList_Clear(self->shareables) or equivalent
  }

In the pure Python decoder (cbor2/_decoder.py), the fp setter similarly fails to clear self._shareables.

Similarly, decode_from_bytes() in both implementations saves and restores the read pointer but does not clear the shareables list between decodes.

The 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.

PoC

import cbor2
from io import BytesIO

# Message from trusted source containing a shareable value
msg1 = cbor2.dumps(cbor2.CBORTag(28, "secret"))

# Attacker-controlled message referencing index 0
msg2 = cbor2.dumps(cbor2.CBORTag(29, 0))

# Decoder reused across trust boundaries
decoder = cbor2.CBORDecoder(BytesIO(b''))
decoder.decode_from_bytes(msg1)
print(decoder.decode_from_bytes(msg2))  # prints "secret"

No special configuration required. Affects any application that reuses a CBORDecoder instance to decode messages from different sources.

Impact

Information 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.

Related

A similar issue in the encoder could produce invalid CBOR with dangling shared references:

import cbor2
from io import BytesIO

# Create encoder with value sharing enabled
encoder = cbor2.CBOREncoder(BytesIO(), value_sharing=True)

# Persistent object that will be encoded multiple times
shared_obj = ['hello']

# First encode: array containing shared_obj twice
encoder.encode([shared_obj, shared_obj])
print(f'First encode: {encoder.fp.getvalue().hex()}')
# Output: d81c82d81c816568656c6c6fd81d01

# Second encode: just shared_obj
encoder.fp = BytesIO()
encoder.encode(shared_obj)
result = encoder.fp.getvalue()
print(f'Second encode: {result.hex()}')
# Output: d81d01  (just a shared reference to index 1!)

# Try to decode the second result as standalone CBOR
decoder = cbor2.CBORDecoder(BytesIO(result))
decoded = decoder.decode()
# FAILS: shared reference 1 not found

While 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.

It 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.

Suggested resolution

Add 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).

Decoder (_decoding flag): - decode(): set flag True, reset state, decode, set flag False - decode_from_bytes(): reset state only when flag is False

Encoder (_encoding flag): - encode(): set flag True, reset state, encode, set flag False - encode_to_bytes(): reset state only when flag is False

Severity
5.5 (Medium)
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
Show details on source website
To clipboard 

{
  "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"
}

GHSA-WFG3-6GRC-FQV3

Vulnerability from github – Published: 2026-04-14 18:30 – Updated: 2026-04-14 18:30
VLAI
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.

Severity
4.6 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "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"
    }
  ]
}

GHSA-WH6W-3828-G9QF

Vulnerability from github – Published: 2022-11-10 21:16 – Updated: 2025-05-02 12:51
VLAI
Summary
Wasmtime may have data leakage between instances in the pooling allocator
Details

Impact

There is a bug in Wasmtime's implementation of it's 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.

The 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.

Heap 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.

One 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:

  • Module A is instantiated, and then deallocated. This leaves A's heap image in place, reset to its initial contents.
  • 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.
  • 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's part to access linear memory will then trap and if the host accesses A's memory it will segfault because the data that's supposed to be mapped is all unmapped.

Adding 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't, causing the host to segfault on unmapped memory it believed was mapped.

Patches

This bug has been patched and users should upgrade to Wasmtime 2.0.2.

Workarounds

Trigging 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:

  • Disabling the pooling allocator - note that pooling allocation is not enabled by default in Wasmtime
  • Disabling the memory-init-cow feature or with Config::memory_init_cow

References

For more information

If you have any questions or comments about this advisory:

Severity
8.6 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "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"
}

GHSA-WH98-P28R-VRC9

Vulnerability from github – Published: 2022-02-11 20:49 – Updated: 2022-02-24 13:15
VLAI
Summary
Exposure of information in Action Pack
Details

Impact

Under certain circumstances response bodies will not be closed, for example a bug in a webserver 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.

Upgrading to the FIXED versions of Rails will ensure mitigation of this issue even in the context of a buggy webserver or middleware implementation.

Patches

This has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

Workarounds

Upgrading is highly recommended, but to work around this problem the following middleware can be used:

class GuardedExecutor < ActionDispatch::Executor
  def call(env)
    ensure_completed!
    super
  end

  private

    def ensure_completed!
      @executor.new.complete! if @executor.active?
    end
end

# Ensure the guard is inserted before ActionDispatch::Executor
Rails.application.configure do
  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor
end
Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "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"
}
Mitigation
Requirements

Clearly specify which information should be regarded as private or sensitive, and require that the product offers functionality that allows the user to cleanse the sensitive information from the resource before it is published or exported to other parties.

Mitigation MIT-46
Architecture and Design

Strategy: Separation of Privilege

  • Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
  • Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Mitigation MIT-57
Implementation Operation

Strategy: Attack Surface Reduction

  • Some tools can automatically analyze documents to redact, strip, or "sanitize" private information, although some human review might be necessary. Tools may vary in terms of which document formats can be processed.
  • When calling an external program to automatically generate or convert documents, invoke the program with any available options that avoid generating sensitive metadata. Some formats have well-defined fields that could contain private data, such as Exchangeable image file format (Exif), which can contain potentially sensitive metadata such as geolocation, date, and time [REF-1515] [REF-1516].
Mitigation MIT-33
Implementation

Strategy: Attack Surface Reduction

Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.

Mitigation
Implementation

Avoid errors related to improper resource shutdown or release (CWE-404), which may leave the sensitive data within the resource if it is in an incomplete state.

CAPEC-168: Windows ::DATA Alternate Data Stream

An attacker exploits the functionality of Microsoft NTFS Alternate Data Streams (ADS) to undermine system security. ADS allows multiple "files" to be stored in one directory entry referenced as filename:streamname. One or more alternate data streams may be stored in any file or directory. Normal Microsoft utilities do not show the presence of an ADS stream attached to a file. The additional space for the ADS is not recorded in the displayed file size. The additional space for ADS is accounted for in the used space on the volume. An ADS can be any type of file. ADS are copied by standard Microsoft utilities between NTFS volumes. ADS can be used by an attacker or intruder to hide tools, scripts, and data from detection by normal system utilities. Many anti-virus programs do not check for or scan ADS. Windows Vista does have a switch (-R) on the command line DIR command that will display alternate streams.

← Back to the CWE list