GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-754

Allowed-with-Review

Improper Check for Unusual or Exceptional Conditions

Abstraction: Class · Status: Incomplete

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

955 vulnerabilities reference this CWE, most recent first.

GHSA-8X3W-QJ7J-GQHF

Vulnerability from github – Published: 2026-02-04 20:24 – Updated: 2026-02-04 20:24
VLAI
Summary
openmls has improper tag validation
Details

Membership and confirmation tags may not be checked correctly due to a missing length check. Any tag that is shorter than the expected tag, but matches up to its length, as well as any empty tag is considered valid.

Impact

The vulnerability affects a secondary authentication guarantee that MLS provides in certain scenarios. The primary authentication guarantee for all messages comes from the signature on MLS messages. This guarantee is not affected by the vulnerability.
The secondary authentication attests to the group membership of the message author. For MLS private messages, it is implied in the AEAD. For MLS public messages, it is expressed as the ‘membership tag’, a MAC whose key is derived from the private group state only known to group members.

In addition, for public Commit messages, the ‘confirmation tag’ works in a similar manner. Its purpose is to help members who processed the Commit message to ascertain that they now have the same view on the group as the creator of the Commit message for both the private and public group state.

The vulnerability lets an attacker create MLS messages with a truncated tag that are considered valid nonetheless.

The vulnerability does not affect the primary authentication guarantees of MLS, but breaks post-compromise security (PCS) of the MLS authentication guarantees. As a consequence, an adversary that has compromised a member’s signature key can create valid-looking proposals even after the affected member has successfully updated its key material. However, this is only possible in applications where the following conditions are met:

  • The application uses public MLS messages (i.e. it has not restricted the wire format type to private MLS messages only), and
  • the application supports proposals by reference (aka standalone proposals).

Note that, in deployments that allow external Commits, an attacker in possession of a member’s signature key can insert itself into the group without having to forge a membership tag.

Patches

There are two ways to mitigate the issue:

  • Upgrade to openmls v0.7.2: This minor release includes a fix for the issue and bumps the libcrux dependencies. This release does not contain any breaking changes from v0.7.1.
  • Upgrade to openmls v0.8.0: This release contains the fix, as well as other improvements. The list of changes is in CHANGELOG.md. Some of the changes are breaking API changes.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "openmls"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-04T20:24:03Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Membership and confirmation tags may not be checked correctly due to a missing length check. Any tag that is shorter than the expected tag, but matches up to its length, as well as any empty tag is considered valid.\n\n### Impact\n\nThe vulnerability affects a secondary authentication guarantee that MLS provides in certain scenarios. The primary authentication guarantee for all messages comes from the signature on MLS messages. This guarantee is *not* affected by the vulnerability.  \nThe secondary authentication attests to the group membership of the message author. For MLS private messages, it is implied in the AEAD. For MLS public messages, it is expressed as the \u2018membership tag\u2019, a MAC whose key is derived from the private group state only known to group members.\n\nIn addition, for public Commit messages, the \u2018confirmation tag\u2019 works in a similar manner. Its purpose is to help members who processed the Commit message to ascertain that they now have the same view on the group as the creator of the Commit message for both the private and public group state. \n\nThe vulnerability lets an attacker create MLS messages with a truncated tag that are considered valid nonetheless.\n\nThe vulnerability does not affect the primary authentication guarantees of MLS, but breaks post-compromise security (PCS) of the MLS authentication guarantees. As a consequence, an adversary that has compromised a member\u2019s signature key can create valid-looking proposals even after the affected member has successfully updated its key material. However, this is only possible in applications where the following conditions are met:\n\n- The application uses public MLS messages (i.e. it has not restricted the wire format type to private MLS messages only), and  \n- the application supports proposals by reference (aka standalone proposals).\n\nNote that, in deployments that allow external Commits, an attacker in possession of a member\u2019s signature key can insert itself into the group without having to forge a membership tag.\n\n### Patches\n\nThere are two ways to mitigate the issue:\n\n- Upgrade to openmls v0.7.2: This minor release includes a fix for the issue and bumps the libcrux dependencies. This release does not contain any breaking changes from v0.7.1.  \n- Upgrade to openmls v0.8.0: This release contains the fix, as well as other improvements. The list of changes is in [CHANGELOG.md](https://github.com/openmls/openmls/blob/main/CHANGELOG.md). Some of the changes are breaking API changes.",
  "id": "GHSA-8x3w-qj7j-gqhf",
  "modified": "2026-02-04T20:24:03Z",
  "published": "2026-02-04T20:24:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openmls/openmls/security/advisories/GHSA-8x3w-qj7j-gqhf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openmls/openmls/commit/91ec049ffc2fa3766110223aa2aabe0303837af8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openmls/openmls"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openmls/openmls/releases/tag/openmls-v0.7.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "openmls has improper tag validation"
}

