GHSA-p9f8-wvj8-2fg8 CVE-2026-81869 GO-2026-6616
OpenTelemetry-Go: UTF-8 replacement rune bypasses attribute length truncation
- 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
- 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
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:
49a6536from September 12, 2022 - Package/module path:
sdk/traceunder thesdkmodule - 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
| Package | Vulnerable | Fixed 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
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why 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
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