Common Weakness Enumeration

CWE-354

Allowed

Improper Validation of Integrity Check Value

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.

231 vulnerabilities reference this CWE, most recent first.

GHSA-R353-4845-PR5P

Vulnerability from github – Published: 2026-03-13 20:44 – Updated: 2026-03-16 22:01
VLAI
Summary
simplesamlphp/xml-security: Missing AES-GCM Authentication Tag Validation on Encrypted Nodes Allows for Unauthorized Decryption
Details

Summary

XML nodes encrypted with either aes-128-gcm, aes-192-gcm, or aes-256-gcm lack validation of the authentication tag length. An attacker can use this to brute-force an authentication tag, recover the GHASH key, and decrypt the encrypted nodes. It also allows to forge arbitrary ciphertexts without knowing the encryption key.

Details

When decrypting with either aes-128-gcm, aes-192-gcm, or aes-256-gcm here, the $authTag is set from a substr(), but never has its length validated (it should be validated with something like strlen($authTag) == self::AUTHTAG_LENGTH). For that reason, a shorter than expected data blob will allow for the $authTag to have as short a tag as only one byte (see PHP's documentation).

See this example:

function test($data) {
    $ivSize = 12;
    $tagSize = 16;

    $iv = substr($data, 0, $ivSize);
    $data = substr($data, $ivSize);
    $offset = 0 - $tagSize;
    $tag = substr($data, $offset);
    $ct = substr($data, 0, $offset);

    echo 'IV: "' . $iv . '"' . PHP_EOL;
    echo 'Tag: "' . $tag . '"' . PHP_EOL;
    echo 'CT: "' . $ct . '"' . PHP_EOL;
}

/* Outputs:
php > test('myNonceNoncet');
IV: "myNonceNonce"
Tag: "t"
CT: ""
php > test('myNonceNonceta');
IV: "myNonceNonce"
Tag: "ta"
CT: ""
php > test('myNonceNoncetag');
IV: "myNonceNonce"
Tag: "tag"
CT: ""
*/

With a legit ciphertext in hand, this is enough to recover the GHASH key. With that key, any authenticated tags can be computed offline which allows for decryption of the ciphertext and forgery of arbitrary ciphertexts. PoC

  1. Setup a server expecting XML with an encrypted assertion

  2. Run this php script poc.php with php -S 127.0.0.1:8888 (taken from this saml test case)

  3. The script expects this private key: sp-private-key.pem.

  4. Create an XML document with an encrypted assertion (encrypted with aes-256-gcm)

Here is the SAMLResponse used in the video below: saml_response.txt

Note: The steps from 3 to 6 are implemented in this exploit script: nonce_reuse_with_fmt_val_oracle.py. You can run the script with sage -python nonce_reuse_with_fmt_val_oracle.py -s 'url-encoded_and_base64-encoded_samlresponse'

  1. Take the content of the node and apply the following modifications

  2. Base64-decode the content

  3. Take the first 12 bytes and save them as the nonce

  4. Take the last 16 bytes and save them as the tag

  5. Now brute-force the tag of an empty ciphertext

  6. Loop through all 256 possible byte values (let's call that byte_tag_attempt)

  7. Concatenate together the nonce and the byte_tag_attempt

  8. Base64-encode the result

  9. Replace the content of the node with this result

  10. On http errors 500, we learn that the tag is valid

  11. Do the same for the next byte of the tag until all 16 bytes have been brute-forced

  12. With this new tag and the empty ciphertext, compute the GHASH key (the way to do this has been described in this blog post)

  13. Use this GHASH key to compute authentication tags offline for arbitrary ciphertexts

  14. Decryption is done by observing XML parsing errors that occur after modifying the ciphertext, those can be seen as http errors 500

https://private-user-images.githubusercontent.com/20672053/531768743-2f6e4a7e-4384-4350-b423-7ddd77aa9152.webm?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzMzMTQ3MjEsIm5iZiI6MTc3MzMxNDQyMSwicGF0aCI6Ii8yMDY3MjA1My81MzE3Njg3NDMtMmY2ZTRhN2UtNDM4NC00MzUwLWI0MjMtN2RkZDc3YWE5MTUyLndlYm0_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzEyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMxMlQxMTIwMjFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zNDRhZThlYTY5OWNmNGZmMmNmOGJhYTNkNzAwMjNiMTVhMDMxOTIzMGRkN2Y3OGU3NTI3NmFkMWE2OTgwMDFhJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.X9UVe9qpwX1YQYo34WmUI84KA0a28FKd4SGy15GEVMU

Impact

The general impact is:

XML nodes encrypted with AES-GCM can be decrypted by observing parsing differences XML nodes encrypted with AES-GCM can be modified to decrypt to an arbitrary value The GCM internal GHASH key can be recovered

In cases where the encryption key is embedded in the XML and is encrypted with the Service Provider's public key (like often done with SAML), the last two items don't have a big impact. This is because:

With the Service Provider's public key, an arbitrary ciphertext can be created with a known symmetric key The symmetric keys are generated on the fly every time the IdP creates a new SAMLResponse

In any case, secrets that are embedded in the XML, whether coming from an IdP, or from another scheme, can be decrypted.

Important: If static symmetric keys are used, as the GHASH key could have leaked, you must rotate those keys.

References

For additional information on the issue, you can refer to this blog post about the OpenSSL issue and how it can be exploited.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "simplesamlphp/xml-security"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "simplesamlphp/xml-security"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.13.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32600"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T20:44:21Z",
    "nvd_published_at": "2026-03-16T14:19:38Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nXML nodes encrypted with either aes-128-gcm, aes-192-gcm, or aes-256-gcm lack validation of the authentication tag length.\nAn attacker can use this to brute-force an authentication tag, recover the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of), and decrypt the encrypted nodes.\nIt also allows to forge arbitrary ciphertexts without knowing the encryption key.\n\n### Details\n\nWhen decrypting with either aes-128-gcm, aes-192-gcm, or aes-256-gcm [here](https://github.com/robrichards/xmlseclibs/blob/2bdfd742624d739dfadbd415f00181b4a77aaf07/src/XMLSecurityKey.php#L467-L479), the $authTag is set from a substr(), but never has its length validated (it should be validated with something like strlen($authTag) == self::AUTHTAG_LENGTH).\nFor that reason, a shorter than expected data blob will allow for the $authTag to have as short a tag as only one byte (see [PHP\u0027s documentation](https://www.php.net/manual/en/function.openssl-decrypt.php#:~:text=The%20length%20of%20the%20tag%20is%20not%20checked%20by%20the%20function.%20It%20is%20the%20caller%27s%20responsibility%20to%20ensure%20that%20the%20length%20of%20the%20tag%20matches%20the%20length%20of%20the%20tag%20retrieved%20when%20openssl_encrypt()%20has%20been%20called.%20Otherwise%20the%20decryption%20may%20succeed%20if%20the%20given%20tag%20only%20matches%20the%20start%20of%20the%20proper%20tag.)).\n\nSee this example:\n\n```php\nfunction test($data) {\n    $ivSize = 12;\n    $tagSize = 16;\n\n    $iv = substr($data, 0, $ivSize);\n    $data = substr($data, $ivSize);\n    $offset = 0 - $tagSize;\n    $tag = substr($data, $offset);\n    $ct = substr($data, 0, $offset);\n\n    echo \u0027IV: \"\u0027 . $iv . \u0027\"\u0027 . PHP_EOL;\n    echo \u0027Tag: \"\u0027 . $tag . \u0027\"\u0027 . PHP_EOL;\n    echo \u0027CT: \"\u0027 . $ct . \u0027\"\u0027 . PHP_EOL;\n}\n\n/* Outputs:\nphp \u003e test(\u0027myNonceNoncet\u0027);\nIV: \"myNonceNonce\"\nTag: \"t\"\nCT: \"\"\nphp \u003e test(\u0027myNonceNonceta\u0027);\nIV: \"myNonceNonce\"\nTag: \"ta\"\nCT: \"\"\nphp \u003e test(\u0027myNonceNoncetag\u0027);\nIV: \"myNonceNonce\"\nTag: \"tag\"\nCT: \"\"\n*/\n```\n\nWith a legit ciphertext in hand, this is enough to recover the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of).\nWith that key, any authenticated tags can be computed offline which allows for decryption of the ciphertext and forgery of arbitrary ciphertexts.\nPoC\n\n1. Setup a server expecting XML with an encrypted assertion\n  -  Run this php script [poc.php](https://github.com/user-attachments/files/24426600/poc.php.txt) with php -S 127.0.0.1:8888 (taken from [this saml test case](https://github.com/robrichards/xmlseclibs/blob/69fd63080bc47a8d51bc101c30b7cb756862d1d6/tests/saml/saml-decrypt.phpt#L62))\n\n  - The script expects this private key: [sp-private-key.pem.](https://github.com/user-attachments/files/24426620/sp-private-key.pem.txt)\n\n2. Create an XML document with an encrypted assertion (encrypted with aes-256-gcm)\n\nHere is the SAMLResponse used in the video below: [saml_response.txt](https://github.com/user-attachments/files/24426638/saml_response.txt)\n\nNote: The steps from 3 to 6 are implemented in this exploit script: [nonce_reuse_with_fmt_val_oracle.py](https://github.com/user-attachments/files/24426645/nonce_reuse_with_fmt_val_oracle.py).\nYou can run the script with sage -python nonce_reuse_with_fmt_val_oracle.py -s \u0027url-encoded_and_base64-encoded_samlresponse\u0027\n\n3. Take the content of the \u003cxenc:CipherValue\u003e node and apply the following modifications\n\n- Base64-decode the content\n\n- Take the first 12 bytes and save them as the nonce\n\n- Take the last 16 bytes and save them as the tag\n\n- Now brute-force the tag of an empty ciphertext\n\n  - Loop through all 256 possible byte values (let\u0027s call that byte_tag_attempt)\n\n  - Concatenate together the nonce and the byte_tag_attempt\n\n  - Base64-encode the result\n\n  - Replace the content of the \u003cxenc:CipherValue\u003e node with this result\n\n  - On http errors 500, we learn that the tag is valid\n\n  - Do the same for the next byte of the tag until all 16 bytes have been brute-forced\n\n4. With this new tag and the empty ciphertext, compute the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of) (the way to do this has been described in this [blog post](https://frereit.de/aes_gcm/))\n\n5. Use this [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of) to compute authentication tags offline for arbitrary ciphertexts\n\n6. Decryption is done by observing XML parsing errors that occur after modifying the ciphertext, those can be seen as http errors 500\n\nhttps://private-user-images.githubusercontent.com/20672053/531768743-2f6e4a7e-4384-4350-b423-7ddd77aa9152.webm?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzMzMTQ3MjEsIm5iZiI6MTc3MzMxNDQyMSwicGF0aCI6Ii8yMDY3MjA1My81MzE3Njg3NDMtMmY2ZTRhN2UtNDM4NC00MzUwLWI0MjMtN2RkZDc3YWE5MTUyLndlYm0_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMzEyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDMxMlQxMTIwMjFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zNDRhZThlYTY5OWNmNGZmMmNmOGJhYTNkNzAwMjNiMTVhMDMxOTIzMGRkN2Y3OGU3NTI3NmFkMWE2OTgwMDFhJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.X9UVe9qpwX1YQYo34WmUI84KA0a28FKd4SGy15GEVMU\n\n### Impact\n\nThe general impact is:\n\nXML nodes encrypted with AES-GCM can be decrypted by observing parsing differences\nXML nodes encrypted with AES-GCM can be modified to decrypt to an arbitrary value\nThe GCM internal [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of) can be recovered\n\nIn cases where the encryption key is embedded in the XML and is encrypted with the Service Provider\u0027s public key (like often done with SAML), the last two items don\u0027t have a big impact.\nThis is because:\n\nWith the Service Provider\u0027s public key, an arbitrary ciphertext can be created with a known symmetric key\nThe symmetric keys are generated on the fly every time the IdP creates a new SAMLResponse\n\nIn any case, secrets that are embedded in the XML, whether coming from an IdP, or from another scheme, can be decrypted.\n\nImportant: If static symmetric keys are used, as the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=%29%20is%20the-,hash%20key,-%2C%20a%20string%20of) could have leaked, you must rotate those keys.\n\n### References\nFor additional information on the issue, you can refer to this [blog post](https://sideni.xyz/posts/exploiting_openssl_api/) about the OpenSSL issue and how it can be exploited.",
  "id": "GHSA-r353-4845-pr5p",
  "modified": "2026-03-16T22:01:35Z",
  "published": "2026-03-13T20:44:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/simplesamlphp/xml-security/security/advisories/GHSA-r353-4845-pr5p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32600"
    },
    {
      "type": "WEB",
      "url": "https://github.com/simplesamlphp/xml-security/commit/cad6d57cf0a5a0b7e0cc4e4a5b18752e56eb1520"
    },
    {
      "type": "WEB",
      "url": "https://github.com/simplesamlphp/xml-security/commit/fdc12449e959c610943f9fd428e95e3832d74c25"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/simplesamlphp/xml-security"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "simplesamlphp/xml-security: Missing AES-GCM Authentication Tag Validation on Encrypted Nodes Allows for Unauthorized Decryption"
}

GHSA-R59W-M3RQ-R7X9

Vulnerability from github – Published: 2025-11-25 18:32 – Updated: 2025-11-25 18:32
VLAI
Details

NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware, where an attacker could cause improper validation of integrity. A successful exploit of this vulnerability might lead to information disclosure.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-33193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-25T18:15:50Z",
    "severity": "MODERATE"
  },
  "details": "NVIDIA DGX Spark GB10 contains a vulnerability in SROOT firmware, where an attacker could cause improper validation of integrity. A successful exploit of this vulnerability might lead to information disclosure.",
  "id": "GHSA-r59w-m3rq-r7x9",
  "modified": "2025-11-25T18:32:22Z",
  "published": "2025-11-25T18:32:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-33193"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5720"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-33193"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RCW3-69HQ-M8X4

