Zemana 3.2.28 Vulnerabilities Explained

The exact Zemana vulnerability scope in one table

The search result “Zemana driver vulnerability” hides four separate questions: which product, which build, which driver binary and which behavior? A CVE can be accurate while a blog post applying it to every Zemana-branded file is wrong. We use the narrowest scope stated by the public record or the cited researcher.

This table isn't a severity league. CVSS measures a defined record under defined assumptions. It doesn't answer whether a particular file on your PC is the affected binary, whether Windows loaded it or whether an attacker supplied the process that tried to use it.

Why AntiMalware version 3.2.28 matters in 2026

Zemana's public release notes end with AntiMalware 3.2.28 dated March 31, 2021. That same number appears in the NVD description for CVE-2022-42045 and at the upper edge of the AntiMalware versions in the later independent analysis. We found no public AntiMalware successor that lets an installed user say, “this is the fixed build.”

A vulnerability record can outlive a supported product, and an old CVE doesn't prove active exploitation on every machine. The decisive maintenance problem is the missing closure: no current fixed-version statement, no newer public client and no support trail that reconciles the privileged driver with current Windows enforcement. Our broader Zemana status and migration advisory covers the release-age, certificate and replacement decision. This page stays on the technical boundary.

That distinction also prevents a common logical error. The last public version being vulnerable doesn't mean every installation is presently compromised. It means the installed security component no longer has a verifiable supported state, which is enough reason to replace it without inflating the evidence.

CVE-2022-42045: serious privilege impact, not remote compromise

NVD describes CVE-2022-42045 as arbitrary code injection affecting Zemana AntiMalware 3.2.28 and Watchdog Anti-Malware 4.1.422. As rechecked August 10, 2026, the record shows CVSS 3.1 6.7 Medium with vector AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. In plain language: local access, low attack complexity, high privileges already required, no victim click and potentially high impact to confidentiality, integrity and availability.

The high-privilege prerequisite matters. This isn't a flaw where a stranger on the internet sends one packet to a clean home PC. The useful threat model begins after malicious code has gained local execution and elevated access. At that point, a flawed kernel component can turn a partial compromise into deeper control or help neutralize defenses.

“Medium” shouldn't be read as “safe to keep.” CVSS captures exploit conditions, not product lifecycle. A maintained vendor can patch a medium-severity privileged component and document the fixed build. The unresolved problem here is that 3.2.28 remains the last public AntiMalware build we could verify.

CVE-2023-36204 and CVE-2023-36205 cover different driver powers

VoidSec's reverse-engineering report separates two access-control failures. CVE-2023-36204 concerns powerful disk access exposed by the driver. CVE-2023-36205 concerns obtaining privileged process handles and a route to local privilege escalation. The report maps the AntiMalware line through 3.2.28 and also discusses related AntiLogger builds.

Those capabilities are dangerous because kernel drivers legitimately operate beyond ordinary application boundaries. A security product may need to inspect processes, files or disks. If the driver's request interface doesn't restrict who can ask for those actions, another local process can try to borrow the driver's authority.

We describe these as independent advisories rather than a vendor statement. The research supplies technical scope and CVE assignments; it doesn't supply a current Zemana support promise or a public fixed AntiMalware version. That evidence gap is why the recommendation stays conservative without pretending the records say more than they do.

CVE-2024-1853 is the AntiLogger boundary people keep losing

NVD's CVE-2024-1853 entry names Zemana AntiLogger 2.74.204.664 and the zam64.sys and zamguard64.sys drivers. It describes arbitrary process termination through a driver request and scores the record 5.5 Medium with low privileges required.

That doesn't automatically turn CVE-2024-1853 into an AntiMalware 3.2.28 record. Related Zemana products may share names, components or code ancestry. A reused driver filename isn't a cryptographic identity. To map a file responsibly, we need its product metadata, file version, hash, signer and package origin, then we compare those identifiers with the research sample.

The boundary isn't pedantry. It stops defenders from attaching the wrong fix, severity or incident story to a file, and it stops a legitimate old remnant from being presented as proof of an active attacker.

A valid signature proves identity, not permanent safety

A digital signature can tell Windows who signed a specific binary, whether the bytes changed after signing and whether the certificate chain is currently trusted. It doesn't certify that the code has no vulnerability, remains supported or should load under today's security policy.

This is why “legitimately signed vulnerable driver” isn't a contradiction. A vendor signs software it believes is suitable at release. Researchers later discover a powerful request path or insufficient access control. Attackers then copy that unchanged signed binary because the operating system may trust its publisher history more readily than an obviously malicious driver.

Signature status can also change. A certificate may expire or be revoked, and Windows can add a file or certificate to a vulnerable-driver blocklist. Record both the signer identity and the current verification result. “Signed by Zemana at release” and “accepted by this Windows configuration today” are different facts.

BYOVD is a post-compromise chain with several breakpoints

