Detect resdata < 6.2.9 Memory-Corruption Vulnerabilities (CVE-2026-55209) in Elastic Security
Detects the presence, installation, and potential exploitation of CVE-2026-55209 in the 'resdata' Python package (Equinor resdata, formerly libecl bindings) versions prior to 6.2.9. The vulnerability is a cluster of memory-safety defects — a classic buffer overflow (CWE-120), out-of-bounds read (CWE-125), improper validation of array index (CWE-129) and NULL pointer dereference (CWE-476) — triggered when resdata parses malformed reservoir-simulation binary files (Eclipse-format GRID/EGRID/INIT/UNRST/SMSPEC files). An attacker who supplies a crafted simulation file to a workflow using a vulnerable resdata build can cause a crash (DoS) or, via the heap/stack buffer overflow, potentially achieve code execution. CVSS 9.8, public PoC. This detection surfaces vulnerable installs across the environment and process/crash telemetry consistent with exploitation attempts against Python processes importing resdata.
MITRE ATT&CK
- Tactic
- Initial Access Execution Impact
Elastic Detection Query
process where process.name in ("python", "python3", "python.exe") and
(
process.command_line : ("*resdata*", "*.EGRID*", "*.UNRST*", "*.SMSPEC*", "*.INIT*")
)
and event.type == "start"Surfaces Python process starts that reference resdata or Eclipse-format simulation files, for correlation against vulnerable-version inventory.
Data Sources
Required Tables
False Positives & Tuning
- Routine reservoir-simulation batch jobs on already-patched hosts.
- Data-science notebooks importing resdata for legitimate analysis.
- Automated pipelines converting simulation output files.
Other platforms for CVE-2026-55209
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Detect vulnerable resdata version via pip
Expected signal: Process launch of python3 with a command line referencing importlib.metadata and resdata.
- Test 2Install vulnerable resdata build in isolated venv
Expected signal: pip install process events and creation of site-packages files for resdata 6.2.8.
- Test 3Parse malformed Eclipse-format file with resdata (crash reproduction)
Expected signal: python process opening /tmp/malformed.EGRID followed by abnormal termination / segfault (non-zero exit code, possible core dump).
Response Playbook
Triage
- Confirm the affected host has resdata installed and determine the exact version via `pip show resdata` or `python -c "import resdata, importlib.metadata as m; print(m.version('resdata'))"`; any version < 6.2.9 is vulnerable.
- Identify how resdata is invoked on the host — interactive analysis, scheduled batch job, or a service that ingests externally-supplied Eclipse-format files (.EGRID/.UNRST/.SMSPEC/.INIT).
- Determine whether the simulation files parsed by resdata originate from an untrusted or externally-reachable source; untrusted input dramatically raises exploitability of the buffer overflow.
- Check for recent Python crashes, segfaults, or abnormal process terminations on the host coinciding with resdata file parsing (potential exploitation or DoS).
Containment
- Upgrade resdata to 6.2.9 or later (`pip install --upgrade 'resdata>=6.2.9'`) across all affected hosts and virtual environments, including CI images and container base images.
- Until patched, quarantine or block ingestion of untrusted Eclipse-format simulation files into workflows that use resdata, and restrict such processing to isolated/sandboxed hosts.
- Disable or pause scheduled jobs and services that automatically parse externally-supplied simulation files with the vulnerable resdata build.
Evidence Collection
- Capture the installed package metadata (`pip freeze`, site-packages path, wheel hash) to document the vulnerable version present at time of investigation.
- Preserve any simulation input files (.EGRID/.UNRST/.SMSPEC/.INIT) processed around the time of a crash, along with core dumps and Python tracebacks, for malware/exploit analysis.
- Collect process-launch and crash telemetry (command line, parent process, user, exit code) for Python processes that imported resdata.
Escalation Criteria
- !Escalate to incident response if a resdata/Python process crash correlates with an externally-sourced or unexpected simulation file, indicating possible exploitation of the buffer overflow.
- !Escalate if a vulnerable resdata build is found on an internet-facing or multi-tenant host that accepts user-supplied simulation files.
- !Escalate if evidence of code execution (unexpected child processes, new persistence, outbound connections) follows resdata file parsing.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Installed resdata version and wheel hash under Python site-packages. - >
Core dumps / crash dumps and Python tracebacks from segfaulting resdata processes. - >
The specific Eclipse-format binary file (.EGRID/.UNRST/.SMSPEC/.INIT) that triggered the crash. - >
Process-launch records for python processes importing resdata with their command lines and parents.
Tuning Guidance
Baseline the legitimate reservoir-engineering hosts and service accounts that routinely run resdata; suppress those known-good combinations and focus alerting on unexpected hosts, ad-hoc user invocations, and processes that parse simulation files sourced from untrusted or external locations. Once inventory confirms all resdata installs are >= 6.2.9, downgrade the version-inventory portion of this detection to informational.
Hunting Queries
Hunt for Python processes that import resdata or open Eclipse-format simulation files, to scope hosts exposed to CVE-2026-55209.
DeviceProcessEvents | where FileName in~ ("python.exe","python","python3") | where ProcessCommandLine has_any ("resdata",".EGRID",".UNRST",".SMSPEC",".INIT") | project Timestamp, DeviceName, ProcessCommandLine, InitiatingProcessAccountNameindex=* sourcetype=*endpoint* (python OR python3) (resdata OR ".EGRID" OR ".UNRST" OR ".SMSPEC") | stats count by host, user, CommandLineAtomic Red Team Tests
Query the installed resdata package version and flag if it is below the fixed 6.2.9 release.
Command
python3 -c "import importlib.metadata as m; v=m.version('resdata'); print('resdata', v, 'VULNERABLE' if tuple(map(int,v.split('.')[:3]))<(6,2,9) else 'OK')"Cleanup
echo 'no cleanup required — read-only version check'Expected Telemetry
Process launch of python3 with a command line referencing importlib.metadata and resdata.
Expected Detection
Software-inventory / version-check logic flags resdata < 6.2.9 as vulnerable.
Create a throwaway virtual environment and install a resdata version prior to 6.2.9 to reproduce a vulnerable install for detection validation.
Command
python3 -m venv /tmp/resdata_vuln && /tmp/resdata_vuln/bin/pip install 'resdata==6.2.8'Cleanup
rm -rf /tmp/resdata_vulnExpected Telemetry
pip install process events and creation of site-packages files for resdata 6.2.8.
Expected Detection
Inventory/SBOM detection reports resdata 6.2.8 (< 6.2.9) as vulnerable on the host.
Feed a truncated/malformed Eclipse-format file to a vulnerable resdata build to trigger the out-of-bounds read / NULL dereference and observe the crash telemetry. Lab-only.
Command
head -c 32 /dev/urandom > /tmp/malformed.EGRID && /tmp/resdata_vuln/bin/python -c "from resdata.grid import Grid; Grid('/tmp/malformed.EGRID')"Cleanup
rm -f /tmp/malformed.EGRIDExpected Telemetry
python process opening /tmp/malformed.EGRID followed by abnormal termination / segfault (non-zero exit code, possible core dump).
Expected Detection
Correlation of a python+resdata process crash with parsing of an untrusted .EGRID file raises the exploitation-attempt alert.