GHSA-8XQ6-23CC-G599

Vulnerability from github – Published: 2026-03-10 21:32 – Updated: 2026-03-11 15:31
VLAI
Details

In dhd_tcpdata_info_get of dhd_ip.c, there is a possible Denial of Service due to a precondition check failure. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-0109"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-10T21:16:44Z",
    "severity": "HIGH"
  },
  "details": "In dhd_tcpdata_info_get of dhd_ip.c, there is a possible Denial of Service due to a precondition check failure. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-8xq6-23cc-g599",
  "modified": "2026-03-11T15:31:46Z",
  "published": "2026-03-10T21:32:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0109"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/docs/security/bulletin/2026/2026-03-01"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/docs/security/bulletin/pixel/2026/2026-03-01"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/pixel/2026-03-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-92WM-282G-VW3W

Vulnerability from github – Published: 2024-02-28 09:30 – Updated: 2025-01-08 18:30
VLAI
Details

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

f2fs: fix panic during f2fs_resize_fs()

f2fs_resize_fs() hangs in below callstack with testcase: - mkfs 16GB image & mount image - dd 8GB fileA - dd 8GB fileB - sync - rm fileA - sync - resize filesystem to 8GB

kernel BUG at segment.c:2484! Call Trace: allocate_segment_by_default+0x92/0xf0 [f2fs] f2fs_allocate_data_block+0x44b/0x7e0 [f2fs] do_write_page+0x5a/0x110 [f2fs] f2fs_outplace_write_data+0x55/0x100 [f2fs] f2fs_do_write_data_page+0x392/0x850 [f2fs] move_data_page+0x233/0x320 [f2fs] do_garbage_collect+0x14d9/0x1660 [f2fs] free_segment_range+0x1f7/0x310 [f2fs] f2fs_resize_fs+0x118/0x330 [f2fs] __f2fs_ioctl+0x487/0x3680 [f2fs] __x64_sys_ioctl+0x8e/0xd0 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9

The root cause is we forgot to check that whether we have enough space in resized filesystem to store all valid blocks in before-resizing filesystem, then allocator will run out-of-space during block migration in free_segment_range().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-47007"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-28T09:15:38Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix panic during f2fs_resize_fs()\n\nf2fs_resize_fs() hangs in below callstack with testcase:\n- mkfs 16GB image \u0026 mount image\n- dd 8GB fileA\n- dd 8GB fileB\n- sync\n- rm fileA\n- sync\n- resize filesystem to 8GB\n\nkernel BUG at segment.c:2484!\nCall Trace:\n allocate_segment_by_default+0x92/0xf0 [f2fs]\n f2fs_allocate_data_block+0x44b/0x7e0 [f2fs]\n do_write_page+0x5a/0x110 [f2fs]\n f2fs_outplace_write_data+0x55/0x100 [f2fs]\n f2fs_do_write_data_page+0x392/0x850 [f2fs]\n move_data_page+0x233/0x320 [f2fs]\n do_garbage_collect+0x14d9/0x1660 [f2fs]\n free_segment_range+0x1f7/0x310 [f2fs]\n f2fs_resize_fs+0x118/0x330 [f2fs]\n __f2fs_ioctl+0x487/0x3680 [f2fs]\n __x64_sys_ioctl+0x8e/0xd0\n do_syscall_64+0x33/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nThe root cause is we forgot to check that whether we have enough space\nin resized filesystem to store all valid blocks in before-resizing\nfilesystem, then allocator will run out-of-space during block migration\nin free_segment_range().",
  "id": "GHSA-92wm-282g-vw3w",
  "modified": "2025-01-08T18:30:41Z",
  "published": "2024-02-28T09:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47007"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1c20a4896409f5ca1c770e1880c33d0a28a8b10f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3ab0598e6d860ef49d029943ba80f627c15c15d6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/822054e5026c43b1dd60cf387dd999e95ee2ecc2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/860afd680d9cc1dabd61cda3cd246f60aa1eb705"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9328-GCFQ-P269

