CWE-476

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kubernetes-csi/external-snapshotter/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kubernetes-csi/external-snapshotter/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-8569"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-12T21:41:14Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Kubernetes CSI snapshot-controller prior to v2.1.3 and v3.0.2 could panic when processing a VolumeSnapshot custom resource when:\n\n- The VolumeSnapshot referenced a non-existing PersistentVolumeClaim and the VolumeSnapshot did not reference any VolumeSnapshotClass.\n- The snapshot-controller crashes, is automatically restarted by Kubernetes, and processes the same VolumeSnapshot custom resource after the restart, entering an endless crashloop.\n\nOnly the volume snapshot feature is affected by this vulnerability. When exploited, users can\u00e2\u20ac\u2122t take snapshots of their volumes or delete the snapshots. All other Kubernetes functionality is not affected.",
  "id": "GHSA-hwrr-rhmm-vcvf",
  "modified": "2021-05-12T21:41:14Z",
  "published": "2022-02-15T01:57:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8569"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kubernetes-csi/external-snapshotter/issues/380"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/kubernetes-security-announce/c/1EzCr1qUxxU"
    }
  ],
  "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"
    }
  ],
  "summary": "NULL Pointer Dereference in Kubernetes CSI snapshot-controller"
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-14435"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-05-14T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "An exploitable denial of service vulnerability exists in the web server functionality of Moxa EDR-810 V4.1 build 17030317. A specially crafted HTTP URI can cause a null pointer dereference resulting in denial of service. An attacker can send a GET request to \"/MOXA\\_CFG.ini\" without a cookie header to trigger this vulnerability.",
  "id": "GHSA-hwvw-78mc-v67r",
  "modified": "2022-05-13T01:01:36Z",
  "published": "2022-05-13T01:01:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14435"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0474"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-38055"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-18T10:15:38Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel: Fix segfault with PEBS-via-PT with sample_freq\n\nCurrently, using PEBS-via-PT with a sample frequency instead of a sample\nperiod, causes a segfault.  For example:\n\n    BUG: kernel NULL pointer dereference, address: 0000000000000195\n    \u003cNMI\u003e\n    ? __die_body.cold+0x19/0x27\n    ? page_fault_oops+0xca/0x290\n    ? exc_page_fault+0x7e/0x1b0\n    ? asm_exc_page_fault+0x26/0x30\n    ? intel_pmu_pebs_event_update_no_drain+0x40/0x60\n    ? intel_pmu_pebs_event_update_no_drain+0x32/0x60\n    intel_pmu_drain_pebs_icl+0x333/0x350\n    handle_pmi_common+0x272/0x3c0\n    intel_pmu_handle_irq+0x10a/0x2e0\n    perf_event_nmi_handler+0x2a/0x50\n\nThat happens because intel_pmu_pebs_event_update_no_drain() assumes all the\npebs_enabled bits represent counter indexes, which is not always the case.\nIn this particular case, bits 60 and 61 are set for PEBS-via-PT purposes.\n\nThe behaviour of PEBS-via-PT with sample frequency is questionable because\nalthough a PMI is generated (PEBS_PMI_AFTER_EACH_RECORD), the period is not\nadjusted anyway.\n\nPutting that aside, fix intel_pmu_pebs_event_update_no_drain() by passing\nthe mask of counter bits instead of \u0027size\u0027.  Note, prior to the Fixes\ncommit, \u0027size\u0027 would be limited to the maximum counter index, so the issue\nwas not hit.",
  "id": "GHSA-hwwv-phfq-243p",
  "modified": "2025-11-14T18:31:22Z",
  "published": "2025-06-18T12:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38055"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0b1874a5b1173fbcb2185ab828f4c33d067e551e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/99bcd91fabada0dbb1d5f0de44532d8008db93c6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ca51db23166767a8445deb8331c9b8d5205d9287"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-38262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-09T11:15:28Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: serial: uartlite: register uart driver in init\n\nWhen two instances of uart devices are probing, a concurrency race can\noccur. If one thread calls uart_register_driver function, which first\nallocates and assigns memory to \u0027uart_state\u0027 member of uart_driver\nstructure, the other instance can bypass uart driver registration and\ncall ulite_assign. This calls uart_add_one_port, which expects the uart\ndriver to be fully initialized. This leads to a kernel panic due to a\nnull pointer dereference:\n\n[    8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8\n[    8.156982] #PF: supervisor write access in kernel mode\n[    8.156984] #PF: error_code(0x0002) - not-present page\n[    8.156986] PGD 0 P4D 0\n...\n[    8.180668] RIP: 0010:mutex_lock+0x19/0x30\n[    8.188624] Call Trace:\n[    8.188629]  ? __die_body.cold+0x1a/0x1f\n[    8.195260]  ? page_fault_oops+0x15c/0x290\n[    8.209183]  ? __irq_resolve_mapping+0x47/0x80\n[    8.209187]  ? exc_page_fault+0x64/0x140\n[    8.209190]  ? asm_exc_page_fault+0x22/0x30\n[    8.209196]  ? mutex_lock+0x19/0x30\n[    8.223116]  uart_add_one_port+0x60/0x440\n[    8.223122]  ? proc_tty_register_driver+0x43/0x50\n[    8.223126]  ? tty_register_driver+0x1ca/0x1e0\n[    8.246250]  ulite_probe+0x357/0x4b0 [uartlite]\n\nTo prevent it, move uart driver registration in to init function. This\nwill ensure that uart_driver is always registered when probe function\nis called.",
  "id": "GHSA-hx36-fpq9-j3mg",
  "modified": "2025-12-18T18:30:28Z",
  "published": "2025-07-09T12:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38262"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5015eed450005bab6e5cb6810f7a62eab0434fc4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/685d29f2c5057b32c7b1b46f2a7d303b926c8f72"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6bd697b5fc39fd24e2aa418c7b7d14469f550a93"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6db06aaea07bb7c8e33a425cf7b98bf29ee6056e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8e958d10dd0ce5ae674cce460db5c9ca3f25243b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9c905fdbba68a6d73d39a6b7de9b9f0d6c46df87"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f5e4229d94792b40e750f30c92bcf7a3107c72ef"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-37888"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-09T07:16:10Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix null-ptr-deref in mlx5_create_{inner_,}ttc_table()\n\nAdd NULL check for mlx5_get_flow_namespace() returns in\nmlx5_create_inner_ttc_table() and mlx5_create_ttc_table() to prevent\nNULL pointer dereference.",
  "id": "GHSA-hx3g-38mv-vv77",
  "modified": "2025-11-12T21:31:03Z",
  "published": "2025-05-09T09:33:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37888"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0b682680b12b08cd62b113ea92b2938195de1dfe"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/91037037ee3d611ce17f39d75f79c7de394b122a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ecd9d2647ddb4f42a121de648e48659ae1856c39"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-36479"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-24T14:15:12Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfpga: bridge: add owner module and take its refcount\n\nThe current implementation of the fpga bridge assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0027s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the bridge if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_bridge\nstruct and use it to take the module\u0027s refcount. Modify the function for\nregistering a bridge to take an additional owner module parameter and\nrename it to avoid conflicts. Use the old function name for a helper macro\nthat automatically sets the module that registers the bridge as the owner.\nThis ensures compatibility with existing low-level control modules and\nreduces the chances of registering a bridge without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga bridge.\n\nOther changes: opportunistically move put_device() from __fpga_bridge_get()\nto fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since\nthe bridge device is taken in these functions.",
  "id": "GHSA-hx3p-xj26-wxj6",
  "modified": "2025-11-03T21:31:09Z",
  "published": "2024-06-24T15:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36479"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/18dc8366abb6cadcb77668b1a16434654e355d49"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1da11f822042eb6ef4b6064dc048f157a7852529"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6896b6b2e2d9ec4e1b0acb4c1698a75a4b34d125"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d7c4081c54a1d4068de9440957303a76f9e5c95b"
    },
    {
      "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-38659"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-22T16:15:41Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: No more self recovery\n\nWhen a node withdraws and it turns out that it is the only node that has\nthe filesystem mounted, gfs2 currently tries to replay the local journal\nto bring the filesystem back into a consistent state.  Not only is that\na very bad idea, it has also never worked because gfs2_recover_func()\nwill refuse to do anything during a withdraw.\n\nHowever, before even getting to this point, gfs2_recover_func()\ndereferences sdp-\u003esd_jdesc-\u003ejd_inode.  This was a use-after-free before\ncommit 04133b607a78 (\"gfs2: Prevent double iput for journal on error\")\nand is a NULL pointer dereference since then.\n\nSimply get rid of self recovery to fix that.",
  "id": "GHSA-hx42-fcj6-qc8x",
  "modified": "2026-06-01T18:31:21Z",
  "published": "2025-08-22T18:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38659"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1a91ba12abef628b43cada87478328274d988e88"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6784367b2f3cd7b89103de35764f37f152590dbd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/69cf5699a402ee7ae1be53954dc2ae652c0a053c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6ebe17b359bead383581f729e43f591c1c36e159"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/97c94c7dbddc34d353c83b541b3decabf98d04af"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/deb016c1669002e48c431d6fd32ea1c20ef41756"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f5426ffbec971a8f7346a57392d3a901bdee5a9b"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-20677"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-02T03:15:25Z",
    "severity": "MODERATE"
  },
  "details": "In Bluetooth driver, there is a possible system crash due to an uncaught exception. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation. Patch ID: WCNCR00412256; Issue ID: MSV-3284.",
  "id": "GHSA-hx4r-v9cq-h9mg",
  "modified": "2025-06-03T18:30:40Z",
  "published": "2025-06-02T03:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20677"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/June-2025"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/bishopfox/sliver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-29781"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-05T00:26:40Z",
    "nvd_published_at": "2026-03-07T16:15:55Z",
    "severity": "LOW"
  },
  "details": "## 1. Executive Summary\nA vulnerability exists in the Sliver C2 server\u0027s Protobuf unmarshalling logic due to a systemic lack of nil-pointer validation. By extracting valid implant credentials and omitting nested fields in a signed message, an authenticated actor can trigger an unhandled runtime panic. Because the mTLS, WireGuard, and DNS transport layers lack the panic recovery middleware present in the HTTP transport, this results in a global process termination. While requiring post-authentication access (a captured implant), this flaw effectively acts as an infrastructure \"kill-switch,\" instantly severing all active sessions across the entire fleet and requiring a manual server restart to restore operations.\n\n## 2. Vulnerability Details\n### 2.0 Technical Workflow: From Envelope to Handler\nSliver encapsulates all C2 traffic in a generic `sliverpb.Envelope`, which acts as a routing wrapper. When the server receives an Envelope with `Type = 53` (MsgBeaconRegister), the internal router strips the envelope and passes the raw `Data` bytes directly to the vulnerable `handlers.beaconRegisterHandler(implantConn, data)`. This flow is consistent across all transports, but the **error handling** of the transport itself determines the final impact.\n\n### 2.1 BeaconRegister Nil-Pointer Dereference\n- **Vulnerability Type:** Remote Denial of Service via Nil-Pointer Dereference ([CWE-476](https://cwe.mitre.org/data/definitions/476.html))\n- **Component:** `server/handlers/beacons.go`\n- **Affected Functions:** [beaconRegisterHandler](https://github.com/BishopFox/sliver/blob/master/server/handlers/beacons.go#L46-L110).\n- **Severity:** Critical\n- **Complexity:** Low\n\n#### Root Cause Analysis\nThe core of the vulnerability lies in the architectural handling of Protobuf messages within the Go runtime. In `proto3`, all fields are optional by design. When a message contains a nested sub-message (like `Register` inside `BeaconRegister`), the Go Protobuf implementation represents this sub-message as a **pointer**.\n\nIn `server/handlers/beacons.go`, the server unmarshals the incoming data without subsequent validation of its nested structures:\n```Go\nfunc beaconRegisterHandler(implantConn *core.ImplantConnection, data []byte) *sliverpb.Envelope {\n    // ...\n    beaconReg := \u0026sliverpb.BeaconRegister{}\n    err := proto.Unmarshal(data, beaconReg)\n\t// Successful even if \u0027Register\u0027 sub-message is omitted\n    \n    // VULNERABILITY: beaconReg.Register is nil if omitted by sender.\n    // Accessing any property of a nil pointer triggers an immediate runtime panic.\n    beaconRegUUID, _ := uuid.FromString(beaconReg.Register.Uuid) \n    // ...\n}\n```\n\nIf an attacker constructs a `BeaconRegister` message and deliberately omits the `Register` field, `proto.Unmarshal` parses the stream without error but leaves the `Register` pointer as `nil`. The subsequent attempt to access `beaconReg.Register.Uuid` triggers a **Nil-Pointer Dereference**.\n### 2.2 Expanded Inventory: System-Wide Nil-Pointer Vulnerabilities\nBeyond the beacon registration, the investigation revealed a systemic pattern of missing nil-checks across various handlers. These vulnerabilities follow the same root cause: immediate dereferencing of nested Protobuf fields post-unmarshalling.\n\n#### 2.2.1 Remote Implant Vectors (Unauthenticated)\nThese handlers process data from implants. If an implant binary is captured, these can be triggered to crash the server:\n- **Reverse Tunneling (`server/handlers/sessions.go`):** The `createReverseTunnelHandler` panics when `req.Rportfwd` is omitted.\n- **SOCKS Proxying (`server/handlers/sessions.go`):** The `socksDataHandler` fails when the `SocksData` sub-message is absent.\n- **Pivot/Peer Communication (`server/handlers/pivot.go`):** Functions `serverKeyExchange` and `peersToString` dereference `peerEnvelope.Peers` without checking if the peer list is empty or nil.\n\n#### 2.2.2 Authenticated Operator Vectors (gRPC Layer)\nThe Sliver RPC server (`server/rpc/`) is also susceptible. While these require an authenticated operator, they represent a significant stability risk where a malformed request from a custom client or automated script can bring down the entire C2 infrastructure.\n\n| Function            | File                            | Vulnerable Pattern                                      |\n| ------------------- | ------------------------------- | ------------------------------------------------------- |\n| getTimeout          | server/rpc/rpc.go               | `req.GetRequest().Timeout`                              |\n| getError            | server/rpc/rpc.go               | `resp.GetResponse().Err`                                |\n| Portfwd             | server/rpc/rpc-portfwd.go       | `req.Request.SessionID`                                 |\n| GetSystem           | server/rpc/rpc-priv.go          | `req.GetRequest().SessionID`                            |\n| GetPrivileges       | server/rpc/rpc-priv.go          | `req.Request.SessionID`                                 |\n| NetConnPivot        | server/rpc/rpc-pivot.go         | `req.Request.SessionID`                                 |\n| PivotListeners      | server/rpc/rpc-pivot.go         | `req.Request.SessionID`                                 |\n| SocksStart          | server/rpc/rpc-socks.go         | `req.Request.SessionID`                                 |\n| SocksStop           | server/rpc/rpc-socks.go         | `req.Request.SessionID`                                 |\n| RPortfwd            | server/rpc/rpc-rportfwd.go      | `req.Request.SessionID`                                 |\n| Shell               | server/rpc/rpc-shell.go         | `req.Request.SessionID`                                 |\n| ShellResize         | server/rpc/rpc-shell.go         | `req.Request.SessionID`                                 |\n| BackdoorImplant     | server/rpc/rpc-backdoor.go      | `req.Request.SessionID`,\u00a0`req.Request.Timeout`          |\n| CrackstationTrigger | server/rpc/rpc-crackstations.go | `statusUpdate.HostUUID`\u00a0(after unmarshal of\u00a0`req.Data`) |\n| Tasks               | server/rpc/rpc-tasks.go         | `req.Request.SessionID`                                 |\n| ImplantReconfig     | server/rpc/rpc-reconfig.go      | `req.Request.SessionID`                                 |\n| MsfInject           | server/rpc/rpc-msf.go           | `req.Request.SessionID`                                 |\n| Hijack              | server/rpc/rpc-hijack.go        | `req.Request.SessionID`                                 |\n\n---\n\n## 3. Proof of Concept \u0026 Attack Feasibility\n### 3.1 Attack Feasibility: Credential Extraction\nThe exploit requires valid implant credentials, which are inherently embedded in Sliver\u0027s generated binaries. Since these binaries are often deployed to untrusted or compromised environments, credential recovery is a high-probability event. During testing, it was confirmed that an attacker can obtain the required mTLS certificates and Age Secret Keys through:\n- **Static Extraction (Trivial):** By default, running the `strings` utility on the implant binary or dumping the embedded configuration block is sufficient to recover the private keys.\n- **Memory Forensics:** If an implant is captured during execution, the configuration structures can be carved directly from the process memory, bypassing most disk-level obfuscation.\n\n### 3.2 Exploit Execution Flow\nThe provided exploit [mtls_poc.go](https://github.com/skoveit/Sliver-Nil-Pointer-DoS-PoC/blob/main/mtls_poc.go) or [mtls_poc.go](https://gist.github.com/skoveit/a5e52b5c9197fc53e2605a861cd8aa33) demonstrates how a single captured implant can be weaponized into a \"Kill Switch\" for the entire C2 infrastructure. The attack follows these steps:\n1. **Authentication:** Establishes a valid mTLS connection using the extracted certificates.\n2. **Multiplexing:** Negotiates a Yamux stream, bypassing standard network-level protections.\n3. **Payload Construction:** Builds a `BeaconRegister` Protobuf message where the `ID` is defined, but the critical `Register` sub-message is explicitly omitted (set to `nil`).\n4. **Envelope Signing:** Deterministically signs the malicious envelope using the recovered Age private key to ensure it is accepted by the server.\n5. **Trigger:** Sends the malformed payload. Upon receipt, the server\u0027s handler attempts to dereference the missing `Register` pointer, leading to an immediate **Full Server DoS**.\n\n## 4. Transport-Specific Response \u0026 Recovery Analysis\nThe impact of this panic varies significantly depending on the C2 transport used by the implant. While the nil-pointer dereference happens in the shared handler logic, the transport layer determines whether this results in a localized request failure or a total server termination.\n\n### 4.1 HTTP/S Transport\nHTTP-based beacons do **not** crash the entire Sliver server. This is because Sliver utilizes the standard Go `net/http` library.\n\n**Code Reference ([server/c2/http.go](https://github.com/BishopFox/sliver/blob/master/server/c2/http.go)):**\n```go\nserver.HTTPServer = \u0026http.Server{\n    Addr:         fmt.Sprintf(\"%s:%d\", req.Host, req.Port),\n    Handler:      server.router(),\n    // ...\n}\n// ...\ngo server.HTTPServer.ListenAndServe()\n```\n\nBy design, `net/http`\u0027s `ServeHTTP` implementation wraps every connection in a `defer recover()` block. When the [beaconRegisterHandler](https://github.com/BishopFox/sliver/blob/master/server/handlers/beacons.go#L46-L109) panics, the standard library catches it, logs the trace, and simply closes that specific TCP connection. The rest of the server remains unaffected.\n\n### 4.2 mTLS \u0026 WireGuard Transports (Full DoS)\nBoth mTLS and WireGuard utilize the `yamux` multiplexer to handle multiple streams over a single connection. Unlike the HTTP server, Sliver manually manages these goroutines without a global recovery mechanism.\n\n**mTLS [server/c2/mtls.go](https://github.com/BishopFox/sliver/blob/master/server/c2/mtls.go):**\n```go\nif handler, ok := handlers[envelope.Type]; ok {\n    mtlsLog.Debugf(\"Received new mtls message type %d, data: %s\", envelope.Type, envelope.Data)\n    go func(envelope *sliverpb.Envelope) {\n        respEnvelope := handler(implantConn, envelope.Data) // \u003c--- PANIC HERE\n        if respEnvelope != nil {\n            implantConn.Send \u003c- respEnvelope\n        }\n    }(envelope)\n}\n```\n\n**WireGuard [server/c2/wireguard.go](https://github.com/BishopFox/sliver/blob/master/server/c2/wireguard.go):**\n```go\nif handler, ok := handlers[envelope.Type]; ok {\n    go func(envelope *sliverpb.Envelope) {\n        respEnvelope := handler(implantConn, envelope.Data) // \u003c--- PANIC HERE\n        // ...\n    }(envelope)\n}\n```\n\nBecause these handlers are invoked in a **raw goroutine** without a `recover()` block, the panic propagates to the top of the stack, causing the entire Go runtime to exit (SIGSEGV). This kills the `sliver-server` process immediately.\n\n### 4.3 DNS Transport (Full DoS)\nSimilar to mTLS, the DNS transport reassembles messages and then forwards them to handlers in unsynchronized goroutines.\n\n**DNS [server/c2/dns.go](https://github.com/BishopFox/sliver/blob/master/server/c2/dns.go):**\n```go\n// Line 833: Forwarding the completed envelope\ngo dnsSession.ForwardCompletedEnvelope(msg.ID, pending)\n// ...\n// Inside ForwardCompletedEnvelope:\nif handler, ok := handlers[envelope.Type]; ok {\n    respEnvelope := handler(s.ImplantConn, envelope.Data) // \u003c--- PANIC HERE\n    // ...\n}\n```\n\nThis asynchronous call also lacks a `recover()` block, making DNS sessions equally capable of crashing the entire server.\n\n### 4.4 Vulnerability Matrix by Protocol\n\n| Protocol | Uses `recover()`? | Impact of Panic | Server Crash? |\n| :--- | :---: | :--- | :---: |\n| **HTTP / HTTPS** | Yes (Built-in) | Request Terminated | No |\n| **mTLS** | No | Process Termination | **Yes** |\n| **WireGuard** | No | Process Termination | **Yes** |\n| **DNS** | No | Process Termination | **Yes** |\n\n\n## 5. Impact Analysis\nThe impact of this vulnerability is\u00a0**Total Operational Paralysis**. Because the panic causes the entire Go runtime to terminate:\n- **Global Disconnection:**\u00a0Every active session and beacon across all transports (including the resilient HTTP transport) is instantly terminated.\n- **Persistence Risk:**\u00a0Implants waiting for their next check-in will find the server offline. Repeated failures may trigger internal implant \"kill-date\" or cleanup logic, or alert defensive monitoring to a failure in the C2 channel.\n- **Operator Eviction:**\u00a0All active operators are evicted from the gRPC interface, losing all unsaved state, active shell buffers, and real-time monitoring streams.\n- **Operational Downtime:**\u00a0Restoration requires manual intervention to restart the service and potentially re-establish complex pivot chains, creating a significant \"Recovery Time Objective\" (RTO) penalty.\n## 6. Countermeasures \u0026 Remediation\nAddressing these vulnerabilities requires a systemic shift towards \"fail-safe\" architecture. The root cause is a combination of unprotected Protobuf pointer dereferences and a lack of isolation in asynchronous transport layers.\n\n### 6.1 Tier 1: Tactical Defensive Programming\nThe immediate priority is to implement strict validation for all nested Protobuf fields. In Go, omitted sub-messages are `nil` after unmarshaling; handlers must assume any pointer-typed field from an implant is potentially `nil`.\n\n#### Implementation Pattern: Validation-First Handlers\nHandlers should validate the entire message structure before proceeding to business logic.\n\n```go\nbeaconReg := \u0026sliverpb.BeaconRegister{}\nif err := proto.Unmarshal(data, beaconReg); err != nil {\n\treturn nil // Drop malformed wire data\n}\n\n// MANDATORY VALIDATION BLOCK\nif beaconReg.Register == nil {\n\tbeaconHandlerLog.Errorf(\"Nil Register message from %s\", core.GetRemoteAddr(implantConn))\n\treturn nil\n}\n\n// Deep access is now safe\nid := beaconReg.Register.Uuid\n// ...\n```\n\n### 6.2 Tier 2: Infrastructure Hardening (RPC Global Accessors)\nTo protect the gRPC/Operator interface, the server should deprecate direct access to the [Request](https://github.com/BishopFox/sliver/blob/master/server/core/sessions.go#L148-L185) metadata field in favor of safe accessors that handle missing metadata gracefully.\n#### Recommended Helper Update \n```go\n// server/rpc/rpc.go\n// getRequestSafe returns the Request metadata or an error, preventing panics\nfunc getRequestSafe(req GenericRequest) (*commonpb.Request, error) {\n    r := req.GetRequest()\n    if r == nil {\n        return nil, status.Error(codes.InvalidArgument, \"missing mandatory \u0027Request\u0027 metadata\")\n    }\n    return r, nil\n}\n```\n### 6.3 Tier 3: Strategic Architectural Resilience (Panic Recovery Middleware)\nTo achieve parity with the resilience of the HTTP transport, all multiplexed transports (mTLS, WireGuard, DNS) must implement a supervisor pattern using Go\u0027s `recover()` mechanism.\n\n#### Implementation: Protected Handler Invoke\nAll handlers should be executed inside a \"Safe Wrapper\" that catches runtime panics, logs the failure, and terminates only the affected stream without crashing the entire C2 daemon.\n\n```go\nfunc SafeInvoke(handler ServerHandler, conn *core.ImplantConnection, data []byte) {\n    defer func() {\n        if r := recover(); r != nil {\n            log.Errorf(\"RECOVERY: Intercepted panic in handler: %v\\n%s\", r, debug.Stack())\n            // The daemon continues running; only this specific action failed.\n        }\n    }()\n    \n    response := handler(conn, data)\n    if response != nil {\n        conn.Send \u003c- response\n    }\n}\n```\n\n### 6.4 Tier 4: Long-Term Assurance\nThe framework should move away from manual nil-checking towards automated schema validation:\n- **`protoc-gen-validate` (PGV)**: Annotate [.proto](https://github.com/BishopFox/sliver/blob/master/protobuf/dnspb/dns.proto) files with `(validate.rules).message.required = true` and generate automatic validation code.\n- **Static Analysis CI**: Integrate custom linters to detect unprotected pointer dereferences of Protobuf types during the PR process.\n\nBy adopting this multi-tiered approach, Sliver evolves from a \"fail-deadly\" design to a robust, enterprise-grade C2 architecture.",
  "id": "GHSA-hx52-cv84-jr5v",
  "modified": "2026-03-09T15:49:25Z",
  "published": "2026-03-05T00:26:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/sliver/security/advisories/GHSA-hx52-cv84-jr5v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29781"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BishopFox/sliver"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Sliver is Vulnerable to Authenticated Nil-Pointer Dereference through its Handlers"
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-40962"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-12T13:15:18Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: allocate dummy checksums for zoned NODATASUM writes\n\nShin\u0027ichiro reported that when he\u0027s running fstests\u0027 test-case\nbtrfs/167 on emulated zoned devices, he\u0027s seeing the following NULL\npointer dereference in \u0027btrfs_zone_finish_endio()\u0027:\n\n  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000011: 0000 [#1] PREEMPT SMP KASAN NOPTI\n  KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]\n  CPU: 4 PID: 2332440 Comm: kworker/u80:15 Tainted: G        W          6.10.0-rc2-kts+ #4\n  Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020\n  Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]\n  RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]\n\n  RSP: 0018:ffff88867f107a90 EFLAGS: 00010206\n  RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff893e5534\n  RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088\n  RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed1081696028\n  R10: ffff88840b4b0143 R11: ffff88834dfff600 R12: ffff88840b4b0000\n  R13: 0000000000020000 R14: 0000000000000000 R15: ffff888530ad5210\n  FS:  0000000000000000(0000) GS:ffff888e3f800000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f87223fff38 CR3: 00000007a7c6a002 CR4: 00000000007706f0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  PKRU: 55555554\n  Call Trace:\n   \u003cTASK\u003e\n   ? __die_body.cold+0x19/0x27\n   ? die_addr+0x46/0x70\n   ? exc_general_protection+0x14f/0x250\n   ? asm_exc_general_protection+0x26/0x30\n   ? do_raw_read_unlock+0x44/0x70\n   ? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]\n   btrfs_finish_one_ordered+0x5d9/0x19a0 [btrfs]\n   ? __pfx_lock_release+0x10/0x10\n   ? do_raw_write_lock+0x90/0x260\n   ? __pfx_do_raw_write_lock+0x10/0x10\n   ? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs]\n   ? _raw_write_unlock+0x23/0x40\n   ? btrfs_finish_ordered_zoned+0x5a9/0x850 [btrfs]\n   ? lock_acquire+0x435/0x500\n   btrfs_work_helper+0x1b1/0xa70 [btrfs]\n   ? __schedule+0x10a8/0x60b0\n   ? __pfx___might_resched+0x10/0x10\n   process_one_work+0x862/0x1410\n   ? __pfx_lock_acquire+0x10/0x10\n   ? __pfx_process_one_work+0x10/0x10\n   ? assign_work+0x16c/0x240\n   worker_thread+0x5e6/0x1010\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0x2c3/0x3a0\n   ? trace_irq_enable.constprop.0+0xce/0x110\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x31/0x70\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   \u003c/TASK\u003e\n\nEnabling CONFIG_BTRFS_ASSERT revealed the following assertion to\ntrigger:\n\n  assertion failed: !list_empty(\u0026ordered-\u003elist), in fs/btrfs/zoned.c:1815\n\nThis indicates, that we\u0027re missing the checksums list on the\nordered_extent. As btrfs/167 is doing a NOCOW write this is to be\nexpected.\n\nFurther analysis with drgn confirmed the assumption:\n\n  \u003e\u003e\u003e inode = prog.crashed_thread().stack_trace()[11][\u0027ordered\u0027].inode\n  \u003e\u003e\u003e btrfs_inode = drgn.container_of(inode, \"struct btrfs_inode\", \\\n         \t\t\t\t\"vfs_inode\")\n  \u003e\u003e\u003e print(btrfs_inode.flags)\n  (u32)1\n\nAs zoned emulation mode simulates conventional zones on regular devices,\nwe cannot use zone-append for writing. But we\u0027re only attaching dummy\nchecksums if we\u0027re doing a zone-append write.\n\nSo for NOCOW zoned data writes on conventional zones, also attach a\ndummy checksum.",
  "id": "GHSA-hx58-3fx6-hp8m",
  "modified": "2025-01-07T18:30:43Z",
  "published": "2024-07-12T15:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40962"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/082b3d4e788953a3ff42ecdb70c4210149076285"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/25cfe59f4470a051d1b80f51fa0ca3a5048e4a19"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cebae292e0c32a228e8f2219c270a7237be24a6a"
    }
  ],
  "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"
    }
  ]
}