Vulnerability from github – Published: 2023-02-08 00:30 – Updated: 2023-02-16 18:30
VLAI
Details

An issue was discovered on Microchip RN4870 1.43 devices. An attacker within BLE radio range can cause a denial of service by sending a pair confirm message with wrong values.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-45191"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-08T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered on Microchip RN4870 1.43 devices. An attacker within BLE radio range can cause a denial of service by sending a pair confirm message with wrong values.",
  "id": "GHSA-rcw3-69hq-m8x4",
  "modified": "2023-02-16T18:30:26Z",
  "published": "2023-02-08T00:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45191"
    },
    {
      "type": "WEB",
      "url": "https://www.microchip.com/en-us/support/product-change-notification"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RM76-4MRF-V9R8

Vulnerability from github – Published: 2025-02-06 20:00 – Updated: 2025-07-02 14:20
VLAI
Summary
vLLM uses Python 3.12 built-in hash() which leads to predictable hash collisions in prefix cache
Details

Summary

Maliciously constructed prompts can lead to hash collisions, resulting in prefix cache reuse, which can interfere with subsequent responses and cause unintended behavior.

Details

vLLM's prefix caching makes use of Python's built-in hash() function. As of Python 3.12, the behavior of hash(None) has changed to be a predictable constant value. This makes it more feasible that someone could try exploit hash collisions.

Impact

The impact of a collision would be using cache that was generated using different content. Given knowledge of prompts in use and predictable hashing behavior, someone could intentionally populate the cache using a prompt known to collide with another prompt in use.

Solution

We address this problem by initializing hashes in vllm with a value that is no longer constant and predictable. It will be different each time vllm runs. This restores behavior we got in Python versions prior to 3.12.

Using a hashing algorithm that is less prone to collision (like sha256, for example) would be the best way to avoid the possibility of a collision. However, it would have an impact to both performance and memory footprint. Hash collisions may still occur, though they are no longer straight forward to predict.

To give an idea of the likelihood of a collision, for randomly generated hash values (assuming the hash generation built into Python is uniformly distributed), with a cache capacity of 50,000 messages and an average prompt length of 300, a collision will occur on average once every 1 trillion requests.

References

  • https://github.com/vllm-project/vllm/pull/12621
  • https://github.com/python/cpython/commit/432117cd1f59c76d97da2eaff55a7d758301dbc7
  • https://github.com/python/cpython/pull/99541
Severity
2.6 (Low)
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-25183"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-06T20:00:05Z",
    "nvd_published_at": "2025-02-07T20:15:34Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\nMaliciously constructed prompts can lead to hash collisions, resulting in prefix cache reuse, which can interfere with subsequent responses and cause unintended behavior.\n\n### Details\n\nvLLM\u0027s prefix caching makes use of Python\u0027s built-in hash() function. As of Python 3.12, the behavior of hash(None) has changed to be a predictable constant value. This makes it more feasible that someone could try exploit hash collisions.\n\n### Impact\n\nThe impact of a collision would be using cache that was generated using different content. Given knowledge of prompts in use and predictable hashing behavior, someone could intentionally populate the cache using a prompt known to collide with another prompt in use. \n\n### Solution\n\nWe address this problem by initializing hashes in vllm with a value that is no longer constant and predictable. It will be different each time vllm runs. This restores behavior we got in Python versions prior to 3.12.\n\nUsing a hashing algorithm that is less prone to collision (like sha256, for example) would be the best way to avoid the possibility of a collision. However, it would have an impact to both performance and memory footprint. Hash collisions may still occur, though they are no longer straight forward to predict.\n\nTo give an idea of the likelihood of a collision, for randomly generated hash values (assuming the hash generation built into Python is uniformly distributed), with a cache capacity of 50,000 messages and an average prompt length of 300, a collision will occur on average once every 1 trillion requests.\n\n### References\n\n* https://github.com/vllm-project/vllm/pull/12621\n* https://github.com/python/cpython/commit/432117cd1f59c76d97da2eaff55a7d758301dbc7\n* https://github.com/python/cpython/pull/99541",
  "id": "GHSA-rm76-4mrf-v9r8",
  "modified": "2025-07-02T14:20:34Z",
  "published": "2025-02-06T20:00:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-rm76-4mrf-v9r8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/pull/99541"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/12621"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/commit/432117cd1f59c76d97da2eaff55a7d758301dbc7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/73b35cca7f3745d07d439c197768b25d88b6ab7f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2025-62.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vLLM uses Python 3.12 built-in hash() which leads to predictable hash collisions in prefix cache"
}

