← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-34926 · CWE-23 · Disclosed 2026-05-21

A directory traversal vulnerability in the Apex One

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is less a front-door break-in than a stolen master key that turns your AV server into a software grenade launcher

CVE-2026-34926 is a CWE-23 directory traversal flaw in Trend Micro Apex One 2019 (on-prem). The vendor says affected builds are server and agent builds below 17079, and fixes are available as SP1 Build 17079 for fresh installs or SP1 Critical Patch Build 18012 for existing SP1 deployments. Exploitation is not internet-preauth RCE: the attacker must already have access to the Apex One server and administrative credentials on that server, then abuse the flaw to modify a key table and inject code that gets deployed to managed agents.

Trend's MEDIUM 6.7 score is technically defensible for the exploit primitive, but it undersells the operational blast radius. Once you factor in confirmed in-the-wild exploitation and the fact that the target is a central endpoint management plane capable of pushing code to many hosts, this stops looking like a routine local bug and starts looking like a high-value post-compromise pivot. The decisive downgrade pressure is the prerequisite stack: local reachability + admin rights on the Apex server means this is usually *after* initial access, not before it.

"KEV matters, but this is still a post-compromise management-plane pivot, not broad unauthenticated internet RCE."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land on the Apex server with admin rights

The attacker first needs a foothold that reaches the Apex One on-prem server and then valid administrator-level access on that box. In practice this is done with built-in tooling such as RDP, SMB, WinRM, or a previously stolen admin session; there is no public exploit chain in reviewed sources that removes this prerequisite. This is why the bug is best understood as a post-compromise amplifier.
Conditions required:
  • Apex One is the on-prem deployment, not SaaS
  • Attacker can reach the server over local network, remote admin path, or equivalent access
  • Attacker already has administrative credentials or an admin session on the Apex server
Where this breaks in practice:
  • This assumes the attacker is already inside or has already compromised privileged credentials
  • Modern PAM, MFA for admin entry points, jump hosts, and EDR frequently disrupt this stage
  • Many enterprises keep the Apex server off the public internet or behind admin-only network paths
Detection/coverage: Detection is strongest here: watch for unusual 4624/4672 admin logons, new RDP/WinRM/SMB admin activity, jump-host bypass, and EDR alerts on admin tools touching the Apex server.
STEP 02

Abuse the traversal to gain a server-side write primitive

With admin on the server, the attacker uses the vulnerable Apex One server component to perform a directory-traversal-style modification of a key table. The reviewed advisories describe the exploit path at a high level, but no public exploit repo or Metasploit module was found, so this likely requires custom tradecraft rather than point-and-shoot automation. The effective tool here is a custom script or manual tampering against the vulnerable server component, guided by the vendor's own description.
Conditions required:
  • Vulnerable Apex One on-prem build below 17079
  • Ability to execute actions on the server as an admin-capable user
  • Knowledge of where and how the key table is modified on the target instance
Where this breaks in practice:
  • No public PoC was identified in reviewed sources
  • The attack path appears product-specific and less commoditized than classic web RCE
  • File integrity monitoring or application control on the server can expose or block the tampering step
Detection/coverage: Traditional network scanners have poor coverage because exploitation is not unauthenticated remote. Version-based detection is better: inventory Apex One server builds and flag anything below 17079.
STEP 03

Plant malicious code into the Apex distribution path

The point of the write primitive is not just server compromise; it is to alter Apex One's trusted distribution mechanism so the server can hand down attacker-controlled code to managed agents. That turns a single management host compromise into a code-distribution event. At this stage the attacker is weaponizing the trust relationship between the server and its endpoints.
Conditions required:
  • Successful modification of the relevant Apex One key table
  • Managed agents remain enrolled and able to receive content or updates from the server
  • No compensating approval workflow blocks server-to-agent changes
Where this breaks in practice:
  • Change-monitoring on Apex server databases, config files, or distribution artifacts can catch this
  • Some shops tightly segment server-to-agent traffic and monitor unusual pushes
  • Application control on agents may still block the final payload depending on what is delivered
Detection/coverage: Look for unexpected changes under PCCSRV, anomalous package/content distribution, sudden agent update waves, or server-side file/database mutations outside maintenance windows.
STEP 04

Fan out from the management plane to endpoints

If the malicious change is accepted by the platform, the Apex server can distribute attacker-controlled code to downstream agents. This is the real risk driver: a bug that begins with local/admin prerequisites can still become a fleet-scale propagation mechanism because the compromised component is an endpoint security manager. The tool in this phase is effectively Apex One itself, abused as the delivery channel.
Conditions required:
  • Endpoints still trust and communicate with the compromised Apex One server
  • Server-to-agent distribution channels are functioning
  • Security teams do not notice and stop the malicious distribution quickly
Where this breaks in practice:
  • EDR on endpoints may block or alert on payload execution even if delivery succeeds
  • Blast radius is limited to the tenant's managed agents, not the whole internet
  • If the server estate is small, emergency patching and isolation are operationally feasible
