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.
4 steps from start to impact.
Land on the Apex server with admin rights
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.- 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
- 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
4624/4672 admin logons, new RDP/WinRM/SMB admin activity, jump-host bypass, and EDR alerts on admin tools touching the Apex server.Abuse the traversal to gain a server-side write primitive
- 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
- 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
17079.Plant malicious code into the Apex distribution path
- 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
- 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
PCCSRV, anomalous package/content distribution, sudden agent update waves, or server-side file/database mutations outside maintenance windows.Fan out from the management plane to endpoints
- 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
- 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
The supporting signals.
| In-the-wild status | Confirmed. TrendAI says it observed *at least one* attempt to exploit this flaw in the wild, and CISA added it to KEV. |
|---|---|
| KEV status | Listed in CISA KEV on 2026-05-21 with a due date of 2026-06-04 in the KEV data mirror. |
| Proof-of-concept availability | No public PoC found in reviewed sources, and no Metasploit/Nuclei reference was identified. That raises attacker friction, but does not offset KEV-listed exploitation. |
| EPSS | User-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 check | CVSS: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 versions | Apex 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 versions | Vendor 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 discovery | This 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 timeline | Vendor, NVD, and JVN all show disclosure on 2026-05-21; NVD shows last modification on 2026-05-22. |
| Reporter / source of advisory | JVN 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. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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. - 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.
- Monitor
PCCSRVfor unauthorized change — Add file integrity monitoring, EDR watch rules, and SIEM alerts for changes in the Apex One server directory, especiallyPCCSRVcontent, service binaries, and configuration/database artifacts tied to agent distribution. Deploy within hours because exploitation aims to tamper with trusted server-side data. - 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.
- 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
17079or missing CP18012. Start immediately so you can scope and close the exposure while the KEV signal is fresh.
- 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.
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.
# 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
}
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.