CVE-2022-31704

What it actually does

CVE-2022-31704 is a broken access control vulnerability in VMware vRealize Log Insight, now VMware Aria Operations for Logs. A network-reachable, unauthenticated attacker can access functionality that should require authorization and use it to inject attacker-controlled code or content into sensitive appliance files. Successful exploitation can lead to remote code execution on the appliance with the privileges of the affected service, enabling full compromise of the logging appliance, modification of application files, persistence, data access, and potential disruption of log collection and analysis.

Why it matters to the business

Compromise of a centralized logging platform is high impact because the system often contains sensitive operational, authentication, infrastructure, and security telemetry from many other systems. An attacker who gains code execution may steal logs, alter or delete evidence, disable visibility, use the appliance as a foothold for lateral movement, or disrupt incident response. The CVSS score is critical, exploitation is weaponized, EPSS is high at 0.81011, and the vulnerability has been public for years, so internet-exposed or broadly reachable appliances should be treated as urgent even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies a reachable vRealize Log Insight or Aria Operations for Logs appliance. Because the flaw is unauthenticated and low complexity, the attacker does not need valid credentials or user interaction. The attacker sends crafted HTTP requests to functionality that should be restricted, abusing the broken access control condition to write or inject attacker-controlled content into sensitive files on the appliance. Once the injected content is processed by the application or supporting service, the attacker obtains command execution. From there, they may run shell commands, deploy a web shell or other persistence mechanism, create or modify files, collect logs and configuration data, tamper with evidence, stage tools, or pivot further into the network using the appliance’s trusted position.

How to fix it

Upgrade affected VMware vRealize Log Insight / VMware Aria Operations for Logs appliances to a vendor-fixed release. VMware addressed this issue in VMware Aria Operations for Logs 8.10.2 and later; organizations should use the latest supported fixed release available from VMware/Broadcom rather than remaining on an older fixed baseline. If immediate upgrade is not possible, apply the official VMware workaround for the applicable version, restrict appliance access to trusted administrative networks, block direct internet exposure, and limit access to management and cluster-related endpoints at network controls or reverse proxies. Treat mitigation as temporary: because public weaponized exploitation exists, full patching and post-patch compromise assessment are recommended.

How to confirm the fix worked

Confirm the running product version from the appliance administrative interface, CLI, or vendor-supported inventory tooling and verify it is VMware Aria Operations for Logs 8.10.2 or later, or another vendor-confirmed fixed release. Validate that unauthenticated users cannot reach administrative, cluster, or internal APIs from untrusted networks. Review firewall, load balancer, and reverse proxy rules to ensure the appliance is not internet-exposed unless explicitly required and protected. After patching, run an authenticated vulnerability scan or vendor-supported assessment to confirm CVE-2022-31704 is no longer reported. Also validate appliance integrity by checking for unexpected file modifications, unauthorized scheduled tasks, unknown processes, abnormal outbound connections, and application errors around the pre-remediation exposure window.

Typical attack path

1. Scan for internet-facing or internally reachable VMware vRealize Log Insight / VMware Aria Operations for Logs appliances.
2. Fingerprint the appliance version or exposed service behavior to determine whether it is likely vulnerable.
3. Send unauthenticated crafted requests to restricted application or cluster-management functionality affected by the broken access control issue.
4. Inject attacker-controlled code or content into sensitive appliance files.
5. Trigger the affected component to load or process the injected content, resulting in remote code execution.
6. Execute post-exploitation commands such as downloading tools, creating persistence, collecting logs and configuration files, or disabling logging functions.
7. Use the compromised logging appliance to hide activity, steal sensitive telemetry, or pivot to other systems.

How to detect it

Investigate historical exposure from the publication date forward, with emphasis on periods before patching or network isolation. Review HTTP access logs, reverse proxy logs, load balancer logs, appliance application logs, audit logs, Linux system logs, shell history, process execution telemetry, file modification timestamps, and outbound network connections. Look for unauthenticated requests to internal, administrative, or cluster-related endpoints; requests containing traversal encodings or payloads that appear to write files; unexpected uploads or archive/package files; new or modified files under Log Insight application, plugin, configuration, temporary, and web directories; abnormal service restarts; and command execution spawned by application service accounts. Correlate suspicious web requests with subsequent process launches such as shell interpreters, curl, wget, Python, Perl, or chmod, and with outbound connections to unfamiliar IP addresses. Because the appliance is a logging platform, also look for gaps in collected logs, unusual drops in ingestion volume, deletion events, or configuration changes that could indicate evidence tampering.

• /internal/
• /cluster/
• applyMembership
• nodeToken
• ../
• ..%2f
• %2e%2e%2f
• %2e%2e/
• POST /internal/
• GET /internal/
• .pak
• /tmp/
• /var/tmp/
• /storage/core/loginsight/
• /storage/core/loginsight/var/
• /usr/lib/loginsight/
• /usr/lib/loginsight/application/
• /usr/lib/loginsight/application/lib/
• /opt/vmware/
• bash -c
• sh -c
• curl http://
• curl https://
• wget http://
• wget https://
• chmod +x
• nc -e
• ncat -e
• python -c
• perl -e
• /bin/bash
• /bin/sh

What your security team should do

• Immediately inventory all VMware vRealize Log Insight / VMware Aria Operations for Logs appliances, including renamed Aria deployments and non-production instances.
• Prioritize patching or isolation of any appliance reachable from the internet, user networks, partner networks, or broad internal address ranges.
• Upgrade to VMware Aria Operations for Logs 8.10.2 or later, preferably the latest supported release, and apply any vendor workaround only as a short-term control.
• Assume exposed vulnerable appliances may have been targeted because exploitation is weaponized and EPSS is high; perform compromise assessment before considering remediation complete.
• Review appliance access logs, application logs, system logs, file integrity data, and network telemetry for suspicious unauthenticated requests, file writes, command execution, and outbound connections.
• Rotate credentials, API tokens, certificates, and integration secrets stored on or accessible from the appliance if compromise is suspected.
• Restrict management access to trusted administrative networks and place the appliance behind network controls that block unauthenticated access to internal or cluster-management endpoints.
• Monitor for abnormal changes in log volume, missing telemetry, service restarts, unexpected configuration changes, and attempts to delete or alter logs.