Skip to content

GHSA-p9f8-wvj8-2fg8 CVE-2026-81869 GO-2026-6616

OpenTelemetry-Go: UTF-8 replacement rune bypasses attribute length truncation

Medium Go
Severity
5.1 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.18%
Chance of exploitation in the next 30 days. Higher than 7.56% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-176 Improper Handling of Unicode Encoding
CWE-400 Uncontrolled Resource Consumption
Fix
1.33.0
Upgrade go.opentelemetry.io/otel/sdk to this version or later

Description

Summary

The OpenTelemetry Go SDK trace package can fail to enforce AttributeValueLengthLimit for string attributes containing the valid Unicode replacement character U+FFFD. An oversized attacker-controlled attribute value that includes U+FFFD is returned untruncated, bypassing the configured memory/DoS protection and allowing increased per-span memory usage. The finding is low severity because it requires a deployment with attribute value length limits enabled and attacker-controlled data being recorded into span attributes.

Introduced in commit 49a6536

Details

String and string-slice span attributes are truncated through safeTruncate when AttributeValueLengthLimit is non-negative. The finding evidence identifies this enforcement path in sdk/trace/span.go:303-331, with string attributes passed to safeTruncate at sdk/trace/span.go:309-310 and string-slice entries passed to safeTruncate in the loop beginning at sdk/trace/span.go:312.

safeTruncate first calls safeTruncateValidUTF8; if that returns ok=false, it calls strings.ToValidUTF8(input, "") and retries. The relevant code is identified in sdk/trace/span.go:337-355. safeTruncateValidUTF8 treats any utf8.RuneError from utf8.DecodeRuneInString as invalid UTF-8 and immediately returns the original input with ok=false. However, Go also returns utf8.RuneError for a valid encoded U+FFFD rune. The validation artifact confirms this behavior with output r=U+FFFD size=3 runeError=true.

For an input such as "AAAA" + U+FFFD + strings.Repeat("B", 20) and a limit of 5, the first truncation attempt sees U+FFFD as utf8.RuneError and returns the full input with ok=false. strings.ToValidUTF8 does not remove the valid U+FFFD rune, so the second attempt returns the same full input. As a result, the span attribute value remains 27 bytes long even though the configured limit is 5.

PoC

validation-artifact.zip

The validation artifact contains a package-level Go test at validation-artifact.tar:safe_truncate_bypass/safe_truncate_poc_test.go and supporting output at validation-artifact.tar:safe_truncate_bypass/runecheck_output.txt.

Reproduction configuration:

  • Repository: pellared/opentelemetry-go
  • Commit: 49a6536 from September 12, 2022
  • Package/module path: sdk/trace under the sdk module
  • Attribute value length limit used by the PoC: limit := 5
  • Dependencies must be available through the network or a local module cache/vendor directory.

Commands:

cd /path/to/opentelemetry-go
git checkout 49a6536
tar -xOf /path/to/validation-artifact.tar safe_truncate_bypass/safe_truncate_poc_test.go > sdk/trace/safe_truncate_poc_test.go
cd sdk
go test ./trace -run TestSafeTruncateBypass -count=1 -v

Expected vulnerable output includes a failing test showing that the returned value exceeds the configured limit:

=== RUN   TestSafeTruncateBypass
    safe_truncate_poc_test.go:14: input_len=27 got_len=27 input="AAAA�BBBBBBBBBBBBBBBBBBBB" got="AAAA�BBBBBBBBBBBBBBBBBBBB"
    safe_truncate_poc_test.go:16: bypass: got_len 27 > limit 5
--- FAIL: TestSafeTruncateBypass

The artifact also records the standalone UTF-8 behavior needed for the bypass:

tar -xOf /path/to/validation-artifact.tar safe_truncate_bypass/runecheck_output.txt

Expected output:

r=U+FFFD size=3 runeError=true

Impact

This is a Unicode handling and resource-limit bypass that weakens span attribute memory controls. Applications that enable AttributeValueLengthLimit to bound memory usage can still store oversized attacker-controlled attribute values if those values contain U+FFFD. The practical impact is increased memory use and reduced denial-of-service protection in the instrumented process; the finding does not show confidentiality or integrity impact.

Affected versions

Go

PackageVulnerableFixed in
go.opentelemetry.io/otel/sdk
>= 1.10.0, < 1.33.0
1.33.0
go.opentelemetry.io/otel/sdk
>= 1.10.0, < 1.33.0
1.33.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

go.opentelemetry.io/otel/sdk Go → 1.33.0

go
go get go.opentelemetry.io/otel/sdk@v1.33.0 && go mod tidy

Severity breakdown

CVSS 4.0 5.1

CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Attack vector
Local
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
None
Availability (vulnerable system)
Low
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

Weakness

CWE-176: Improper Handling of Unicode Encoding

The product does not properly handle when an input contains Unicode encoding.

How to prevent it
  • Architecture and Design: Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CWE-400: Uncontrolled Resource Consumption

The product does not properly control the allocation and maintenance of a limited resource.

How to prevent it
  • Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
  • Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
  • Implementation: Ensure that all failures in resource allocation place the system into a safe posture.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-8wmf-6v46-5gfg
OpenTelemetry-Go: Exporter config logging may leak endpoint URLs in info logs
Low Also affects go.opentelemetry.io/otel/sdk
GHSA-hfvc-g4fc-pqhx
opentelemetry-go: BSD kenv command not using absolute path enables PATH hijacking
High Also affects go.opentelemetry.io/otel/sdk
GHSA-9h8m-3fm2-qjrq
OpenTelemetry Go SDK Vulnerable to Arbitrary Code Execution via PATH Hijacking
High Also affects go.opentelemetry.io/otel/sdk
GHSA-8xpq-cjcf-3wh9
Deno: Permission Bypass via Unicode Normalization Mismatch on macOS (APFS)
High Same weakness, CWE-176
GHSA-q6x5-8v7m-xcrf
protobufjs has overlong UTF-8 decoding
Medium Same weakness, CWE-176
GHSA-vx9m-xjwf-8cqm
uutils coreutils has an Improper Handling of Unicode Encoding Issue
Low Same weakness, CWE-176
GHSA-392f-ggf5-fp3c
OpenClaw: Unicode canonicalization drift in node metadata policy classification could broaden node allowlists
Medium Same weakness, CWE-176
GHSA-r6q2-hw4h-h46w
Race Condition in node-tar Path Reservations via Unicode Ligature Collisions on macOS APFS
Medium Same weakness, CWE-176

Credits: MrAlias, pellared

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor