A newly reported UEFI bootkit known as BlackX was described as being used in an espionage campaign in early 2026, according to reporting citing security researchers. The malware reportedly exploited the older Baton Drop vulnerability to bypass Secure Boot and install a malicious driver intended to interfere with security tools from Kaspersky and Avast.

Although the campaign appears to be targeted, the technical method matters beyond the immediate victims. For European businesses, the incident highlights a persistent security problem: older firmware and boot-process weaknesses can still be effective attack paths when patching, hardware lifecycle management and endpoint controls are inconsistent.

What happened

According to the report, BlackX is a UEFI bootkit—malware designed to compromise the system at a very early stage of the startup process. In this case, the attackers reportedly used the previously disclosed Baton Drop flaw to get around Secure Boot protections and load a driver before the operating system’s normal security layers could fully protect the device.

Secure Boot is intended to prevent untrusted code from running during startup. When attackers are able to bypass it, they may gain a deeper level of persistence and can potentially tamper with security software, survive reinstallation efforts or make detection harder.

The source report says the malicious driver was designed to interfere with security products from Kaspersky and Avast. That does not mean only users of those products are exposed; the broader issue is that firmware-level compromise can reduce the effectiveness of endpoint protection in general.

Why it matters for European businesses

For many SMEs, laptops and workstations are protected mainly through endpoint security software, operating system updates and cloud identity controls. A bootkit operates below much of that stack. That makes it especially relevant for businesses handling sensitive information, remote devices or executive endpoints.

The practical risk is not limited to large enterprises. A successful firmware or boot-level compromise can affect:

• Incident response: infections may be harder to detect and remove than standard malware.
• Trust in endpoint tools: if malware can interfere with security software, monitoring and remediation become more difficult.
• Device lifecycle management: older hardware and delayed firmware updates can create long-lived exposure.
• Supply chain and partner risk: compromised endpoints can be used for espionage, credential theft or further intrusion into business systems.

For regulated organisations or companies preparing for stricter cybersecurity obligations under frameworks such as NIS2, the case reinforces the importance of asset visibility, vulnerability management and security controls that extend beyond standard OS patching.

Who may be affected

The reported campaign was described as espionage-related, so it may have focused on specific targets rather than broad indiscriminate distribution. However, several business groups should pay attention:

• SMEs with mixed or ageing device fleets that may not receive firmware updates consistently.
• IT teams managing Windows endpoints where Secure Boot and driver trust are central protections.
• Companies with remote or distributed staff that rely on endpoint tooling for visibility and control.
• Businesses handling commercially sensitive data, including legal, consulting, manufacturing and technology firms.
• Managed service providers and digital agencies responsible for client endpoint security and device governance.

What companies should consider

Based on the reported technique, businesses should review whether firmware and boot security are included in their normal security processes, not treated as one-off configuration tasks.

• Check firmware update coverage: confirm that laptops, desktops and other relevant devices receive BIOS/UEFI updates from approved vendors.
• Review exposure to older boot vulnerabilities: identify devices that may still be affected by known Secure Boot or UEFI issues, especially older hardware.
• Verify Secure Boot posture: ensure it is enabled where required, and validate that related trust configurations have not drifted from policy.
• Strengthen endpoint detection: use tools and monitoring capable of spotting driver tampering, boot anomalies and attempts to disable security controls.
• Improve asset inventory: maintain accurate records of device models, firmware versions and support status so vulnerable systems can be identified quickly.
• Plan for higher-assurance investigations: if a deep compromise is suspected, standard reimaging may not be enough; businesses may need vendor guidance or hardware replacement in severe cases.

At this stage, the public reporting points to a specific campaign and technique rather than a general emergency for all organisations. Still, the incident is a useful reminder that known vulnerabilities in low-level system components can remain operationally relevant for years if patching, hardware refresh and security validation do not keep pace.