This is a tenant who can already enter the building slamming a utility closet door until the breaker trips
CVE-2025-0222 is a local null-pointer dereference in the IUProcessFilter.sys IOCTL handler used by IObit Protected Folder. The affected range published by VulDB/NVD is 13.6.0.0 through 13.6.0.5; the crash is triggered through IOCTLs 0x8001E000 and 0x8001E004, and the stated outcome is denial of service rather than code execution or privilege escalation.
The vendor/CNA MEDIUM label is still generous for enterprise triage. In real deployments this requires a user already logged onto the Windows host, already able to talk to the device object, and the impact stops at availability disruption on a product that is consumer-oriented and not commonly business-critical; that combination pushes this down to LOW.
4 steps from start to impact.
Land on a Windows host with Protected Folder installed
- Windows endpoint has IObit Protected Folder installed
- Attacker already has local execution as an authenticated user
- This is a niche desktop utility, not a broadly deployed enterprise platform
- Any requirement for local code execution means the attacker is already post-compromise
Open the driver path and send crafted IOCTLs
IUProcessFilter.sys via DeviceIoControl, targeting IOCTLs 0x8001E000/0x8001E004. The attacker uses a custom harness or the published PoC pattern to pass malformed input into the IOCTL handler.- Access to the relevant device interface exposed by the driver
- Ability to execute user-mode code that can call
CreateFile/DeviceIoControl
- The published record indicates
PR:L, not anonymous access - Application control, WDAC, AppLocker, or EDR can block unsigned crash harnesses or suspicious child processes
DeviceIoControl usage from unknown binaries, but most vuln scanners will miss exploitability validation.Trigger null dereference in IUProcessFilter.sys
- Vulnerable build
<= 13.6.0.5 - Input reaches the vulnerable code path without prior sanitization
- No confidentiality or integrity impact is documented
- No public evidence shows this crosses into code execution or privilege escalation
Use the crash as disruption, not expansion
- Host matters enough that a reboot or hang is painful
- Protected Folder is actually used on that endpoint
- Single-host blast radius is typical
- Modern enterprise response can usually reimage, reboot, or remove the software quickly
- Perimeter WAFs and network IPS: this is not a remotely exposed web or network service, so those controls never get a chance to intervene.
- MFA: strong identity helps initial access, but once an attacker already has local code execution, MFA does nothing for a local IOCTL-driven crash.
- Traditional external vulnerability scanning: scanners looking from the network edge will not see a local desktop-driver issue like this.
The supporting signals.
| In-the-wild status | No reliable evidence of active exploitation found. CISA ADP enrichment marks exploitation as poc, not known-active. |
|---|---|
| PoC availability | A public exploit reference is listed by NVD/OpenCVE at a Notion URL, and VulDB tags it as an exploit. That means reproduction details exist, but this is still a local crash PoC, not a wormable weapon. |
| EPSS | 0.00051 from your intel, which is extremely low and consistent with a niche, local-only DoS. |
| KEV status | Not KEV-listed. No CISA KEV entry found for CVE-2025-0222. |
| CVSS interpretation | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H means *local*, *authenticated*, *no user interaction*, *availability-only*. The decisive reducers are AV:L and PR:L. |
| Affected versions | Published affected builds are 13.6.0.0 through 13.6.0.5 of IObit Protected Folder; vulnerable component is IUProcessFilter.sys in the IOCTL handler. |
| Fixed version | No vendor-fixed version was clearly documented in the sources reviewed. Treat anything > 13.6.0.5 as unknown until the vendor publishes release notes or an advisory. |
| Scanning / exposure data | This is a local Windows desktop utility/driver, not an internet service. Shodan/Censys-style external exposure is effectively not applicable; the real exposure question is software prevalence in your endpoint fleet. |
| Disclosure timeline | VulDB/OpenCVE timeline shows the advisory disclosed on 2025-01-04 and the CVE published on 2025-01-05. |
| Reporter | Reported by TopGun (VulDB User) according to the CNA record exposed via OpenCVE. |
Sources.
Why this verdict
- Start from 5.5 MEDIUM: the CNA/NVD baseline assumes the technical availability impact is real, and it is
- Downward adjustment for attacker position:
AV:L+PR:Lmeans this is not an initial-access path; it assumes the attacker already compromised the endpoint or is already a logged-in user - Downward adjustment for exposure population: IObit Protected Folder is a niche endpoint utility, not a common enterprise control plane or server component, so reachable population is small
- Downward adjustment for defensive friction: WDAC/AppLocker/EDR commonly block or at least surface the custom user-mode harness needed to poke the IOCTL interface from arbitrary code
- No upward pressure from threat intel: no KEV listing, no trustworthy evidence of active campaigns, and an extremely low EPSS
Why not higher?
There is no remote reachability, no user-to-admin escalation documented, and no confidentiality or integrity impact in the published record. Even with a public PoC, this is still a local crash against a narrow population of hosts, which is exactly the kind of compounding friction that should keep severity down.
Why not lower?
It is still a real kernel-adjacent driver bug in shipping Windows software, with public exploit references and a credible denial-of-service outcome. If this software exists on shared workstations, kiosks, or operational endpoints, a local attacker can create real disruption, so 'IGNORE' would be too dismissive.
Crowdsourced verification payload.
Run this on the target Windows endpoint or through your management tool as a local script. Invoke with powershell -ExecutionPolicy Bypass -File .\check-CVE-2025-0222.ps1; local admin is recommended for consistent access to uninstall registry and driver metadata, though standard user often works.
# check-CVE-2025-0222.ps1
# Detect likely exposure to CVE-2025-0222 on Windows hosts.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
[CmdletBinding()]
param()
$ErrorActionPreference = 'SilentlyContinue'
function Get-VersionObject {
param([string]$VersionString)
try {
if ([string]::IsNullOrWhiteSpace($VersionString)) { return $null }
return [version]$VersionString
} catch {
return $null
}
}
function Get-ProtectedFolderInstall {
$paths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
foreach ($p in $paths) {
$items = Get-ItemProperty $p | Where-Object {
$_.DisplayName -match 'Protected Folder' -or $_.DisplayName -match 'IObit Protected Folder'
}
foreach ($item in $items) {
[pscustomobject]@{
DisplayName = $item.DisplayName
DisplayVersion = $item.DisplayVersion
InstallLocation = $item.InstallLocation
Publisher = $item.Publisher
}
}
}
}
function Get-DriverVersion {
$candidatePaths = @(
'C:\Program Files\IObit\Protected Folder\IUProcessFilter.sys',
'C:\Program Files (x86)\IObit\Protected Folder\IUProcessFilter.sys',
'C:\Program Files\IObit\Protected Folder\pffilter.sys',
'C:\Program Files (x86)\IObit\Protected Folder\pffilter.sys'
)
foreach ($path in $candidatePaths) {
if (Test-Path $path) {
$f = Get-Item $path
return [pscustomobject]@{
Path = $path
FileVersion = $f.VersionInfo.FileVersion
ProductVersion = $f.VersionInfo.ProductVersion
}
}
}
return $null
}
$fixedBoundary = Get-VersionObject '13.6.0.5'
$installs = @(Get-ProtectedFolderInstall)
$driver = Get-DriverVersion
if ($installs.Count -eq 0 -and -not $driver) {
Write-Output 'PATCHED - IObit Protected Folder not detected on this host.'
exit 0
}
$foundVersion = $null
foreach ($install in $installs) {
$v = Get-VersionObject $install.DisplayVersion
if ($v) {
if (-not $foundVersion -or $v -gt $foundVersion) {
$foundVersion = $v
}
}
}
if (-not $foundVersion -and $driver) {
$v = Get-VersionObject $driver.ProductVersion
if (-not $v) { $v = Get-VersionObject $driver.FileVersion }
if ($v) { $foundVersion = $v }
}
if (-not $foundVersion) {
Write-Output 'UNKNOWN - Protected Folder artifacts found, but no reliable version could be parsed.'
if ($driver) { Write-Output ('Driver: ' + $driver.Path) }
exit 2
}
if ($foundVersion -le $fixedBoundary) {
Write-Output ('VULNERABLE - Detected Protected Folder version ' + $foundVersion.ToString() + ' (affected range includes 13.6.0.0 through 13.6.0.5).')
if ($driver) { Write-Output ('Driver: ' + $driver.Path) }
exit 1
}
Write-Output ('UNKNOWN - Detected version ' + $foundVersion.ToString() + ' which is newer than 13.6.0.5, but no authoritative vendor-fixed version was confirmed in reviewed sources.')
if ($driver) { Write-Output ('Driver: ' + $driver.Path) }
exit 2