WatchGuard CVE-2026-13043: Update Windows Protection 8.00.26.0012 to Fix PSKMAD Memory Leak

The bug is CVE-2026-13043. It lives in the Panda-lineage Kernel Memory Access Driver, PSKMAD. Panda Security products and WatchGuard Endpoint Security share this code, a legacy of WatchGuard's acquisition of Panda. Here is what the vendor confirms, what researchers claim, and what Windows admins should do now.

What WatchGuard confirms​

WatchGuard's advisory says a missing authentication vulnerability in the Kernel Memory Access Driver (PSKMAD) used by WatchGuard endpoint security products allows a local, authenticated attacker to bypass the driver's access-control handshake and issue arbitrary privileged commands to the driver, resulting in disclosure of kernel and process memory.

The key facts from the vendor:

• Severity: Critical 9.3 CVSS v4.0, published and updated on October 1, 2026.
• Affected versions: Endpoint Security for Windows >= 0, < 8.00.26.0012 is affected. Version 8.00.26.0012 and later is not.
• Weakness classes: CWE-306 Missing Authentication for Critical Function and CWE-798 Use of Hard-coded Credentials, mapped to CAPEC-115 (Authentication Bypass) and CAPEC-194 (Fake the Source of Data).
• Fix: WatchGuard's only listed solution is to update to a fixed release per the affected-version ranges above.

The release notes for both Endpoint Security Prime and Endpoint Security Basic say Windows protection v8.00.26.0012 resolves the CVE-2026-13043 vulnerability in the PSKMAD.sys driver. This vulnerability could enable an attacker to send specially crafted IOCTL requests to read memory allocated to other processes. That release is dated October 1, 2026.

The hard-coded credentials label matters. It suggests the driver's "handshake" relied on a secret that ships inside the product, and a secret every customer receives isn't much of a secret.

Summary: the vendor confirms a local, authenticated bypass of PSKMAD's access control that exposes kernel and process memory. It is fixed in Windows protection 8.00.26.0012.

How "critical" is a local bug?​

The phrase "local, authenticated" can make a bug sound tame. The CVSS v4.0 vector in the CVE record says otherwise: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. In plain English:

• Attack vector: Local. The attacker needs code running on the machine.
• Attack complexity: Low, with no special attack requirements.
• Privileges required: Low. No admin rights are needed, just an ordinary account.
• User interaction: None.
• Impact: High across confidentiality, integrity and availability, both on the vulnerable system and on systems beyond it.

That last point is what lifts the score into the 9s. Memory read from one endpoint, such as credential material, can be used against other machines. The bug doesn't break in. It's what an intruder uses after getting in with a phished user or a malicious download to escalate and move sideways.

Not everyone agrees on how urgent it is. The Vulners database shows its own 6.1 Medium risk AI score next to the 9.3 CVSS rating, and a low EPSS probability. NVD analysis was pending when aggregators indexed the record, so there is no independent NIST score yet. Treat 9.3 as the vendor's rating. Still, a credential-dumping primitive inside a trusted, signed driver is exactly what ransomware crews look for.

The researcher's account: unconfirmed details​

The deeper technical claims come from secondary reporting, not from WatchGuard. CyberPress credits security researcher Juan Sacco with the discovery. It says the driver exposes a user-mode-reachable device interface, \.\PSMEMDriver, intended to support privileged memory-inspection operations.

GBHackers adds that although the opening procedure includes an extended-attribute handshake called PsOpenPacket000, this vulnerability allows an attacker to bypass the intended access-control gate. This matches the vendor's "handshake bypass" description, though WatchGuard doesn't name the device or the handshake.

According to the researcher materials CyberPress cites, which it attributes to ExploitPack:

1. A KASLR leak. The proof of concept uses an IOCTL_MSR request to read model-specific registers, including IA32_LSTAR. GBHackers explains that revealing this privileged address to user mode can expose kernel address information and potentially undermine kernel address space layout randomization.
2. Reading another process's memory. The attacker supplies a process ID, a virtual address and a size. Chained map, transfer and unmap IOCTLs (IOCTL_ENTRY_MAP, IOCTL_TRANSFER, IOCTL_ENTRY_UNMAP) then copy pages out of the target process.
3. An LSASS dump. CyberPress says the proof of concept dumped LSASS on a fully patched Windows 11 25h2 with VBS/HVCI/kCET enabled.

