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

CWE-672

Allowed-with-Review

Operation on a Resource after Expiration or Release

Abstraction: Class · Status: Draft

The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.

133 vulnerabilities reference this CWE, most recent first.

GHSA-8H6Q-7WVM-5W36

Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2026-05-12 12:32
VLAI
Details

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

ACPI: battery: Fix possible crash when unregistering a battery hook

When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash.

Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-49955"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T18:15:16Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: battery: Fix possible crash when unregistering a battery hook\n\nWhen a battery hook returns an error when adding a new battery, then\nthe battery hook is automatically unregistered.\nHowever the battery hook provider cannot know that, so it will later\ncall battery_hook_unregister() on the already unregistered battery\nhook, resulting in a crash.\n\nFix this by using the list head to mark already unregistered battery\nhooks as already being unregistered so that they can be ignored by\nbattery_hook_unregister().",
  "id": "GHSA-8h6q-7wvm-5w36",
  "modified": "2026-05-12T12:32:11Z",
  "published": "2024-10-21T18:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49955"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/07b98400cb0285a6348188aa8c5ec6a2ae0551f7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/76959aff14a0012ad6b984ec7686d163deccdc16"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/76fb2cbf01571926da8ecf6876cc8cb07d3f5183"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9f469ef1c79dac7f9ac1518643a33703918f7e13"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c47843a831e0eae007ad7e848d208e675ba4c132"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ca1fb7942a287b40659cc79551a1de54a2c2e7d5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ca26e8eed9c1c6651f51f7fa38fe444f8573cd1b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ce31847f109c3a5b2abdd19d7bcaafaacfde53de"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/da964de4c18199e14b961b5b2e5e6570552a313c"
    },
    {
      "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:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8QRG-FXFF-9FCM

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

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

net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice

The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs.

To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID.

Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-49953"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T18:15:16Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice\n\nThe km.state is not checked in driver\u0027s delayed work. When\nxfrm_state_check_expire() is called, the state can be reset to\nXFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This\nhappens when xfrm state is deleted, but not freed yet. As\n__xfrm_state_delete() is called again in xfrm timer, the following\ncrash occurs.\n\nTo fix this issue, skip xfrm_state_check_expire() if km.state is not\nXFRM_STATE_VALID.\n\n Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP\n CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core]\n RIP: 0010:__xfrm_state_delete+0x3d/0x1b0\n Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 \u003c48\u003e 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48\n RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246\n RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036\n RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980\n RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000\n R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246\n R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400\n FS:  0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  \u003cIRQ\u003e\n  ? die_addr+0x33/0x90\n  ? exc_general_protection+0x1a2/0x390\n  ? asm_exc_general_protection+0x22/0x30\n  ? __xfrm_state_delete+0x3d/0x1b0\n  ? __xfrm_state_delete+0x2f/0x1b0\n  xfrm_timer_handler+0x174/0x350\n  ? __xfrm_state_delete+0x1b0/0x1b0\n  __hrtimer_run_queues+0x121/0x270\n  hrtimer_run_softirq+0x88/0xd0\n  handle_softirqs+0xcc/0x270\n  do_softirq+0x3c/0x50\n  \u003c/IRQ\u003e\n  \u003cTASK\u003e\n  __local_bh_enable_ip+0x47/0x50\n  mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core]\n  process_one_work+0x137/0x2d0\n  worker_thread+0x28d/0x3a0\n  ? rescuer_thread+0x480/0x480\n  kthread+0xb8/0xe0\n  ? kthread_park+0x80/0x80\n  ret_from_fork+0x2d/0x50\n  ? kthread_park+0x80/0x80\n  ret_from_fork_asm+0x11/0x20\n  \u003c/TASK\u003e",
  "id": "GHSA-8qrg-fxff-9fcm",
  "modified": "2024-11-07T18:31:21Z",
  "published": "2024-10-21T18:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49953"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0b1672834634df9ac9cedf856db9fc36d92c50ef"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/151e7dead1f5399a73c19c4b50307ea48aff1dc0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/7b124695db40d5c9c5295a94ae928a8d67a01c3d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fab615ac9fcb8589222303099975d464d8857527"
    }
  ],
  "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-95W4-863F-9MJ3

Vulnerability from github – Published: 2025-09-05 21:32 – Updated: 2025-09-05 21:32
VLAI
Details

