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.

956 vulnerabilities reference this CWE, most recent first.

GHSA-G8PP-M4FH-WJG4

Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2022-05-24 16:46
VLAI
Details

A CWE-248: Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause a possible denial of Service when writing invalid memory blocks to the controller over Modbus.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-7856"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-22T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "A CWE-248: Uncaught Exception vulnerability exists in all versions of the Modicon M580, Modicon M340, Modicon Quantum, and Modicon Premium which could cause a possible denial of Service when writing invalid memory blocks to the controller over Modbus.",
  "id": "GHSA-g8pp-m4fh-wjg4",
  "modified": "2022-05-24T16:46:14Z",
  "published": "2022-05-24T16:46:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7856"
    },
    {
      "type": "WEB",
      "url": "https://www.schneider-electric.com/en/download/document/SEVD-2019-134-11"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0767"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-G986-42M5-MXWM

Vulnerability from github – Published: 2022-09-01 00:00 – Updated: 2023-01-20 21:30
VLAI
Details

An issue was discovered in wolfSSL before 5.5.0. When a TLS 1.3 client connects to a wolfSSL server and SSL_clear is called on its session, the server crashes with a segmentation fault. This occurs in the second session, which is created through TLS session resumption and reuses the initial struct WOLFSSL. If the server reuses the previous session structure (struct WOLFSSL) by calling wolfSSL_clear(WOLFSSL* ssl) on it, the next received Client Hello (that resumes the previous session) crashes the server. Note that this bug is only triggered when resuming sessions using TLS session resumption. Only servers that use wolfSSL_clear instead of the recommended SSL_free; SSL_new sequence are affected. Furthermore, wolfSSL_clear is part of wolfSSL's compatibility layer and is not enabled by default. It is not part of wolfSSL's native API.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-38152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-31T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in wolfSSL before 5.5.0. When a TLS 1.3 client connects to a wolfSSL server and SSL_clear is called on its session, the server crashes with a segmentation fault. This occurs in the second session, which is created through TLS session resumption and reuses the initial struct WOLFSSL. If the server reuses the previous session structure (struct WOLFSSL) by calling wolfSSL_clear(WOLFSSL* ssl) on it, the next received Client Hello (that resumes the previous session) crashes the server. Note that this bug is only triggered when resuming sessions using TLS session resumption. Only servers that use wolfSSL_clear instead of the recommended SSL_free; SSL_new sequence are affected. Furthermore, wolfSSL_clear is part of wolfSSL\u0027s compatibility layer and is not enabled by default. It is not part of wolfSSL\u0027s native API.",
  "id": "GHSA-g986-42m5-mxwm",
  "modified": "2023-01-20T21:30:31Z",
  "published": "2022-09-01T00:00:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38152"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wolfSSL/wolfssl/pull/5468"
    },
    {
      "type": "WEB",
      "url": "https://blog.trailofbits.com/2023/01/12/wolfssl-vulnerabilities-tlspuffin-fuzzing-ssh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tlspuffin/tlspuffin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wolfSSL/wolfssl/releases"
    },
    {
      "type": "WEB",
      "url": "https://www.wolfssl.com/docs/security-vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/170604/wolfSSL-Session-Resumption-Denial-Of-Service.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2023/Jan/7"
    }
  ],
  "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-G9HV-X236-4QP3

Vulnerability from github – Published: 2026-07-24 16:47 – Updated: 2026-08-12 20:53
VLAI
Summary
Russh: client wrong-length X25519 `clone_from_slice` panic (pre-auth DoS)
Details

Summary

A malicious SSH server can crash a russh client session with a single malformed key-exchange reply, causing a pre-authentication Denial-of-Service before the server host key is verified. The embedding process itself stays up, but the connection is killed deterministically.

Details

Every other kex path in russh validates the peer ephemeral length before cloning:

  • Curve25519Kex::server_dh (russh/src/kex/curve25519.rs:61-65) checks if pubkey_len != 32 { return Err(crate::Error::Kex); } before clone_from_slice.
  • The hybrid ML-KEM, ECDH-NIST, and DH/GEX paths all validate lengths.

