deps: bump go.opentelemetry.io/otel/sdk to v1.43.0 (CVE-2026-39883)

[Copilot]

go.opentelemetry.io/otel/sdk v1.42.0 uses a bare kenv command name (no absolute path) in its BSD host ID reader, enabling PATH hijacking on FreeBSD/BSD/Solaris at OTel SDK initialization. Fixed in v1.43.0 which uses /bin/kenv.

Changes

• go.mod / go.sum: go.opentelemetry.io/otel/sdk pinned at v1.43.0 (transitive via cloud.google.com/go/bigtable → otel/sdk/resource → otel/sdk)

Reachability

The vulnerable code compiles only under BSD/Solaris build tags and is never reached on Linux. This project has no direct OTel SDK imports — exposure exists only if the emulator is run on a BSD host. The fix is in the dependency graph regardless of platform.

Original prompt

---

This section details the Dependabot vulnerability alert you should resolve

<alert_title>opentelemetry-go: BSD kenv command not using absolute path enables PATH hijacking</alert_title>
<alert_description>## Summary

The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.

Root Cause

sdk/resource/host_id.go line 42:

if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil {

Compare with the fixed Darwin path at line 58:

result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice")

The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when the command name contains no path separator.

Affected platforms (per build tag in host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.

The kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems.

Attack

1. Attacker has local access to a system running a Go application that imports go.opentelemetry.io/otel/sdk
2. Attacker places a malicious kenv binary earlier in $PATH
3. Application initializes OpenTelemetry resource detection at startup
4. hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary
5. Arbitrary code executes in the context of the application

Same attack vector and impact as CVE-2026-24051.

Suggested Fix

Use the absolute path:

if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil {

On FreeBSD, kenv is located at /bin/kenv.</alert_description>

high
GHSA-hfvc-g4fc-pqhx, CVE-2026-39883
go.opentelemetry.io/otel/sdk
go
<vulnerable_versions>= v1.42.0</vulnerable_versions>
<patched_version>1.43.0</patched_version>
<manifest_path>go.mod</manifest_path>

https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-hfvc-g4fc-pqhx http://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.43.0 https://nvd.nist.gov/vuln/detail/CVE-2026-39883 https://github.com/advisories/GHSA-hfvc-g4fc-pqhx

<agent_instructions>update all dependencies (go get -u ./...)</agent_instructions>

<task_instructions>Resolve this alert by updating the affected package to a non-vulnerable version. Prefer the lowest non-vulnerable version (see the patched_version field above) over the latest to minimize breaking changes. Include a Reachability Assessment section in the PR description. Review the alert_description field to understand which APIs, features, or configurations are affected, then search the codebase for usage of those specific items. If the vulnerable code path is reachable, explain how (which files, APIs, or call sites use the affected functionality) and note that the codebase is actively exposed to this vulnerability. If the vulnerable code path is not reachable, explain why (e.g. the affected API is never called, the vulnerable configuration is not used) and note that the update is primarily to satisfy vulnerability scanners rather than to address an active risk. If the advisory is too vague to determine reachability (e.g. 'improper input validation' with no specific API named), state that reachability could not be determined and explain why. Include a confidence level in the reachability assessment (e.g. high confidence if the advisory names a specific API and you confirmed it is or is not called, low confidence if the usage is indirect and hard to trace). If no patched version is available, check the alert_description field for a Workarounds section — the advisory may describe configuration changes or usage patterns that mitigate the vulnerability without a version update. If a workaround is available, apply it and leave a code comment referencing the advisory identifier explaining it is a temporary mitigation. If neither a patch nor a workaround is available, explain in the PR description why the alert cannot be resolved automatically so a human reviewer can take over. Inspect the repository to determine which package manager is used (e.g. lock files, config files, build scripts) and use that tooling to perform the update — do not edit lock files directly. If the version constraint in the manifest (e.g. package.json, Gemfile, pyproject.toml) caps the version below the fix, update the constraint first. For transitive dependencies, determine whether it is simpler to update the direct dependency that pulls in the vulnerable package or to update the transitive dependency directly, and choose the least disruptive approach. If upgrading to fix the vulnerability forces a major version bump or known breaking changes, review the chang...

• Resolves bitly/little_bigtable alert fix compatibility issue with gob registrations #23