CVE-2022-46290

What it actually does

Out-of-bounds write in the ORCA format nAtoms coordinate storage loop due to missing index validation against the declared atom count, enabling memory corruption that can be leveraged for arbitrary code execution.

Why it matters to the business

Processing of untrusted chemistry data files can allow remote attackers to execute code on researcher or lab systems, risking data theft, tampering with scientific results, or full host compromise; low but stable exploit probability and public exploit code increase urgency for organizations handling molecular file formats.

How an attack unfolds

An attacker crafts a malformed ORCA file containing an nAtoms value that exceeds allocated storage, then supplies the file to a victim application using Open Babel. When the parser reaches the coordinate-writing loop, the unchecked index overwrites adjacent memory, allowing the attacker to hijack control flow and execute arbitrary code.

How to fix it

Update Open Babel to a version that enforces bounds checking in the ORCA coordinate loop; until a fixed release is available, avoid processing untrusted ORCA files and sandbox any Open Babel invocations that must handle external data.

How to confirm the fix worked

Confirm the presence of index validation against nAtoms in the ORCA coordinate storage routine; test with a crafted file containing nAtoms larger than the actual coordinate list and verify that no out-of-bounds write occurs and the process remains stable.

Typical attack path

1. Create a specially crafted ORCA file with an inflated nAtoms value and malicious coordinate data
2. Deliver the file via email, download link, shared storage, or any chemistry data exchange channel
3. Victim opens or converts the file using Open Babel or a dependent tool
4. The ORCA parser enters the coordinate loop and performs the out-of-bounds write
5. Memory corruption leads to code execution or process crash under attacker control

How to detect it

Review application or system logs for Open Babel crashes or segmentation faults occurring immediately after ORCA file parsing; correlate with file creation or access events involving .orca or related extensions from untrusted sources.

What your security team should do

• Immediately restrict Open Babel usage to trusted internal files only
• Monitor upstream Open Babel repository and package feeds for the corrective release
• Add file-type sandboxing or conversion gateways for any workflow ingesting external molecular files
• Include Open Babel in the vulnerability management inventory with a 30-day remediation SLA given public exploit availability