Only the client-side curve25519 compute_shared_secret is missing the check. This asymmetric validation gap makes the bug easy to miss in code review: a malicious client cannot panic a russh server this way (the server path checks the length), but a malicious server can panic a russh client.

Incriminated source code (repo-relative paths):

  • Vulnerable compute_shared_secret: russh/src/kex/curve25519.rs:110-117 (panic at line 113)
  • Client-side entry point: russh/src/client/kex.rs:266-277 (KEX_ECDH_REPLYBytes::decodecompute_shared_secret)
  • Server-side contrast (has the length check): russh/src/kex/curve25519.rs:51-88 (server_dh)
  • Session spawn site: russh/src/client/mod.rs (connect_streamrussh_util::runtime::spawn)
  • Runtime wrapper: russh-util/src/runtime.rs:37-48 (spawn wraps tokio::spawn; panic surfaces as JoinError)

PoC

A standalone, self-contained Cargo PoC is provided in vuln_poc/vuln_002_client_wronglen_x25519_panic/ in this repo. It installs a global panic hook that sets an AtomicBool if any panic fires, starts a malicious raw SSH server on 127.0.0.1:0 that completes the SSH id and KEXINIT exchange, reads the client KEX_ECDH_INIT, and sends KEX_ECDH_REPLY with a 16-byte server ephemeral (instead of 32) and a fake signature. It then calls russh::client::connect with Preferred::kex set to curve25519-sha256 and a handler that accepts any server key (the check is never reached because the client panics first) and prints a clear verdict.

Build & run:

cd vuln_poc/vuln_002_client_wronglen_x25519_panic
cargo run --release

Expected output (verdict line, from a successful reproduction):

[poc] panic captured: panicked at russh/src/kex/curve25519.rs:113:25:
  copy_from_slice: source slice length (16) does not match destination slice length (32)
[!] Vulnerability reproduced: russh client panicked in Curve25519Kex::compute_shared_secret
  on a wrong-length (16-byte) server ephemeral before verifying the host key signature
  (pre-auth client DoS).

The malicious payload is the f field of KEX_ECDH_REPLY:

MSG_KEX_ECDH_REPLY (1 byte, value 0x1f)
  string K_S            (server host key blob — any valid-looking bytes)
  string f              (server ephemeral — 16 bytes of 0x00 instead of 32)
  string signature      (fake; never verified by the client)

The length prefix of f is 4 (u32 BE) = 16, followed by 16 bytes. The russh client decodes this into exchange.server_ephemeral (a Vec<u8> of length 16) and passes it to compute_shared_secret, which panics on clone_from_slice.

Impact

What kind of vulnerability: CWE-704 (incorrect type conversion / cast — clone_from_slice length mismatch) → deterministic panic → pre-authentication per-connection Denial-of-Service. The attacker does not need the server's private key; any network position that can deliver a malformed KEX_ECDH_REPLY (a rogue server, or a MitM before authentication) suffices.

Who is impacted: any deployment that uses russh::client::connect (or connect_stream) to connect to an attacker-controlled or MitM-reachable SSH server, and that negotiates curve25519-sha256 (the default and most-preferred kex algorithm in russh). A single malformed KEX_ECDH_REPLY kills the client session; the attack is deterministic and single-packet. The panic is isolated to the spawned session task (tokio::spawn catches it and surfaces a JoinError), so the embedding process keeps running — the impact is per-connection DoS, not process crash, unless the embedder installs a custom panic hook that calls std::process::abort.

Workaround: until a fix is released, clients can reduce exposure by disabling curve25519-sha256 in the Preferred::kex list and preferring a kex algorithm whose peer-ephemeral length is validated (e.g. the ECDH-NIST or DH/GEX paths). This is a mitigation, not a fix.

Suggested fix (one-line length check, mirrors the existing server-side server_dh check):

