Allocation of Resources Without Limits and Throttling and Sensitive Information in Resource Not Removed…

CVE-2026-13585 lives in the ASUS System Control Interface v3 kernel driver and the ASUS Business Manager userland that talks to it. A local user with administrator privileges can send crafted IOCTL requests that either (a) leak residual kernel/driver memory that was not zeroed before reuse (CWE-226), or (b) allocate driver resources without any throttling (CWE-770), starving the host until it bluescreens. Affected scope is any Windows endpoint shipping the ASUS SCI driver or Business Manager — largely ASUS ExpertBook, ExpertCenter, and ProArt commercial SKUs. ASUS has not yet published fixed version numbers in the public advisory as of disclosure day.

There is no vendor/authority CVSS from ASUS, but a CVSS:4.0 vector of AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/SC:H/SI:N/SA:H (8.2) is circulating via GHSA. That 8.2 is inflated. PR:H means the attacker is already the local administrator — at that point they can install a driver of their own, dump LSASS, or bcdedit the machine into oblivion. This class of bug is a hygiene issue, not a break-glass. Real-world severity is LOW.

Why this verdict

• Local + admin gate: AV:L/PR:H means both physical/interactive presence AND administrator privileges are required. The reachable population is a rounding error against remote unauth bugs.
• No integrity, no confidentiality on the primary host: CVSS 4.0 vector shows VC:N/VI:N — the impact on the vulnerable host itself is availability-only plus incidental memory leak. The SC:H/SA:H subsequent-system scoring is theoretical.
• Role multiplier — endpoint role only: ASUS SCI ships on ASUS-branded Windows endpoints (ExpertBook / ExpertCenter / ProArt). It does NOT ship on domain controllers, hypervisors, IdPs, PAM, backup servers, EDR agents, network edge, or any high-value-role catalog component. There is no plausible role in which this bug produces domain, fleet, or supply-chain compromise. Floor stays at LOW.
• Capability parity: Local admin already implies system-halt and cross-process memory access via legitimate APIs (WinDbg kernel debug, driver install, NtSystemDebugControl). This bug adds nothing an attacker in that position cannot already achieve.
• No KEV, EPSS ~0.001: No exploitation observed, no financially motivated actor interest predicted.

Why not higher?

MEDIUM would require either a non-admin trigger path (there isn't one), or a scenario where the memory disclosure meaningfully bootstraps a further attack (it doesn't — the attacker is already admin and can read kernel memory legitimately). HIGH/CRITICAL are off the table because the affected component has no high-value deployment role — it's a laptop utility driver, not identity/hypervisor/backup/CI infrastructure.

Why not lower?

IGNORE is inappropriate because this is a real defect in a signed kernel driver, and driver bugs of this shape occasionally become links in Bring-Your-Own-Vulnerable-Driver (BYOVD) chains once PoCs mature. LOW keeps it on the backlog where it belongs.

1. Enforce least privilege — remove standing local admin — The bug is neutralized by removing the prerequisite. Deploy LAPS + JIT admin (Intune Endpoint Privilege Management, CyberArk EPM, BeyondTrust) so daily-driver accounts run as standard user. No mitigation SLA for a LOW verdict — fold this into normal privilege-hygiene work.
2. Add the ASUS SCI driver device paths to EDR telemetry watchlists — Alert on unusual DeviceIoControl volume against \\.\Asus* device objects from non-ASUS-signed processes. Cheap detection that also catches BYOVD-style abuse of this and future ASUS driver bugs.
3. Enable Microsoft Vulnerable Driver Blocklist / HVCI-enforced code integrity — If ASUS's fix flags the vulnerable driver hash, Microsoft's block list will refuse to load it. Turn on HVCI (Memory Integrity) on ASUS commercial fleet imagery so the pathway to kernel-mode privilege gain from userland admin is also constrained.
4. Watch ASUS PSIRT for the SCI driver + Business Manager fixed build — Fixed version was not published on disclosure day. Assign an owner to poll the ASUS Security Advisory feed weekly and land the patch inside the 365-day noisgate remediation window once available — no rush.
5. Remove ASUS Business Manager on hosts that don't need it — Many enterprise images include it by default even though only IT uses the management console. Uninstall from user endpoints; the driver stays if hardware features (fan/power profile) depend on it.

