GHSA-wp73-mwgf-4jq9
MEDIUMGHSA-wp73-mwgf-4jq9 is a medium-severity (CVSS 5.5) Improper Input Validation vulnerability in go.opentelemetry.io/obi. O3 Security confirms whether GHSA-wp73-mwgf-4jq9 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OpenTelemetry eBPF Instrumentation: Unsafe fastelf parsing allows malformed ELF to crash agent
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-wp73-mwgf-4jq9.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-wp73-mwgf-4jq9 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 0 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
go.opentelemetry.io/obiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
OBI's replacement ELF parser trusts section offsets, counts, and string offsets from the executable file. A crafted local ELF can make OBI dereference invalid section pointers or slice past string tables, causing the agent to panic while determining the process language.
Details
matchExeSymbols iterates over sections and uses offsets/symbol names from the unvalidated fastelf context; nil section pointers or out-of-range offsets can trigger panics during dereference/slicing.
GetCStringUnsafe and ReadStruct perform unsafe slicing and pointer conversion without guarding against out-of-range or negative offsets derived from ELF data, enabling panics on malformed input.
NewElfContextFromData trusts Shoff/Shnum/Phnum from the ELF header, converting them to int and populating sections/segments without validating offsets or ensuring ReadStruct returned non-nil.
Malformed ELF metadata can therefore crash OBI during normal process discovery.
PoC
Local testing confirms the parser panic path on the vulnerable release, but one caveat is worth noting: rerunning a previously captured malformed-ELF PoC directly against the current checkout did not reproduce the original crash. That means the parser has drifted since the vulnerable release, so reproduction should be performed against the affected release tag or commit range rather than assuming current HEAD still panics in exactly the same way.
Use a vulnerable build:
git checkout v0.0.0-rc.1+build
make build
Create a small valid ELF and then corrupt its section-header metadata:
cat >/tmp/hello.c <<'EOF'
int main(void) { return 0; }
EOF
cc -o /tmp/hello /tmp/hello.c
cp /tmp/hello /tmp/hello-bad
printf '\xff\xff' | dd of=/tmp/hello-bad bs=1 seek=$((0x3c)) conv=notrunc
Run the malformed executable so OBI inspects it during process discovery:
chmod +x /tmp/hello-bad
/tmp/hello-bad &
Start OBI or trigger a rescan of processes:
sudo ./bin/obi
On a vulnerable build, OBI can panic while parsing the malformed ELF. If the first corruption does not hit the exact fragile path on your architecture, alter section-name or symbol-table offsets instead; the root issue is the lack of defensive validation before GetCStringUnsafe and related section lookups.
Impact
This is a local denial of service against the telemetry agent. Any local tenant or process owner able to execute a malformed binary on a monitored host can crash OBI and interrupt observability for other workloads.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | go.opentelemetry.io/obi | all versions | 0.9.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for go.opentelemetry.io/obi. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update go.opentelemetry.io/obi to 0.9.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wp73-mwgf-4jq9 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-wp73-mwgf-4jq9 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-wp73-mwgf-4jq9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-wp73-mwgf-4jq9 in your dependencies?
O3 detects GHSA-wp73-mwgf-4jq9 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.