CVE-2026-39883

What it actually does

OpenTelemetry-Go versions 1.15.0 through 1.42.0 can invoke the BSD/Solaris `kenv` utility by bare command name instead of an absolute path. On affected platforms, a local attacker who can influence the `PATH` environment of an OpenTelemetry-instrumented Go process can cause the process to execute an attacker-controlled executable named `kenv`. The resulting code execution occurs with the privileges of the vulnerable process. The flaw is local, requires prior access or control over the process environment, and has high confidentiality, integrity, and availability impact when the target process runs with elevated privileges.

Why it matters to the business

Systems running affected OpenTelemetry-Go-based applications on BSD or Solaris may allow a local user or compromised low-privilege process to escalate impact by executing code as a more trusted service account. This can lead to service disruption, tampering with application telemetry or runtime behavior, credential theft from the process environment, or broader host compromise. Exploitation is not known to be in CISA KEV, is not currently associated with ransomware, and has a low EPSS score, but organizations using OpenTelemetry-Go broadly should still prioritize upgrades because observability libraries are commonly embedded across many applications and may be overlooked in asset inventories.

How an attack unfolds

An attacker first obtains local access to a BSD or Solaris host, or gains the ability to modify the environment used to launch an OpenTelemetry-instrumented Go application. The attacker places a malicious executable named `kenv` in a directory that appears earlier in the target process `PATH` than the legitimate system utility. When the vulnerable OpenTelemetry-Go code runs the platform resource-detection logic and invokes `kenv` by name, the operating system resolves the command through `PATH` and launches the attacker’s executable instead of the intended system binary. The malicious `kenv` then runs with the privileges of the OpenTelemetry-instrumented process, allowing the attacker to run arbitrary commands, alter files accessible to that account, read secrets available to the process, or establish persistence.

How to fix it

Upgrade OpenTelemetry-Go to version 1.43.0 or later. Rebuild and redeploy all Go applications that statically include affected OpenTelemetry-Go versions, because upgrading the module in source control alone does not update already-built binaries. Review SBOMs, `go.mod`, `go.sum`, vendored dependencies, and built binary metadata for `go.opentelemetry.io/otel` or related OpenTelemetry-Go modules in versions 1.15.0 through 1.42.0. As interim mitigations, restrict who can modify application startup files and environment variables, run services with minimal privileges, sanitize `PATH` for services, prefer absolute paths in wrappers and supervisors, remove writable directories from service `PATH`, and monitor or block execution of `kenv` from non-system directories.

How to confirm the fix worked

Confirm that all relevant Go projects and built artifacts use OpenTelemetry-Go 1.43.0 or later. Use dependency tooling such as `go list -m all`, SBOM scanners, or source composition analysis to identify affected module versions. For compiled binaries, use `go version -m <binary>` where available to inspect embedded module versions. On BSD or Solaris hosts, confirm service definitions, rc scripts, cron entries, supervisor configs, and shell wrappers do not place writable directories before system directories in `PATH`. Validate that no application process can resolve `kenv` from a user-writable location by testing command resolution under the same environment used by the service. After remediation, redeploy rebuilt binaries and verify runtime telemetry or EDR process events no longer show OpenTelemetry-instrumented services launching `kenv` from unexpected paths.

Typical attack path

1. Identify a BSD or Solaris system running a Go application built with OpenTelemetry-Go version 1.15.0 through 1.42.0.
2. Obtain local access or another foothold that allows control over the application launch environment, service wrapper, shell profile, cron job, rc script, or equivalent startup configuration.
3. Create an attacker-controlled executable named `kenv` in a writable directory.
4. Modify or influence `PATH` so the writable directory is searched before the legitimate system command location.
5. Trigger application startup or the OpenTelemetry code path that invokes `kenv`.
6. The vulnerable process executes the malicious `kenv` with the privileges of the application process.
7. Use the resulting execution context to steal process-accessible secrets, modify application behavior, move laterally, or establish persistence.