// russh/src/kex/curve25519.rs, at the top of compute_shared_secret:
fn compute_shared_secret(&mut self, remote_pubkey_: &[u8]) -> Result<(), crate::Error> {
    if remote_pubkey_.len() != 32 {
        return Err(crate::Error::Kex);
    }
    let local_secret = self.local_secret.take().ok_or(crate::Error::KexInit)?;
    let mut remote_pubkey = MontgomeryPoint([0; 32]);
    remote_pubkey.0.clone_from_slice(remote_pubkey_);
    let shared = local_secret * remote_pubkey;
    self.shared_secret = Some(shared);
    Ok(())
}

This makes the client-side compute_shared_secret consistent with the existing server-side server_dh check at russh/src/kex/curve25519.rs:61-65 and with the other kex paths that already validate peer ephemeral lengths.

vuln_poc.zip

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.62.3"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "russh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.62.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73429"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-704",
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T16:47:16Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nA malicious SSH server can crash a `russh` client session with a single\nmalformed key-exchange reply, causing a pre-authentication Denial-of-Service\nbefore the server host key is verified. The embedding process itself stays\nup, but the connection is killed deterministically.\n\n### Details\nEvery *other* kex path in `russh` validates the peer ephemeral length before\ncloning:\n\n- `Curve25519Kex::server_dh` (`russh/src/kex/curve25519.rs:61-65`) checks\n  `if pubkey_len != 32 { return Err(crate::Error::Kex); }` before\n  `clone_from_slice`.\n- The hybrid ML-KEM, ECDH-NIST, and DH/GEX paths all validate lengths.\n\nOnly the client-side curve25519 `compute_shared_secret` is missing the check.\nThis asymmetric validation gap makes the bug easy to miss in code review: a\nmalicious *client* cannot panic a `russh` server this way (the server path\nchecks the length), but a malicious *server* can panic a `russh` client.\n\nIncriminated source code (repo-relative paths):\n\n- Vulnerable `compute_shared_secret`: `russh/src/kex/curve25519.rs:110-117` (panic at line 113)\n- Client-side entry point: `russh/src/client/kex.rs:266-277` (`KEX_ECDH_REPLY` \u2192 `Bytes::decode` \u2192 `compute_shared_secret`)\n- Server-side contrast (has the length check): `russh/src/kex/curve25519.rs:51-88` (`server_dh`)\n- Session spawn site: `russh/src/client/mod.rs` (`connect_stream` \u2192 `russh_util::runtime::spawn`)\n- Runtime wrapper: `russh-util/src/runtime.rs:37-48` (`spawn` wraps `tokio::spawn`; panic surfaces as `JoinError`)\n\n### PoC\nA standalone, self-contained Cargo PoC is provided in\n`vuln_poc/vuln_002_client_wronglen_x25519_panic/` in this repo. It installs a\nglobal panic hook that sets an `AtomicBool` if any panic fires, starts a\nmalicious raw SSH server on `127.0.0.1:0` that completes the SSH id and\n`KEXINIT` exchange, reads the client `KEX_ECDH_INIT`, and sends\n`KEX_ECDH_REPLY` with a 16-byte server ephemeral (instead of 32) and a fake\nsignature. It then calls `russh::client::connect` with `Preferred::kex` set\nto `curve25519-sha256` and a handler that accepts any server key (the check\nis never reached because the client panics first) and prints a clear verdict.\n\nBuild \u0026 run:\n\n```bash\ncd vuln_poc/vuln_002_client_wronglen_x25519_panic\ncargo run --release\n```\n\nExpected output (verdict line, from a successful reproduction):\n\n```\n[poc] panic captured: panicked at russh/src/kex/curve25519.rs:113:25:\n  copy_from_slice: source slice length (16) does not match destination slice length (32)\n[!] Vulnerability reproduced: russh client panicked in Curve25519Kex::compute_shared_secret\n  on a wrong-length (16-byte) server ephemeral before verifying the host key signature\n  (pre-auth client DoS).\n```\n\nThe malicious payload is the `f` field of `KEX_ECDH_REPLY`:\n\n```\nMSG_KEX_ECDH_REPLY (1 byte, value 0x1f)\n  string K_S            (server host key blob \u2014 any valid-looking bytes)\n  string f              (server ephemeral \u2014 16 bytes of 0x00 instead of 32)\n  string signature      (fake; never verified by the client)\n```\n\nThe length prefix of `f` is `4` (u32 BE) = 16, followed by 16 bytes. The\n`russh` client decodes this into `exchange.server_ephemeral` (a `Vec\u003cu8\u003e` of\nlength 16) and passes it to `compute_shared_secret`, which panics on\n`clone_from_slice`.\n\n### Impact\n**What kind of vulnerability:** CWE-704 (incorrect type conversion / cast \u2014\n`clone_from_slice` length mismatch) \u2192 deterministic panic \u2192 pre-authentication\nper-connection Denial-of-Service. The attacker does not need the server\u0027s\nprivate key; any network position that can deliver a malformed\n`KEX_ECDH_REPLY` (a rogue server, or a MitM before authentication) suffices.\n\n**Who is impacted:** any deployment that uses `russh::client::connect` (or\n`connect_stream`) to connect to an attacker-controlled or MitM-reachable SSH\nserver, and that negotiates `curve25519-sha256` (the default and\nmost-preferred kex algorithm in `russh`). A single malformed\n`KEX_ECDH_REPLY` kills the client session; the attack is deterministic and\nsingle-packet. The panic is isolated to the spawned session task\n(`tokio::spawn` catches it and surfaces a `JoinError`), so the embedding\nprocess keeps running \u2014 the impact is per-connection DoS, not process crash,\nunless the embedder installs a custom panic hook that calls\n`std::process::abort`.\n\n**Workaround:** until a fix is released, clients can reduce exposure by\ndisabling `curve25519-sha256` in the `Preferred::kex` list and preferring a\nkex algorithm whose peer-ephemeral length is validated (e.g. the ECDH-NIST\nor DH/GEX paths). This is a mitigation, not a fix.\n\n**Suggested fix (one-line length check, mirrors the existing server-side\n`server_dh` check):**\n\n```rust\n// russh/src/kex/curve25519.rs, at the top of compute_shared_secret:\nfn compute_shared_secret(\u0026mut self, remote_pubkey_: \u0026[u8]) -\u003e Result\u003c(), crate::Error\u003e {\n    if remote_pubkey_.len() != 32 {\n        return Err(crate::Error::Kex);\n    }\n    let local_secret = self.local_secret.take().ok_or(crate::Error::KexInit)?;\n    let mut remote_pubkey = MontgomeryPoint([0; 32]);\n    remote_pubkey.0.clone_from_slice(remote_pubkey_);\n    let shared = local_secret * remote_pubkey;\n    self.shared_secret = Some(shared);\n    Ok(())\n}\n```\n\nThis makes the client-side `compute_shared_secret` consistent with the\nexisting server-side `server_dh` check at `russh/src/kex/curve25519.rs:61-65`\nand with the other kex paths that already validate peer ephemeral lengths.\n\n[vuln_poc.zip](https://github.com/user-attachments/files/29255207/vuln_poc.zip)",
  "id": "GHSA-g9hv-x236-4qp3",
  "modified": "2026-08-12T20:53:25Z",
  "published": "2026-07-24T16:47:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Eugeny/russh/security/advisories/GHSA-g9hv-x236-4qp3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Eugeny/russh/commit/a7fc1eb5717264e31c3c5f7dd849b73989a08f3d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Eugeny/russh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Eugeny/russh/releases/tag/v0.62.4"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Russh: client wrong-length X25519 `clone_from_slice` panic (pre-auth DoS)"
}

