This is less a burglar at the front door than a disgruntled employee pulling a breaker inside one room
CVE-2025-0223 is a local null-pointer dereference in IURegistryFilter.sys, the IOCTL-handling driver used by IObit Protected Folder. NVD and related records say versions 13.6.0.0 through 13.6.0.5 are affected, and a low-privileged local user can hit IOCTL paths 0x8001E000, 0x8001E00C, 0x8001E004, or 0x8001E010 to crash the vulnerable component. The stated impact is availability only: no confidentiality loss, no integrity loss, and no evidence of privilege escalation from this CVE by itself.
The vendor/CNA MEDIUM 5.5 score is technically fair in CVSS terms but too generous operationally for enterprise patch triage. The decisive friction is attacker position: this requires already being on the box with local authenticated code execution, on a host that also happens to run a fairly niche Windows folder-locking utility. That makes it a post-compromise, single-host disruption issue, not a broad initial-access or lateral-movement accelerator.
4 steps from start to impact.
Land local code execution on a Windows endpoint
- Windows host
- Attacker already has local code execution
- Attacker has at least low privileges on the machine
- This is post-initial-access by definition
- EDR, application control, and basic endpoint hardening should already be contesting this stage
- No path from unauthenticated remote attacker directly to the bug
Find a host that actually runs IObit Protected Folder
CreateFile and DeviceIoControl, or an equivalent PoC. Reference records point to a public exploit disclosure, but not to broad operational use.- IObit Protected Folder installed
- Affected version in the vulnerable range
- Driver device reachable by the low-privileged user as claimed by the CNA metrics
- This is a niche endpoint utility, not a common enterprise platform
- Many estates will have zero exposure because the software is absent
- Public disclosure exists, but there is no sign of industrialized exploitation or mass targeting
Send malformed IOCTLs to IURegistryFilter.sys
IURegistryFilter.sys, producing a null-pointer dereference. The likely weapon is a tiny custom PoC or test harness using Windows API calls rather than a complex exploit chain. This is a reliability-style trigger, not stealthy tradecraft.- Ability to open the device handle
- Knowledge of the vulnerable IOCTL codes or public write-up
- Vulnerable driver loaded in memory
- Impact is limited to a crash/DoS path, not code execution
- Even successful exploitation does not expand attacker privileges per available records
- The exploit may be noisy and destabilizing, which is operationally unattractive outside sabotage
Cause single-host disruption
- Exploit trigger succeeds
- Host is business-relevant enough that a crash matters
- Availability-only effect
- Single-endpoint blast radius unless an attacker has many endpoints already compromised
- Reboot/recovery often restores the host to service
- A WAF does nothing here because there is no HTTP request path to inspect.
- Perimeter scanning will not find or meaningfully prioritize this; exposure is driven by local software install state, not internet-facing services.
- MFA is good hygiene but irrelevant to the crash path once an attacker already has local execution on the endpoint.
The supporting signals.
| In-the-wild status | No confirmed in-the-wild exploitation found in the sources reviewed. CISA KEV does not list this CVE, and the available references describe public disclosure rather than active campaigns. |
|---|---|
| Proof-of-concept availability | Public exploit disclosure is referenced by NVD/VulDB via a Notion link, so defenders should assume reproducer-level details exist even though this does not appear widely operationalized. |
| EPSS | 0.00066 per the intel provided and mirrored by Vulners; that is consistent with a very low near-term exploitation probability signal. |
| KEV status | Not KEV-listed as of the CISA Known Exploited Vulnerabilities Catalog reviewed for this assessment. |
| CVSS vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H — the whole story is in AV:L and PR:L: local, authenticated, availability-only. |
| Affected versions | IObit Protected Folder 13.6.0.0 through 13.6.0.5 per NVD change history and mirrored CVE aggregators. |
| Fixed version | No authoritative fixed version found. Positive Technologies/dbugs explicitly says there is *no information about a newer version that contains a fix*. |
| Exposure reality | Not an internet-facing service. This is a local Windows utility/driver, so Shodan/Censys-style perimeter exposure is effectively irrelevant; exposure is governed by software presence on endpoints, not open ports. |
| Disclosure timeline | Disclosed 2025-01-05; NVD shows publication on 2025-01-05 and later enrichment on 2025-01-23. |
| Reporting / source | The CNA source shown by NVD is VulDB. NVD also states the vendor was contacted early but did not respond. |
Sources.
Why this verdict
- Requires local authenticated access: this is not remotely reachable; it presumes the attacker is already on the host.
- Implies prior compromise or insider presence:
AV:L+PR:Lmeans this is a post-initial-access problem, which sharply narrows real-world exploitability. - Narrow exposure population: IObit Protected Folder is a niche Windows utility, not a standard enterprise platform or edge service.
- Blast radius is one endpoint at a time: the available impact is denial of service, not credential theft, lateral movement, or domain-wide compromise.
- Threat telemetry is weak: no KEV listing, no confirmed campaigns, and a very low EPSS signal reduce urgency further.
Why not higher?
There is no unauthenticated remote path, no network exposure, and no evidence this bug yields code execution or privilege escalation. Even a successful trigger appears to buy the attacker a crash on an already-accessed machine, which is disruptive but not strategically powerful.
Why not lower?
I did not drop this to IGNORE because it still sits in a kernel-adjacent driver path and can intentionally disrupt business endpoints where the software is installed. If you have this utility on shared kiosks, labs, or sensitive workstation pools, a low-privileged user could weaponize it for noisy disruption.
Crowdsourced verification payload.
Run this on the target Windows host or through your endpoint management tool as a standard software-inventory check. Invoke it with powershell.exe -ExecutionPolicy Bypass -File .\check-CVE-2025-0223.ps1; no admin rights are strictly required for the registry checks, though admin helps if you also want to inspect file versions under protected paths.
# check-CVE-2025-0223.ps1
# Detects vulnerable IObit Protected Folder versions for CVE-2025-0223.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
$ErrorActionPreference = 'Stop'
function Get-InstalledProtectedFolderVersion {
$paths = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
foreach ($path in $paths) {
try {
$items = Get-ItemProperty -Path $path -ErrorAction SilentlyContinue |
Where-Object {
($_.DisplayName -match '^Protected Folder($|\s)') -or
($_.DisplayName -match '^IObit Protected Folder($|\s)')
}
foreach ($item in $items) {
if ($item.DisplayVersion) {
return [string]$item.DisplayVersion
}
}
} catch {
# continue
}
}
$candidateFiles = @(
'C:\Program Files\IObit\Protected Folder\ProtectedFolder.exe',
'C:\Program Files (x86)\IObit\Protected Folder\ProtectedFolder.exe'
)
foreach ($file in $candidateFiles) {
if (Test-Path $file) {
try {
$ver = (Get-Item $file).VersionInfo.ProductVersion
if ($ver) { return [string]$ver }
} catch {
# continue
}
}
}
return $null
}
function Compare-Version {
param(
[Parameter(Mandatory=$true)][string]$A,
[Parameter(Mandatory=$true)][string]$B
)
try {
$va = [version]$A
$vb = [version]$B
return $va.CompareTo($vb)
} catch {
return $null
}
}
try {
$version = Get-InstalledProtectedFolderVersion
if (-not $version) {
Write-Output 'PATCHED: IObit Protected Folder not found (not affected on this host).'
exit 0
}
$lower = '13.6.0.0'
$upper = '13.6.0.5'
$cmpLower = Compare-Version -A $version -B $lower
$cmpUpper = Compare-Version -A $version -B $upper
if ($null -eq $cmpLower -or $null -eq $cmpUpper) {
Write-Output ("UNKNOWN: Found IObit Protected Folder version '{0}', but version parsing failed." -f $version)
exit 2
}
if ($cmpLower -ge 0 -and $cmpUpper -le 0) {
Write-Output ("VULNERABLE: IObit Protected Folder version {0} is within affected range 13.6.0.0-13.6.0.5 for CVE-2025-0223." -f $version)
exit 1
}
if ($cmpUpper -gt 0) {
Write-Output ("PATCHED: IObit Protected Folder version {0} is newer than 13.6.0.5." -f $version)
exit 0
}
Write-Output ("UNKNOWN: Found IObit Protected Folder version {0}; unable to classify confidently." -f $version)
exit 2
} catch {
Write-Output ("UNKNOWN: Detection failed with error: {0}" -f $_.Exception.Message)
exit 2
}