← Back to Feed CACHED · 2026-10-08 06:17:36 · CACHE_KEY CVE-2026-6958
CVE-2026-6958 · CWE-427 · Disclosed 2026-09-04

Acunetix 25.11.x for Windows Local Privilege Escalation via wvsc.exe OpenSSL Config Path Hijack

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

A security scanner left its build scaffolding in the shipping container, and now anyone in the warehouse can wear the foreman's hard hat

CVE-2026-6958 targets Acunetix 25.11.251107123 for Windows — specifically the wvsc.exe Web Vulnerability Scanning Engine, which runs as SYSTEM. During compilation, a hardcoded path referencing a build-time OpenSSL configuration directory (C:\builds\...\openssl.cnf) was baked into the binary. That directory does not exist on customer systems, and because Windows default ACLs on C:\ allow authenticated users to create new top-level folders, any local low-privilege user can forge the directory tree and plant a malicious openssl.cnf (or an OpenSSL engine .dll it references). When wvsc.exe next loads the config, it executes the attacker's payload as SYSTEM. All builds of Acunetix 25.11.x on Windows are affected; Invicti (the vendor) was contacted on April 23, 2026 and never responded. There is no patch as of October 2026.

The vendor's CVSS 7.8 HIGH is *technically accurate* for the local impact profile — low-privilege, no user interaction, full CIA compromise — but it dramatically overstates real-world risk. Acunetix is a niche DAST scanner with roughly 1,900 customers globally and a 0.03% market share. In a typical 10,000-host estate you'll find 1–3 hosts running it, usually dedicated scanning VMs managed exclusively by the security team. The chances of an unprivileged adversary having an interactive session on that specific host are vanishingly small. There is no remote vector, no wild exploitation, no KEV listing, and EPSS sits at the 6th percentile. The vendor severity is a textbook case of CVSS inflation on a niche, local-only, single-host bug.

"Niche scanner, local-only chain, tiny blast radius — downgraded to MEDIUM."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Obtain local session on Acunetix host

The attacker must first gain interactive local access (RDP, physical console, SSH, or a shell from prior compromise) to the Windows machine running Acunetix 25.11.x. The required privilege level is any authenticated local user, including domain users with standard permissions. This is the hardest prerequisite: Acunetix scanners are typically installed on dedicated VMs with restricted login policies.
Conditions required:
  • Interactive local session on the target Windows host
  • Standard (non-admin) user privileges
Where this breaks in practice:
  • Acunetix hosts are usually dedicated scanning VMs without general-purpose user logons
  • Security teams often restrict RDP access to scanning infrastructure via jump-host or PAM
  • In many orgs only 1–3 hosts globally run Acunetix
Detection/coverage: Unusual RDP / interactive logon to scanning infra flagged by SIEM logon-source correlation rules (Event ID 4624 type 10).
STEP 02

Create the missing build directory tree

The attacker creates the directory hierarchy C:\builds\...\ that wvsc.exe expects. Windows default ACLs on C:\ allow authenticated users to create new child directories. The attacker then plants a malicious openssl.cnf and/or a crafted OpenSSL engine DLL in the newly created path. No special tools are needed — mkdir and copy suffice.
Conditions required:
  • Write access to C:\ (default on Windows for authenticated users)
  • Knowledge of the hardcoded path (disclosed in the Full Disclosure advisory by Andrea Intilangelo)
Where this breaks in practice:
  • Application control policies (AppLocker / WDAC) on well-managed hosts may block creation of directories outside sanctioned paths
  • File-integrity monitoring (FIM) on scanning hosts would alert on new directories under C:\builds
Detection/coverage: FIM or Sysmon Event ID 11 (FileCreate) on C:\builds\* directory tree. EDR behavioral detection on OpenSSL engine DLL loads from non-standard paths.
STEP 03

Wait for wvsc.exe to load the planted payload

The Acunetix scanning engine (wvsc.exe) periodically initializes OpenSSL and reads the configuration from the hardcoded path. The attacker waits for the next scan cycle or service restart. No user interaction is required — the service runs automatically under the SYSTEM account. When wvsc.exe parses the attacker's openssl.cnf, it loads any engine directive, executing the malicious DLL as NT AUTHORITY\SYSTEM.
Conditions required:
  • wvsc.exe service is running or will restart
  • Malicious openssl.cnf references a crafted engine DLL in the same directory