GHSA-G9M2-7JC6-PMVF

Vulnerability from github – Published: 2025-04-17 03:30 – Updated: 2025-04-17 03:30
VLAI
Details

Nullsoft Scriptable Install System (NSIS) before 3.11 on Windows allows local users to escalate privileges to SYSTEM during an installation, because the temporary plugins directory is created under %WINDIR%\temp and unprivileged users can place a crafted executable file by winning a race condition. This occurs because EW_CREATEDIR does not always set the CreateRestrictedDirectory error flag.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-43715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-17T03:15:16Z",
    "severity": "HIGH"
  },
  "details": "Nullsoft Scriptable Install System (NSIS) before 3.11 on Windows allows local users to escalate privileges to SYSTEM during an installation, because the temporary plugins directory is created under %WINDIR%\\temp and unprivileged users can place a crafted executable file by winning a race condition. This occurs because EW_CREATEDIR does not always set the CreateRestrictedDirectory error flag.",
  "id": "GHSA-g9m2-7jc6-pmvf",
  "modified": "2025-04-17T03:30:30Z",
  "published": "2025-04-17T03:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43715"
    },
    {
      "type": "WEB",
      "url": "https://nsis.sourceforge.io/Docs/AppendixF.html#v3.11-rl"
    },
    {
      "type": "WEB",
      "url": "https://sourceforge.net/p/nsis/bugs/1315"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G9PM-VPPM-577Q

Vulnerability from github – Published: 2022-03-09 00:00 – Updated: 2025-08-12 12:30
VLAI
Details

A vulnerability has been identified in RUGGEDCOM ROS M2100 (All versions < V5.6.0), RUGGEDCOM ROS RMC8388 devices (All versions < V5.6.0), RUGGEDCOM ROS RS416v2 (All versions < V5.6.0), RUGGEDCOM ROS RS900G (All versions < V5.6.0), RUGGEDCOM ROS RS900G (32M) (All versions < V5.6.0), RUGGEDCOM ROS RSG2100 (32M) V5.X (All versions < V5.6.0), RUGGEDCOM ROS RSG2100P (All versions < V5.6.0), RUGGEDCOM ROS RSG2100P (32M) V5.X (All versions < V5.6.0), RUGGEDCOM ROS RSG2288 V5.X (All versions < V5.6.0), RUGGEDCOM ROS RSG2300 V5.X (All versions < V5.6.0), RUGGEDCOM ROS RSG2300P V5.X (All versions < V5.6.0), RUGGEDCOM ROS RSG2488 V5.X (All versions < V5.6.0), RUGGEDCOM ROS RSG900 V5.X (All versions < V5.6.0), RUGGEDCOM ROS RSG920P V5.X (All versions < V5.6.0), RUGGEDCOM ROS RSL910 (All versions < V5.6.0), RUGGEDCOM ROS RST2228 (All versions < V5.6.0), RUGGEDCOM ROS RST916C (All versions < V5.6.0), RUGGEDCOM ROS RST916P (All versions < V5.6.0). The third-party component in its TFTP functionality fails to check for null terminations in file names. If an attacker were to exploit this, it could result in data corruption, and possibly a hard-fault of the application.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-42020"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-08T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in RUGGEDCOM ROS M2100 (All versions \u003c V5.6.0), RUGGEDCOM ROS RMC8388 devices (All versions \u003c V5.6.0), RUGGEDCOM ROS RS416v2 (All versions \u003c V5.6.0), RUGGEDCOM ROS RS900G (All versions \u003c V5.6.0), RUGGEDCOM ROS RS900G (32M) (All versions \u003c V5.6.0), RUGGEDCOM ROS RSG2100 (32M) V5.X (All versions \u003c V5.6.0), RUGGEDCOM ROS RSG2100P (All versions \u003c V5.6.0), RUGGEDCOM ROS RSG2100P (32M) V5.X (All versions \u003c V5.6.0), RUGGEDCOM ROS RSG2288 V5.X (All versions \u003c V5.6.0), RUGGEDCOM ROS RSG2300 V5.X (All versions \u003c V5.6.0), RUGGEDCOM ROS RSG2300P V5.X (All versions \u003c V5.6.0), RUGGEDCOM ROS RSG2488 V5.X (All versions \u003c V5.6.0), RUGGEDCOM ROS RSG900 V5.X (All versions \u003c V5.6.0), RUGGEDCOM ROS RSG920P V5.X (All versions \u003c V5.6.0), RUGGEDCOM ROS RSL910 (All versions \u003c V5.6.0), RUGGEDCOM ROS RST2228 (All versions \u003c V5.6.0), RUGGEDCOM ROS RST916C (All versions \u003c V5.6.0), RUGGEDCOM ROS RST916P (All versions \u003c V5.6.0). The third-party component in its TFTP functionality fails to check for null terminations in file names. If an attacker were to exploit this, it could result in data corruption, and possibly a hard-fault of the application.",
  "id": "GHSA-g9pm-vppm-577q",
  "modified": "2025-08-12T12:30:32Z",
  "published": "2022-03-09T00:00:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42020"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-256353.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-256353.pdf"
    }
  ],
  "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-GFMF-6GHH-GJWR