CyberPress also says the driver is signed by the Microsoft Windows Hardware Compatibility Publisher. It lists a vulnerable sample with SHA-256 9bf3b737afa4d4f5e7b00ec749d4b75656ad66d9a2b402e1e81934e95ba7df5b and driver versions 1.1.0.23 and 1.1.0.45.

None of these details appear in WatchGuard's advisory or release notes: the device path, IOCTL names, hash, driver versions, Microsoft signature, and the LSASS demo on Windows 11 25H2. GBHackers itself noted that the vendor's advisory was not retrievable during verification when it wrote its piece. Treat these as credible but unverified until the original research is published in full.

Why the LSASS claim matters if it's true. VBS and HVCI protect kernel code integrity. They don't stop a legitimately loaded, signed driver from doing what it was built to do, and this driver was built to read memory. This is the old "bring your own vulnerable driver" problem, except the driver arrives with your security agent.

This driver has history​

This isn't PSKMAD's first appearance in a vulnerability database. The LOLDrivers project lists the older 64-bit build and says Panda Kernel Memory Access Driver versions through 1.1.0.21 are affected by CVE-2023-6330, CVE-2023-6331 and related issues. WatchGuard's own Endpoint Security Basic release history records a fix for a vulnerability in the pskmad_64.sys driver that could enable an attacker with Administrator privileges to run code with SYSTEM privileges on the target computer. That fix requires Windows protection version 8.00.22.0023 or higher.

Compare the version numbers. The 2023 batch covered builds through 1.1.0.21. The versions reported for CVE-2026-13043 (1.1.0.23 and 1.1.0.45) are later. If those numbers hold up, this is a new weakness in builds released after the earlier fixes, not a missed old one.

There's also a difference in privilege. The earlier pskmad_64.sys fix described an attacker who already had Administrator rights. The 2026 bug, per its CVSS vector, needs only low privileges. A kernel memory-access interface keeps producing bugs because what it does for a living is dangerous. It's like an amp built to go to eleven that keeps blowing speakers.

What Windows admins should do now​

WatchGuard's guidance is short: update. Here's how to work through it with what the vendor has documented.

1. Check the right version number. The fix is tied to Windows protection 8.00.26.0012. In WatchGuard's Endpoint Security Prime 4.70.00 component list, the Windows agent is a separate component, version 1.25.13.0000. Don't read a current agent version as proof the protection module is patched.
2. Inventory below the threshold. Flag every Windows endpoint running Windows protection older than 8.00.26.0012. Pay extra attention to shared systems with many interactive users, such as RDS hosts, jump boxes and lab machines. More local accounts means more chances to exploit a local bug.
3. Expect a staged rollout. WatchGuard says new versions roll out to accounts gradually. Upgrade notifications appear as alerts in the upper-right corner of the management UI. If no alert appears and you need the update, the vendor says to contact your WatchGuard representative and request one.
4. Watch for side effects in the same build. Windows protection 8.00.26.0012 also fixes NNSPRV.sys blue screens (including on Windows 11 ARM64), SCCM/Microsoft Endpoint Configuration Manager failures installing large MSI files, Windows Server 2022 performance problems, and high bandwidth use from Patch Management downloads. Those fixes are unrelated to the CVE, but some fleets may notice them.
5. Be careful with hash blocking. Researchers suggest blocking the vulnerable driver hash and watching for access to \\.\PSMEMDriver. WatchGuard hasn't published either as an official mitigation, and blocking a driver your own EDR depends on could break protection. Test in a pilot group first. Hunting for unexpected processes opening that device is a reasonable lead, as long as you remember the device path is a researcher claim.
6. Assume credentials may be exposed on suspect hosts. If a machine below the fixed version shows signs of compromise, plan as if LSASS memory may have been read. Rotate credentials for accounts that signed in there and review lateral-movement telemetry. This is standard credential-theft response practice, not a WatchGuard instruction.

The bigger picture​

Endpoint protection needs deep kernel access to fight kernel-level threats, and every one of those privileged interfaces is attack surface. Microsoft has been pushing security vendors toward less kernel dependence for exactly this reason. CVE-2026-13043 shows why: a driver whose job is reading other processes' memory is a credential-theft tool if its access check fails.

WatchGuard's disclosure was brief but useful. It gives a clear version boundary, a CVSS vector, and a fix already shipping. The gaps are the technical detail, indicators of compromise and detection guidance, which come mostly from secondary reports of the researcher's work. Until the vendor or the researcher publishes more, the plan is simple: confirm Windows protection is at 8.00.26.0012 or later, chase the stragglers, and test any driver-blocking rule before you deploy it.