Where this breaks in practice:
  • If the Acunetix service is stopped or scans are infrequent, dwell time between plant and execution may be hours to days
  • EDR should flag an unsigned DLL loaded by a SYSTEM process from an unusual path
Detection/coverage: EDR process-tree analysis: wvsc.exe (SYSTEM) loading an unsigned DLL from C:\builds\*. Sysmon Event ID 7 (ImageLoaded) with anomalous path. Most commercial EDR (CrowdStrike, SentinelOne, Defender for Endpoint) will flag this as suspicious DLL sideload.
STEP 04

SYSTEM-level code execution on the scanning host

The attacker now has arbitrary code execution as SYSTEM on the Acunetix host. Impact is confined to that single host: the attacker can access stored scanning credentials, scan result data (which maps the org's web application attack surface), and potentially pivot to scanned targets if the scanner host has network reachability to them. There is no inherent mechanism to escalate beyond this single host to domain or fleet level.
Conditions required:
  • Successful DLL load from step 3
Where this breaks in practice:
  • Network segmentation should limit lateral movement from a scanning VM
  • Stored credentials may be encrypted at rest depending on Acunetix configuration
Detection/coverage: Post-exploitation activity (credential dumping, lateral movement) detected by EDR and network monitoring.
03 · Compensating Control

1
MEDIUM 5.0→LOW 2.5
SEVERITY REDUCED
Pre-create the build directory with restrictive ACLs — Run mkdir C:\builds as Administrator, then apply an ACL granting Full Control only to SYSTEM and BUILTIN\Administrators, with inheritance. This breaks the chain at step 2 by preventing low-privilege users from creating the directory or planting files. This is the single most effective mitigation and should be deployed on all Acunetix hosts immediately. No noisgate mitigation SLA applies at MEDIUM — go straight to the 365-day remediation window, but this control is trivial and should be applied within days.
2
MEDIUM 5.0→LOW 2.0
SEVERITY REDUCED
Restrict interactive logon to the Acunetix host — Configure the 'Allow log on locally' and 'Allow log on through Remote Desktop Services' Group Policy settings to permit only the Acunetix service account and designated security-team administrators. Deny all other users. This breaks the chain at step 1. Apply within the 365-day remediation window.
3
MEDIUM 5.0→LOW 2.0
SEVERITY REDUCED
Enable application control (AppLocker or WDAC) on the scanning host — Create a DLL rule that blocks execution of unsigned DLLs from C:\builds\* or any path outside the Acunetix installation directory. This breaks the chain at step 3 by preventing the SYSTEM-level DLL load. Apply within the 365-day remediation window.
4
MEDIUM 5.0→MEDIUM 4.5
Deploy file-integrity monitoring on the Acunetix host — Configure FIM (or Sysmon with Event ID 11) to alert on any file creation under C:\builds\. This does not prevent exploitation but ensures detection within minutes, enabling rapid response. Deploy within the 365-day remediation window.
What doesn't work
  • Network segmentation alone — the attack is entirely local; network controls do not prevent a user who already has a session on the host from creating directories and files.
  • Antivirus signature scanning — the payload is a custom DLL; traditional AV signature matching will not detect a novel implant. Behavioral EDR is needed, not signature AV.
  • Rotating Acunetix scan credentials — while good hygiene, this does not prevent the privilege escalation itself; the attacker gains SYSTEM regardless of what credentials are stored.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone confirmed. Not listed in CISA KEV. No campaigns reported by Mandiant, CrowdStrike, or SentinelOne threat intel feeds as of October 2026.
Proof-of-ConceptSemi-public. Advisory PDF by Andrea Intilangelo published via olografix.org. Full Disclosure mailing list post on seclists.org. No standalone GitHub exploit repo found. Not indexed on pocindex.io. Exploitation is trivial (mkdir + copy + wait) so a formal PoC tool is unnecessary.
EPSS0.00175 (0.175%) — 6th percentile. The model considers this highly unlikely to be exploited in the next 30 days.
KEV StatusNot listed. No CISA binding operational directive applies.
CVSS v3.1 VectorCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — 7.8 HIGH. Local access, low complexity, low privilege, no user interaction, unchanged scope, full CIA impact. CVSS v4.0 score is 8.5.
Affected VersionsAcunetix 25.11.251107123 for Windows (25.11.x branch). Linux installations are not affected. Confirmed on Windows 11 and Windows 11 IoT Enterprise LTSC.
Fixed VersionNone available. Invicti (vendor) was contacted April 23, 2026 and never responded. The researcher disclosed after the 120-day deadline expired on August 31, 2026. No patch or updated build has been released as of October 8, 2026.
Installed Base~1,900 customers globally per 6sense (0.03% cloud security market share). Largest segments: US (579), India (260), Brazil (86). 437 companies with 10,000+ employees. In a typical enterprise, 1–3 hosts run Acunetix.
Disclosure TimelineDiscovered April 18, 2026 by Andrea Intilangelo. Vendor contacted April 23. 120-day deadline. Public disclosure August 31, 2026. CVE published September 4, 2026. NVD last updated October 7, 2026.
ResearcherAndrea Intilangelo — independent researcher. Advisory published via olografix.org and Full Disclosure mailing list.

Sources.

  1. Full Disclosure Advisory — Andrea Intilangelo
  2. NVD / CVE Feed — CVE-2026-6958 Detail
  3. SentinelOne Vulnerability Database
  4. Threat Radar — Live Threat Intelligence
  5. 6sense — Acunetix Market Share
  6. OpenCVE — CVE-2026-6958
  7. Vulners — VULNRICHMENT Entry
05 · The Call

Final Verdict
↓ DOWNGRADED to MEDIUM (5.0/10)

Why this verdict

  • Local-only, post-access chain: CVSS AV:L means the attacker must already have an interactive session on the specific Windows host running Acunetix. This is not a remotely reachable vulnerability. The chain begins *after* initial access and local privilege are already established on a particular machine — a significant narrowing.
  • Ultra-narrow installed base: Acunetix has ~1,900 customers globally. In a 10,000-host enterprise, 1–3 hosts are affected. The exposed population within any given org is effectively a rounding error. This alone is a major downward adjustment from the vendor's blanket HIGH.
  • Dedicated-host deployment pattern: Acunetix scanners are overwhelmingly run on single-purpose VMs or appliances managed by the security team, not on multi-user workstations or shared servers. The probability that an unprivileged attacker has (or can obtain) an interactive session on this specific host is extremely low in well-run environments.
  • No wild exploitation, rock-bottom EPSS: Zero confirmed in-the-wild activity. EPSS 0.175% (6th percentile). Not KEV-listed. The threat is purely theoretical as of October 2026.
  • Role multiplier: Acunetix is a DAST web scanner. (a) *Low-value role:* security team test scanner on a lab VM — SYSTEM compromise is inconsequential. (b) *Typical role:* dedicated scanning server — SYSTEM access exposes stored scan credentials and vulnerability reports for the org's web apps; blast radius is host-level to tenant-level. (c) *High-value role:* scanner integrated into CI/CD pipeline with stored production credentials — SYSTEM could theoretically leak creds for production targets. However, Acunetix is not a canonical high-value-role component (it is not an IdP, PAM, hypervisor, DC, backup, CA, or network edge device). Fewer than 5% of installs occupy a CI/CD-integrated high-value role. The blast radius in the worst case is host → credentials for scanned targets, NOT domain takeover, fleet compromise, or supply-chain pivot. No floor applies.
  • EDR friction at the payload stage: The critical exploitation step — SYSTEM process loading an unsigned DLL from C:\builds\* — is exactly the pattern modern EDR (CrowdStrike, SentinelOne, MDE) is designed to catch. In monitored environments, the chain is likely to be interrupted before impact.

Why not higher?

The vendor's 7.8 HIGH would be appropriate if this bug were in a widely-deployed, multi-user Windows component where unprivileged local users routinely coexist with SYSTEM services. Acunetix is none of those things. It is a niche scanner on a dedicated VM with ~1,900 global customers, no remote vector, no wild exploitation, and EDR coverage at the DLL-load step. Elevating to HIGH would misallocate patching resources away from genuinely impactful vulnerabilities.

Why not lower?

Despite the narrow blast radius, the vulnerability is trivially exploitable with no tooling beyond mkdir and copy, there is no vendor patch (Invicti has been unresponsive for nearly six months), and the PoC is public. A motivated insider or red-teamer who lands on the scanning host can reliably reach SYSTEM. The stored scanning credentials and vulnerability data on the host have real intelligence value to an adversary. Dropping below MEDIUM would understate the risk for the small number of hosts that are actually affected.

06 · Verification

Crowdsourced verification payload.

Run this script on each Windows host where Acunetix may be installed, from an elevated (Administrator) PowerShell prompt. Example: .\Check-CVE-2026-6958.ps1. No external dependencies required.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#Requires -Version 5.1
<#
  Check-CVE-2026-6958.ps1
  Checks whether the local host is vulnerable to CVE-2026-6958
  (Acunetix wvsc.exe OpenSSL config path hijack).
  Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN
#>

$ErrorActionPreference = 'Stop'
$wvscPaths = @(
    "$env:ProgramFiles\Acunetix\*\wvsc.exe",
    "${env:ProgramFiles(x86)}\Acunetix\*\wvsc.exe",
    "$env:ProgramData\Acunetix\*\wvsc.exe"
)

$found = $false
foreach ($pattern in $wvscPaths) {
    $hits = Get-ChildItem -Path $pattern -ErrorAction SilentlyContinue
    if ($hits) {
        foreach ($exe in $hits) {
            $found = $true
            $ver = $exe.VersionInfo.ProductVersion
            Write-Host "[*] Found wvsc.exe: $($exe.FullName)"
            Write-Host "[*] Product version: $ver"

            # Check if version matches vulnerable 25.11.x
            if ($ver -match '^25\.11\.') {
                Write-Host "[!] Version $ver is in the vulnerable 25.11.x range."

                # Check if the hardcoded build path exists and is writable by non-admins
                $buildRoot = 'C:\builds'
                if (Test-Path $buildRoot) {
                    $acl = Get-Acl $buildRoot
                    $openToUsers = $false
                    foreach ($rule in $acl.Access) {
                        if ($rule.IdentityReference -match 'Users|Authenticated Users|Everyone' -and
                            $rule.FileSystemRights -match 'Write|FullControl|Modify' -and
                            $rule.AccessControlType -eq 'Allow') {
                            $openToUsers = $true
                            break
                        }
                    }
                    if ($openToUsers) {
                        Write-Host "[!!] VULNERABLE — C:\builds exists and is writable by non-admin users."
                        exit 1
                    } else {
                        Write-Host "[+] PATCHED (mitigated) — C:\builds exists but ACLs restrict write to admins/SYSTEM only."
                        exit 0
                    }
                } else {
                    # C:\builds does not exist — check if users can create it
                    $cAcl = Get-Acl 'C:\'
                    $canCreate = $false
                    foreach ($rule in $cAcl.Access) {
                        if ($rule.IdentityReference -match 'Users|Authenticated Users|Everyone' -and
                            $rule.FileSystemRights -match 'CreateDirectories|Write|FullControl|Modify' -and
                            $rule.AccessControlType -eq 'Allow') {
                            $canCreate = $true
                            break
                        }
                    }
                    if ($canCreate) {
                        Write-Host "[!!] VULNERABLE — C:\builds does not exist and non-admin users can create it on C:\."
                        exit 1
                    } else {
                        Write-Host "[+] PATCHED (mitigated) — C:\ ACL prevents non-admin directory creation."
                        exit 0
                    }
                }
            } else {
                Write-Host "[+] Version $ver is outside the known vulnerable range."
                Write-Host "[+] PATCHED"
                exit 0
            }
        }
    }
}

if (-not $found) {
    Write-Host "[*] Acunetix wvsc.exe not found on this host."
    Write-Host "[*] UNKNOWN (not applicable)"
    exit 2
}