Vulnerability from github – Published: 2024-04-12 18:33 – Updated: 2025-02-06 21:32
VLAI
Details

An Improper Check for Unusual or Exceptional Conditions vulnerability in the the Public Key Infrastructure daemon (pkid) of Juniper Networks Junos OS allows an unauthenticated networked attacker to cause Denial of Service (DoS).

The pkid is responsible for the certificate verification. Upon a failed verification, the pkid uses all CPU resources and becomes unresponsive to future verification attempts. This means that all subsequent VPN negotiations depending on certificate verification will fail.

This CPU utilization of pkid can be checked using this command:   root@srx> show system processes extensive | match pkid   xxxxx  root  103  0  846M  136M  CPU1  1 569:00 100.00% pkid

This issue affects: Juniper Networks Junos OS All versions prior to 20.4R3-S10; 21.2 versions prior to 21.2R3-S7; 21.4 versions prior to 21.4R3-S5; 22.1 versions prior to 22.1R3-S4; 22.2 versions prior to 22.2R3-S3; 22.3 versions prior to 22.3R3-S1; 22.4 versions prior to 22.4R3; 23.2 versions prior to 23.2R1-S2, 23.2R2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-30397"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-12T16:15:39Z",
    "severity": "HIGH"
  },
  "details": "An Improper Check for Unusual or Exceptional Conditions vulnerability in the the\u00a0Public Key Infrastructure daemon (pkid) of Juniper Networks Junos OS allows an unauthenticated networked attacker to cause Denial of Service (DoS).\n\nThe pkid is responsible for the certificate verification. Upon a failed verification, the pkid uses all CPU resources and becomes unresponsive to future verification attempts. This means that all subsequent VPN negotiations depending on certificate verification will fail.\n\nThis CPU utilization of pkid can be checked using this command: \n\u00a0 root@srx\u003e show system processes extensive | match pkid\n\u00a0 xxxxx \u2003root \u2003103\u2003 0 \u2003846M \u2003136M \u2003CPU1 \u20031\u00a0569:00 100.00% pkid\n\nThis issue affects:\nJuniper Networks Junos OS\nAll\u00a0versions prior to 20.4R3-S10;\n21.2 versions prior to 21.2R3-S7;\n21.4 versions prior to 21.4R3-S5;\n22.1 versions prior to 22.1R3-S4;\n22.2 versions prior to\u00a022.2R3-S3;\n22.3 versions prior to\u00a022.3R3-S1;\n22.4 versions prior to\u00a022.4R3;\n23.2 versions prior to\u00a023.2R1-S2, 23.2R2.",
  "id": "GHSA-gfmf-6ghh-gjwr",
  "modified": "2025-02-06T21:32:05Z",
  "published": "2024-04-12T18:33:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30397"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA79179"
    },
    {
      "type": "WEB",
      "url": "https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L"
    },
    {
      "type": "WEB",
      "url": "https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-GGRW-X635-4PJ7

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

Improper conditions check in some firmware for some Intel(R) Graphics Drivers and Intel LTS kernels within Ring 1: Device Drivers may allow a denial of service. Unprivileged software adversary with an authenticated user combined with a high complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are present with special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (low) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-32739"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-10T17:16:17Z",
    "severity": "LOW"
  },
  "details": "Improper conditions check in some firmware for some Intel(R) Graphics Drivers and Intel LTS kernels within Ring 1: Device Drivers may allow a denial of service. Unprivileged software adversary with an authenticated user combined with a high complexity attack may enable denial of service. This result may potentially occur via local access when attack requirements are present with special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (none) and availability (low) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.",
  "id": "GHSA-ggrw-x635-4pj7",
  "modified": "2026-02-10T18:30:40Z",
  "published": "2026-02-10T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32739"
    },
    {
      "type": "WEB",
      "url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01385.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-GH66-FP7J-98V5

Vulnerability from github – Published: 2023-06-28 22:34 – Updated: 2023-06-28 22:34
VLAI
Summary
Shopware improper mail validation vulnerability
Details

Impact

The mail validation in the registration process had some flaws, so it was possible to construct different mail addresses, that in the end result in the same address, which is shared by multiple accounts.

Patches

We recommend updating to the current version 5.7.18. You can get the update to 5.7.18 regularly via the Auto-Updater or directly via the release page. https://github.com/shopware5/shopware/releases/tag/v5.7.18

For older versions you can use the Security Plugin: https://store.shopware.com/en/swag575294366635f/shopware-security-plugin.html

References

https://docs.shopware.com/en/shopware-5-en/security-updates/security-update-06-2023

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.7.17"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/shopware"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.1.4"
            },
            {
              "fixed": "5.7.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-34099"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-28T22:34:08Z",
    "nvd_published_at": "2023-06-27T17:15:09Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe mail validation in the registration process had some flaws, so it was possible to construct different mail addresses, that in the end result in the same address, which is shared by multiple accounts. \n\n### Patches\nWe recommend updating to the current version 5.7.18. You can get the update to 5.7.18 regularly via the Auto-Updater or directly via the release page.\nhttps://github.com/shopware5/shopware/releases/tag/v5.7.18\n\nFor older versions you can use the Security Plugin:\nhttps://store.shopware.com/en/swag575294366635f/shopware-security-plugin.html\n\n\n### References\nhttps://docs.shopware.com/en/shopware-5-en/security-updates/security-update-06-2023",
  "id": "GHSA-gh66-fp7j-98v5",
  "modified": "2023-06-28T22:34:08Z",
  "published": "2023-06-28T22:34:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/security/advisories/GHSA-gh66-fp7j-98v5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware5/shopware/security/advisories/GHSA-gh66-fp7j-98v5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34099"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware5/shopware/commit/39cc714d9a0be33b43877044d0b88ea3c6b43f3d"
    },
    {
      "type": "WEB",
      "url": "https://docs.shopware.com/en/shopware-5-en/security-updates/security-update-06-2023"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shopware5/shopware"
    },
    {
      "type": "WEB",
      "url": "https://www.shopware.com/en/changelog-sw5/#5-7-18"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Shopware improper mail validation vulnerability"
}