How to detect it

To determine whether this was already exploited, review process execution telemetry from EDR, auditd, BSD process accounting, Solaris audit logs, shell history, service supervisor logs, cron logs, and file integrity monitoring. Focus on executions of a process named `kenv` where the executable path is not the legitimate system utility, where the parent process is a Go application or service using OpenTelemetry, or where the command was launched shortly after a service restart. Search for files named `kenv` created in writable directories such as `/tmp`, `/var/tmp`, user home directories, application working directories, or deployment directories. Correlate with environment or startup configuration changes that prepend writable locations to `PATH`. Investigate suspicious `chmod +x` activity, new executable files named `kenv`, unexpected outbound connections from the `kenv` process, child shells spawned by `kenv`, and post-exploitation artifacts such as modified startup scripts, new cron entries, or credential access from the affected service account. There are no known public threat actors or KEV-listed campaigns for this issue at the time of the provided data, so detection should be behavior-based rather than signature-only.

• process.name=kenv
• comm=kenv
• argv[0]=kenv
• execve("kenv"
• /tmp/kenv
• /var/tmp/kenv
• /usr/tmp/kenv
• /dev/shm/kenv
• /home/*/kenv
• chmod +x *kenv
• PATH=/tmp:
• PATH=/var/tmp:
• PATH=.*:/tmp
• PATH=.*:/var/tmp
• process.executable=/tmp/kenv
• process.executable=/var/tmp/kenv
• process.executable=/usr/tmp/kenv
• process.executable=/home/*/kenv
• go.opentelemetry.io/otel v1.15.0
• go.opentelemetry.io/otel v1.16.0
• go.opentelemetry.io/otel v1.17.0
• go.opentelemetry.io/otel v1.18.0
• go.opentelemetry.io/otel v1.19.0
• go.opentelemetry.io/otel v1.20.0
• go.opentelemetry.io/otel v1.21.0
• go.opentelemetry.io/otel v1.22.0
• go.opentelemetry.io/otel v1.23.0
• go.opentelemetry.io/otel v1.24.0
• go.opentelemetry.io/otel v1.25.0
• go.opentelemetry.io/otel v1.26.0
• go.opentelemetry.io/otel v1.27.0
• go.opentelemetry.io/otel v1.28.0
• go.opentelemetry.io/otel v1.29.0
• go.opentelemetry.io/otel v1.30.0
• go.opentelemetry.io/otel v1.31.0
• go.opentelemetry.io/otel v1.32.0
• go.opentelemetry.io/otel v1.33.0
• go.opentelemetry.io/otel v1.34.0
• go.opentelemetry.io/otel v1.35.0
• go.opentelemetry.io/otel v1.36.0
• go.opentelemetry.io/otel v1.37.0
• go.opentelemetry.io/otel v1.38.0
• go.opentelemetry.io/otel v1.39.0
• go.opentelemetry.io/otel v1.40.0
• go.opentelemetry.io/otel v1.41.0
• go.opentelemetry.io/otel v1.42.0

What your security team should do

• Inventory Go applications and binaries that include OpenTelemetry-Go, prioritizing BSD and Solaris deployments.
• Upgrade affected applications to OpenTelemetry-Go 1.43.0 or later and redeploy rebuilt binaries.
• Treat this as higher priority for services running as root or privileged service accounts, even though public exploitation likelihood is currently low.
• Harden service launch environments by using minimal, fixed `PATH` values and excluding writable directories such as temporary, home, or application upload directories.
• Add detection for execution of `kenv` from any path other than the legitimate system location, especially when the parent process is an application service.
• Review recent process execution logs for suspicious `kenv` executions and correlate with file creation or permission changes in writable directories.
• Limit write access to application directories, startup scripts, service definitions, and shell initialization files used by production services.
• If suspicious execution is found, preserve the malicious `kenv` file, collect process lineage, rotate secrets accessible to the affected process, and investigate for persistence.