Detection/coverage: Monitor agent update events, code execution spawned by Apex components, unusual simultaneous behavior across many managed endpoints, and any unsigned or unexpected binaries appearing via management workflows.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusConfirmed. TrendAI says it observed *at least one* attempt to exploit this flaw in the wild, and CISA added it to KEV.
KEV statusListed in CISA KEV on 2026-05-21 with a due date of 2026-06-04 in the KEV data mirror.
Proof-of-concept availabilityNo public PoC found in reviewed sources, and no Metasploit/Nuclei reference was identified. That raises attacker friction, but does not offset KEV-listed exploitation.
EPSSUser-provided EPSS is 0.00751 (~0.751% over 30 days). A reviewed third-party mirror places it around the 49th percentile; treat that percentile as *secondary-source context*, not primary-source ground truth.
CVSS vector reality checkCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:L correctly encodes the main friction: local access, high complexity, high privileges required. The S:C scope change matters because the server can affect downstream agents.
Affected versionsApex One 2019 (On-prem) with server and agent builds below 17079 are affected. SaaS/SEP entries in the bulletin are not the exploitable server-side target for this CVE.
Fixed versionsVendor fix is SP1 Build 17079 for new installs or SP1 Critical Patch Build 18012 for existing SP1 users; JVN also lists Security Agent Build 14.0.18012 for the on-prem line.
Exposure and discoveryThis is not a classic internet-scan-and-fire bug. Exposure is constrained to orgs running on-prem Apex One, and runZero recommends internal discovery with query vendor:="Trend Micro" product:="Apex One"; vendor docs show console ports are commonly 80/443/8080/4343, often configurable.
Disclosure timelineVendor, NVD, and JVN all show disclosure on 2026-05-21; NVD shows last modification on 2026-05-22.
Reporter / source of advisoryJVN states Trend Micro Incorporated reported these vulnerabilities to JPCERT/CC to notify users. No external researcher credit was identified for this specific CVE in reviewed sources.
04 · The Call

noisgate verdict.

Final Verdict
UPGRADED to HIGH (8.0/10)

The single biggest severity limiter is that exploitation requires prior administrative control of the Apex One server, which makes this a post-initial-access pivot rather than a broad first-hop compromise. It still lands in HIGH because the compromised asset is a central endpoint management plane and CISA/TrendAI both indicate real-world exploitation, so one successful server compromise can cascade to many managed hosts.

HIGH Exploit prerequisites are restrictive: on-prem only, server access required, admin credentials required
HIGH Active exploitation / KEV status
MEDIUM Exact exploit implementation details and public weaponization level

Why this verdict

  • Upgrade from vendor MEDIUM: KEV listing on 2026-05-21 and vendor-confirmed in-the-wild attempts mean this is no longer a hypothetical local bug.
  • Blast radius amplifier: the vulnerable component is the Apex One management server, so a single exploited host can become a trusted code-delivery channel to many endpoints.
  • Friction audit keeps it out of CRITICAL: step 1 requires local/internal reachability plus admin rights on the server, which implies prior compromise or privileged credential theft and sharply narrows the reachable population.
  • Population is limited: only on-prem Apex One 2019 servers below the fixed builds are exposed; SaaS tenants are not the vulnerable server-side target here.
  • Modern controls should stop prerequisites: MFA on admin paths, PAM, jump hosts, EDR, server segmentation, and restricted console access should all reduce how often an attacker can satisfy the initial conditions.

Why not higher?

This is not unauthenticated remote internet RCE. The attacker already needs to be on or into the server path and already hold admin-level access on the Apex server, which means much of the damage potential depends on an earlier compromise succeeding first. That prerequisite stack is a major real-world brake on mass exploitation.

Why not lower?

Apex One is a management-plane product, not an isolated workstation app. Once exploited, the vulnerability can let an attacker turn a trusted security server into a fleet distribution mechanism, and that is exactly the kind of leverage that justifies keeping it above MEDIUM. KEV listing removes any comfort that the awkward prerequisites make it purely theoretical.

05 · Compensating Control

What to do — in priority order.

  1. Lock down admin entry paths — Restrict RDP, SMB, WinRM, console, and jump-host access to the Apex One server to a tiny admin group and require MFA/PAM where possible. Because this CVE is KEV-listed, apply this within hours, not on a normal 30-day cycle.
  2. Isolate the management server — Move the Apex One server into a hardened admin segment and block user-VLAN reachability to its management ports except from approved admin networks. Do this within hours to cut off the most realistic attacker path: reusing existing internal access against a high-trust server.
  3. Monitor PCCSRV for unauthorized change — Add file integrity monitoring, EDR watch rules, and SIEM alerts for changes in the Apex One server directory, especially PCCSRV content, service binaries, and configuration/database artifacts tied to agent distribution. Deploy within hours because exploitation aims to tamper with trusted server-side data.
  4. Require change scrutiny for agent pushes — Tighten operational review of Apex-originated content updates, package pushes, and unusual agent-wide actions until all servers are patched. Implement within hours so a compromised server cannot quietly fan out malicious changes.
  5. Inventory every Apex One server — Use internal discovery tools such as runZero and CMDB data to identify all on-prem Apex One instances and confirm which are below build 17079 or missing CP 18012. Start immediately so you can scope and close the exposure while the KEV signal is fresh.
