Common Weakness Enumeration

CWE-226

Allowed

Sensitive Information in Resource Not Removed Before Reuse

Abstraction: Base · Status: Draft

The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities.

62 vulnerabilities reference this CWE, most recent first.

GHSA-P2CJ-86V4-7782

Vulnerability from github – Published: 2024-06-18 21:30 – Updated: 2025-05-01 13:31
VLAI
Summary
Moodle HTTP authorization header is preserved between "emulated redirects"
Details

The cURL wrapper in Moodle retained the original request headers when following redirects, so HTTP authorization header information could be unintentionally sent in requests to redirect URLs.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.4.0-beta"
            },
            {
              "fixed": "4.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0-beta"
            },
            {
              "fixed": "4.3.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0-beta"
            },
            {
              "fixed": "4.2.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-38275"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-226",
      "CWE-459"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-18T22:45:35Z",
    "nvd_published_at": "2024-06-18T20:15:13Z",
    "severity": "MODERATE"
  },
  "details": "The cURL wrapper in Moodle retained the original request headers when following redirects, so HTTP authorization header information could be unintentionally sent in requests to redirect URLs.",
  "id": "GHSA-p2cj-86v4-7782",
  "modified": "2025-05-01T13:31:07Z",
  "published": "2024-06-18T21:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38275"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle/commit/0df3c5837a592e6663c4d531ff6a1f776bc2f785"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle/commit/3e38c84315a7991ce5ef5f241f5e873b5ca24f01"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle/commit/836b2c23a210317d130017d77bb64e3b510869a9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle/commit/f7988538b2208c55f2c40ce4f0815901dc88049b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/mod/forum/discuss.php?d=459500"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Moodle HTTP authorization header is preserved between \"emulated redirects\""
}

GHSA-PQ38-4MFG-VPXJ

Vulnerability from github – Published: 2026-04-07 21:32 – Updated: 2026-04-07 21:32
VLAI
Details

The Semtech LR11xx LoRa transceivers running early versions of firmware contains an information disclosure vulnerability in its firmware validation functionality. When a host issues a firmware validity check command via the SPI interface, the device decrypts the provided encrypted firmware package block-by-block to validate its integrity. However, the last decrypted firmware block remains uncleared in memory after the validation process completes. An attacker with access to the SPI interface can subsequently issue memory read commands to retrieve the decrypted firmware contents from this residual memory, effectively bypassing the firmware encryption protection mechanism. The attack requires physical access to the device's SPI interface.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-14858"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-226"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-07T20:16:22Z",
    "severity": "MODERATE"
  },
  "details": "The Semtech LR11xx LoRa transceivers running early versions of firmware contains an information disclosure vulnerability in its firmware validation functionality. When a host issues a firmware validity check command via the SPI interface, the device decrypts the provided encrypted firmware package block-by-block to validate its integrity. However, the last decrypted firmware block remains uncleared in memory after the validation process completes. An attacker with access to the SPI interface can subsequently issue memory read commands to retrieve the decrypted firmware contents from this residual memory, effectively bypassing the firmware encryption protection mechanism. The attack requires physical access to the device\u0027s SPI interface.",
  "id": "GHSA-pq38-4mfg-vpxj",
  "modified": "2026-04-07T21:32:39Z",
  "published": "2026-04-07T21:32:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14858"
    },
    {
      "type": "WEB",
      "url": "https://www.semtech.com/company/security/security-bulletins/sem-psa-2026-001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:N/R:A/V:C/RE:M/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PX79-JX9M-M5H5

Vulnerability from github – Published: 2023-05-31 21:31 – Updated: 2024-04-04 04:26
VLAI
Details

A known cache speculation vulnerability, known as Branch History Injection (BHI) or Spectre-BHB, becomes actual again for the new hw AmpereOne. Spectre-BHB is similar to Spectre v2, except that malicious code uses the shared branch history (stored in the CPU Branch History Buffer, or BHB) to influence mispredicted branches within the victim's hardware context. Once that occurs, speculation caused by the mispredicted branches can cause cache allocation. This issue leads to obtaining information that should not be accessible.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-3006"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-212",
      "CWE-226"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-31T20:15:11Z",
    "severity": "MODERATE"
  },
  "details": "A known cache speculation vulnerability, known as Branch History Injection (BHI) or Spectre-BHB, becomes actual again for the new hw AmpereOne. Spectre-BHB is similar to Spectre v2, except that malicious code uses the shared branch history (stored in the CPU Branch History Buffer, or BHB) to influence mispredicted branches within the victim\u0027s hardware context. Once that occurs, speculation caused by the mispredicted branches can cause cache allocation. This issue leads to obtaining information that should not be accessible.",
  "id": "GHSA-px79-jx9m-m5h5",
  "modified": "2024-04-04T04:26:48Z",
  "published": "2023-05-31T21:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3006"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=0e5d5ae837c8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QQVG-8FP4-2XFF

