dbcve.org
VulnerabilityAwaiting classification

CVE-2026-7762

CRITICAL · 9.8 CVSS v3.1 Published 2026-06-05
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
100/100
Remediation priority · Urgent
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
A heap-based buffer overflow vulnerability in the dot11ah.ko HaLow Wi-Fi kernel driver in Morse Micro HaLowLink 2 software versions prior to 2.11.13 allows an unauthenticated attacker within radio range to cause a Denial of Service (kernel panic) or potentially achieve Remote Code Execution via a crafted 802.11ah beacon or probe response frame containing a malformed S1G Capabilities Information Element (IE element ID 0xD9). The function morse_dot11ah_find_s1g_caps_for_bssid() uses the IE length field directly as the size argument to memcpy without validating it against the 15-byte destination buffer. An attacker can supply up to 255 bytes, causing an overflow of up to 240 bytes of attacker-controlled data into adjacent kernel heap memory. The vulnerability is triggerable during normal scanning without authentication, association, or user interaction.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

Heap-based buffer overflow in Morse Micro HaLow Wi-Fi kernel driver (dot11ah.ko) where function morse_dot11ah_find_s1g_caps_for_bssid() copies attacker-controlled data using an unvalidated length from the S1G Capabilities IE (0xD9) into a 15-byte fixed buffer, allowing up to 240 bytes of overflow into kernel heap memory. Triggerable by unauthenticated attackers via crafted beacon/probe response frames during normal scanning.

MitigationUpdate Morse Micro HaLowLink 2 software to version 2.11.13 or later to obtain the patched driver. Until patched, restrict radio exposure to trusted devices and monitor for kernel panics.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Verify dot11ah.ko driver presence
    Run 'lsmod | grep dot11ah' or 'modinfo dot11ah' to check if the Morse Micro HaLow Wi-Fi driver module is loaded or available on the system
    Affected if The dot11ah.ko module is loaded and the system has 802.11ah HaLow Wi-Fi hardware enabled
  2. Check driver version
    Run 'modinfo dot11ah' and look for the 'version' or 'srcversion' field, or check '/sys/module/dot11ah/version' if available
    Affected if The driver version is earlier than 2.11.13 (the version with proper bounds checking)
  3. Verify S1G capability processing is active
    Check if the system has an active 802.11ah interface by running 'iw list' or 'ip link show' to enumerate wireless interfaces, then use 'iw <interface> info' to see if the interface supports 802.11ah (S1G)
    Affected if An 802.11ah/S1G interface is active and processing beacon or probe response frames containing S1G IE (0xD9)
  4. Monitor for crash indicators
    Check kernel logs with 'dmesg' or 'journalctl -k' for messages containing 'morse_dot11ah_find_s1g_caps_for_bssid', 'buffer overflow', or 'kernel panic' related to the dot11ah driver
    Affected if Kernel panic or memory corruption errors related to the dot11ah driver appear in system logs

If the dot11ah.ko driver is loaded with a version prior to 2.11.13 and an 802.11ah interface is active, the system is vulnerable to heap overflow via malformed S1G IE frames.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Update Morse Micro HaLowLink 2 software to version 2.11.13 or later to obtain the patched driver. Until patched, restrict radio exposure to trusted devices and monitor for kernel panics.

Recommended fix High confidence

Morse Micro HaLowLink 2 version 2.11.13 or later

  1. 1. Identify all devices running Morse Micro HaLowLink 2 software versions prior to 2.11.13
  2. 2. Obtain the firmware update to version 2.11.13 or later from Morse Micro
  3. 3. Review the firmware release notes for any specific update instructions or prerequisites
  4. 4. Apply the firmware update to affected devices following the vendor's recommended procedure
  5. 5. Verify the update was successful by checking the software version on each device
  6. 6. Confirm the dot11ah.ko driver has been updated and is functioning normally

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation3.0 h
  • Implementation6.0 h
  • Testing8.0 h
  • Review / QA3.0 h
20.0 hours of engineering $3,420
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $5,472.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-7762 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-7762 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data