The following analysis examines the attack vector for CVE-2025-47761 , a vulnerability found in the Fortips_74.sys kernel driver used by FortiClient VPN for Windows. The core of the vulnerability lies in a mishandled IOCTL that allows unprivileged user-mode processes to interact with the kernel, enabling an arbitrary 4-byte write primitive.
The flaw was discovered on January 31, 2025, by Alex Ghiotto , a member of the Hackerhood community. Although the corrective patch was integrated as early as September 2025 with the release of version 7.4.4 ,
Fortinet only formalized the vulnerability on November 18, 2025 with the publication of the official bulletin FG-IR-25-112 .
This case study is particularly interesting for evaluating the effectiveness of modern system mitigations: the exploit relies on obtaining the kernel address of the process token, an operation made complex starting with Windows 11 24H2 . In this latest version, accessing this information via NtQuerySystemInformation now requires the SeDebugPrivilege privilege, significantly raising the requirements for an effective attack by non-administrative users.
Fortips_74.sys is a kernel driver used by some Fortinet solutions, including FortiClientVPN . During analysis of the driver, a vulnerability emerged that was later identified and patched as CVE-2025-47761 . The goal of this article is to describe the analysis process that led to its discovery and to understand its main security implications . The vulnerability allows an arbitrary 4-byte write to a user-controlled address . This behavior can cause a system crash or be exploited for full privilege escalation .
When analyzing a driver for potential privilege escalation, the first fundamental question is: who can interact with it?
If even non-privileged users can open a handle, then it’s worth looking into.
In this case, the first step is to observe who can interact with Fortips_74.sys.
Using WinObj , you immediately notice that the driver does not set restrictive permissions – this immediately catches your attention.
A more technical view of DACLs is possible from the kernel via WinDBG
The Fortips_74 driver creates a kernel device without defining custom DACLs , relying on the default security descriptor . In practice, any process on the system can open a handle to the driver, including those with low integrity (such as sandboxed browser processes).
(On this last point I admit that I have not carried out a formal check to confirm.)
Analyzing the DACLs , it appears that SYSTEM and administrators have full access, but other users can still communicate with the driver , albeit with limited permissions .
This behavior makes the driver too sociable: anyone can communicate via IOCTL , and in the absence of adequate controls the dispatch must be managed extremely rigorously to avoid vulnerabilities .
Before we get into the specific details of the Fortips driver, a quick refresher is in order.
Input/Output Control ( IOCTLs ) allow user-mode processes to send specific commands to drivers.
In Windows, the DeviceIoControl feature allows you to:
Basically, it’s a way of saying:
“Perform this operation with this data.”
Analyzing the driver IOCTLs, one in particular looks suspicious: 0x12C803 .
This IOCTL uses METHOD_NEITHER , the most dangerous of the Windows methods: the kernel passes user-mode pointers directly to the driver without any validation .
It is therefore the driver ‘s sole responsibility to check:
If these checks are missing, the attacker can pass arbitrary pointers , causing the driver to read/write memory it shouldn’t be accessing.
Using this tool you can confirm that the driver directly uses the METHOD_NEITHER IOCTL type.
The driver uses the caller-provided UserBuffer directly to write output, without any prior copying or validation. This means that a user-mode process can pass an arbitrary pointer , which the driver will use as the data destination. Without proper checks, a malicious address can transform simple output into an arbitrary kernel-mode write , with obvious security implications.
Following the buffer flow, the function copies the contents of the user-mode buffer into a local buffer on the stack. The first 24 bytes (0x18) are interpreted as:
The Size field is not relevant in this chain, while Code and Buffer are.
To reach the vulnerable branch , Code must be 0x63 .
After preliminary copying to a local buffer , the driver jumps to the affected condition.
At this point, uVar7 is set to 4 .
Here lies the heart of vulnerability:
The driver copies 4 bytes from an uninitialized buffer to the address specified by the user via the IOCTL.
There is no control or sanitization.
Since the data source is stack-junk, the vulnerability results in an arbitrary 4-byte write .
For example, by specifying the kernel address of the _TOKEN structure, privilege escalation can be achieved.
In my PoC, I changed the token to enable the SeDebugPrivilege privilege, then launched a cmd as SYSTEM.
To reduce the required user interaction, I analyzed the mechanism by which FortiClient starts the IPSec service.
The main process uses a Named Pipe to handle IPC communication, sending a buffer to the pipe
\Device\NamedPipe\FC_{6DA09263-AA93-452B-95F3-B7CEC078EB30} .
Inside the buffer there are several fields, including the name of the IPSec tunnel to initialize. This call is sufficient to start the driver, even without administrative privileges , a prerequisite for the vulnerability.
In FortiClient VPN version 7.4.3.1790, it is also possible to create a completely fake IPSec profile using arbitrary parameters. In my case, for the testing phase, I set the remote gateway to “google.it” , a behavior different from what Fortinet indicated in the official CVE bulletin.
Video Player
As mentioned, exploitation of this vulnerability relies on obtaining the kernel address of the token associated with the process, thus manipulating its privileges. Starting with Windows 11 24H2, this is no longer possible from a process with a medium integrity level using the traditional NtQuerySystemInformation call, as accessing this information now requires the SeDebugPrivilege privilege, which is normally unavailable to non-administrator users.
In my proof-of-concept, I exploited the CVE-2025-53136 vulnerability, which uses a race condition to leak the _TOKEN address. This allows the PoC to remain functional until the vulnerability is fixed in the August/September 2025 updates.
Outside of this specific case, exploiting the vulnerability on a fully updated system would require an additional bug that could leak the required address, as protections introduced in the new kernel prevent it from being obtained directly.
Follow us on Google News to receive daily updates on cybersecurity. Contact us if you would like to report news, insights or content for publication.
