PT-2026-44726 · Go · Go.Opentelemetry.Io/Otel/Schema/V1.0+1
Published
2026-05-28
·
Updated
2026-05-28
·
CVE-2026-45287
CVSS v4.0
2.1
Low
| Vector | AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N |
Summary
go.opentelemetry.io/otel/schema/v1.0 and go.opentelemetry.io/otel/schema/v1.1 leaks one file descriptor on each successful ParseFile call. ParseFile opens the schema file and passes it to Parse without closing it; repeated parsing in a long-running process can exhaust the process file descriptor limit and cause denial of service. The severity is low because exploitation depends on a consuming application exposing repeated schema parsing to an attacker-controlled path.Introduced in commit: e72a235
Details
In
schema/v1.0/parser.go:41-47, ParseFile opens the requested schema path with os.Open and then returns Parse(file) without a defer file.Close() or other close path:file, err := os.Open(schemaFilePath)
if err != nil {
return nil, err
}
return Parse(file)
The validation evidence also identifies
schema/v1.0/parser.go:50-73: Parse accepts an io.Reader, decodes from it, and does not close it. Ownership of the opened file is therefore not transferred to Parse, leaving the descriptor open until the Go runtime eventually finalizes the file object. With repeated ParseFile calls, descriptors can accumulate until the process receives EMFILE / "too many open files".PoC
The local artifact
validation-artifact.zip contains:leak poc.go: PoC source that repeatedly callsschema.ParseFile("schema/v1.0/testdata/valid-example.yaml")and prints/proc/self/fdcounts.LEAK POC README.txt: reproduction notes.leak poc run.log: captured attempted run; the local offline environment failed before execution because Go module download fromproxy.golang.orgwas forbidden.
Reproduce from the root of a checkout of
pellared/opentelemetry-go at commit e72a235 with Go module dependencies already available:/bin/sh -c 'ulimit -n 256; GOGC=off go run leak poc.go'
Configuration:
- File descriptor soft limit:
256 - Garbage collection: disabled with
GOGC=offso leaked descriptors are not reclaimed during the loop - Schema file:
schema/v1.0/testdata/valid-example.yaml
Expected output is increasing descriptor counts followed by an
EMFILE failure, for example:iter 0 fds 7
iter 50 fds 57
iter 100 fds 107
...
panic: iteration 248: open schema/v1.0/testdata/valid-example.yaml: too many open files
The exact initial descriptor count and failing iteration can vary by OS and process state.
Impact
This is a file descriptor resource leak leading to availability loss. Applications that call
schema.ParseFile repeatedly, especially through a runtime reload or request-controlled path, can exhaust their process file descriptor table and fail subsequent file, socket, or other descriptor operations. Impact is limited to denial of service of the consuming process; the evidence does not show confidentiality or integrity impact.Fix
Missing Release of Resource after Effective Lifetime
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Go.Opentelemetry.Io/Otel/Schema/V1.0
Go.Opentelemetry.Io/Otel/Schema/V1.1