GHSA-GHC9-27WR-4W58

Vulnerability from github – Published: 2023-10-13 00:30 – Updated: 2024-04-04 08:37
VLAI
Details

An Improper Check for Unusual or Exceptional Conditions in the Packet Forwarding Engine (pfe) of Juniper Networks Junos OS Evolved on PTX10003 Series allows an unauthenticated adjacent attacker to cause an impact to the integrity of the system.

When specific transit MPLS packets are received by the PFE, these packets are internally forwarded to the RE. This issue is a prerequisite for CVE-2023-44195.

This issue affects Juniper Networks Junos OS Evolved:

  • All versions prior to 20.4R3-S8-EVO;
  • 21.1-EVO version 21.1R1-EVO and later;
  • 21.2-EVO versions prior to 21.2R3-S6-EVO;
  • 21.3-EVO version 21.3R1-EVO and later;
  • 21.4-EVO versions prior to 21.4R3-S3-EVO;
  • 22.1-EVO versions prior to 22.1R3-S4-EVO;
  • 22.2-EVO versions prior to 22.2R3-S3-EVO;
  • 22.3-EVO versions prior to 22.3R2-S2-EVO, 22.3R3-EVO;
  • 22.4-EVO versions prior to 22.4R2-EVO.
Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-44196"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-13T00:15:12Z",
    "severity": "MODERATE"
  },
  "details": "\nAn Improper Check for Unusual or Exceptional Conditions in the Packet Forwarding Engine (pfe) of Juniper Networks Junos OS Evolved on PTX10003 Series allows an unauthenticated adjacent attacker to cause an impact to the integrity of the system.\n\nWhen specific transit MPLS packets are received by the PFE, these packets are internally forwarded to the RE. This issue is a prerequisite for CVE-2023-44195.\n\nThis issue affects Juniper Networks Junos OS Evolved:\n\n\n\n  *  All versions prior to 20.4R3-S8-EVO;\n  *  21.1-EVO version 21.1R1-EVO and later;\n  *  21.2-EVO versions prior to 21.2R3-S6-EVO;\n  *  21.3-EVO version 21.3R1-EVO and later;\n  *  21.4-EVO versions prior to 21.4R3-S3-EVO;\n  *  22.1-EVO versions prior to 22.1R3-S4-EVO;\n  *  22.2-EVO versions prior to 22.2R3-S3-EVO;\n  *  22.3-EVO versions prior to 22.3R2-S2-EVO, 22.3R3-EVO;\n  *  22.4-EVO versions prior to 22.4R2-EVO.\n\n\n\n\n\n\n",
  "id": "GHSA-ghc9-27wr-4w58",
  "modified": "2024-04-04T08:37:09Z",
  "published": "2023-10-13T00:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44196"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA73162"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GJCG-VRXG-XMGV

