CVE-2025-70616 in wnBios64.sys
Summary
by MITRE • 03/05/2026
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 > 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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 03/11/2026
This vulnerability resides within the Wincor Nixdorf wnBios64.sys kernel driver version 1.2.0.0, specifically targeting the IOCTL handler for code 0x80102058. The flaw represents a classic stack buffer overflow condition that arises from inadequate input validation mechanisms. The driver fails to implement proper bounds checking on the user-controlled Options parameter, creating a scenario where malicious input can exceed the allocated 40-byte stack buffer named Src[40]. This absence of input sanitization directly violates security principles outlined in the CWE-121 category for stack-based buffer overflow vulnerabilities, where insufficient boundary checks allow attackers to overwrite adjacent stack memory locations.
The technical exploitation of this vulnerability requires an attacker with local system access to craft a malicious IOCTL request that deliberately sets the Options parameter to a value exceeding 40 bytes. When the memmove function executes with this oversized parameter, it copies data beyond the confines of the 40-byte buffer, causing unpredictable memory corruption. This memory corruption can overwrite return addresses, function pointers, and other critical stack variables, potentially enabling arbitrary code execution within kernel space. The vulnerability's classification aligns with ATT&CK technique T1068 which describes local privilege escalation through kernel exploits, while also mapping to CWE-787 for out-of-bounds write conditions that can result in code execution.
The operational impact of this vulnerability extends beyond simple code execution capabilities to include potential system instability and information disclosure. Beyond the primary risk of kernel code execution, the same IOCTL handler demonstrates additional security flaws by leaking kernel addresses and sensitive stack data when reading beyond buffer boundaries. This information disclosure aspect creates a significant risk for attackers seeking to bypass security mitigations such as ASLR, as leaked kernel addresses can be used to construct more sophisticated exploitation payloads. The vulnerability's potential for local privilege escalation means that an attacker could gain elevated system privileges, potentially allowing access to sensitive system resources, user credentials, or the ability to install malware that persists across system reboots.
Mitigation strategies for this vulnerability must address both immediate exploitation prevention and long-term system hardening. System administrators should implement immediate patch management procedures to upgrade to the latest version of the wnBios64.sys driver where the bounds checking has been properly implemented. Additionally, deploying kernel-mode exploit protection mechanisms such as Control Flow Guard and Driver Signature Enforcement can help prevent exploitation attempts even if patches are not immediately available. The principle of least privilege should be enforced through proper access controls to limit local user access to system resources that might be leveraged for exploitation. Organizations should also implement monitoring solutions capable of detecting anomalous IOCTL activity patterns that could indicate exploitation attempts targeting this specific vulnerability. Regular security assessments and vulnerability scanning should include checks for this specific driver version to ensure proper remediation has been completed across all affected systems.