CVE-2026-62878 Teardown: Anatomy of the Wormable Windows DNS Server Stack Overflow That Threatens Every Active Directory Domain Controller

One packet. No credentials, no phishing lure, no user clicking anything. It lands on UDP or TCP port 53, gets parsed by dns.exe, and on the far side of that parse sits the single most load-bearing box in most enterprises: a domain controller that also happens to be your DNS server. That is the shape of CVE-2026-62878, a CVSS 9.8 stack-based buffer overflow Microsoft patched on August 11, 2026. It has not been exploited in the wild and no public proof-of-concept exists yet. That gap – patch shipped, weaponization not yet done – is exactly why this is the right week to take it apart.

A note on what is public and what is not

I want to be straight with you before we go deep, because a lot of “teardown” content on brand-new CVEs quietly invents the parts nobody actually knows.

Here is what is confirmed from Microsoft’s MSRC advisory, NVD, SANS ISC, and ZDI commentary:

Here is what nobody has published as of this writing: the exact vulnerable function name inside dns.exe, which resource-record type or wire field triggers it, the stack frame layout, the overflow offset, and whether UDP, TCP, or both reach the sink. Anyone claiming otherwise this early is guessing.

So this teardown does two honest things. It walks the confirmed attack surface and the well-documented anatomy of prior Windows DNS overflows in real detail, and it gives you the exact binary-diff methodology to derive the specifics yourself. Where I reconstruct a plausible code path, it is labelled as a reconstruction of the vulnerability class, not a confirmed fact about this CVE. On a security education site, that distinction is the whole job.

How dns.exe sees the wire

To understand where a stack frame gets smashed, you need to understand how the DNS Server service reads a packet, because every Windows DNS overflow for the last two decades has lived in the same neighborhood: the per-record-type parsing functions.

A DNS message (RFC 1035) is a header followed by four sections. The header is fixed at 12 bytes:

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode    |AA|TC|RD|RA| Z      | RCODE     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

After the header come the Question, Answer, Authority, and Additional sections. The Answer/Authority/Additional sections are made of Resource Records, and the resource record wire format is where the interesting parsing happens:

  NAME      variable  (compressed or uncompressed label sequence)
  TYPE      2 bytes   (0x0018 = SIG, 0x002E = RRSIG, 0x0010 = TXT ...)
  CLASS     2 bytes   (0x0001 = IN)
  TTL       4 bytes
  RDLENGTH  2 bytes   (uint16 length of RDATA)
  RDATA     RDLENGTH bytes, type-specific

Two things about this layout have generated a startling number of CVEs.

First, RDLENGTH is a 16-bit unsigned integer. It maxes out at 65,535. Any time the parser computes a size from record contents and lets that computation exceed a 16-bit value, you get an integer wrap. That is the whole origin story of SIGRed.

Second, DNS names use compression pointers (RFC 1035 section 4.1.4). A label sequence can end in a two-byte pointer 0xC0 XX that says “the rest of this name is back at offset XX.” Decompression means the number of bytes the parser writes out can be far larger than the number of bytes it read off the wire. Compression is the mechanism by which a small packet inflates into a large in-memory structure, which is precisely the primitive you want when you are trying to overflow a fixed buffer.

dns.exe handles all of this with a dispatch table. When it parses a record, it reads the TYPE field and calls the matching per-type wire reader. Check Point’s SIGRed research documented this pattern directly: functions like SigWireRead, TxtWireRead, NsecWireRead, each responsible for consuming one record type’s RDATA and building the in-memory representation. RR_AllocateEx sits underneath allocating storage. That table is the map of the attack surface. Every entry is a parser that trusts attacker-controlled length and pointer fields to some degree, and any one of them can be the sink for CVE-2026-62878.

The service listens on UDP/53 and TCP/53 by default, and on DNS-over-TLS port 853 on Server 2022 and later. TCP matters here because a UDP DNS message is capped near 512 bytes (or larger with EDNS0), while TCP prefixes a 2-byte length and cleanly carries payloads up to 64KB. SIGRed’s most reliable trigger path was TCP for exactly this reason. If CVE-2026-62878 needs a large decompressed structure to reach the overflow, TCP is the likely delivery vehicle, but that is something you confirm by diff, not by assertion.

Root-cause analysis: deriving the overflowable frame yourself

This is the section where fabrication is tempting and wrong. Instead, here is how you actually find the bug, and the plausible shape of the answer based on how these parsers are built.

The binary diff workflow

You need the unpatched dns.exe from a pre-August-2026 build and the patched dns.exe from the August cumulative update, plus public symbols.

symchk.exe /r dns.exe /s srv*C:\symbols*https://msdl.microsoft.com/download/symbols

Load both into IDA Pro or Ghidra, apply symbols, then run BinDiff (or Diaphora if you are staying FOSS). In the changed-functions list, ignore anything at similarity 1.0 (untouched) and 0.0 (new/removed boilerplate). The gold is in the 0.5 to 0.85 band: functions that were modified but recognizably the same. For a stack overflow fix, you are hunting for one of three fingerprints:

1. A new explicit bounds check inserted before a stack write or a memcpy.
2. A widened integer type, for example a computation moved from WORD to DWORD so it can no longer wrap at 65,535.
3. An unbounded copy (memcpy, wcscpy, hand-rolled loop) replaced by a size-checked variant (memcpy_s, StringCchCopyW).

When you find the fixed function, mentally revert the patch and you have the vulnerable path.

The plausible class, labelled as reconstruction

Based on the CWE-121 classification and the structure of the RR parsers, here is a reconstruction of the vulnerability class. This is illustrative of how these bugs look, not a claim about the specific bytes of this CVE.

// RECONSTRUCTED FROM PRIOR-ART PATTERN - NOT original source,
// NOT a confirmed representation of CVE-2026-62878's actual code path.
// Illustrates the CWE-121 class in a DNS RR wire reader.

int SomeRecordWireRead(PBYTE wire, DWORD wireLen, PPARSED_RR out)
{
    BYTE stackName[256];          // fixed on-stack scratch for a decoded name
    WORD copyLen;                 // 16-bit length, the classic trap

    // rdlength and an internal count are attacker-controlled
    copyLen = read_u16(wire + RDLENGTH_OFF);

    // decompress a name / copy a variable field into the stack buffer.
    // The pre-patch build trusts copyLen (or a value derived from a
    // compressed name expansion) without validating it against
    // sizeof(stackName). memcpy walks past the 256-byte frame and
    // overwrites the saved return address / SEH record.
    memcpy(stackName, wire + FIELD_OFF, copyLen);   // <-- overflow sink

    // ... build parsed record ...
    return 0;
}

The essential ingredients are always the same: a fixed-size buffer that lives on the stack, a length or count that comes from the packet (directly from RDLENGTH, or indirectly from a decompressed name length, or from a per-record count field), and a copy into the fixed buffer that trusts that length. When the copy runs long, it does not corrupt heap metadata the way SIGRed did. It marches straight over the saved return address and the stack cookie and, on 32-bit builds, the SEH frame.

The distinction between “stack” and “heap” here is not pedantry. It changes both exploitation and detection, and it is the crux of the argument I am about to pick with Microsoft’s severity rating.

Stack versus heap: why SIGRed and CVE-2026-62878 are different animals

SIGRed (CVE-2020-1350) was CWE-122, a heap overflow born from an integer overflow. An oversized SIG record caused dns.exe to under-allocate a heap buffer and then write roughly 64KB past it. Exploiting a heap overflow means grooming the heap, corrupting an adjacent object’s metadata or vtable, and steering execution through that. It is fiddly, it depends on allocator state, but it degrades gracefully: you can often retry.

CVE-2026-62878 is CWE-121. A stack overflow overwrites the return address and the exception frames directly. In the abstract, that is a more direct route to instruction-pointer control than a heap overflow. So why does Microsoft rate it “Exploitation less likely”?

Because modern dns.exe is not a soft target. Two mitigations stand between an overflow and a working exploit:

• Stack cookies (/GS). Recent dns.exe builds are compiled with stack canaries. Before that return address is used, the cookie is checked. A straight linear overflow trips the cookie, and the process calls __report_gsfailure and dies. To get RIP control you first need an information leak that discloses the cookie, and DNS parsing does not obviously hand you an oracle for that.
• CET shadow stack and CFG. On Server 2022 and later with Control-flow Enforcement Technology, the CPU keeps a shadow copy of return addresses. Even if you overwrite the on-stack return address, the mismatch faults on ret. Control Flow Guard constrains indirect calls on top of that.

Put those together and the most likely near-term outcome of a naive trigger is not SYSTEM. It is a crash: dns.exe falls over, the DNS Server service restarts, and you have a denial-of-service against a domain controller. That is bad, but it is not remote code execution, and that gap is what Microsoft’s exploitability index is measuring.

Here is where I disagree with how the two ratings sit next to each other. “Exploitation less likely” and “wormable” answer different questions, and pairing them the way the advisory does invites complacency.

“Exploitation less likely” is a probability statement about whether a reliable RCE exploit exists soon. “Wormable” is a statement about the bug’s structure: no authentication, no user interaction, network-reachable, and a service that itself speaks the protocol it is being attacked over, so a successful exploit can pivot from victim to victim autonomously. A bug can be genuinely hard to exploit reliably and still be perfectly wormable the moment someone lands the canary leak. SIGRed carried the same tension and it took the community months, not years, to move from patch to working public exploit. Treat CVE-2026-62878 as wormable and patch on that timeline. Do not let the exploitability index buy you extra weeks.

Historical parallels: the Windows DNS overflow lineage

CVE-2026-62878 is the newest entry in a family, and the family teaches you what to expect.

SIGRed is the archetype. The SigWireRead function parsed SIG records (an obsolete DNSSEC precursor from RFC 2930/2931), and the sum of a decompressed Signer’s Name plus the Signature field could exceed 65,535, wrapping a 16-bit length and under-allocating. A response carrying a SIG record larger than 64KB, delivered over TCP, produced a controlled heap overflow. Its interim mitigation is still instructive: cap TCP DNS payloads with TcpReceivePacketSize = 0xFF00 under HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters. That workaround exists because the bug needed large TCP payloads to reach the sink.

CVE-2021-26897 is the odd one out mechanically: it triggered when many consecutive Signature RR Dynamic Updates were combined into base64 strings before being written to the zone file, producing a heap write. It required Dynamic Updates to be enabled, which is the default for AD-integrated zones. The lesson: features that are on by default in AD-integrated DNS widen the surface.

The April 2023 cluster, including CVE-2023-28254, is the contrast that flatters CVE-2026-62878. Most of the 2023 DNS RCEs required an attacker to win a race condition and to hold elevated privileges. That is why they capped around CVSS 7.2. CVE-2026-62878 asks for neither. PR:N, AC:L, UI:N. No race, no creds, no clicks. On the difficulty-of-preconditions axis, it is closer to SIGRed than to 2023.

The through-line across all four: the vulnerable code always lives in the record-parsing layer, the length/count fields are always the trigger, and the impact is always SYSTEM-or-adjacent on a domain controller. Which is the real problem.

Why every AD DS deployment is the blast radius

If DNS ran on some isolated appliance, a dns.exe RCE would be a bad day for one server. It does not. In the overwhelming majority of Active Directory environments, DNS is installed on the domain controllers, because AD-integrated DNS zones store their records in AD itself and replicate over the directory. That co-location is a Microsoft-recommended default, and it means the process you just achieved code execution inside is running with SYSTEM authority on a box that holds NTDS.dit.

Walk the trust path. Code execution as SYSTEM on a DC gives you the domain’s crown jewels directly. You can perform DCSync (mapping to MITRE ATT&CK T1003.006) to pull every credential hash including krbtgt. With krbtgt you forge golden tickets (T1558.001) and you own authentication for the entire forest, persistently, in a way that survives password resets on everything except krbtgt itself (twice). The initial exploit maps to T1190, Exploit Public-Facing Application, or T1210 when it is fired from an internal foothold.

