CVE-2026-84897 (GCVE-0-2026-84897)

Vulnerability from cvelistv5 – Published: 2026-10-07 02:42 – Updated: 2026-10-07 18:37
VLAI
Title
wolfSSH server accepts server-to-client DH group exchange messages from an unauthenticated client, causing pre-authentication primality-test CPU exhaustion and key exchange role confusion
Summary
src/internal.c in wolfSSL wolfSSH through 1.5.0 admits the server-to-client Diffie-Hellman group exchange messages SSH_MSG_KEX_DH_GEX_GROUP (31) and SSH_MSG_KEX_DH_GEX_REPLY (33) when a server receives them from an unauthenticated client. IsMessageAllowedServer() applies no direction check to the key exchange message range: when the peer is keying and no particular message is expected, which is the state a server is in for the whole window after it processes the client's KEXINIT because nothing sets handshake->expectMsgId there, the function falls out of its expectation branch without a verdict and reaches a numeric bound that admits every message id from 30 through 34. A client that negotiates diffie-hellman-group-exchange-sha256 and then sends message 31 makes the server run the client-side handler DoKexDhGexGroup(), which validates the attacker-supplied group with two 8-round Miller-Rabin primality tests, one on p and one on (p-1)/2, on a value of up to 8192 bits. The handler then returns success: the server stores the attacker's prime and generator, generates a Diffie-Hellman key pair in the attacker's group, and sends the client-role message SSH_MSG_KEX_DH_GEX_INIT (32) back to the attacker. Published RFC 3526 safe primes are the worst-case input and cost the attacker nothing to obtain. The primality validation was added in 1.5.0; versions from 1.2.0 through 1.4.22 admit the same message and enter the same client-role path without the primality cost. Message 33 is admitted as well, but on a server it is rejected before any cryptography because no public key check callback is registered, so it carries no comparable cost. Builds that define WOLFSSH_NO_DH_GEX_SHA256, which is implied by WOLFSSH_NO_DH or NO_SHA256, are unaffected.
SSVC
Exploitation: none Automatable: yes Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-07 18:36 UTC
CWE
  • CWE-372 - Incomplete Internal State Distinction
  • CWE-405 - Asymmetric Resource Consumption (Amplification)
  • CWE-400 - Uncontrolled Resource Consumption