Bring Your Own Vulnerable Driver describes an attacker supplying or reusing a real driver whose privileged functions can be abused. The chain starts before the driver: malicious code needs a foothold, then enough access to place and load a kernel driver. The operating system accepts the signed component, the attacker-controlled loader sends privileged requests and defenses may be stopped or manipulated.

Each stage leaves different evidence. Endpoint telemetry may show the initial process; elevation creates account or token events; driver installation creates a service and file path; Code Integrity records whether Windows allowed or blocked the image; EDR logs may show unusual targeting of security processes. A defender can log, block or investigate before the chain reaches its final effect.

The sequence explains two facts that sound opposed but are both true. A vulnerable Zemana-related driver can be useful to an attacker. Finding that driver alone doesn't prove how it arrived, whether it loaded, which process called it or whether defenses were impaired.

Terminator and Spyboy reporting shows the attacker-controlled half

Sophos documents Terminator variants that use legitimately signed Zemana-related drivers to terminate antivirus and EDR processes. The loader, targeting logic and follow-on payload are attacker-controlled. The signed vulnerable driver supplies a privileged mechanism; it isn't the whole tool.

This separation matters when interpreting a vendor detection. A security product may block the driver because its risk is known even when no malicious loader is visible. Conversely, an attacker can rename a copied driver, so a harmless-looking filename can't clear it. Detection names, full paths, hashes and process ancestry are stronger than the basename displayed in a popup.

Continued variants also explain why an old consumer product remains relevant to current threat research. Attackers reuse reliable signed components long after the original software's commercial moment has passed. That's a reason to remove the unsupported component and preserve Windows protections, not a reason to label every historical Zemana customer infected.

The WatchDog SDK case is related history, not the same installer

Check Point Research's 2025 Silver Fox analysis carefully distinguishes an older ZAM 3.0.0.000 component from a separate WatchDog amsdk.sys 1.0.600 driver derived from the Zemana Anti-Malware SDK. The report says the latter was Microsoft-signed and, in the tested conditions, could load on fully updated Windows 10 and Windows 11 while outside the blocklist coverage described at that time.

“Derived from the Zemana SDK” doesn't mean “the same binary shipped by the consumer AntiMalware 3.2.28 installer.” SDK code can be embedded, renamed, rebuilt and signed in another product context. Use Check Point's case to understand ancestry and the limits of signature-based trust, not to collapse WatchDog, AntiLogger and AntiMalware into one package.

A February 2026 BleepingComputer case records Code Integrity blocking amsdk.sys because of a revoked certificate and hypervisor incompatibility. It's a useful example of the message a user may see. One support thread can't estimate how many systems have the file or prove that every occurrence has the same origin.

Use a driver evidence matrix, not a filename verdict

Before removal, capture enough information that another analyst could identify the exact binary later. A screenshot of the popup is useful; the underlying event, file properties and hash are better. Don't upload a potentially sensitive corporate file to a public service without authorization.

Preserve timestamps too. A file written five years ago to a disconnected secondary disk presents a different immediate question from a renamed copy created minutes before an EDR process stopped. Both deserve exact cleanup; only the second pattern strongly points toward an active incident.

Keep Memory Integrity and the vulnerable-driver blocklist enabled

Microsoft uses several controls because signatures alone can't solve vulnerable-driver abuse. The recommended driver-block rules deny known risky binaries or certificates. Memory Integrity, also called HVCI, isolates code-integrity decisions using virtualization-based security.

Blocklists aren't a perfect historical catalogue. Researchers can find a driver before it's covered, vendors can release variants and policy availability differs by Windows version and configuration. That limitation argues for layered defense: current Windows updates, Memory Integrity where supported, one maintained antivirus and investigation of unexpected driver-load events.

Don't disable Memory Integrity or import a permissive policy to make Zemana 3.2.28 run. The compatibility failure is telling you the old privileged component doesn't meet the current boundary. Replace the product. Our Microsoft Defender review explains the built-in real-time role; the malware-removal guide covers maintained second-opinion options.

Route a known installation and an unexpected driver differently

A known install explains provenance; it doesn't make the old driver suitable. An unusual path raises suspicion; it doesn't replace verification. This two-part reasoning avoids panic and avoids false reassurance. For the normal-uninstall, restart, protection-handoff and remnant-routing sequence, use our complete Zemana removal guide.

Six mistakes that destroy evidence or weaken the PC

1. Deleting by filename. Record the path, hash, signer and load state before changing the system.
2. Applying the AntiLogger CVE to every AntiMalware file. Match product, build and binary identity.
3. Calling BYOVD a remote exploit. The documented chain begins after foothold and privilege acquisition.
4. Disabling Memory Integrity. Remove incompatible legacy software instead of removing the control.
5. Running copied driver-store or registry commands. Broad cleanup can damage Windows and erase the service context an analyst needs.
6. Installing several real-time replacements. Keep one maintained real-time owner; use additional scanners deliberately.

There's one more reporting mistake: saying “Zemana is malware.” The historical consumer program was legitimate. The current safety problem is an old unsupported build and privileged components with public vulnerability and abuse history. Precise language produces a stronger recommendation.