Elastic APM Server Windows installer permissions flaw can enable local privilege escalation

An uncontrolled search path element vulnerability can lead to local privilege Escalation (LPE) via Insecure Directory Permissions. The vulnerability arises from improper handling of directory permissions. An attacker with local access may exploit this flaw to move and delete arbitrary files, potentially gaining SYSTEM privileges.

• Elastic APM Server on Windows installed through the install-service script:
• Branch 8.16: affected through and including 8.16.2.
• Branch 8.17: affected through and including 8.17.0.
• Elastic states that the issue is resolved in 8.16.3 and 8.17.1.
• The advisory does not establish the status of parallel or other release branches. Those branches should not be assumed unaffected.

Elastic APM Server is affected by an uncontrolled search path element vulnerability (CWE-427) involving improper directory-permission handling. The confirmed affected configuration is APM Server installed on Windows through the install-service script. A local attacker may exploit the flaw to move or delete arbitrary files, potentially resulting in execution with SYSTEM privileges. The public detail does not identify the specific directory, executable, or search-path resolution mechanism, so additional exploit steps should not be inferred.

The issue is locally reachable rather than remotely reachable over the network. The record describes low required privileges, high attack complexity, and no user interaction. The supplied record does not identify a public exploit, and the returned vulnerability metadata records exploitation as none and automatable as no within that assessment. This does not establish that undisclosed or future exploitation is impossible.

The flaw may allow a low-privileged local account to move or delete arbitrary files through unsafe directory permissions in the affected installation configuration. The described outcome includes potential acquisition of SYSTEM privileges, creating risks to the confidentiality, integrity, and availability of the Windows host. The assessed scope is unchanged, so the direct impact is centered on the system running APM Server and the host where it is installed. The record does not provide evidence of a specific intrusion or identify the exact directories or files involved.

The risk is concentrated in Elastic APM Server deployments on Windows that were installed with the install-service script.

• A local account may be able to alter or remove arbitrary files, causing service disruption or compromising the integrity of the host.
• If SYSTEM privileges are obtained, the attacker could extend the impact beyond APM Server data and processes to a broader portion of the Windows host.
• The record contains no evidence of a specific compromise, so organizations should not infer that a breach occurred; they should prioritize deployment scoping and patching.

1. Upgrade Elastic APM Server on Windows to 8.16.3 for the 8.16 branch or to 8.17.1 for the 8.17 branch, according to the deployed branch.
2. If immediate upgrade is not possible, identify and reduce exposure for installations using the Windows install-service script, and review the permissions of directories associated with the service installation to remove unnecessary write access.
3. Recheck the environment after the change to confirm both the deployed version and installation method for each host. A fix in one branch is not evidence that every other branch has been addressed.

1. Inventory Elastic APM Server deployments on Windows and determine how each installation was performed.
2. Identify systems using the Windows install-service script, because Elastic limits the affected configuration to that installation method.
3. Compare deployed versions with the affected branches and fixed releases listed in affected_summary and remediation.
4. Review permissions on directories associated with the service installation for inappropriate write or modification access by local accounts.
5. Check telemetry for unusual file moves or deletions and privilege changes around the service. Treat this as precautionary monitoring, not as a confirmed indicator of compromise; absence of such events does not prove safety.