Vulnerability from github – Published: 2021-09-10 17:54 – Updated: 2021-09-10 16:32
VLAI
Summary
Incorrect handling of H2 GOAWAY + SETTINGS frames
Details

Envoy, which Pomerium is based on, can abnormally terminate if an H/2 GOAWAY and SETTINGS frame are received in the same IO event.

Impact

This can lead to a DoS in the presence of untrusted upstream servers.

Patches

0.15.1 contains an upgraded envoy binary with this vulnerability patched.

Workarounds

If only trusted upstreams are configured, there is not substantial risk of this condition being triggered.

References

envoy GSA envoy CVE envoy announcement

For more information

If you have any questions or comments about this advisory: * Open an issue in pomerium/pomerium * Email us at security@pomerium.com

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pomerium/pomerium"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.15.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-39162"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-10T16:32:16Z",
    "nvd_published_at": "2021-09-09T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "Envoy, which Pomerium is based on, can abnormally terminate if an H/2 GOAWAY and SETTINGS frame are received in the same IO event.  \n\n### Impact\nThis can lead to a DoS in the presence of untrusted *upstream* servers.\n\n### Patches\n0.15.1 contains an upgraded envoy binary with this vulnerability patched.\n\n### Workarounds\nIf only trusted upstreams are configured, there is not substantial risk of this condition being triggered.\n\n### References\n[envoy GSA](https://github.com/envoyproxy/envoy/security/advisories/GHSA-j374-mjrw-vvp8)\n[envoy CVE](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32780)\n[envoy announcement](https://groups.google.com/g/envoy-announce/c/5xBpsEZZDfE/m/wD05NZBbAgAJ)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [pomerium/pomerium](https://github.com/pomerium/pomerium/issues)\n* Email us at [security@pomerium.com](mailto:security@pomerium.com)\n\n",
  "id": "GHSA-gjcg-vrxg-xmgv",
  "modified": "2021-09-10T16:32:16Z",
  "published": "2021-09-10T17:54:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/envoyproxy/envoy/security/advisories/GHSA-j374-mjrw-vvp8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pomerium/pomerium/security/advisories/GHSA-gjcg-vrxg-xmgv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39162"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pomerium/pomerium"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/envoy-announce/c/5xBpsEZZDfE/m/wD05NZBbAgAJ"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Incorrect handling of H2 GOAWAY + SETTINGS frames"
}

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.