And do not comfort yourself with “our DCs are not internet-facing.” They should not be. But CVE-2026-62878 is triggered by anything that can send DNS traffic to your resolver, and inside a Windows domain, everything sends DNS traffic to your resolver. A single phished laptop, a rogue device on a flat branch VLAN, a contractor on the VPN, a compromised print server: any of them can deliver the packet. A wormable DNS bug and a network full of clients that all talk to the DC’s DNS service is the definition of internal propagation.

There is also the patch-latency problem. Domain controllers are the servers organizations are most nervous about rebooting. They get scheduled cautiously, tested extensively, and often lag the rest of the fleet by weeks. Which means the machines most catastrophically affected by this bug are statistically the last ones to get the fix. Attackers know this too.

Building a fuzzing harness before the PoC drops

You do not need a public exploit to start hunting. You need an unpatched lab target and a way to feed it malformed records. Everything below runs against a self-built, isolated VM on an air-gapped network. Never a production resolver.

Lab shape: Windows Server 2019 Evaluation from the Microsoft Evaluation Center, DNS Server role installed, snapshotted before patching (label it VULN-BASE), on a host-only network, with WinDbg Preview attached to dns.exe and a Kali attacker box on the same isolated segment.

The dumb fuzzer’s whole job is to attack the length/data relationship: oversized RDLENGTH, values pinned to the 16-bit boundary, and decompression edge cases.

#!/usr/bin/env python3
# dns_stack_fuzz.py - GenXCyber lab fuzzer for CVE-2026-62878 research
# ISOLATED, AIR-GAPPED LAB ONLY. Never against production.
from scapy.all import IP, TCP, Raw, send
import random, struct, sys

TARGET_IP, TARGET_PORT = "192.168.56.10", 53

def build_malformed_rr(rr_type, rdlength_override, rdata):
    name       = b'\xc0\x0c'                     # compression ptr to question
    return (name + struct.pack('>H', rr_type) + struct.pack('>H', 1)
            + struct.pack('>I', 300)
            + struct.pack('>H', rdlength_override & 0xFFFF) + rdata)

def build_response(qname, raw_rr, txid=0x1337):
    hdr = struct.pack('>HHHHHH', txid, 0x8580, 1, 1, 0, 0)
    q = b''.join(bytes([len(l)]) + l.encode() for l in qname.rstrip('.').split('.'))
    q += b'\x00' + struct.pack('>HH', 0x0001, 0x0001)
    return hdr + q + raw_rr

def fuzz_iteration(rr_type):
    rdata = bytes(random.randint(0,255)
                  for _ in range(random.choice([64,512,1024,32768,65535])))
    rdlength = random.choice([len(rdata), 0xFFFF, 0xFF00,
                              len(rdata)+random.randint(1,1024), 0x0000])
    payload = build_response("fuzz.test.lab.",
                             build_malformed_rr(rr_type, rdlength, rdata))
    tcp_payload = struct.pack('>H', len(payload)) + payload   # TCP length prefix
    send(IP(dst=TARGET_IP)/TCP(dport=TARGET_PORT,
            sport=random.randint(1024,65535), flags='PA')/Raw(load=tcp_payload),
         verbose=False)

# RR types with a history of parser bugs; add the one your diff confirms.
INTERESTING = [0x0018, 0x002E, 0x0010, 0x0030, 0x002F, 0x0002, 0x000F, 0x0021]

if __name__ == '__main__':
    n = int(sys.argv[1]) if len(sys.argv) > 1 else 1000
    for i in range(n):
        fuzz_iteration(random.choice(INTERESTING))
        if i % 100 == 0: print(f"[{i}/{n}]")

What this looks like to a defender: a flood of DNS records with RDLENGTH values that do not match the actual RDATA length, unusual RR types (SIG/RRSIG in query/answer flows where they should not appear), and DNS-over-TCP payloads near 64KB. Every one of those is a network signature you will build in the next section. On the host, a fuzzing run that finds anything shows up as repeated DNS Server service crashes and restarts (Event ID 2, “DNS Server has started”) and Sysmon driver errors.

