$LOGGER.$FATAL(...) inside a goroutine calls os.Exit(1) after logging, which immediately terminates the entire process — even when the goroutine contains a defer/recover handler. This turns any transient error (e.g., an unreachable callback URI) into a process-level crash that cannot be caught by the caller. Replace with a non-fatal method such as Errorf or
Rule Explorer
Search the public rule index by CVE, GHSA, CWE, language, framework, author, or rule slug. Filter by language, framework, severity, confidence, license, and validation status.
- Public rules
- 2917
- Downloads
- 3.3M
- Verified
- 2917
- Authors
- 2
Inverted bounds assertion before AES_unwrap_key: the guard `OUT.len() + 8 <= IN.len()` is reversed. AES key unwrap (RFC 3394) writes `IN.len() - 8` bytes into `OUT`, so the correct invariant is `OUT.len() + 8 >= IN.len()` (equivalently `OUT.len() >= IN.len() - 8`). The reversed comparison admits undersized output buffers and causes an out-of-bounds write fro
Using `assert` for string validation before usage is vulnerable to a bypass because Python strips assert statements from bytecode when executed with optimizations (`-O`). Attackers can supply inputs that bypass string-prefix boundaries, potentially leading to arbitrary code execution, unintended module loading, or path traversal. Replace the `assert` stateme
Using `panic!` inside libp2p `ConnectionHandler` negotiation events (`FullyNegotiatedInbound`, `FullyNegotiatedOutbound`) exposes the application to remote Denial of Service (DoS) attacks. An attacker can intentionally negotiate duplicate streams or unexpected states to trigger the panic and crash the node. Handle invalid states gracefully by returning an er
Using `.expect()` or `.unwrap()` on the result of a checked arithmetic operation (e.g., `checked_add`, `checked_sub`) causes a runtime panic on overflow/underflow. When processing untrusted input, this leads to Denial of Service (DoS) due to reachable assertions. Handle the error gracefully using `.ok_or(...)?` or a `match` statement.
Using `assert` for critical data validation or state checks (such as end-of-file boundaries, stream validation, or field presence) is unsafe. When Python is executed with optimizations enabled (`-O` or `PYTHONOPTIMIZE=1`), all `assert` statements are stripped. This allows malformed data to bypass checks entirely, potentially leading to infinite loops or Deni
The code asserts that two object fields are null (indicating an uninitialized or free state), and then subsequently assigns to one of them. If the execution path reaching this assertion can be triggered multiple times via external input, the assertion will fail and crash the application (Denial of Service). Replace this assertion with proper conditional logi
Failing to drop Initial encryption keys prior to or while dropping Handshake keys can lead to an assertion failure and Denial of Service (DoS). A malicious server might prematurely confirm the handshake (e.g., by sending a HANDSHAKE_DONE frame early), leaving unexpected Initial keys in the state. Ensure `protocol.EncryptionInitial` keys are explicitly droppe
Debug assertions (`DCHECK`, `assert`) are compiled out in release builds (e.g., when NDEBUG is defined). Using them exclusively for bounds checking discards the safety guarantee, potentially enabling memory corruption vulnerabilities if out-of-bounds data is processed. Enforce bounds limits using `CHECK`, exceptions, or standard conditional validation that p
Missing handler for OGS_SBI_SERVICE_NAME_NPCF_AM_POLICY_CONTROL in the gmm_state_authentication function. An unexpected AM Policy Control response causes the AMF to hit a DEFAULT case that invokes ogs_assert_if_reached(), leading to a Denial of Service.