GHSA-RP8J-Q5X9-CP57

Vulnerability from github – Published: 2024-06-07 18:30 – Updated: 2024-06-07 18:30
VLAI
Details

An issue was discovered in Samsung Mobile Processor EExynos 2200, Exynos 1480, Exynos 2400. It lacks a check for the validation of native handles, which can result in an Out-of-Bounds Write.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-31958"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-07T17:15:50Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Samsung Mobile Processor EExynos 2200, Exynos 1480, Exynos 2400. It lacks a check for the validation of native handles, which can result in an Out-of-Bounds Write.",
  "id": "GHSA-rp8j-q5x9-cp57",
  "modified": "2024-06-07T18:30:37Z",
  "published": "2024-06-07T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31958"
    },
    {
      "type": "WEB",
      "url": "https://semiconductor.samsung.com/support/quality-support/product-security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RQ6V-X3J8-7QGF

Vulnerability from github – Published: 2026-05-21 17:56 – Updated: 2026-05-21 17:56
VLAI
Summary
Amazon SageMaker Python SDK is missing integrity verification in its Triton inference handler
Details

Summary

Amazon SageMaker Python SDK is an open-source library for training and deploying machine learning models on Amazon SageMaker. An issue exists where, under certain circumstances, the Triton inference handler deserializes model artifacts without performing integrity verification, allowing specially crafted pickle payloads to execute arbitrary code.

Impact

When using ModelBuilder with the Triton inference server, the Triton handler did not perform integrity verification before deserializing model artifacts. A remote authenticated actor with S3 write access to the model artifact path could replace model files with a crafted payload that would execute automatically on the next container lifecycle event, achieving code execution with the SageMaker execution role's IAM permissions.

Impacted versions: >= v2.199.0 AND <= v2.257.1, >= v3.0.0 AND <= v3.7.1

Patches

This issue has been addressed in Amazon SageMaker Python SDK v2.257.2 and v3.8.0. The Triton inference handler now performs integrity verification before deserializing model artifacts. AWS recommend upgrading to the latest version and rebuilding any Triton models previously created with ModelBuilder using the updated SDK. Ensure any forked or derivative code is patched to incorporate the new fixes.

Workarounds

If upgrading is not immediately possible, users should restrict S3 write access to model artifact paths to only trusted principals and monitor for unintended modifications to files in model artifact S3 locations.

References

If there any questions or comments about this advisory, contact AWS Security via vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
6.4 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.257.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "sagemaker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.199.0"
            },
            {
              "fixed": "2.257.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.7.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "sagemaker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-8597"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-21T17:56:39Z",
    "nvd_published_at": "2026-05-14T20:17:21Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nAmazon SageMaker Python SDK is an open-source library for training and deploying machine learning models on Amazon SageMaker. An issue exists where, under certain circumstances, the Triton inference handler deserializes model artifacts without performing integrity verification, allowing specially crafted pickle payloads to execute arbitrary code.\n\n## Impact\nWhen using ModelBuilder with the Triton inference server, the Triton handler did not perform integrity verification before deserializing model artifacts. A remote authenticated actor with S3 write access to the model artifact path could replace model files with a crafted payload that would execute automatically on the next container lifecycle event, achieving code execution with the SageMaker execution role\u0027s IAM permissions.\n\n\n**Impacted versions:** \u003e= v2.199.0 AND \u003c= v2.257.1, \u003e= v3.0.0 AND \u003c= v3.7.1\n\n## Patches\nThis issue has been addressed in Amazon SageMaker Python SDK v2.257.2 and v3.8.0. The Triton inference handler now performs integrity verification before deserializing model artifacts. AWS recommend upgrading to the latest version and rebuilding any Triton models previously created with ModelBuilder using the updated SDK. Ensure any forked or derivative code is patched to incorporate the new fixes.\n\n## Workarounds\nIf upgrading is not immediately possible, users should restrict S3 write access to model artifact paths to only trusted principals and monitor for unintended modifications to files in model artifact S3 locations.\n\n## References\nIf there any questions or comments about this advisory, contact AWS Security via [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.",
  "id": "GHSA-rq6v-x3j8-7qgf",
  "modified": "2026-05-21T17:56:39Z",
  "published": "2026-05-21T17:56:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aws/sagemaker-python-sdk/security/advisories/GHSA-rq6v-x3j8-7qgf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8597"
    },
    {
      "type": "WEB",
      "url": "https://aws.amazon.com/security/security-bulletins/2026-031-aws"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aws/sagemaker-python-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/sagemaker-python-sdk/releases/tag/v2.257.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/sagemaker-python-sdk/releases/tag/v3.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Amazon SageMaker Python SDK is missing integrity verification in its Triton inference handler"
}