For real coverage, graduate to WinAFL over DynamoRIO. Identify the parsing function from your BinDiff, wrap it in a harness DLL, seed a corpus of valid DNS responses captured off a clean DC, and let it drive:

afl-fuzz.exe -i corpus\ -o findings\ -D C:\DynamoRIO\bin64\ -t 5000 -- ^
  -coverage_module dns.exe -target_module harness.dll ^
  -target_method FuzzEntry -nargs 2 -- harness.exe @@

When you get a crash, triage it in WinDbg. Load the MSEC !exploitable extension, and look for an access violation writing into the stack region, a corrupted return address in the k backtrace, or a mangled SEH chain via !exchain. To find the offset, feed a cyclic pattern as RDATA and match the crashed RIP/RSP against cyclic_find. That offset is the distance from your controlled field to the saved return address, and it is the first real number in your eventual PoC. I am deliberately not shipping a completed PoC here, because none exists publicly and this is a wormable DC bug; the value of this piece is the method and the defenses, not a turnkey worm seed.

Detection engineering: network signatures

You can detect the shape of this attack without knowing the exact vulnerable field, because the malicious traffic violates DNS norms in ways benign traffic does not.

A Zeek script that flags RDLENGTH-versus-payload mismatches and anomalous record types on the answer path:

# cve-2026-62878.zeek - anomalous DNS record shapes
event dns_message(c: connection, is_orig: bool, msg: dns_msg, len: count) {
    # Oversized DNS over TCP is the SIGRed-class delivery vector.
    if (c$id$resp_p == 53/tcp && len > 0xFF00)
        NOTICE([$note=DNS::OversizedTCP, $conn=c,
                $msg=fmt("DNS/TCP payload %d bytes, near 64KB overflow window", len)]);
}

event dns_rejected(c: connection, msg: dns_msg, query: string) {
    # dns.exe rejecting/erroring on malformed records shows here in volume.
    NOTICE([$note=DNS::MalformedBurst, $conn=c, $msg="malformed DNS parse"]);
}

Suricata rules for the two highest-signal conditions, oversized TCP DNS and suspicious SIG/RRSIG records inbound to an authoritative server:

alert tcp any any -> $DNS_SERVERS 53 (msg:"CVE-2026-62878 oversized DNS/TCP toward resolver";
  flow:to_server,established; dsize:>65280; classtype:attempted-admin;
  threshold:type limit,track by_src,count 1,seconds 60; sid:2026628781; rev:1;)

alert udp any any -> $DNS_SERVERS 53 (msg:"CVE-2026-62878 anomalous SIG/RRSIG record in DNS message";
  content:"|00 18|"; offset:0; depth:2; content:"|00 2e|"; distance:0;
  classtype:attempted-admin; sid:2026628782; rev:1;)

Tune sid:2026628782 for your environment; legitimate DNSSEC will carry RRSIG, so the value is in unexpected placement and volume rather than presence alone. Once your binary diff confirms the exact triggering RR type, add a tight content match on that type code, which is the single most precise network detector you can build.

A YARA rule for hunting the trigger in captured pcap or on-disk DNS debug logs:

rule CVE_2026_62878_dns_length_mismatch {
    meta:
        description = "Heuristic: DNS record with RDLENGTH near uint16 boundary"
        author = "GenXCyber"
        reference = "CVE-2026-62878"
    strings:
        $sig_type   = { 00 18 00 01 }        // SIG, class IN
        $rrsig_type = { 00 2e 00 01 }        // RRSIG, class IN
        $max_rdlen  = { ff ff }              // RDLENGTH = 65535
        $near_max   = { ff 00 }              // RDLENGTH = 65280 (SIGRed boundary)
    condition:
        (any of ($sig_type, $rrsig_type)) and (any of ($max_rdlen, $near_max))
}

Detection engineering: host telemetry

Network detection catches delivery. Host telemetry catches the crash and the post-exploitation pivot, which on a DC is where the real damage lands.

Turn on the built-in DNS debug log, no agent required:

dnscmd /config /logLevel 0x8100
dnscmd /config /logFilePath C:\Windows\System32\dns\dns.log
dnscmd /config /logFileMaxSize 100000000