Vulnerability from github – Published: 2024-05-18 00:30 – Updated: 2024-11-04 21:30
VLAI
Summary
Tor Arti's STUB circuits incorrectly have a length of 2
Details

In Tor Arti before 1.2.3, STUB circuits incorrectly have a length of 2 (with lite vanguards), aka TROVE-2024-003.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "arti"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.2.2"
            },
            {
              "fixed": "1.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.2.2"
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "tor-circmgr"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.18.0"
            },
            {
              "fixed": "0.18.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.18.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2024-35312"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-670",
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-20T16:18:10Z",
    "nvd_published_at": "2024-05-17T22:15:07Z",
    "severity": "HIGH"
  },
  "details": "In Tor Arti before 1.2.3, STUB circuits incorrectly have a length of 2 (with lite vanguards), aka TROVE-2024-003.",
  "id": "GHSA-9328-gcfq-p269",
  "modified": "2024-11-04T21:30:45Z",
  "published": "2024-05-18T00:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35312"
    },
    {
      "type": "PACKAGE",
      "url": "https://gitlab.torproject.org/tpo/core/arti"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHANGELOG.md#arti-123-15-may-2024"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.torproject.org/tpo/core/arti/-/commit/da95138c14f762c706e46e89c6adfa46fcd5252c"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.torproject.org/tpo/core/arti/-/issues/1409"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2145"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2154"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2156"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/TROVE"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0339.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Tor Arti\u0027s STUB circuits incorrectly have a length of 2"
}

GHSA-93C4-8FXM-4WQ3

Vulnerability from github – Published: 2025-01-08 18:30 – Updated: 2025-11-03 21:32
VLAI
Details

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

drm/sti: avoid potential dereference of error pointers

The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-56776"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-08T18:15:18Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sti: avoid potential dereference of error pointers\n\nThe return value of drm_atomic_get_crtc_state() needs to be\nchecked. To avoid use of error pointer \u0027crtc_state\u0027 in case\nof the failure.",
  "id": "GHSA-93c4-8fxm-4wq3",
  "modified": "2025-11-03T21:32:05Z",
  "published": "2025-01-08T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56776"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/40725c5fabee804fecce41d4d5c5bae80c45e1c4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/831214f77037de02afc287eae93ce97f218d8c04"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8ab73ac97c0fa528f66eeccd9bb53eb6eb7d20dc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e98ff67f5a68114804607de549c2350d27628fc7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f67786293193cf01ebcc6fdbcbd1587b24f52679"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-94MV-98XV-9MQQ

Vulnerability from github – Published: 2024-02-28 09:30 – Updated: 2025-01-08 18:30
VLAI
Details

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

net/sched: act_ct: fix wild memory access when clearing fragments

while testing re-assembly/re-fragmentation using act_ct, it's possible to observe a crash like the following one:

KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f] CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S 5.12.0-rc7+ #424 Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0 Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203 RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350 R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000 R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160 FS: 0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: inet_frag_destroy+0xa9/0x150 call_timer_fn+0x2d/0x180 run_timer_softirq+0x4fe/0xe70 __do_softirq+0x197/0x5a0 irq_exit_rcu+0x1de/0x200 sysvec_apic_timer_interrupt+0x6b/0x80

when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb results in putting random data in FRAG_CB(), and this causes those "wild" memory accesses later, when the rbtree is purged. Never overwrite the skb cb in case tcf_ct_handle_fragments() returns -EINPROGRESS.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-47014"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-28T09:15:38Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_ct: fix wild memory access when clearing fragments\n\nwhile testing re-assembly/re-fragmentation using act_ct, it\u0027s possible to\nobserve a crash like the following one:\n\n KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f]\n CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S                5.12.0-rc7+ #424\n Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017\n RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0\n Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 \u003c42\u003e 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48\n RSP: 0018:ffff888c31449db8 EFLAGS: 00010203\n RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960\n RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e\n RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350\n R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000\n R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160\n FS:  0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  \u003cIRQ\u003e\n  inet_frag_destroy+0xa9/0x150\n  call_timer_fn+0x2d/0x180\n  run_timer_softirq+0x4fe/0xe70\n  __do_softirq+0x197/0x5a0\n  irq_exit_rcu+0x1de/0x200\n  sysvec_apic_timer_interrupt+0x6b/0x80\n  \u003c/IRQ\u003e\n\nwhen act_ct temporarily stores an IP fragment, restoring the skb qdisc cb\nresults in putting random data in FRAG_CB(), and this causes those \"wild\"\nmemory accesses later, when the rbtree is purged. Never overwrite the skb\ncb in case tcf_ct_handle_fragments() returns -EINPROGRESS.",
  "id": "GHSA-94mv-98xv-9mqq",
  "modified": "2025-01-08T18:30:41Z",
  "published": "2024-02-28T09:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47014"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0648941f4c8bbf8b4b6c0b270889ae7aa769b921"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f77bd544a6bbe69aa50d9ed09f13494cf36ff806"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-954R-QQ48-9VR2

Vulnerability from github – Published: 2026-03-24 15:30 – Updated: 2026-03-24 21:31
VLAI
Details

Incorrect boundary conditions in the Graphics component. This vulnerability affects Firefox < 149 and Firefox ESR < 140.9.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-4713"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-24T13:16:07Z",
    "severity": "HIGH"
  },
  "details": "Incorrect boundary conditions in the Graphics component. This vulnerability affects Firefox \u003c 149 and Firefox ESR \u003c 140.9.",
  "id": "GHSA-954r-qq48-9vr2",
  "modified": "2026-03-24T21:31:22Z",
  "published": "2026-03-24T15:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4713"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2018113"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-20"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-22"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-23"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-24"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9622-2JM8-94X7

Vulnerability from github – Published: 2026-05-29 00:38 – Updated: 2026-05-29 21:31
VLAI
Details

Improper Check for Unusual or Exceptional Conditions vulnerability in Drupal SAML SSO - Service Provider allows Privilege Escalation.

This issue affects SAML SSO - Service Provider: from 0.0.0 before 3.1.4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-5343"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-28T23:16:44Z",
    "severity": "HIGH"
  },
  "details": "Improper Check for Unusual or Exceptional Conditions vulnerability in Drupal SAML SSO - Service Provider allows Privilege Escalation.\n\nThis issue affects SAML SSO - Service Provider: from 0.0.0 before 3.1.4.",
  "id": "GHSA-9622-2jm8-94x7",
  "modified": "2026-05-29T21:31:18Z",
  "published": "2026-05-29T00:38:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5343"
    },
    {
      "type": "WEB",
      "url": "https://www.drupal.org/sa-contrib-2026-031"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-96H7-CV3R-XQWX

Vulnerability from github – Published: 2025-01-31 15:30 – Updated: 2025-01-31 15:30
VLAI
Details

IBM Security Verify Directory 10.0 through 10.0.3 is vulnerable to a denial of service when sending an LDAP extended operation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-45650"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-31T15:15:13Z",
    "severity": "HIGH"
  },
  "details": "IBM Security Verify Directory 10.0 through 10.0.3 is vulnerable to a denial of service when sending an LDAP extended operation.",
  "id": "GHSA-96h7-cv3r-xqwx",
  "modified": "2025-01-31T15:30:45Z",
  "published": "2025-01-31T15:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45650"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7182169"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-977J-XJ7Q-2JR9