MongoDB Server may allow upsert operations retried within a transaction to violate unique index constraints, potentially causing an invariant failure and server crash during commit. This issue may be triggered by improper WriteUnitOfWork state management. This issue affects MongoDB Server v6.0 versions prior to 6.0.25, MongoDB Server v7.0 versions prior to 7.0.22 and MongoDB Server v8.0 versions prior to 8.0.12

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-10060"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-05T21:15:34Z",
    "severity": "MODERATE"
  },
  "details": "MongoDB Server may allow upsert operations retried within a transaction to violate unique index constraints, potentially causing an invariant failure and server crash during commit. This issue may be triggered by improper WriteUnitOfWork state management.  This issue affects MongoDB Server v6.0 versions prior to 6.0.25, MongoDB Server v7.0 versions prior to 7.0.22 and MongoDB Server v8.0 versions prior to 8.0.12",
  "id": "GHSA-95w4-863f-9mj3",
  "modified": "2025-09-05T21:32:38Z",
  "published": "2025-09-05T21:32:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10060"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-95524"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9FXP-FXMH-Q3Q6

Vulnerability from github – Published: 2026-09-03 21:31 – Updated: 2026-09-04 18:31
VLAI
Details

Use of released resource in Mobile in Google Chrome on on Android prior to 152.0.7977.82 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-85044"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-03T20:17:23Z",
    "severity": "MODERATE"
  },
  "details": "Use of released resource in Mobile in Google Chrome on on Android prior to 152.0.7977.82 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-9fxp-fxmh-q3q6",
  "modified": "2026-09-04T18:31:15Z",
  "published": "2026-09-03T21:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85044"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_01882797386.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/517482830"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9J23-GV58-CFXH

Vulnerability from github – Published: 2026-08-25 21:31 – Updated: 2026-08-28 00:31
VLAI
Details

Operation on a resource after expiration or release in Network in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-79010"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T21:17:56Z",
    "severity": "MODERATE"
  },
  "details": "Operation on a resource after expiration or release in Network in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-9j23-gv58-cfxh",
  "modified": "2026-08-28T00:31:58Z",
  "published": "2026-08-25T21:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79010"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/08/stable-channel-update-for-desktop_0256176589.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/497869284"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C58X-2X8H-GWQ3

Vulnerability from github – Published: 2024-05-14 18:30 – Updated: 2024-05-14 18:30
VLAI
Details

A flaw was found in the QEMU Virtio PCI Bindings (hw/virtio/virtio-pci.c). An improper release and use of the irqfd for vector 0 during the boot process leads to a guest triggerable crash via vhost_net_stop(). This flaw allows a malicious guest to crash the QEMU process on the host.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-4693"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-14T15:44:26Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the QEMU Virtio PCI Bindings (hw/virtio/virtio-pci.c). An improper release and use of the irqfd for vector 0 during the boot process leads to a guest triggerable crash via vhost_net_stop(). This flaw allows a malicious guest to crash the QEMU process on the host.",
  "id": "GHSA-c58x-2x8h-gwq3",
  "modified": "2024-05-14T18:30:56Z",
  "published": "2024-05-14T18:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4693"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-4693"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2279965"
    }
  ],
  "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-C9P5-PWMJ-4F88

Vulnerability from github – Published: 2026-05-08 09:31 – Updated: 2026-05-08 21:31
VLAI
Details

Apache::Session versions through 1.94 for Perl re-creates deleted sessions.

The session stores Apache::Session::Store::File and Apache::Session::Store::DB_File will create a session that does not exist. This can lead to sessions being revived, potentially with data that was to be deleted.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2013-10075"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-08T08:16:43Z",
    "severity": "CRITICAL"
  },
  "details": "Apache::Session versions through 1.94 for Perl re-creates deleted sessions.\n\nThe session stores Apache::Session::Store::File and Apache::Session::Store::DB_File will create a session that does not exist.  This can lead to sessions being revived, potentially with data that was to be deleted.",
  "id": "GHSA-c9p5-pwmj-4f88",
  "modified": "2026-05-08T21:31:24Z",
  "published": "2026-05-08T09:31:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-10075"
    },
    {
      "type": "WEB",
      "url": "https://rt.cpan.org/Public/Bug/Display.html?id=83525"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/05/08/12"
    }
  ],
  "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"
    }
  ]
}

GHSA-CM26-5974-52H8

Vulnerability from github – Published: 2026-07-14 20:28 – Updated: 2026-07-14 20:28
VLAI
Summary
nebula-mesh: Certificate revocation is never enforced at the mesh
Details

Summary

