A vulnerability was found in lwIP up to 2

CVE-2026-8836 is a stack-based buffer overflow in lwIP's SNMPv3 USM parsing path, specifically snmp_parse_inbound_frame() in src/apps/snmp/snmp_msg.c. Upstream lwIP versions through 2.2.1 are affected; the fix is a small bounds-checking patch in commit 0c957ec03054eb6c8205e9c9d1d05d90ada3898c. The bug is reachable over the network *if* the device includes the optional SNMP agent code, has SNMPv3 enabled, and exposes that management surface to an attacker.

The vendor-style 9.8 score is technically defensible in a lab because the bug is pre-auth, remote, and memory unsafe. In enterprise reality it overstates fleet-wide urgency: lwIP is a library, not a uniform product, and this flaw sits in an optional SNMPv3 feature that many deployments never compile, never enable, or never expose beyond a management VLAN. That drops this from universal fire-drill territory to a focused but real HIGH.

Why this verdict

• Down from 9.8 because this is an optional component, not the core stack — the bug lives in the SNMP app code, so a huge fraction of lwIP consumers are unaffected in practice.
• Down again because the vulnerable path is SNMPv3-specific — requiring the v3 USM parser narrows the population further versus 'any network packet to any lwIP host'.
• Still high because attacker position can be unauthenticated remote — once UDP/161 to a vulnerable device is reachable, the parser can be hit without creds or user action.
• Still high because embedded management surfaces are sticky — these devices often live for years, patch slowly, and sit on flat or trusted management networks where one foothold makes later movement easier.

Why not higher?

This is not a universal lwIP internet-RCE in the way the headline score implies. There is no verified KEV listing, no verified public exploitation evidence in the official sources reviewed, and the reachable population is sharply reduced by optional-feature and management-plane exposure requirements.

Why not lower?

Calling this MEDIUM would underweight the fact that the bug is still pre-auth, network reachable, and memory unsafe when the feature is present. On embedded network gear or OT-adjacent devices, even crash-only exploitation can have outsized operational impact, and successful code execution would land inside a trusted appliance context.

1. Restrict UDP/161 now — Apply ACLs so SNMP is reachable only from your management servers and jump networks. For a HIGH verdict, deploy this within 30 days; if you already know a vulnerable device is internet- or user-segment-exposed, do it immediately rather than waiting.
2. Disable SNMPv3 where unused — If the product allows disabling the SNMP agent or SNMPv3 specifically, turn it off on systems that do not require it. This removes the vulnerable parser path entirely and should be completed within 30 days.
3. Segment management planes — Move affected devices behind dedicated management VLANs or out-of-band networks and block SNMP from workstation/user segments. For HIGH, this is a within-30-days mitigation because it shrinks attacker reach even if patching is delayed.
4. Monitor for device instability — Add alerts for unexpected reboots, SNMP polling failures, watchdog resets, and disappearing devices. Do this within 30 days so you can catch crash-oriented exploitation or testing while the fleet is being remediated.

Run this on an auditor workstation, CI job, or build host against an extracted firmware source tree or vendor SDK that contains lwIP sources. Invoke it as python3 verify_lwip_cve_2026_8836.py /path/to/lwip with read access only; no admin privileges are required.

#!/usr/bin/env python3
# verify_lwip_cve_2026_8836.py
# Detects the vulnerable vs patched SNMPv3 auth-parameter length handling in lwIP.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import re
import sys

VULN_FILE = os.path.join('src', 'apps', 'snmp', 'snmp_msg.c')

VULN_PATTERNS = [
    r'/\*\s*IF_PARSE_ASSERT\(tlv\.value_len\s*<=\s*SNMP_V3_MAX_AUTH_PARAM_LENGTH\);\s*\*/',
    r'&u16_value\s*,\s*tlv\.value_len\s*\)\s*;'
]

PATCH_PATTERNS = [
    r'IF_PARSE_ASSERT\(tlv\.value_len\s*<=\s*SNMP_V3_MAX_AUTH_PARAM_LENGTH\);',
    r'&u16_value\s*,\s*SNMP_V3_MAX_AUTH_PARAM_LENGTH\s*\)\s*;'
]


def load_file(root):
    path = os.path.join(root, VULN_FILE)
    if not os.path.isfile(path):
        return None, path
    try:
        with open(path, 'r', encoding='utf-8', errors='ignore') as f:
            return f.read(), path
    except Exception:
        return None, path


def main():
    if len(sys.argv) != 2:
        print('UNKNOWN - usage: python3 verify_lwip_cve_2026_8836.py /path/to/lwip')
        sys.exit(2)

    root = sys.argv[1]
    text, path = load_file(root)
    if text is None:
        print(f'UNKNOWN - could not read expected source file: {path}')
        sys.exit(2)

    vuln_hits = all(re.search(p, text, re.MULTILINE) for p in VULN_PATTERNS)
    patch_hits = all(re.search(p, text, re.MULTILINE) for p in PATCH_PATTERNS)

    if patch_hits and not vuln_hits:
        print(f'PATCHED - fixed bounds checks found in {path}')
        sys.exit(0)

    if vuln_hits and not patch_hits:
        print(f'VULNERABLE - vulnerable auth-parameter length handling found in {path}')
        sys.exit(1)

    # Mixed or unrecognized code: could be vendor backport, refactor, or unrelated fork.
    print(f'UNKNOWN - unable to classify {path}; inspect handling of SNMP_V3_MAX_AUTH_PARAM_LENGTH and snmp_asn1_dec_raw() manually')
    sys.exit(2)


if __name__ == '__main__':
    main()

Sources

1. NVD CVE-2026-8836
2. Upstream fix commit
3. lwIP repository README
4. lwIP SNMPv2c/v3 agent documentation
5. lwIP SNMPv3 header documentation
6. Debian CVE tracker entry
7. Debian source package tracker for lwip
8. CISA Known Exploited Vulnerabilities Catalog