Vulnerability from github – Published: 2020-01-28 21:32 – Updated: 2024-10-30 21:27
VLAI
Summary
Segmentation faultin TensorFlow when converting a Python string to `tf.float16`
Details

Impact

Converting a string (from Python) to a tf.float16 value results in a segmentation fault in eager mode as the format checks for this use case are only in the graph mode.

This issue can lead to denial of service in inference/training where a malicious attacker can send a data point which contains a string instead of a tf.float16 value.

Similar effects can be obtained by manipulating saved models and checkpoints whereby replacing a scalar tf.float16 value with a scalar string will trigger this issue due to automatic conversions.

This can be easily reproduced by tf.constant("hello", tf.float16), if eager execution is enabled.

Patches

We have patched the vulnerability in GitHub commit 5ac1b9.

We are additionally releasing TensorFlow 1.15.1 and 2.0.1 with this vulnerability patched.

TensorFlow 2.1.0 was released after we fixed the issue, thus it is not affected.

We encourage users to switch to TensorFlow 1.15.1, 2.0.1 or 2.1.0.

For more information

Please consult SECURITY.md for more information regarding the security model and how to contact us with issues and questions.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.15.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.0.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.15.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.0.0"
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.15.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.0.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2020-5215"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-01-28T21:24:08Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\n\nConverting a string (from Python) to a `tf.float16` value results in a segmentation fault in eager mode as the format checks for this use case are only in the graph mode.\n\nThis issue can lead to denial of service in inference/training where a malicious attacker can send a data point which contains a string instead of a `tf.float16` value.\n\nSimilar effects can be obtained by manipulating saved models and checkpoints whereby replacing a scalar `tf.float16` value with a scalar string will trigger this issue due to automatic conversions.\n\nThis can be easily reproduced by `tf.constant(\"hello\", tf.float16)`, if eager execution is enabled.\n\n### Patches\nWe have patched the vulnerability in GitHub commit [5ac1b9](https://github.com/tensorflow/tensorflow/commit/5ac1b9e24ff6afc465756edf845d2e9660bd34bf).\n\nWe are additionally releasing TensorFlow 1.15.1 and 2.0.1 with this vulnerability patched.\n\nTensorFlow 2.1.0 was released after we fixed the issue, thus it is not affected.\n\nWe encourage users to switch to TensorFlow 1.15.1, 2.0.1 or 2.1.0.\n\n### For more information\n\nPlease consult [`SECURITY.md`](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.",
  "id": "GHSA-977j-xj7q-2jr9",
  "modified": "2024-10-30T21:27:16Z",
  "published": "2020-01-28T21:32:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-977j-xj7q-2jr9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5215"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/commit/5ac1b9e24ff6afc465756edf845d2e9660bd34bf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2020-303.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2020-338.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2020-258.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tensorflow/tensorflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/releases/tag/v1.15.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/releases/tag/v2.0.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Segmentation faultin TensorFlow when converting a Python string to `tf.float16`"
}

Mitigation MIT-3
Requirements

Strategy: Language Selection

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
Mitigation
Implementation

Check the results of all functions that return a value and verify that the value is expected.

Mitigation
Implementation

If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).

Mitigation MIT-39
Implementation
  • Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
  • If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
  • Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
  • Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-38
Architecture and Design Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.

Mitigation
Architecture and Design

Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.

No CAPEC attack patterns related to this CWE.