nebula-mesh revokes a host by adding its certificate fingerprint to a per-CA blocklist and shipping that list to every other agent on each poll. Slack's Nebula enforces certificate revocation ONLY through the pki.blocklist list in config.yml (no CRL/OCSP). The project's own code states this: internal/pki/durations.go:15 — "Revocation via the blocklist remains the immediate security control."

The server side is fully implemented (computes per-CA blocklist via GetBlocklistForCA, returns it in the agent-updates response, sets has_updates=true when non-empty). The agent side was never implemented:

  1. The agent decodes the blocklist JSON field into UpdatesResponse.Blocklist (internal/agent/poller.go:33) and then DISCARDS it — poll() applies CertificatePEM, CACertPEM, ConfigYAML, but never references updates.Blocklist (internal/agent/poller.go:300-339).
  2. The config generator has NO field to emit pki.blocklistpkiSection is only ca/cert/key (internal/configgen/marshal.go:42-46) and GeneratorInput carries no blocklist (internal/configgen/generator.go:23-52). So even the server-rendered config.yml shipped via ConfigYAML cannot carry it.

Result: a blocked/offboarded/compromised host's certificate is never rejected by its peers. Its handshakes keep succeeding for the full remaining cert lifetime — up to 30 days for agent hosts (DefaultAgentCertDuration) and 365 days for mobile hosts (DefaultMobileCertDuration). Blocking a host in the UI/API has no effect on the data plane.

Affected components

  • Agent drops the blocklist: internal/agent/poller.go:33 (decode target), internal/agent/poller.go:300-339 (poll() applies cert/CA/config, never the blocklist).
  • Generator cannot emit it: internal/configgen/marshal.go:42-46 (pkiSection{CA,Cert,Key}), internal/configgen/generator.go:23-52 (GeneratorInput has no blocklist), internal/api/enroll.go:255-330 (renderHostConfig, source of shipped ConfigYAML).
  • Server correctly produces/ships it (proves intent): internal/store/sqlite.go:2034 (GetBlocklistForCA), internal/api/updates.go:182-191 (resp.Blocklist), internal/api/updates.go:277 (has_updates set on blocklist change).
  • Dead helper: internal/pki/blocklist.go (Blocklist type) is never used in non-test code — no server-side enforcement either.

Reachability (hop by hop)

  1. Operator clicks Block on host B (or B is compromised/offboarded). B's fingerprint enters the per-CA blocklist table.
  2. Every other host A under the same CA polls GET /api/v1/agent/updates; server returns blocklist: [<B-fp>, ...] and has_updates=true.
  3. A's agent decodes Blocklist then discards it; poll() has no blocklist branch.
  4. Even on a config re-render, configgen.Generate emits pki: {ca,cert,key} with no blocklist key (proven by PoC).
  5. A's Nebula daemon has an empty blocklist and accepts handshakes from B's still-valid cert. B keeps full mesh access.

Impact

Revocation is the only in-band mechanism that isolates a compromised/offboarded host from a Nebula mesh. Because the blocklist never reaches any peer's config.yml, a Blocked host retains full overlay reachability to every peer under its CA (and internal services on the mesh) for up to 30d (agent) / 365d (mobile). An attacker who exfiltrates host.key+host.crt can run stock slackhq/nebula directly, ignore the agent's 403/410 poll responses, and stay connected after the operator revokes the host. Operator-visible state (UI shows blocked, audit log records it) is misleading.

Proof of Concept (benign)

internal/configgen/blocklist_poc_test.go renders a fully-populated host config and asserts the output contains the pki section but NO blocklist key:

$ go test ./internal/configgen/ -run TestPoC_NMESH001 -v
=== RUN   TestPoC_NMESH001_GeneratedConfigOmitsBlocklist
    CONFIRMED: generated config has a pki section but no blocklist key
    pki:
      ca: /etc/nebula/ca.crt
      cert: /etc/nebula/host.crt
      key: /etc/nebula/host.key
    ...
--- PASS

The agent half is verifiable by inspection: poll() has branches for CertificatePEM/CACertPEM/ConfigYAML/RekeyRequired but none for Blocklist.

Distinctness

NOT a duplicate of GHSA-339v / CVE-2026-53602 (revocation durability = a blocked host getting a NEW cert re-issued; its fix CheckIssuanceAllowed is present and orthogonal). This bug is that the EXISTING cert is never rejected at peers — the distribution/enforcement layer. Checked against all 17 known advisories; none cover blocklist application in the agent or pki.blocklist generation.

