CVE-2026-78413: LocalSystem Executable Dispatch Through SysmonLogForward

The short version

Velociraptor 0.77.1 allowed a stock investigator to add Windows.Sysinternals.SysmonLogForward to client monitoring with a caller-selected SysmonFileLocation. The transitive call into SysmonInstall performed execve() operations without enforcing the investigator’s missing EXECVE permission.

In an isolated Windows lab, a prepositioned fixed-behavior canary executed four times as LocalSystem. The path selected the executable but did not itself upload a file or provide arbitrary argument control. The issue was fixed before 0.77.3 and is tracked as CVE-2026-78413.

At a glance

Field	Detail
Server tested	Velociraptor 0.77.1, Linux build, commit `3137c7f71`
Target	Disposable enrolled Windows endpoint
Fixed version	0.77.3
Vulnerability class	Incorrect default permissions, CWE-276
Vendor affected range	Linux server/control plane before 0.77.3; effect demonstrated on a Windows endpoint
Required access	Investigator with `COLLECT_CLIENT`, without `EXECVE`
Demonstrated impact	Attacker-selected executable dispatch as LocalSystem
Credits	Yuval Miller and Leon Kayaliev

Safe test setup

The lab owner independently placed a fixed-behavior canary at:

C:\Windows\Temp\f1054-canary.exe

The canary could only append its identity and command line to a proof file. Its hash was recorded before testing, and the endpoint received a temporary label so the monitoring change affected only that disposable client.

This setup separated the authorization bypass from file placement. The attacker phase used only ordinary investigator GUI credentials over HTTPS and did not use endpoint access, artifact-writing permissions, an API certificate, or an agent on the attacker workstation.

Why I prepositioned a fixed-behavior canary

The permission question was whether an investigator could cause a selected path to execute as LocalSystem-not whether this path could also deliver a payload. Having the lab owner place a harmless, single-purpose binary kept those claims separate. Recording its hash before the test also ruled out a different executable appearing at the path between setup and collection.

The canary wrote only identity and command-line data. This gave enough evidence to establish the security boundary crossed while avoiding a reverse shell or a general command runner. The temporary endpoint label limited the blast radius, and saving the complete monitoring table was essential because the update API replaced state rather than appending one isolated rule.

Control: direct collection

The investigator first attempted a normal collection of Windows.Sysinternals.SysmonInstall with the canary path:

{
  "client_id": "CLIENT_ID",
  "artifacts": ["Windows.Sysinternals.SysmonInstall"],
  "specs": [{
    "artifact": "Windows.Sysinternals.SysmonInstall",
    "parameters": {"env": [{
      "key": "SysmonFileLocation",
      "value": "C:/Windows/Temp/f1054-canary.exe"
    }]}
  }],
  "urgent": true
}

The API returned HTTP 403 with an EXECVE permission error. No flow was created and the canary did not execute.

Bypass: client monitoring

Using the same investigator session, the complete monitoring table placed Windows.Sysinternals.SysmonLogForward under the temporary endpoint label and supplied the same path:

{
  "artifacts": {"artifacts": []},
  "label_events": [{
    "label": "f1054-esc",
    "artifacts": {
      "artifacts": ["Windows.Sysinternals.SysmonLogForward"],
      "specs": [{
        "artifact": "Windows.Sysinternals.SysmonLogForward",
        "parameters": {"env": [{
          "key": "SysmonFileLocation",
          "value": "C:/Windows/Temp/f1054-canary.exe"
        }]}
      }]
    }
  }]
}

The state update returned HTTP 200. Endpoint evidence showed the canary running four times as SYSTEM with arguments normally intended for Sysmon, including configuration and update operations. The executable hash on the endpoint matched the independently prepared fixture.

The previous monitoring table was recorded before the test because this API replaces the complete table. It and the temporary label were restored after validation.

Root cause

SysmonLogForward invoked Windows.Sysinternals.SysmonInstall, which declared an EXECVE requirement and used the first file matching SysmonFileLocation as argv[0]. Client-monitoring compilation did not enforce the initiating principal’s permissions across that transitive artifact dependency.

The direct path correctly rejected the call, but the monitoring wrapper did not declare the permission required by the artifact it invoked.

Artifact and launcher analysis

In the vulnerable tree, Windows.Sysinternals.SysmonLogForward.yaml called Artifact.Windows.Sysinternals.SysmonInstall() but declared no required_permissions. SysmonInstall itself declared EXECVE, selected the first file matching SysmonFileLocation, and used that path in several execve() calls for Sysmon installation and configuration operations.

This produced two distinct authorization views:

direct SysmonInstall collection -> sees EXECVE -> investigator denied
SysmonLogForward monitoring      -> wrapper declares none -> accepted

The Linux product entry in the advisory describes the vulnerable server and control plane. The privileged process dispatch occurs on the enrolled Windows endpoint. Calling the issue only “Windows” or only “Linux” obscures those two sides of the path.

Impact boundaries

The reproduction proves unauthorized executable-path selection and dispatch as LocalSystem. It does not prove that this path independently places an executable or gives arbitrary control over its arguments. General code execution requires a suitable executable already present at the chosen path or a separate file-placement primitive.

Detection notes

Review client-monitoring state for custom SysmonFileLocation values, particularly absolute paths outside the expected Sysmon deployment directory. On endpoints, correlate Velociraptor monitoring updates with LocalSystem process creation where the image path matches that parameter and the arguments resemble Sysmon configuration or update switches.

The strongest evidence joins control-plane and endpoint records: who changed the monitoring table, which label selected the client, the executable path and hash resolved on that client, and the resulting process token. Hash allowlists alone are insufficient because the vulnerable behavior is path selection and privileged dispatch; they should be evaluated alongside the expected artifact and signer policy.

Remediation

Upgrade to Velociraptor 0.77.3 or later. The fix in 7906c82f adds required_permissions: [EXECVE] directly to SysmonLogForward. Runtime monitoring enforcement therefore sees the wrapper’s explicit requirement and, with the earlier CVE-2026-19583 fix, rejects the investigator.

The same commit also extends the artifact verifier so static analysis includes CLIENT_EVENT artifacts and propagates called-artifact permissions into verifier state. That graph propagation is a build-time/static verification improvement; it is not a new runtime transitive-authorization engine. The runtime protection for this artifact comes from the explicit wrapper metadata.

Disclosure timeline

Date	Event
2026-08-05	Windows-specific impact reported to Rapid7
2026-10-05	Rapid7 confirmed remediation in the latest release