CVE-2025-70616: wnBios64.sys Buffer Overflow Vulnerability

CVE-2025-70616 Overview

A stack buffer overflow vulnerability exists in the Wincor Nixdorf wnBios64.sys kernel driver (version 1.2.0.0) in the IOCTL handler for code 0x80102058. The vulnerability is caused by missing bounds checking on the user-controlled Options parameter before copying data into a 40-byte stack buffer (Src[40]) using memmove. An attacker with local access can exploit this vulnerability by sending a crafted IOCTL request with Options greater than 40, causing a stack buffer overflow that may lead to kernel code execution, local privilege escalation, or denial of service (system crash). Additionally, the same IOCTL handler can leak kernel addresses and other sensitive stack data when reading beyond the buffer boundaries.

Critical Impact

This kernel-level vulnerability enables local privilege escalation to SYSTEM, arbitrary kernel code execution, or complete system crash through a maliciously crafted IOCTL request targeting the wnBios64.sys driver.

Affected Products

• Wincor Nixdorf wnBios64.sys kernel driver version 1.2.0.0
• Systems utilizing Wincor Nixdorf ATM/POS hardware with vulnerable driver versions

Discovery Timeline

• 2026-03-05 - CVE-2025-70616 published to NVD
• 2026-03-05 - Last updated in NVD database

Technical Details for CVE-2025-70616

Vulnerability Analysis

This vulnerability represents a classic stack buffer overflow in a Windows kernel driver. The wnBios64.sys driver exposes an IOCTL interface at code 0x80102058 that fails to properly validate user-supplied input before performing memory operations. When processing IOCTL requests, the driver allocates a fixed 40-byte stack buffer but does not validate that the user-controlled Options parameter stays within these bounds before invoking memmove to copy data.

The security implications are severe due to the kernel context in which this driver operates. A successful exploit allows an attacker to overwrite critical kernel stack structures, potentially hijacking control flow to execute arbitrary code with kernel privileges. The vulnerability also enables information disclosure, as reading beyond buffer boundaries can leak kernel memory addresses, defeating ASLR protections and exposing sensitive stack data.

Root Cause

The root cause is the absence of bounds checking on the user-controlled Options parameter in the IOCTL handler. The driver allocates a fixed-size stack buffer of 40 bytes (Src[40]) but accepts arbitrarily large Option values from user-mode callers. When memmove is called with an Options value exceeding 40, the operation writes past the stack buffer boundary, corrupting adjacent stack memory including saved registers and return addresses.

Attack Vector

The attack requires local access to the target system where the vulnerable wnBios64.sys driver is loaded. An attacker can exploit this vulnerability through the following steps:

1. Open a handle to the device object exposed by wnBios64.sys
2. Craft a malicious IOCTL request targeting code 0x80102058
3. Set the Options parameter to a value greater than 40 bytes
4. Send the IOCTL request to trigger the stack buffer overflow
5. Leverage the overflow to corrupt kernel stack structures for privilege escalation or code execution

The attacker does not need administrative privileges to send the IOCTL request, as the driver does not implement proper access control checks on the device object. Technical details and proof-of-concept code are available in the wnBios64-CVE GitHub Repository.

Detection Methods for CVE-2025-70616

Indicators of Compromise

• Unexpected system crashes (BSOD) with bug check codes related to stack corruption or memory access violations
• Suspicious processes making IOCTL calls to wnBios64.sys device objects
• Evidence of privilege escalation from low-privileged user accounts to SYSTEM
• Kernel memory dumps showing stack corruption patterns near 40-byte boundaries

Detection Strategies

• Monitor for IOCTL calls to device objects associated with wnBios64.sys using kernel-level ETW (Event Tracing for Windows) providers
• Implement driver behavior monitoring to detect anomalous memory operations in kernel drivers
• Deploy endpoint detection solutions capable of identifying privilege escalation attempts originating from user-mode applications
• Enable Windows Kernel Driver Integrity checks and monitor for unsigned or tampered driver loads

Monitoring Recommendations

• Configure SentinelOne to monitor for suspicious driver interactions and kernel exploitation attempts
• Enable crash dump analysis for systems running Wincor Nixdorf hardware to identify exploitation attempts
• Implement application whitelisting to prevent unauthorized applications from communicating with vulnerable drivers
• Monitor Windows Event Logs for driver load events involving wnBios64.sys

How to Mitigate CVE-2025-70616

Immediate Actions Required

• Identify all systems with wnBios64.sys version 1.2.0.0 installed and prioritize them for remediation
• Contact Wincor Nixdorf (now Diebold Nixdorf) for updated driver versions with the vulnerability patched
• Consider temporarily unloading the vulnerable driver if business operations permit
• Restrict local access to systems running vulnerable drivers to trusted administrators only
• Deploy SentinelOne endpoint protection to detect and prevent exploitation attempts

Patch Information

No vendor patch information is currently available in the CVE database. Organizations should contact Diebold Nixdorf directly for guidance on obtaining patched driver versions. Monitor the wnBios64-CVE GitHub Repository for updates and remediation guidance.

Workarounds

• Restrict access to the device object exposed by wnBios64.sys using Windows Security Descriptors to limit which users can send IOCTL requests
• Implement application control policies to prevent unauthorized executables from communicating with the driver
• Consider using Device Guard or Hypervisor-Protected Code Integrity (HVCI) to add defense-in-depth against kernel exploitation
• Deploy network segmentation to isolate ATM/POS systems running vulnerable drivers from general network access

The mitigation approach requires restricting local access and implementing defense-in-depth controls until an official patch is available from the vendor. Organizations should prioritize updating the wnBios64.sys driver once a patched version is released.