Vulnerability from github – Published: 2026-03-21 15:33 – Updated: 2026-03-21 15:33
VLAI
Details

CEWE PHOTO IMPORTER 6.4.3 contains a denial of service vulnerability that allows local attackers to crash the application by importing a specially crafted image file. Attackers can create a malformed JPG file with an oversized buffer and trigger the crash through the import functionality during the image processing workflow.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-25553"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-226"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-21T13:16:17Z",
    "severity": "MODERATE"
  },
  "details": "CEWE PHOTO IMPORTER 6.4.3 contains a denial of service vulnerability that allows local attackers to crash the application by importing a specially crafted image file. Attackers can create a malformed JPG file with an oversized buffer and trigger the crash through the import functionality during the image processing workflow.",
  "id": "GHSA-qqvg-8fp4-2xff",
  "modified": "2026-03-21T15:33:23Z",
  "published": "2026-03-21T15:33:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25553"
    },
    {
      "type": "WEB",
      "url": "https://cewe-photoworld.com"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/46862"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/cewe-photo-importer-denial-of-service-via-malformed-image"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-R45X-GHR2-QJXC

Vulnerability from github – Published: 2022-06-17 00:30 – Updated: 2022-06-23 17:29
VLAI
Summary
Duplicate Advisory: `#[zeroize(drop)]` doesn't implement `Drop` for `enum`s
Details

Duplicate Advisory

This advisory is a duplicate of GHSA-c5hx-w945-j4pq. This link is preserved to maintain external references.

Original Description

Affected versions of this crate did not implement Drop when #[zeroize(drop)] was used on an enum.

This can result in memory not being zeroed out after dropping it, which is exactly what is intended when adding this attribute.

The flaw was corrected in version 1.2 and #[zeroize(drop)] on enums now properly implements Drop.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "zeroize_derive"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-226"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-17T00:30:52Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\nThis advisory is a duplicate of [GHSA-c5hx-w945-j4pq](https://github.com/advisories/GHSA-c5hx-w945-j4pq). This link is preserved to maintain external references.\n\n## Original Description\nAffected versions of this crate did not implement `Drop` when `#[zeroize(drop)]` was used on an `enum`.\n\nThis can result in memory not being zeroed out after dropping it, which is exactly what is intended when adding this attribute.\n\nThe flaw was corrected in version 1.2 and `#[zeroize(drop)]` on `enum`s now properly implements `Drop`.\n",
  "id": "GHSA-r45x-ghr2-qjxc",
  "modified": "2022-06-23T17:29:03Z",
  "published": "2022-06-17T00:30:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/iqlusioninc/crates/issues/876"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/iqlusioninc/crates"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2021-0115.html"
    }
  ],
  "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": "Duplicate Advisory: `#[zeroize(drop)]` doesn\u0027t implement `Drop` for `enum`s",
  "withdrawn": "2022-06-23T17:29:03Z"
}

GHSA-R7P8-XQ5M-436C

Vulnerability from github – Published: 2026-04-14 00:06 – Updated: 2026-04-14 00:06
VLAI
Summary
Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables
Details

Description (as reported)

A security vulnerability has been identified in Jetty's JaspiAuthenticator.java.

The root cause is a failure to consistently clear authentication metadata stored in ThreadLocal during certain error or incomplete authentication flows. Specifically, after a GroupPrincipalCallback is persisted into the ThreadLocal, the authentication process may exit prematurely — before the ThreadLocal storage is cleared — if a mandatory CallerPrincipalCallback is missing or an exception occurs. This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

Impact

An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

Patches

No patches yet.

Workarounds

Do not use Jetty's JASPI.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.1.7"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.ee11:jetty-ee11-jaspi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.1.0"
            },
            {
              "fixed": "12.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.1.7"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.ee10:jetty-ee10-jaspi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.1.0"
            },
            {
              "fixed": "12.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.1.7"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.ee9:jetty-ee9-jaspi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.1.0"
            },
            {
              "fixed": "12.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.1.7"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.ee8:jetty-ee8-jaspi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.1.0"
            },
            {
              "fixed": "12.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.0.33"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.ee11:jetty-ee11-jaspi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.0.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.0.33"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.ee10:jetty-ee10-jaspi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.0.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.0.33"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.ee9:jetty-ee9-jaspi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.0.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.0.33"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.ee8:jetty-ee8-jaspi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.0.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.0.28"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-jaspi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.0.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.0.28"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-jaspi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.4.60"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty:jetty-jaspi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.4.0"
            },
            {
              "fixed": "9.4.61"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-5795"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-226",
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T00:06:27Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Description (as reported)\n\nA security vulnerability has been identified in Jetty\u0027s  `JaspiAuthenticator.java`. \n\nThe root cause is a failure to consistently clear authentication metadata stored in  `ThreadLocal`  during certain error or incomplete authentication flows. \nSpecifically, after a `GroupPrincipalCallback`  is persisted into the  `ThreadLocal`, the authentication process may exit prematurely \u2014 before the  `ThreadLocal`  storage is cleared \u2014 if a mandatory `CallerPrincipalCallback`  is missing or an exception occurs. \nThis allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.\n\nSee also attached PDF.\n\n### Impact\nAn unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).\n\n### Patches\nNo patches yet.\n\n### Workarounds\nDo not use Jetty\u0027s JASPI.",
  "id": "GHSA-r7p8-xq5m-436c",
  "modified": "2026-04-14T00:06:27Z",
  "published": "2026-04-14T00:06:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/security/advisories/GHSA-r7p8-xq5m-436c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5795"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jetty/jetty.project"
    },
    {
      "type": "WEB",
      "url": "https://github.com/user-attachments/files/26118760/JaspiAuthenticator_Security_Report.pdf"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.eclipse.org/security/cve-assignment/-/issues/92"
    }
  ],
  "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": "Eclipse Jetty: Early return from the JASPIAuthenticator code can potentially no clear ThreadLocal variables"
}