Run on the target Windows endpoint in an elevated PowerShell prompt: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-13585.ps1. Requires local administrator to read driver service metadata and installed-product versions. Outputs VULNERABLE, PATCHED, or UNKNOWN.

#requires -RunAsAdministrator
# Check-CVE-2026-13585.ps1
# Detects ASUS System Control Interface v3 driver / ASUS Business Manager presence
# and compares against the fixed build once ASUS publishes it.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN, 3 = NOT INSTALLED

$ErrorActionPreference = 'Stop'

# TODO: update these once ASUS PSIRT publishes fixed versions
$FixedDriverVersion  = [Version]'0.0.0.0'   # placeholder — replace with ASUS-published fix
$FixedManagerVersion = [Version]'0.0.0.0'   # placeholder — replace with ASUS-published fix

function Get-InstalledProduct($namePattern) {
    $paths = @(
        'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*',
        'HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
    )
    Get-ItemProperty $paths -ErrorAction SilentlyContinue |
        Where-Object { $_.DisplayName -like $namePattern } |
        Select-Object DisplayName, DisplayVersion
}

# 1. Driver check — ASUS System Control Interface v3
$driverSvc = Get-CimInstance Win32_SystemDriver -Filter "Name LIKE 'AsusCert%%' OR Name LIKE 'AsIO%%' OR Name LIKE 'asuscert%%'" -ErrorAction SilentlyContinue
$driverFileVersion = $null
if ($driverSvc) {
    foreach ($d in $driverSvc) {
        if ($d.PathName -and (Test-Path $d.PathName.Trim('"'))) {
            $fi = (Get-Item $d.PathName.Trim('"')).VersionInfo
            $driverFileVersion = [Version]$fi.FileVersion
            break
        }
    }
}

# 2. Product check — ASUS Business Manager
$mgr = Get-InstalledProduct '*ASUS Business Manager*'
$mgrVersion = if ($mgr) { [Version]$mgr.DisplayVersion } else { $null }

if (-not $driverSvc -and -not $mgr) {
    Write-Output 'NOT INSTALLED — ASUS SCI driver and ASUS Business Manager not present.'
    exit 3
}

$vulnerable = $false
$reasons = @()

if ($driverFileVersion -and $driverFileVersion -lt $FixedDriverVersion) {
    $vulnerable = $true
    $reasons += "SCI driver $driverFileVersion < fixed $FixedDriverVersion"
}
if ($mgrVersion -and $mgrVersion -lt $FixedManagerVersion) {
    $vulnerable = $true
    $reasons += "Business Manager $mgrVersion < fixed $FixedManagerVersion"
}

if ($FixedDriverVersion -eq [Version]'0.0.0.0' -and $FixedManagerVersion -eq [Version]'0.0.0.0') {
    Write-Output "UNKNOWN — ASUS has not published fixed versions yet. Detected: driver=$driverFileVersion manager=$mgrVersion"
    exit 2
}

if ($vulnerable) {
    Write-Output ('VULNERABLE — ' + ($reasons -join '; '))
    exit 1
} else {
    Write-Output "PATCHED — driver=$driverFileVersion manager=$mgrVersion"
    exit 0
}

Sources

1. CVE.org record — CVE-2026-13585
2. GitHub Advisory GHSA-jf28-f99p-265w
3. OffSeq Threat Radar entry
4. Secably CVE summary
5. TheHackerWire advisory
6. ASUS Product Security Advisory hub
7. CWE-226 — Sensitive Information in Resource Not Removed Before Reuse
8. CWE-770 — Allocation of Resources Without Limits or Throttling