A vulnerability was found in IObit Protected Folder up to 13

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.

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:L means 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.

1. Inventory the product — Use EDR, Intune, SCCM, or uninstall-registry inventory to identify where IObit Protected Folder exists and whether it is actually business-approved. For a LOW verdict there is no emergency window, but you should complete this as normal backlog hygiene and use it to scope later removal or replacement.
2. Block untrusted local tooling — Enforce WDAC, AppLocker, or equivalent application control so opportunistic malware or users cannot easily run ad hoc crash harnesses against device drivers. This is a broad hardening win and is appropriate as standard endpoint policy rather than a special CVE-only response.
3. Prefer removal on unmanaged-use endpoints — If Protected Folder is not on an approved software list, remove it during your standard software-rationalization cycle instead of spending analyst time waiting for a vendor hotfix that is not clearly documented. For LOW, treat this as backlog hygiene tied to your normal endpoint cleanup process.
4. Watch for bugchecks on affected hosts — Route Windows crash, reboot, and bugcheck telemetry into the SOC so repeated kernel crashes on hosts with this software do not get dismissed as random instability. This does not prevent exploitation, but it reduces dwell time if someone is deliberately using the crash path.

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

Sources

1. NVD CVE-2025-0222
2. OpenCVE record for CVE-2025-0222
3. CVE Details summary
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS API documentation
6. IObit FAQ - Protected Folder
7. IObit Japan download center
8. IObit Protected Folder quick start guide