GHSA-V2MV-99JP-98VC

Vulnerability from github – Published: 2025-03-14 15:32 – Updated: 2025-03-14 15:32
VLAI
Details

An improper validation of integrity check value vulnerability [CWE-354] in FortiNDR version 7.4.2 and below, version 7.2.1 and below, version 7.1.1 and below, version 7.0.6 and below may allow an authenticated attacker with at least Read/Write permission on system maintenance to install a corrupted firmware image.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-47573"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-14T15:15:43Z",
    "severity": "MODERATE"
  },
  "details": "An improper validation of integrity check value vulnerability [CWE-354] in FortiNDR version 7.4.2 and below, version 7.2.1 and below, version 7.1.1 and below, version 7.0.6 and below may allow an authenticated attacker with at least Read/Write permission on system maintenance to install a corrupted firmware image.",
  "id": "GHSA-v2mv-99jp-98vc",
  "modified": "2025-03-14T15:32:04Z",
  "published": "2025-03-14T15:32:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47573"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-23-461"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VCRJ-5576-FC99

Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2025-11-04 00:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

nfsd: map the EBADMSG to nfserr_io to avoid warning

Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING.

Fix it by mapping EBADMSG to nfserr_io.

nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING

[ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-49875"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T18:15:09Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: map the EBADMSG to nfserr_io to avoid warning\n\nExt4 will throw -EBADMSG through ext4_readdir when a checksum error\noccurs, resulting in the following WARNING.\n\nFix it by mapping EBADMSG to nfserr_io.\n\nnfsd_buffered_readdir\n iterate_dir // -EBADMSG -74\n  ext4_readdir // .iterate_shared\n   ext4_dx_readdir\n    ext4_htree_fill_tree\n     htree_dirblock_to_tree\n      ext4_read_dirblock\n       __ext4_read_dirblock\n        ext4_dirblock_csum_verify\n         warn_no_space_for_csum\n          __warn_no_space_for_csum\n        return ERR_PTR(-EFSBADCRC) // -EBADMSG -74\n nfserrno // WARNING\n\n[  161.115610] ------------[ cut here ]------------\n[  161.116465] nfsd: non-standard errno: -74\n[  161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0\n[  161.118596] Modules linked in:\n[  161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138\n[  161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe\nmu.org 04/01/2014\n[  161.123601] RIP: 0010:nfserrno+0x9d/0xd0\n[  161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6\n 05 ce 2b 61 03 01 e8 99 20 d8 00 \u003c0f\u003e 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33\n[  161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286\n[  161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n[  161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a\n[  161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827\n[  161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021\n[  161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8\n[  161.135244] FS:  0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000\n[  161.136695] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0\n[  161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  161.141519] PKRU: 55555554\n[  161.142076] Call Trace:\n[  161.142575]  ? __warn+0x9b/0x140\n[  161.143229]  ? nfserrno+0x9d/0xd0\n[  161.143872]  ? report_bug+0x125/0x150\n[  161.144595]  ? handle_bug+0x41/0x90\n[  161.145284]  ? exc_invalid_op+0x14/0x70\n[  161.146009]  ? asm_exc_invalid_op+0x12/0x20\n[  161.146816]  ? nfserrno+0x9d/0xd0\n[  161.147487]  nfsd_buffered_readdir+0x28b/0x2b0\n[  161.148333]  ? nfsd4_encode_dirent_fattr+0x380/0x380\n[  161.149258]  ? nfsd_buffered_filldir+0xf0/0xf0\n[  161.150093]  ? wait_for_concurrent_writes+0x170/0x170\n[  161.151004]  ? generic_file_llseek_size+0x48/0x160\n[  161.151895]  nfsd_readdir+0x132/0x190\n[  161.152606]  ? nfsd4_encode_dirent_fattr+0x380/0x380\n[  161.153516]  ? nfsd_unlink+0x380/0x380\n[  161.154256]  ? override_creds+0x45/0x60\n[  161.155006]  nfsd4_encode_readdir+0x21a/0x3d0\n[  161.155850]  ? nfsd4_encode_readlink+0x210/0x210\n[  161.156731]  ? write_bytes_to_xdr_buf+0x97/0xe0\n[  161.157598]  ? __write_bytes_to_xdr_buf+0xd0/0xd0\n[  161.158494]  ? lock_downgrade+0x90/0x90\n[  161.159232]  ? nfs4svc_decode_voidarg+0x10/0x10\n[  161.160092]  nfsd4_encode_operation+0x15a/0x440\n[  161.160959]  nfsd4_proc_compound+0x718/0xe90\n[  161.161818]  nfsd_dispatch+0x18e/0x2c0\n[  161.162586]  svc_process_common+0x786/0xc50\n[  161.163403]  ? nfsd_svc+0x380/0x380\n[  161.164137]  ? svc_printk+0x160/0x160\n[  161.164846]  ? svc_xprt_do_enqueue.part.0+0x365/0x380\n[  161.165808]  ? nfsd_svc+0x380/0x380\n[  161.166523]  ? rcu_is_watching+0x23/0x40\n[  161.167309]  svc_process+0x1a5/0x200\n[  161.168019]  nfsd+0x1f5/0x380\n[  161.168663]  ? nfsd_shutdown_threads+0x260/0x260\n[  161.169554]  kthread+0x1c4/0x210\n[  161.170224]  ? kthread_insert_work_sanity_check+0x80/0x80\n[  161.171246]  ret_from_fork+0x1f/0x30",
  "id": "GHSA-vcrj-5576-fc99",
  "modified": "2025-11-04T00:31:40Z",
  "published": "2024-10-21T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49875"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0ea4333c679f333e23956de743ad17387819d3f2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/340e61e44c1d2a15c42ec72ade9195ad525fd048"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6fe058502f8864649c3d614b06b2235223798f48"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/825789ca94602543101045ad3aad19b2b60c6b2a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c76005adfa93d1a027433331252422078750321f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e9cfecca22a36b927a440abc6307efb9e138fed5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f7d8ee9db94372b8235f5f22bb24381891594c42"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VM7Q-JFHX-RFC9

Vulnerability from github – Published: 2022-12-20 00:30 – Updated: 2022-12-27 21:30
VLAI
Details

The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) accepts PairCon_rmSend with incorrect values.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-46402"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-19T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) accepts PairCon_rmSend with incorrect values.",
  "id": "GHSA-vm7q-jfhx-rfc9",
  "modified": "2022-12-27T21:30:21Z",
  "published": "2022-12-20T00:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46402"
    },
    {
      "type": "WEB",
      "url": "https://microchip.com"
    },
    {
      "type": "WEB",
      "url": "https://www.computer.org/csdl/proceedings-article/sp/2023/933600a521/1He7Yja1AYM"
    },
    {
      "type": "WEB",
      "url": "https://www.computer.org/csdl/proceedings/sp/2023/1He7WWuJExG"
    },
    {
      "type": "WEB",
      "url": "https://www.microchip.com/en-us/products/wireless-connectivity/software-vulnerability-response/deviating-behaviors-in-bluetooth-le"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQ82-PF9C-33H9

Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-06-29 00:00
VLAI
Details

This issue was addressed with improved checks. This issue is fixed in Security Update 2021-004 Mojave, iOS 14.5 and iPadOS 14.5, watchOS 7.4, Security Update 2021-003 Catalina, tvOS 14.5, macOS Big Sur 11.3. Processing maliciously crafted server messages may lead to heap corruption.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-1883"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-08T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "This issue was addressed with improved checks. This issue is fixed in Security Update 2021-004 Mojave, iOS 14.5 and iPadOS 14.5, watchOS 7.4, Security Update 2021-003 Catalina, tvOS 14.5, macOS Big Sur 11.3. Processing maliciously crafted server messages may lead to heap corruption.",
  "id": "GHSA-vq82-pf9c-33h9",
  "modified": "2022-06-29T00:00:40Z",
  "published": "2022-05-24T19:13:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1883"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212317"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212323"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212324"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212325"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212530"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212531"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Implementation

Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.

CAPEC-145: Checksum Spoofing

An adversary spoofs a checksum message for the purpose of making a payload appear to have a valid corresponding checksum. Checksums are used to verify message integrity. They consist of some value based on the value of the message they are protecting. Hash codes are a common checksum mechanism. Both the sender and recipient are able to compute the checksum based on the contents of the message. If the message contents change between the sender and recipient, the sender and recipient will compute different checksum values. Since the sender's checksum value is transmitted with the message, the recipient would know that a modification occurred. In checksum spoofing an adversary modifies the message body and then modifies the corresponding checksum so that the recipient's checksum calculation will match the checksum (created by the adversary) in the message. This would prevent the recipient from realizing that a change occurred.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.

CAPEC-75: Manipulating Writeable Configuration Files

Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.

← Back to the CWE list