What doesn't work
  • A generic internet-edge WAF is not a meaningful control here because the published exploit path already assumes server access and admin rights; this is not a simple external web exploit.
  • CVSS-only prioritization fails here: the vendor's 6.7 MEDIUM score misses the management-plane blast radius and the KEV signal.
  • Endpoint-only controls are not enough by themselves; if the management server is abused as a trusted distributor, some agents may receive malicious changes before agent-side tooling reacts.
  • MFA alone does not solve the problem once an attacker already has an admin session or stolen privileged token on the server.
06 · Verification

Crowdsourced verification payload.

Run this on the Apex One server itself in an elevated PowerShell session. Example: powershell.exe -ExecutionPolicy Bypass -File .\check-apexone-cve-2026-34926.ps1. Local admin rights are recommended because the script reads install locations and registry uninstall data; it outputs VULNERABLE, PATCHED, or UNKNOWN and exits 1, 0, or 2 respectively.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# check-apexone-cve-2026-34926.ps1

# Verifies whether a Windows host running Trend Micro Apex One on-prem appears patched

# for CVE-2026-34926 based on detected server build/version.

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


$ErrorActionPreference = 'SilentlyContinue'

function Get-BuildFromVersionString {
    param([string]$VersionString)
    if ([string]::IsNullOrWhiteSpace($VersionString)) { return $null }
    $m = [regex]::Match($VersionString, '(\d+)\.(\d+)\.(\d+)\.(\d+)')
    if ($m.Success) {
        return [int]$m.Groups[4].Value
    }
    $m2 = [regex]::Match($VersionString, '(\d{5})')
    if ($m2.Success) {
        return [int]$m2.Groups[1].Value
    }
    return $null
}

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

$patchedThreshold = 17079
$detected = @()

# Common Apex One / OfficeScan server locations

$paths = @(
    (Join-Path $env:ProgramFiles 'Trend Micro\Apex One\PCCSRV'),
    (Join-Path ${env:ProgramFiles(x86)} 'Trend Micro\Apex One\PCCSRV'),
    (Join-Path ${env:ProgramFiles(x86)} 'Trend Micro\OfficeScan\PCCSRV'),
    (Join-Path $env:SystemDrive 'PCCSRV')
) | Select-Object -Unique

$fileCandidates = @(
    'OfcService.exe',
    'TmListen.exe',
    'NtrtScan.exe',
    'PccNTMon.exe'
)

foreach ($root in $paths) {
    if (-not (Test-Path $root)) { continue }

    foreach ($name in $fileCandidates) {
        $full = Join-Path $root $name
        if (Test-Path $full) {
            $item = Get-Item $full
            $ver = $item.VersionInfo.FileVersion
            $build = Get-BuildFromVersionString -VersionString $ver
            if ($build) {
                $detected += [pscustomobject]@{
                    Source = $full
                    Version = $ver
                    Build = $build
                }
            }
        }
    }
}

# Fallback: check uninstall registry entries

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

foreach ($u in $uninstallRoots) {
    Get-ItemProperty $u | Where-Object {
        $_.DisplayName -match 'Apex One|OfficeScan'
    } | ForEach-Object {
        $ver = $_.DisplayVersion
        $build = Get-BuildFromVersionString -VersionString $ver
        if ($build) {
            $detected += [pscustomobject]@{
                Source = "Registry: $($_.DisplayName)"
                Version = $ver
                Build = $build
            }
        }
    }
}

if (-not $detected -or $detected.Count -eq 0) {
    Emit-Result -State 'UNKNOWN' -Detail 'Apex One / OfficeScan server build could not be determined on this host.' -Code 2
}

$best = $detected | Sort-Object Build -Descending | Select-Object -First 1

if ($best.Build -ge $patchedThreshold) {
    Emit-Result -State 'PATCHED' -Detail ("Detected build {0} from {1} (version {2}); threshold is {3}." -f $best.Build, $best.Source, $best.Version, $patchedThreshold) -Code 0
}
else {
    Emit-Result -State 'VULNERABLE' -Detail ("Detected build {0} from {1} (version {2}); below fixed threshold {3}." -f $best.Build, $best.Source, $best.Version, $patchedThreshold) -Code 1
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat every on-prem Apex One server as a high-trust asset under active scrutiny: identify all instances immediately, lock down admin access paths and network exposure within hours because this CVE is KEV-listed, and verify whether each server is below build 17079 / missing CP 18012. Under the noisgate mitigation SLA, KEV evidence overrides the normal HIGH window, so temporary containment and exposure reduction should happen immediately, within hours; under the noisgate remediation SLA, HIGH would normally allow up to 180 days, but this is one of the rare cases where you should use an emergency change and patch the small server population fast rather than consuming the full window.

Sources

  1. TrendAI security bulletin
  2. NVD CVE entry
  3. JVN advisory
  4. CISA KEV data mirror
  5. runZero asset discovery guidance
  6. TrendAI ports and protocols documentation
  7. Help Net Security coverage of active exploitation
  8. Pinaka EPSS mirror for percentile context
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.