Remediation

  1. Add Blocklist []safeString to pkiSection (yaml blocklist,omitempty) and GeneratorInput; consider also pki.disconnect_invalid: true.
  2. Have the agent apply updates.Blocklist by re-rendering/rewriting config.yml + SIGHUP (same path as ConfigYAML). Simplest: fold the blocklist into the server-rendered ConfigYAML so it flows through the existing write path.
  3. Add a regression test asserting a non-empty server blocklist yields a pki.blocklist entry in the agent's written config.yml.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/forgekeep/nebula-mesh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-299",
      "CWE-672"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T20:28:18Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nnebula-mesh revokes a host by adding its certificate fingerprint to a per-CA blocklist and shipping that list to every other agent on each poll. Slack\u0027s Nebula enforces certificate revocation ONLY through the `pki.blocklist` list in `config.yml` (no CRL/OCSP). The project\u0027s own code states this: `internal/pki/durations.go:15` \u2014 \"Revocation via the blocklist remains the immediate security control.\"\n\nThe server side is fully implemented (computes per-CA blocklist via `GetBlocklistForCA`, returns it in the agent-updates response, sets `has_updates=true` when non-empty). The agent side was never implemented:\n\n1. The agent decodes the `blocklist` JSON field into `UpdatesResponse.Blocklist` (`internal/agent/poller.go:33`) and then DISCARDS it \u2014 `poll()` applies `CertificatePEM`, `CACertPEM`, `ConfigYAML`, but never references `updates.Blocklist` (`internal/agent/poller.go:300-339`).\n2. The config generator has NO field to emit `pki.blocklist` \u2014 `pkiSection` is only `ca`/`cert`/`key` (`internal/configgen/marshal.go:42-46`) and `GeneratorInput` carries no blocklist (`internal/configgen/generator.go:23-52`). So even the server-rendered `config.yml` shipped via `ConfigYAML` cannot carry it.\n\nResult: a blocked/offboarded/compromised host\u0027s certificate is never rejected by its peers. Its handshakes keep succeeding for the full remaining cert lifetime \u2014 up to 30 days for agent hosts (`DefaultAgentCertDuration`) and 365 days for mobile hosts (`DefaultMobileCertDuration`). Blocking a host in the UI/API has no effect on the data plane.\n\n### Affected components\n\n- Agent drops the blocklist: `internal/agent/poller.go:33` (decode target), `internal/agent/poller.go:300-339` (poll() applies cert/CA/config, never the blocklist).\n- Generator cannot emit it: `internal/configgen/marshal.go:42-46` (`pkiSection{CA,Cert,Key}`), `internal/configgen/generator.go:23-52` (`GeneratorInput` has no blocklist), `internal/api/enroll.go:255-330` (`renderHostConfig`, source of shipped ConfigYAML).\n- Server correctly produces/ships it (proves intent): `internal/store/sqlite.go:2034` (`GetBlocklistForCA`), `internal/api/updates.go:182-191` (`resp.Blocklist`), `internal/api/updates.go:277` (`has_updates` set on blocklist change).\n- Dead helper: `internal/pki/blocklist.go` (`Blocklist` type) is never used in non-test code \u2014 no server-side enforcement either.\n\n### Reachability (hop by hop)\n\n1. Operator clicks Block on host B (or B is compromised/offboarded). B\u0027s fingerprint enters the per-CA `blocklist` table.\n2. Every other host A under the same CA polls `GET /api/v1/agent/updates`; server returns `blocklist: [\u003cB-fp\u003e, ...]` and `has_updates=true`.\n3. A\u0027s agent decodes `Blocklist` then discards it; `poll()` has no blocklist branch.\n4. Even on a config re-render, `configgen.Generate` emits `pki: {ca,cert,key}` with no `blocklist` key (proven by PoC).\n5. A\u0027s Nebula daemon has an empty blocklist and accepts handshakes from B\u0027s still-valid cert. B keeps full mesh access.\n\n### Impact\n\nRevocation is the only in-band mechanism that isolates a compromised/offboarded host from a Nebula mesh. Because the blocklist never reaches any peer\u0027s config.yml, a Blocked host retains full overlay reachability to every peer under its CA (and internal services on the mesh) for up to 30d (agent) / 365d (mobile). An attacker who exfiltrates `host.key`+`host.crt` can run stock slackhq/nebula directly, ignore the agent\u0027s 403/410 poll responses, and stay connected after the operator revokes the host. Operator-visible state (UI shows blocked, audit log records it) is misleading.\n\n### Proof of Concept (benign)\n\n`internal/configgen/blocklist_poc_test.go` renders a fully-populated host config and asserts the output contains the `pki` section but NO `blocklist` key:\n\n```\n$ go test ./internal/configgen/ -run TestPoC_NMESH001 -v\n=== RUN   TestPoC_NMESH001_GeneratedConfigOmitsBlocklist\n    CONFIRMED: generated config has a pki section but no blocklist key\n    pki:\n      ca: /etc/nebula/ca.crt\n      cert: /etc/nebula/host.crt\n      key: /etc/nebula/host.key\n    ...\n--- PASS\n```\n\nThe agent half is verifiable by inspection: `poll()` has branches for CertificatePEM/CACertPEM/ConfigYAML/RekeyRequired but none for Blocklist.\n\n### Distinctness\n\nNOT a duplicate of GHSA-339v / CVE-2026-53602 (revocation durability = a blocked host getting a NEW cert re-issued; its fix `CheckIssuanceAllowed` is present and orthogonal). This bug is that the EXISTING cert is never rejected at peers \u2014 the distribution/enforcement layer. Checked against all 17 known advisories; none cover blocklist application in the agent or `pki.blocklist` generation.\n\n### Remediation\n\n1. Add `Blocklist []safeString` to `pkiSection` (yaml `blocklist,omitempty`) and `GeneratorInput`; consider also `pki.disconnect_invalid: true`.\n2. Have the agent apply `updates.Blocklist` by re-rendering/rewriting `config.yml` + SIGHUP (same path as `ConfigYAML`). Simplest: fold the blocklist into the server-rendered `ConfigYAML` so it flows through the existing write path.\n3. Add a regression test asserting a non-empty server blocklist yields a `pki.blocklist` entry in the agent\u0027s written config.yml.",
  "id": "GHSA-cm26-5974-52h8",
  "modified": "2026-07-14T20:28:18Z",
  "published": "2026-07-14T20:28:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/forgekeep/nebula-mesh/security/advisories/GHSA-cm26-5974-52h8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/forgekeep/nebula-mesh/commit/0426e2f224a9b1e2029029bf923c93ed39d21cdb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/forgekeep/nebula-mesh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/forgekeep/nebula-mesh/releases/tag/v0.7.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "nebula-mesh: Certificate revocation is never enforced at the mesh"
}