Impacted products
Vendor Product Version CPE status
wolfSSL Inc. wolfSSH Affected: 1.2.0 , ≤ 1.5.0 (semver)
guessed Create a notification for this product.
Show details on NVD website

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-84897",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-07T18:36:45.750446Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-07T18:37:00.316Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "key exchange"
          ],
          "product": "wolfSSH",
          "programFiles": [
            "src/internal.c"
          ],
          "programRoutines": [
            {
              "name": "IsMessageAllowedServer"
            },
            {
              "name": "DoKexDhGexGroup"
            },
            {
              "name": "ValidateKexDhGexGroup"
            }
          ],
          "repo": "https://github.com/wolfSSL/wolfssh",
          "vendor": "wolfSSL Inc.",
          "versions": [
            {
              "changes": [
                {
                  "at": "1.6.0",
                  "status": "unaffected"
                }
              ],
              "lessThanOrEqual": "1.5.0",
              "status": "affected",
              "version": "1.2.0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Abdullah Al Ishtiaq, Kai Tu, Matthew Carter, Xiaotian Zhou, Ananna Rahman, Yilu Dong, Tianwei Yu, Ali Ranjbar, Syed Rafiul Hussain"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003ccode\u003esrc/internal.c\u003c/code\u003e in wolfSSL wolfSSH through 1.5.0 admits the server-to-client Diffie-Hellman group exchange messages \u003ccode\u003eSSH_MSG_KEX_DH_GEX_GROUP\u003c/code\u003e (31) and \u003ccode\u003eSSH_MSG_KEX_DH_GEX_REPLY\u003c/code\u003e (33) when a server receives them from an unauthenticated client. \u003ccode\u003eIsMessageAllowedServer()\u003c/code\u003e applies no direction check to the key exchange message range: when the peer is keying and no particular message is expected, which is the state a server is in for the whole window after it processes the client\u0027s KEXINIT because nothing sets \u003ccode\u003ehandshake-\u0026gt;expectMsgId\u003c/code\u003e there, the function falls out of its expectation branch without a verdict and reaches a numeric bound that admits every message id from 30 through 34. A client that negotiates \u003ccode\u003ediffie-hellman-group-exchange-sha256\u003c/code\u003e and then sends message 31 makes the server run the client-side handler \u003ccode\u003eDoKexDhGexGroup()\u003c/code\u003e, which validates the attacker-supplied group with two 8-round Miller-Rabin primality tests, one on \u003ccode\u003ep\u003c/code\u003e and one on \u003ccode\u003e(p-1)/2\u003c/code\u003e, on a value of up to 8192 bits. The handler then returns success: the server stores the attacker\u0027s prime and generator, generates a Diffie-Hellman key pair in the attacker\u0027s group, and sends the client-role message \u003ccode\u003eSSH_MSG_KEX_DH_GEX_INIT\u003c/code\u003e (32) back to the attacker. Published RFC 3526 safe primes are the worst-case input and cost the attacker nothing to obtain. The primality validation was added in 1.5.0; versions from 1.2.0 through 1.4.22 admit the same message and enter the same client-role path without the primality cost. Message 33 is admitted as well, but on a server it is rejected before any cryptography because no public key check callback is registered, so it carries no comparable cost. Builds that define \u003ccode\u003eWOLFSSH_NO_DH_GEX_SHA256\u003c/code\u003e, which is implied by \u003ccode\u003eWOLFSSH_NO_DH\u003c/code\u003e or \u003ccode\u003eNO_SHA256\u003c/code\u003e, are unaffected.\u003cbr\u003e"
            }
          ],
          "value": "src/internal.c in wolfSSL wolfSSH through 1.5.0 admits the server-to-client Diffie-Hellman group exchange messages SSH_MSG_KEX_DH_GEX_GROUP (31) and SSH_MSG_KEX_DH_GEX_REPLY (33) when a server receives them from an unauthenticated client. IsMessageAllowedServer() applies no direction check to the key exchange message range: when the peer is keying and no particular message is expected, which is the state a server is in for the whole window after it processes the client\u0027s KEXINIT because nothing sets handshake-\u003eexpectMsgId there, the function falls out of its expectation branch without a verdict and reaches a numeric bound that admits every message id from 30 through 34. A client that negotiates diffie-hellman-group-exchange-sha256 and then sends message 31 makes the server run the client-side handler DoKexDhGexGroup(), which validates the attacker-supplied group with two 8-round Miller-Rabin primality tests, one on p and one on (p-1)/2, on a value of up to 8192 bits. The handler then returns success: the server stores the attacker\u0027s prime and generator, generates a Diffie-Hellman key pair in the attacker\u0027s group, and sends the client-role message SSH_MSG_KEX_DH_GEX_INIT (32) back to the attacker. Published RFC 3526 safe primes are the worst-case input and cost the attacker nothing to obtain. The primality validation was added in 1.5.0; versions from 1.2.0 through 1.4.22 admit the same message and enter the same client-role path without the primality cost. Message 33 is admitted as well, but on a server it is rejected before any cryptography because no public key check callback is registered, so it carries no comparable cost. Builds that define WOLFSSH_NO_DH_GEX_SHA256, which is implied by WOLFSSH_NO_DH or NO_SHA256, are unaffected."
        }
      ],
      "impacts": [
        {
          "descriptions": [
            {
              "lang": "en",
              "value": "Pre-authentication CPU exhaustion with a high work-per-byte ratio, plus key exchange role confusion. One unauthenticated packet of roughly 1 KB costs a wolfSSH server about 0.48 seconds of single-core CPU when it carries the 4096-bit RFC 3526 safe prime, and about 5.8 seconds when it carries the 8192-bit one, measured on a 64-bit desktop core; a single-threaded or embedded server is unavailable for that whole interval, and the cost repeats on every connection. The server then stores the attacker-chosen group, generates a Diffie-Hellman key pair in it, and sends the client-role message SSH_MSG_KEX_DH_GEX_INIT back to the attacker, so the key exchange continues in the wrong role until it fails. Reaching the 8192-bit case requires a wolfSSL math configuration that can represent an 8192-bit integer; a default build tops out near 4096 bits and caps the burn at roughly half a second."
            }
          ]
        },
        {
          "capecId": "CAPEC-227",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-227 Sustained Client Engagement"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "YES",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.9,
            "baseSeverity": "MEDIUM",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/AU:Y",
            "version": "4.0",
            "vulnAvailabilityImpact": "LOW",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-372",
              "description": "CWE-372 Incomplete Internal State Distinction",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-405",
              "description": "CWE-405 Asymmetric Resource Consumption (Amplification)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400 Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-07T02:42:28.388Z",
        "orgId": "50d2cd11-d01a-48ed-9441-5bfce9d63b27",
        "shortName": "wolfSSL"
      },
      "references": [
        {
          "name": "Fix PR #1221",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/wolfSSL/wolfssh/pull/1221"
        },
        {
          "name": "Fix commit a472f1ee (reject the KEX replies a server never receives)",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/wolfSSL/wolfssh/commit/a472f1ee2b653f623d85ef2297321733f1dbfd22"
        },
        {
          "name": "RFC 4419 sections 3 and 5 (SSH_MSG_KEX_DH_GEX_GROUP and SSH_MSG_KEX_DH_GEX_REPLY are sent by the server)",
          "tags": [
            "technical-description"
          ],
          "url": "https://www.rfc-editor.org/rfc/rfc4419.html"
        },
        {
          "name": "RFC 3526 (published MODP safe primes usable as the worst-case input)",
          "tags": [
            "technical-description"
          ],
          "url": "https://www.rfc-editor.org/rfc/rfc3526.html"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "wolfSSH server accepts server-to-client DH group exchange messages from an unauthenticated client, causing pre-authentication primality-test CPU exhaustion and key exchange role confusion",
      "workarounds": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Build wolfSSH with \u003ccode\u003eWOLFSSH_NO_DH_GEX_SHA256\u003c/code\u003e defined so that \u003ccode\u003ediffie-hellman-group-exchange-sha256\u003c/code\u003e is neither offered nor accepted, which removes the message 31 dispatch path entirely. Where group exchange must stay available, lowering \u003ccode\u003eWOLFSSH_DEFAULT_GEXDH_MAX\u003c/code\u003e reduces the size of the value a peer can submit for primality testing and so the cost of a single packet, but it does not stop a server from accepting the message.\u003cbr\u003e"
            }
          ],
          "value": "Build wolfSSH with WOLFSSH_NO_DH_GEX_SHA256 defined so that diffie-hellman-group-exchange-sha256 is neither offered nor accepted, which removes the message 31 dispatch path entirely. Where group exchange must stay available, lowering WOLFSSH_DEFAULT_GEXDH_MAX reduces the size of the value a peer can submit for primality testing and so the cost of a single packet, but it does not stop a server from accepting the message."
        }
      ],
      "x_generator": {
        "engine": "Vulnogram 1.0.5"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "50d2cd11-d01a-48ed-9441-5bfce9d63b27",
    "assignerShortName": "wolfSSL",
    "cveId": "CVE-2026-84897",
    "datePublished": "2026-10-07T02:42:28.388Z",
    "dateReserved": "2026-09-02T15:07:44.223Z",
    "dateUpdated": "2026-10-07T18:37:00.316Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-84897",
      "date": "2026-10-07",
      "epss": "0.00301",
      "percentile": "0.20939"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "modules": [
                  "key exchange"
                ],
                "product": "wolfSSH",
                "programFiles": [
                  "src/internal.c"
                ],
                "programRoutines": [
                  {
                    "name": "IsMessageAllowedServer"
                  },
                  {
                    "name": "DoKexDhGexGroup"
                  },
                  {
                    "name": "ValidateKexDhGexGroup"
                  }
                ],
                "repo": "https://github.com/wolfSSL/wolfssh",
                "vendor": "wolfSSL Inc.",
                "versions": [
                  {
                    "changes": [
                      {
                        "at": "1.6.0",
                        "status": "unaffected"
                      }
                    ],
                    "lessThanOrEqual": "1.5.0",
                    "status": "affected",
                    "version": "1.2.0",
                    "versionType": "semver"
                  }
                ]
              }
            ],
            "source": "facts@wolfssl.com"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "src/internal.c in wolfSSL wolfSSH through 1.5.0 admits the server-to-client Diffie-Hellman group exchange messages SSH_MSG_KEX_DH_GEX_GROUP (31) and SSH_MSG_KEX_DH_GEX_REPLY (33) when a server receives them from an unauthenticated client. IsMessageAllowedServer() applies no direction check to the key exchange message range: when the peer is keying and no particular message is expected, which is the state a server is in for the whole window after it processes the client\u0027s KEXINIT because nothing sets handshake-\u003eexpectMsgId there, the function falls out of its expectation branch without a verdict and reaches a numeric bound that admits every message id from 30 through 34. A client that negotiates diffie-hellman-group-exchange-sha256 and then sends message 31 makes the server run the client-side handler DoKexDhGexGroup(), which validates the attacker-supplied group with two 8-round Miller-Rabin primality tests, one on p and one on (p-1)/2, on a value of up to 8192 bits. The handler then returns success: the server stores the attacker\u0027s prime and generator, generates a Diffie-Hellman key pair in the attacker\u0027s group, and sends the client-role message SSH_MSG_KEX_DH_GEX_INIT (32) back to the attacker. Published RFC 3526 safe primes are the worst-case input and cost the attacker nothing to obtain. The primality validation was added in 1.5.0; versions from 1.2.0 through 1.4.22 admit the same message and enter the same client-role path without the primality cost. Message 33 is admitted as well, but on a server it is rejected before any cryptography because no public key check callback is registered, so it carries no comparable cost. Builds that define WOLFSSH_NO_DH_GEX_SHA256, which is implied by WOLFSSH_NO_DH or NO_SHA256, are unaffected."
          }
        ],
        "id": "CVE-2026-84897",
        "lastModified": "2026-10-07T19:17:44.647",
        "metrics": {
          "cvssMetricV40": [
            {
              "cvssData": {
                "Automatable": "YES",
                "Recovery": "NOT_DEFINED",
                "Safety": "NOT_DEFINED",
                "attackComplexity": "LOW",
                "attackRequirements": "NONE",
                "attackVector": "NETWORK",
                "availabilityRequirement": "NOT_DEFINED",
                "baseScore": 6.9,
                "baseSeverity": "MEDIUM",
                "confidentialityRequirement": "NOT_DEFINED",
                "exploitMaturity": "NOT_DEFINED",
                "integrityRequirement": "NOT_DEFINED",
                "modifiedAttackComplexity": "NOT_DEFINED",
                "modifiedAttackRequirements": "NOT_DEFINED",
                "modifiedAttackVector": "NOT_DEFINED",
                "modifiedPrivilegesRequired": "NOT_DEFINED",
                "modifiedSubAvailabilityImpact": "NOT_DEFINED",
                "modifiedSubConfidentialityImpact": "NOT_DEFINED",
                "modifiedSubIntegrityImpact": "NOT_DEFINED",
                "modifiedUserInteraction": "NOT_DEFINED",
                "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
                "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
                "modifiedVulnIntegrityImpact": "NOT_DEFINED",
                "privilegesRequired": "NONE",
                "providerUrgency": "NOT_DEFINED",
                "subAvailabilityImpact": "NONE",
                "subConfidentialityImpact": "NONE",
                "subIntegrityImpact": "NONE",
                "userInteraction": "NONE",
                "valueDensity": "NOT_DEFINED",
                "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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:Y/R:X/V:X/RE:X/U:X",
                "version": "4.0",
                "vulnAvailabilityImpact": "LOW",
                "vulnConfidentialityImpact": "NONE",
                "vulnIntegrityImpact": "NONE",
                "vulnerabilityResponseEffort": "NOT_DEFINED"
              },
              "source": "facts@wolfssl.com",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-84897",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "yes"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-07T18:36:45.750446Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-10-07T03:17:00.067",
        "references": [
          {
            "source": "facts@wolfssl.com",
            "url": "https://github.com/wolfSSL/wolfssh/commit/a472f1ee2b653f623d85ef2297321733f1dbfd22"
          },
          {
            "source": "facts@wolfssl.com",
            "url": "https://github.com/wolfSSL/wolfssh/pull/1221"
          },
          {
            "source": "facts@wolfssl.com",
            "url": "https://www.rfc-editor.org/rfc/rfc3526.html"
          },
          {
            "source": "facts@wolfssl.com",
            "url": "https://www.rfc-editor.org/rfc/rfc4419.html"
          }
        ],
        "sourceIdentifier": "facts@wolfssl.com",
        "vulnStatus": "Undergoing Analysis",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-372"
              },
              {
                "lang": "en",
                "value": "CWE-400"
              },
              {
                "lang": "en",
                "value": "CWE-405"
              }
            ],
            "source": "facts@wolfssl.com",
            "type": "Secondary"
          }
        ]
      }
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-84897",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "yes"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-10-07T18:36:45.750446Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-10-07T18:36:55.771Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "modules": [
                "key exchange"
              ],
              "product": "wolfSSH",
              "programFiles": [
                "src/internal.c"
              ],
              "programRoutines": [
                {
                  "name": "IsMessageAllowedServer"
                },
                {
                  "name": "DoKexDhGexGroup"
                },
                {
                  "name": "ValidateKexDhGexGroup"
                }
              ],
              "repo": "https://github.com/wolfSSL/wolfssh",
              "vendor": "wolfSSL Inc.",
              "versions": [
                {
                  "changes": [
                    {
                      "at": "1.6.0",
                      "status": "unaffected"
                    }
                  ],
                  "lessThanOrEqual": "1.5.0",
                  "status": "affected",
                  "version": "1.2.0",
                  "versionType": "semver"
                }
              ]
            }
          ],
          "credits": [
            {
              "lang": "en",
              "type": "finder",
              "value": "Abdullah Al Ishtiaq, Kai Tu, Matthew Carter, Xiaotian Zhou, Ananna Rahman, Yilu Dong, Tianwei Yu, Ali Ranjbar, Syed Rafiul Hussain"
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "supportingMedia": [
                {
                  "base64": false,
                  "type": "text/html",
                  "value": "\u003ccode\u003esrc/internal.c\u003c/code\u003e in wolfSSL wolfSSH through 1.5.0 admits the server-to-client Diffie-Hellman group exchange messages \u003ccode\u003eSSH_MSG_KEX_DH_GEX_GROUP\u003c/code\u003e (31) and \u003ccode\u003eSSH_MSG_KEX_DH_GEX_REPLY\u003c/code\u003e (33) when a server receives them from an unauthenticated client. \u003ccode\u003eIsMessageAllowedServer()\u003c/code\u003e applies no direction check to the key exchange message range: when the peer is keying and no particular message is expected, which is the state a server is in for the whole window after it processes the client\u0027s KEXINIT because nothing sets \u003ccode\u003ehandshake-\u0026gt;expectMsgId\u003c/code\u003e there, the function falls out of its expectation branch without a verdict and reaches a numeric bound that admits every message id from 30 through 34. A client that negotiates \u003ccode\u003ediffie-hellman-group-exchange-sha256\u003c/code\u003e and then sends message 31 makes the server run the client-side handler \u003ccode\u003eDoKexDhGexGroup()\u003c/code\u003e, which validates the attacker-supplied group with two 8-round Miller-Rabin primality tests, one on \u003ccode\u003ep\u003c/code\u003e and one on \u003ccode\u003e(p-1)/2\u003c/code\u003e, on a value of up to 8192 bits. The handler then returns success: the server stores the attacker\u0027s prime and generator, generates a Diffie-Hellman key pair in the attacker\u0027s group, and sends the client-role message \u003ccode\u003eSSH_MSG_KEX_DH_GEX_INIT\u003c/code\u003e (32) back to the attacker. Published RFC 3526 safe primes are the worst-case input and cost the attacker nothing to obtain. The primality validation was added in 1.5.0; versions from 1.2.0 through 1.4.22 admit the same message and enter the same client-role path without the primality cost. Message 33 is admitted as well, but on a server it is rejected before any cryptography because no public key check callback is registered, so it carries no comparable cost. Builds that define \u003ccode\u003eWOLFSSH_NO_DH_GEX_SHA256\u003c/code\u003e, which is implied by \u003ccode\u003eWOLFSSH_NO_DH\u003c/code\u003e or \u003ccode\u003eNO_SHA256\u003c/code\u003e, are unaffected.\u003cbr\u003e"
                }
              ],
              "value": "src/internal.c in wolfSSL wolfSSH through 1.5.0 admits the server-to-client Diffie-Hellman group exchange messages SSH_MSG_KEX_DH_GEX_GROUP (31) and SSH_MSG_KEX_DH_GEX_REPLY (33) when a server receives them from an unauthenticated client. IsMessageAllowedServer() applies no direction check to the key exchange message range: when the peer is keying and no particular message is expected, which is the state a server is in for the whole window after it processes the client\u0027s KEXINIT because nothing sets handshake-\u003eexpectMsgId there, the function falls out of its expectation branch without a verdict and reaches a numeric bound that admits every message id from 30 through 34. A client that negotiates diffie-hellman-group-exchange-sha256 and then sends message 31 makes the server run the client-side handler DoKexDhGexGroup(), which validates the attacker-supplied group with two 8-round Miller-Rabin primality tests, one on p and one on (p-1)/2, on a value of up to 8192 bits. The handler then returns success: the server stores the attacker\u0027s prime and generator, generates a Diffie-Hellman key pair in the attacker\u0027s group, and sends the client-role message SSH_MSG_KEX_DH_GEX_INIT (32) back to the attacker. Published RFC 3526 safe primes are the worst-case input and cost the attacker nothing to obtain. The primality validation was added in 1.5.0; versions from 1.2.0 through 1.4.22 admit the same message and enter the same client-role path without the primality cost. Message 33 is admitted as well, but on a server it is rejected before any cryptography because no public key check callback is registered, so it carries no comparable cost. Builds that define WOLFSSH_NO_DH_GEX_SHA256, which is implied by WOLFSSH_NO_DH or NO_SHA256, are unaffected."
            }
          ],
          "impacts": [
            {
              "descriptions": [
                {
                  "lang": "en",
                  "value": "Pre-authentication CPU exhaustion with a high work-per-byte ratio, plus key exchange role confusion. One unauthenticated packet of roughly 1 KB costs a wolfSSH server about 0.48 seconds of single-core CPU when it carries the 4096-bit RFC 3526 safe prime, and about 5.8 seconds when it carries the 8192-bit one, measured on a 64-bit desktop core; a single-threaded or embedded server is unavailable for that whole interval, and the cost repeats on every connection. The server then stores the attacker-chosen group, generates a Diffie-Hellman key pair in it, and sends the client-role message SSH_MSG_KEX_DH_GEX_INIT back to the attacker, so the key exchange continues in the wrong role until it fails. Reaching the 8192-bit case requires a wolfSSL math configuration that can represent an 8192-bit integer; a default build tops out near 4096 bits and caps the burn at roughly half a second."
                }
              ]
            },
            {
              "capecId": "CAPEC-227",
              "descriptions": [
                {
                  "lang": "en",
                  "value": "CAPEC-227 Sustained Client Engagement"
                }
              ]
            }
          ],
          "metrics": [
            {
              "cvssV4_0": {
                "Automatable": "YES",
                "Recovery": "NOT_DEFINED",
                "Safety": "NOT_DEFINED",
                "attackComplexity": "LOW",
                "attackRequirements": "NONE",
                "attackVector": "NETWORK",
                "baseScore": 6.9,
                "baseSeverity": "MEDIUM",
                "exploitMaturity": "NOT_DEFINED",
                "privilegesRequired": "NONE",
                "providerUrgency": "NOT_DEFINED",
                "subAvailabilityImpact": "NONE",
                "subConfidentialityImpact": "NONE",
                "subIntegrityImpact": "NONE",
                "userInteraction": "NONE",
                "valueDensity": "NOT_DEFINED",
                "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/AU:Y",
                "version": "4.0",
                "vulnAvailabilityImpact": "LOW",
                "vulnConfidentialityImpact": "NONE",
                "vulnIntegrityImpact": "NONE",
                "vulnerabilityResponseEffort": "NOT_DEFINED"
              },
              "format": "CVSS",
              "scenarios": [
                {
                  "lang": "en",
                  "value": "GENERAL"
                }
              ]
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-372",
                  "description": "CWE-372 Incomplete Internal State Distinction",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            },
            {
              "descriptions": [
                {
                  "cweId": "CWE-405",
                  "description": "CWE-405 Asymmetric Resource Consumption (Amplification)",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            },
            {
              "descriptions": [
                {
                  "cweId": "CWE-400",
                  "description": "CWE-400 Uncontrolled Resource Consumption",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-10-07T02:42:28.388Z",
            "orgId": "50d2cd11-d01a-48ed-9441-5bfce9d63b27",
            "shortName": "wolfSSL"
          },
          "references": [
            {
              "name": "Fix PR #1221",
              "tags": [
                "patch"
              ],
              "url": "https://github.com/wolfSSL/wolfssh/pull/1221"
            },
            {
              "name": "Fix commit a472f1ee (reject the KEX replies a server never receives)",
              "tags": [
                "patch"
              ],
              "url": "https://github.com/wolfSSL/wolfssh/commit/a472f1ee2b653f623d85ef2297321733f1dbfd22"
            },
            {
              "name": "RFC 4419 sections 3 and 5 (SSH_MSG_KEX_DH_GEX_GROUP and SSH_MSG_KEX_DH_GEX_REPLY are sent by the server)",
              "tags": [
                "technical-description"
              ],
              "url": "https://www.rfc-editor.org/rfc/rfc4419.html"
            },
            {
              "name": "RFC 3526 (published MODP safe primes usable as the worst-case input)",
              "tags": [
                "technical-description"
              ],
              "url": "https://www.rfc-editor.org/rfc/rfc3526.html"
            }
          ],
          "source": {
            "discovery": "EXTERNAL"
          },
          "title": "wolfSSH server accepts server-to-client DH group exchange messages from an unauthenticated client, causing pre-authentication primality-test CPU exhaustion and key exchange role confusion",
          "workarounds": [
            {
              "lang": "en",
              "supportingMedia": [
                {
                  "base64": false,
                  "type": "text/html",
                  "value": "Build wolfSSH with \u003ccode\u003eWOLFSSH_NO_DH_GEX_SHA256\u003c/code\u003e defined so that \u003ccode\u003ediffie-hellman-group-exchange-sha256\u003c/code\u003e is neither offered nor accepted, which removes the message 31 dispatch path entirely. Where group exchange must stay available, lowering \u003ccode\u003eWOLFSSH_DEFAULT_GEXDH_MAX\u003c/code\u003e reduces the size of the value a peer can submit for primality testing and so the cost of a single packet, but it does not stop a server from accepting the message.\u003cbr\u003e"
                }
              ],
              "value": "Build wolfSSH with WOLFSSH_NO_DH_GEX_SHA256 defined so that diffie-hellman-group-exchange-sha256 is neither offered nor accepted, which removes the message 31 dispatch path entirely. Where group exchange must stay available, lowering WOLFSSH_DEFAULT_GEXDH_MAX reduces the size of the value a peer can submit for primality testing and so the cost of a single packet, but it does not stop a server from accepting the message."
            }
          ],
          "x_generator": {
            "engine": "Vulnogram 1.0.5"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "50d2cd11-d01a-48ed-9441-5bfce9d63b27",
        "assignerShortName": "wolfSSL",
        "cveId": "CVE-2026-84897",
        "datePublished": "2026-10-07T02:42:28.388Z",
        "dateReserved": "2026-09-02T15:07:44.223Z",
        "dateUpdated": "2026-10-07T18:37:00.316Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…