GHSA-RHWX-656Q-5R7X

Vulnerability from github – Published: 2024-11-13 21:30 – Updated: 2024-11-13 21:30
VLAI
Details

Sensitive information in resource not removed before reuse in some Intel(R) TDX Seamldr module software before version 1.5.02.00 may allow a privileged user to potentially enable escalation of privilege via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21850"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-226"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-13T21:15:09Z",
    "severity": "HIGH"
  },
  "details": "Sensitive information in resource not removed before reuse in some Intel(R) TDX Seamldr module software before version 1.5.02.00 may allow a privileged user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-rhwx-656q-5r7x",
  "modified": "2024-11-13T21:30:35Z",
  "published": "2024-11-13T21:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21850"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01076.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VWJ9-2733-P4WV

Vulnerability from github – Published: 2024-10-31 18:31 – Updated: 2024-10-31 18:31
VLAI
Details

When using Arm Cortex-M Security Extensions (CMSE), Secure stack contents can be leaked to Non-secure state via floating-point registers when a Secure to Non-secure function call is made that returns a floating-point value and when this is the first use of floating-point since entering Secure state. This allows an attacker to read a limited quantity of Secure stack contents with an impact on confidentiality. This issue is specific to code generated using LLVM-based compilers.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-7883"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-226"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-31T17:15:14Z",
    "severity": "LOW"
  },
  "details": "When using Arm Cortex-M Security Extensions (CMSE), Secure stack \ncontents can be leaked to Non-secure state via floating-point registers \nwhen a Secure to Non-secure function call is made that returns a \nfloating-point value and when this is the first use of floating-point \nsince entering Secure state. This allows an attacker to read a limited \nquantity of Secure stack contents with an impact on confidentiality. \nThis issue is specific to code generated using LLVM-based compilers.",
  "id": "GHSA-vwj9-2733-p4wv",
  "modified": "2024-10-31T18:31:19Z",
  "published": "2024-10-31T18:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7883"
    },
    {
      "type": "WEB",
      "url": "https://developer.arm.com/Arm%20Security%20Center/Cortex-M%20Security%20Extensions%20Vulnerability"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/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:

Show details on source website

{
  "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-X43Q-54P7-VW63

Vulnerability from github – Published: 2023-11-09 15:30 – Updated: 2023-11-09 15:30
VLAI
Details

The AppsAnywhere macOS client-privileged helper can be tricked into executing arbitrary commands with elevated permissions by a local user process.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-41138"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-226",
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-09T15:15:08Z",
    "severity": "HIGH"
  },
  "details": "The AppsAnywhere macOS client-privileged helper can be tricked into executing arbitrary commands with elevated permissions by a local user process.",
  "id": "GHSA-x43q-54p7-vw63",
  "modified": "2023-11-09T15:30:30Z",
  "published": "2023-11-09T15:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41138"
    },
    {
      "type": "WEB",
      "url": "https://docs.appsanywhere.com/appsanywhere/3.1/2023-11-security-advisory"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design Implementation

During critical state transitions, information not needed in the next state should be removed or overwritten with fixed patterns (such as all 0's) or random data, before the transition to the next state.

Mitigation
Architecture and Design Implementation

When releasing, de-allocating, or deleting a resource, overwrite its data and relevant metadata with fixed patterns or random data. Be cautious about complex resource types whose underlying representation might be non-contiguous or change at a low level, such as how a file might be split into different chunks on a file system, even though "logical" file positions are contiguous at the application layer. Such resource types might require invocation of special modes or APIs to tell the underlying operating system to perform the necessary clearing, such as SDelete (Secure Delete) on Windows, although the appropriate functionality might not be available at the application layer.

CAPEC-37: Retrieve Embedded Sensitive Data

An attacker examines a target system to find sensitive data that has been embedded within it. This information can reveal confidential contents, such as account numbers or individual keys/credentials that can be used as an intermediate step in a larger attack.