GHSA-F77J-WJFQ-QGMP

Vulnerability from github – Published: 2026-03-16 21:34 – Updated: 2026-03-16 21:34
VLAI
Details

Mattermost versions 10.11.x <= 10.11.10 Fail to invalidate cached permalink preview data when a user loses channel access which allows the user to continue viewing private channel content via previously cached permalink previews until cache reset or relogin.. Mattermost Advisory ID: MMSA-2026-00580

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-1629"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-16T21:16:19Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 10.11.x \u003c= 10.11.10 Fail to invalidate cached permalink preview data when a user loses channel access which allows the user to continue viewing private channel content via previously cached permalink previews until cache reset or relogin.. Mattermost Advisory ID: MMSA-2026-00580",
  "id": "GHSA-f77j-wjfq-qgmp",
  "modified": "2026-03-16T21:34:32Z",
  "published": "2026-03-16T21:34:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1629"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FGVG-65VF-2W8H

Vulnerability from github – Published: 2026-05-28 21:32 – Updated: 2026-05-28 21:32
VLAI
Details

Operation on a Resource after Expiration or Termination (CWE-672) in Kibana can lead to unauthorized information disclosure. A logic error in how expiration timestamps were validated allowed a time-bounded access token to remain usable beyond its intended validity window, enabling an unauthenticated actor in possession of the token to retrieve the associated content after expiration.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-33463"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-28T20:16:22Z",
    "severity": "MODERATE"
  },
  "details": "Operation on a Resource after Expiration or Termination (CWE-672) in Kibana can lead to unauthorized information disclosure. A logic error in how expiration timestamps were validated allowed a time-bounded access token to remain usable beyond its intended validity window, enabling an unauthenticated actor in possession of the token to retrieve the associated content after expiration.",
  "id": "GHSA-fgvg-65vf-2w8h",
  "modified": "2026-05-28T21:32:03Z",
  "published": "2026-05-28T21:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33463"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/8-19-16-9-3-5-security-update-esa-2026-33/386551"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.