A vulnerability has been found in IOBit Protected Folder up to 1

CVE-2025-0221 is a local null-pointer dereference in pffilter.sys, the driver behind IObit Protected Folder, affecting versions up to and including 1.3.0. A user-mode process with local access can talk to the driver's IOCTL handler (0x22200c) and trigger a crash path that causes availability impact only—think driver crash / BSOD / local denial of service, not code execution, privilege escalation, or data theft.

The vendor/CNA MEDIUM 5.5 score is technically fair in a vacuum, but it overstates enterprise urgency. The decisive real-world friction is that this requires local code execution plus local privileges on a host that already has this niche product installed, and the outcome is only single-host disruption. For a 10,000-host program, this is backlog hygiene, not an interrupt-the-week emergency.

Why this verdict

• Down from vendor 5.5: AV:L is not a small detail; it means the attacker is already on the box, so this vulnerability does not help with initial access.
• Further down: PR:L implies a logged-in user or equivalent foothold, which compounds the post-compromise requirement instead of broadening exposure.
• Further down: impact is A:H only; there is no confidentiality, integrity, or privilege-escalation payoff in the published scoring and descriptions.
• Further down: the affected product appears to be a niche endpoint utility, not a core enterprise platform with ubiquitous managed deployment.
• Slight upward pressure: a public PoC/exploit reference exists, so the bug is reproducible and should not be dismissed as purely theoretical.

Why not higher?

There is no remote reachability, no authentication bypass, no privilege escalation, and no evidence that exploiting this bug turns a minor foothold into materially greater control. In a real enterprise kill chain, an attacker who already has local execution generally has easier and more useful ways to cause disruption than crashing this specific third-party driver.

Why not lower?

I would not mark it IGNORE because kernel-driver bugs can still create real workstation/server instability, and public PoC availability lowers the effort for a malicious insider or already-landed malware to weaponize it. If this product is present on sensitive endpoints, you should still track it and reduce exposure rather than hand-wave it away.

1. Inventory the product — Identify where IObit Protected Folder is installed, including the presence of pffilter.sys, so you know whether the issue exists at all. For a LOW verdict there is no mitigation SLA; do this as normal vulnerability hygiene while planning remediation inside the 365-day window.
2. Restrict untrusted code execution — Use WDAC/AppLocker/EDR policy to block unsigned or unapproved binaries and scripts from running on endpoints with this software. That directly cuts off the prerequisite local execution step; for a LOW finding, fold this into normal hardening rather than treating it as an emergency.
3. Remove the software where unnecessary — If Protected Folder is not a business requirement, uninstall it from managed endpoints and VDI images. This eliminates the vulnerable driver entirely and is usually a better answer than waiting for a vendor patch that may never arrive; complete under the 365-day remediation window.
4. Watch for crash patterns — Add detection for repeated bugchecks, sudden reboots, or user-mode tools targeting the driver on systems where Protected Folder is installed. This will not prevent exploitation, but it helps you distinguish accidental instability from deliberate endpoint sabotage during the remediation period.

Run this on the target Windows host or through your endpoint management tool as Administrator. Example: powershell.exe -ExecutionPolicy Bypass -File .\Test-CVE-2025-0221.ps1. It checks for IObit Protected Folder and the pffilter.sys driver version; because no public fixed version was found, any installed version <= 1.3.0 is treated as VULNERABLE.

# Test-CVE-2025-0221.ps1

# Checks whether IObit Protected Folder / pffilter.sys is present and vulnerable.

# Output: VULNERABLE / PATCHED / UNKNOWN

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


$ErrorActionPreference = 'Stop'

function Write-Result {
    param(
        [string]$State,
        [int]$Code,
        [string]$Detail
    )
    Write-Output ("{0} - {1}" -f $State, $Detail)
    exit $Code
}

function Parse-Version {
    param([string]$Value)
    try {
        return [version]$Value
    } catch {
        return $null
    }
}

try {
    $paths = @(
        "$env:ProgramFiles\IObit\Protected Folder\pffilter.sys",
        "$env:ProgramFiles\IObit\Protected Folder\drivers\pffilter.sys",
        "$env:ProgramFiles(x86)\IObit\Protected Folder\pffilter.sys",
        "$env:ProgramFiles(x86)\IObit\Protected Folder\drivers\pffilter.sys"
    )

    $driver = $paths | Where-Object { Test-Path $_ } | Select-Object -First 1

    $uninstallRoots = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
    )

    $app = Get-ItemProperty $uninstallRoots -ErrorAction SilentlyContinue |
        Where-Object {
            $_.DisplayName -match 'Protected Folder' -or $_.Publisher -match 'IObit'
        } |
        Sort-Object DisplayVersion -Descending |
        Select-Object -First 1

    $appVersion = $null
    if ($app -and $app.DisplayVersion) {
        $appVersion = Parse-Version $app.DisplayVersion
    }

    $driverVersion = $null
    if ($driver) {
        $fvi = [System.Diagnostics.FileVersionInfo]::GetVersionInfo($driver)
        if ($fvi -and $fvi.FileVersion) {
            $driverVersion = Parse-Version $fvi.FileVersion
        }
    }

    $threshold = [version]'1.3.0.0'

    if (-not $driver -and -not $app) {
        Write-Result -State 'PATCHED' -Code 0 -Detail 'IObit Protected Folder not installed; host not affected.'
    }

    if ($appVersion -and $appVersion -le $threshold) {
        Write-Result -State 'VULNERABLE' -Code 1 -Detail ("Installed product version {0} is <= 1.3.0." -f $appVersion)
    }

    if ($driverVersion -and $driverVersion -le $threshold) {
        Write-Result -State 'VULNERABLE' -Code 1 -Detail ("Driver version {0} is <= 1.3.0 at {1}." -f $driverVersion, $driver)
    }

    if ($appVersion -and $appVersion -gt $threshold) {
        Write-Result -State 'PATCHED' -Code 0 -Detail ("Installed product version {0} is > 1.3.0." -f $appVersion)
    }

    if ($driverVersion -and $driverVersion -gt $threshold) {
        Write-Result -State 'PATCHED' -Code 0 -Detail ("Driver version {0} is > 1.3.0 at {1}." -f $driverVersion, $driver)
    }

    Write-Result -State 'UNKNOWN' -Code 2 -Detail 'Protected Folder artifacts found, but version could not be determined confidently.'
}
catch {
    Write-Result -State 'UNKNOWN' -Code 2 -Detail $_.Exception.Message
}

Sources

1. NVD CVE-2025-0221
2. OpenCVE mirror of CVE record
3. IObit Protected Folder product page
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS API documentation
6. FIRST EPSS overview
7. inTheWild.io tracking page