CVE-2026-49494: Comodo Internet Security IPv6 parser kernel DoS
TL;DR - A crafted IPv6 packet can crash Windows systems running Comodo Internet Security. - Exposure is remote and unauthenticated, in the Inspect.sys firewall driver. - Public PoC exists; no verified vendor fix was confirmed at publication time.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-49494 |
| CVSS score | 7.5 |
| Attack vector | Network |
| Auth required | None |
| Patch status | No official patch or fixed version confirmed from retrieved sources |
What defenders need to know first
CVE-2026-49494 is a remote denial-of-service vulnerability in Comodo Internet Security, specifically in the Inspect.sys firewall kernel driver. According to the NVD description, the bug is an integer underflow in the product’s IPv6 packet parser. A remote attacker can trigger the issue by sending a single crafted IPv6 packet, causing a Windows kernel crash and resulting in a BSOD.
The operationally important detail is that the vulnerable parsing path is reached before firewall rule enforcement. In practical terms, that means systems may still be reachable for exploitation even if administrators believe exposure is reduced because all inbound ports are blocked. This is not a remote code execution issue based on currently available evidence, but it is still a serious availability risk because it can forcibly crash endpoints or servers over the network without authentication or user interaction.
Affected products and version status
The confirmed affected product is Comodo Internet Security, and the affected component is the firewall driver Inspect.sys. That product and component naming is supported by the NVD description and corroborating public references. However, the exact official affected version range was not provided in the accessible primary-source material reviewed for this article.
One version has been mentioned in secondary reporting and public references: 12.2.2.8012. Because the retrieved source set did not include an official vendor advisory or published version matrix, defenders should treat Comodo Internet Security version 12.2.2.8012 as potentially affected, while also assuming other nearby or current builds may be affected unless Comodo states otherwise. Just as importantly, no fixed version number could be verified from available primary sources, so this article cannot honestly quote a confirmed patched release.
For teams that need a precise inventory statement, the most defensible wording is:
- Confirmed affected product:
Comodo Internet Security - Confirmed affected component:
Inspect.sys - Publicly referenced affected version:
12.2.2.8012 - Official full affected range: unknown from available primary sources
- Official fixed version: unknown from available primary sources
In the absence of vendor guidance, defenders should assume any deployed Comodo Internet Security installation with the vulnerable Inspect.sys driver may be exposed to remote IPv6-based denial of service.
Why this vulnerability matters
This vulnerability matters because it is remotely reachable, unauthenticated, and kernel-level. The attack requires only a crafted IPv6 packet and does not depend on credentials, local access, or a user opening a file. That combination makes it especially relevant for internet-facing Windows assets, remote worker endpoints, and internal networks where IPv6 is enabled by default but not consistently monitored.
It also matters because the crash occurs in kernel context at DISPATCH_LEVEL, according to the NVD description. Even when the effect is “only” denial of service, kernel crashes can disrupt business operations, interrupt remote access, cause service restarts, and trigger incident response activity that consumes staff time. On servers, the effect could look like unexplained instability; on endpoints, it may appear as repeat BSOD events with limited obvious application-level clues.
Technical root cause
The underlying bug is described as an integer underflow in the IPv6 extension-header parsing logic inside Inspect.sys. The parser reads the IPv6 fixed header’s payload length, stores it in an unsigned 64-bit value, and then subtracts the size of each IPv6 extension header as it walks the packet. If the attacker supplies a payload length smaller than the total extension-header length, the subtraction underflows and wraps to a very large value.
That bad length state then influences later operations in the driver. Per the NVD description, one path can trigger an out-of-bounds read, and another can lead to an oversized memcpy. Because the vulnerable logic runs inside a Windows kernel driver, the net effect is a system crash rather than a safely handled parse error. There is currently no primary-source evidence in the reviewed materials that this bug is exploitable for remote code execution, so defenders should frame it as a remote kernel DoS.
Technical Notes
The vulnerable condition is tied to malformed IPv6 packets whose declared payload length does not match the cumulative size of chained extension headers. Defenders reviewing packet captures should pay attention to IPv6 traffic with suspicious or inconsistent extension-header chains, especially where the payload length appears too small relative to hop-by-hop, routing, destination options, fragment, or other extension headers.
A high-level representation of the dangerous condition looks like this:
IPv6 Header:
Payload Length = small value
Extension Headers:
Header 1 length = X
Header 2 length = Y
Header 3 length = Z
Condition:
Payload Length < (X + Y + Z)
Exploitation status and threat assessment
A public PoC or exploit research repository exists. The NVD reference list includes the GitHub repository https://github.com/MalwareTech/ComoDoS, which materially increases defender concern because it lowers the barrier for reproduction and testing. Public technical write-up references also indicate that the issue has received researcher attention beyond a bare CVE entry.
At the same time, in-the-wild exploitation is not confirmed from the sources reviewed here. The CVE is not listed in CISA KEV as of 2026-06-07, which means there is no CISA-confirmed active exploitation designation at this time. That does not mean exploitation is impossible or unlikely; it means defenders should avoid overstating the threat intelligence picture. The accurate state today is:
- PoC/public exploit material: Yes
- Confirmed in-the-wild exploitation: No verified primary-source confirmation found
- CISA KEV listed: No
For prioritization, most organizations should treat this as a high-priority availability issue if Comodo Internet Security is present and IPv6 traffic can reach affected hosts.
What to tell leadership
This is a remotely triggerable availability issue in a kernel driver, not currently a confirmed in-the-wild campaign. The business risk is interruption rather than known data theft or code execution. That said, the presence of a public PoC and the pre-firewall parsing behavior make it more urgent than an ordinary local crash bug.
Leadership should understand three points: first, affected systems may be crashable from the network with no credentials; second, there is no verified fixed version from the sources available today; third, interim mitigations may require IPv6 restrictions or compensating network controls that could affect operations and should be coordinated carefully.
Bottom line
CVE-2026-49494 is a serious remote kernel DoS flaw in Comodo Internet Security’s Inspect.sys driver, reachable via crafted IPv6 traffic before firewall rules are applied. Public PoC material exists, but there is no verified evidence of exploitation in the wild from the reviewed primary sources and no confirmed fixed version number yet.
If you run Comodo Internet Security, assume exposure until proven otherwise, inventory systems with Inspect.sys, restrict untrusted IPv6 traffic now, and monitor aggressively for crash events and suspicious IPv6 activity while awaiting authoritative vendor remediation guidance.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection and hunting guidance
Detection will be imperfect because a single malformed packet may simply crash the host before rich application logging occurs. The first practical indicator is often host instability rather than a clean security alert. Look for BSODs, unexpected reboots, watchdog-related crashes, and network-adjacent crashes on systems running Comodo Internet Security with Inspect.sys loaded.
You should also correlate host crash events with inbound IPv6 traffic. Since the vulnerability is tied to malformed IPv6 extension-header processing, network telemetry is valuable. Even if you cannot prove exploit intent from logs alone, a pattern of suspicious IPv6 packets immediately before endpoint crashes is enough to escalate and isolate exposed systems.
Technical Notes
On Windows, start by reviewing system events around crash time:
Get-WinEvent -LogName System | Where-Object {
$_.Id -in 41,1001
} | Select-Object TimeCreated, Id, ProviderName, Message | Format-List
Useful crash-related indicators include:
- Event ID 41 from Microsoft-Windows-Kernel-Power after an unexpected reboot
- Event ID 1001 bugcheck events indicating a BSOD/minidump was generated
If you collect packet telemetry with Zeek, Suricata, or a sensor capable of IPv6 header inspection, hunt for malformed extension-header chains. A practical Suricata-style detection concept is to flag IPv6 packets with extension headers from untrusted sources for deeper review, especially if followed by host crash events:
alert ipv6 any any -> $HOME_NET any (
msg:"Suspicious IPv6 extension header traffic to potential Comodo Inspect.sys target";
ipv6.hdr;
classtype:attempted-dos;
sid:4949401;
rev:1;
)
That rule is intentionally broad and should be tuned. If you have full packet capture, look for a pattern like:
ipv6.payload_length < total_extension_header_length
In Splunk, you can correlate crash events with prior IPv6 activity from the same host:
(index=wineventlog EventCode=41 OR EventCode=1001)
| eval host_key=coalesce(host, ComputerName)
| join type=left host_key [
search index=network ipv6=*
| stats latest(_time) as last_ipv6 by host_key, src_ip, dest_ip
]
| table _time, host_key, EventCode, src_ip, dest_ip, Message
Mitigation and response
No official vendor patch or fixed version was confirmed in the retrieved source material. Because of that, defenders should be explicit internally: there is no verified fixed version number available to cite as of 2026-06-07. If your team finds a newer vendor advisory later, update your asset management notes and incident playbooks immediately.
Until a vendor-supported fix is confirmed, the most practical mitigation is to reduce exposure to untrusted IPv6 traffic. That can include disabling IPv6 where operationally safe, filtering IPv6 at network boundaries, restricting inbound IPv6 to known peers, or temporarily removing Comodo Internet Security from high-risk internet-facing systems if business constraints allow. Since the vulnerable parsing occurs before firewall rule enforcement in the product, relying on local Comodo firewall policy alone is not a sufficient control.
Technical Notes
If your organization decides that temporary IPv6 disablement is acceptable on an affected Windows host, an administrator can disable IPv6 bindings on adapters with PowerShell:
Get-NetAdapterBinding -ComponentID ms_tcpip6 | Disable-NetAdapterBinding -ComponentID ms_tcpip6
To verify status:
Get-NetAdapterBinding -ComponentID ms_tcpip6 | Select-Object Name, DisplayName, Enabled
If you need a host firewall workaround outside the vulnerable product, use Windows Defender Firewall or upstream network controls to reduce inbound IPv6 exposure. Example PowerShell command to block inbound IPv6 traffic at the host firewall:
New-NetFirewallRule -DisplayName "Temporary Block Inbound IPv6" -Direction Inbound -Action Block -Protocol Any -RemoteAddress ::/0
To remove the temporary rule later:
Remove-NetFirewallRule -DisplayName "Temporary Block Inbound IPv6"
For software update operations, there is no specific verified upgrade command to a fixed Comodo version because the fixed version is unknown. If you use enterprise software deployment tooling, the right operational step is to check the installed Comodo version and compare it against any future vendor bulletin before rollout. For example, inventory the installed product and driver version first:
Get-Item "C:\Windows\System32\drivers\inspect.sys" | Select-Object Name, VersionInfo
If no mitigation is operationally acceptable, isolate exposed systems from untrusted IPv6 sources and prioritize crash monitoring and business continuity planning.
References
- NVD entry for CVE-2026-49494
- GitHub reference:
https://github.com/MalwareTech/ComoDoS - Research write-up reference:
https://malwaretech.com/2026/06/exploiting-a-remote-kernel-vulnerability-in-comodo-internet-security.html - VulnCheck advisory reference:
https://www.vulncheck.com/advisories/comodo-internet-security-inspect-sys-ipv6-integer-underflow-remote-denial-of-service - For more information on cybersecurity best practices, check our Ransomware Response Checklist and FAQs on Training Data Poisoning.