Watch for malformed-packet errors and parser exceptions clustering in time. Then correlate against the events below.

A Sigma rule for the single most reliable post-exploitation tell, dns.exe becoming a parent process:

title: DNS Server Service Spawning Suspicious Child Process
id: 8b1f2c4a-2026-62878-dnsexe-child
status: experimental
description: dns.exe spawning a shell or LOLBin, indicating post-exploitation of a DNS Server RCE such as CVE-2026-62878
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith: '\dns.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\wmic.exe'
  condition: selection
level: critical
tags:
  - attack.execution
  - attack.t1190
  - attack.t1059
falsepositives:
  - Effectively none on a domain controller

The crash-cycle detection (Event ID 2 firing repeatedly) deserves a dedicated alert of its own, because in a wormable-bug scenario, a fleet of DCs restarting their DNS service within a short window is what a worm’s failed exploitation attempts look like at scale. That pattern is your earliest possible warning that someone is spraying the trigger across your internal network.

Detection and defense: what to do this week

Patch first. Apply the August 11, 2026 cumulative update to every Windows Server with the DNS Server role, and prioritize domain controllers despite the reboot pain, precisely because they are the worst-case target and the slowest-patched. Confirm the specific KB against the MSRC advisory for your OS build, and validate deployment with the Nessus plugins (334604 through 334618) or your scanner’s equivalent.

Where you genuinely cannot patch immediately, borrow SIGRed’s interim control if your diff or Microsoft’s guidance indicates the trigger needs large payloads: set TcpReceivePacketSize to 0xFF00 under HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters and restart the DNS service. Treat this as a delay, not a fix, and only after testing it does not break legitimate large TCP responses in your environment.

Beyond that: segment so that arbitrary internal hosts cannot reach DC DNS ports directly where your design allows internal resolvers, restrict who can send to TCP/53, deploy the network signatures above at your internal choke points (not just the perimeter, since the blast radius is internal), and stand up the DC-DNS-crash-cycle alert so you see a spray campaign the moment it starts rather than after the first successful exploit.

Key takeaways

• CVE-2026-62878 is a confirmed CVSS 9.8, unauthenticated, wormable stack overflow in dns.exe, patched August 11, 2026, with no public PoC yet. That gap is a gift, not a reason to relax.
• The precise vulnerable function, RR type, and offset are not public. Anyone presenting them as fact this early is fabricating. Derive them yourself via BinDiff, and label reconstructions as reconstructions.
• “Exploitation less likely” (about near-term reliable RCE, gated by /GS, CFG, and CET) and “wormable” (about the bug’s preconditions) answer different questions. Patch on the wormable timeline regardless of the exploitability index.
• The near-term realistic outcome may be a DoS crash of the DNS service on a DC. That is still an identity-infrastructure outage, and the crash-restart cycle is your best early-warning signal.
• DNS-on-DC co-location turns one packet into SYSTEM on the box holding NTDS.dit, and every client in your domain is a potential delivery vector. Internal segmentation and internal detection matter more than the perimeter here.
• You can detect the attack’s shape today, before a PoC exists: RDLENGTH/payload mismatches, oversized DNS-over-TCP, anomalous SIG/RRSIG placement on the wire, and dns.exe spawning children on the host.

Related Tutorials

• Classic Stack Buffer Overflow: Smashing the Stack on Windows
• Active OSINT: DNS, Certificate Transparency, and Subdomain Enumeration
• Understanding the Stack: Frames, Prologue/Epilogue, and Stack Layout

References

• msdl.microsoft.com
• CVE-2026-62878 – Windows DNS Server Remote Code Execution Vulnerability (Microsoft Security Response Center)
• CVE-2026-62878 – NVD / NIST National Vulnerability Database Entry
• Exploitation of Remote Services, Technique T1210 – MITRE ATT&CK Enterprise
• Microsoft Patch Tuesday for August 2026 Fixed a Zero-Day and Wormable RCE – Security Affairs
• Patch Tuesday August 2026: 5 Critical Threats to Fix Now (CVE-2026-62878 Deep Dive) – Decryption Digest