high · 7.8CVE-2022-46290Jul 1, 2026

CVE-2022-46290: Open Babel ORCA Parser Heap Buffer Overflow

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

A crafted ORCA chemistry file can trick Open Babel into writing past the end of a heap buffer, potentially allowing an attacker to execute arbitrary code on any system that parses untrusted files with

Packageopenbabel
Ecosystempip
Affected< 3.2.0
Fixed in3.2.0

The problem

Open Babel's ORCA output reader (orcaformat.cpp) allocates a coordinate buffer sized from a parsed `nAtoms` value, then fills it inside a while loop that reads every "CARTESIAN COORDINATES" block in the file.

The loop uses its own running index and never checks that index against `nAtoms`. Supplying more coordinate rows than `nAtoms` declares causes a write of 8 bytes (one double) past the end of the heap-allocated `confCoords` buffer. This is CWE-122 (Heap-based Buffer Overflow) and CWE-787 (Out-of-bounds Write), and can reach arbitrary code execution.

Proof of concept

A working proof-of-concept for CVE-2022-46290 in openbabel, with the exact payload below.

text
# Minimal ORCA output file triggering CVE-2022-46290
# nAtoms = 1 -> confCoords allocated for 1 atom (3 doubles = 24 bytes)
# Loop then writes a second coordinate row -> 8-byte OOB write

                         CARTESIAN COORDINATES (A.U.)

 NO LB      ZA    FRAG MASS         X           Y           Z
  1 H     1.0000   0   1.008   0.000000    0.000000    0.000000
  2 H     1.0000   0   1.008   1.000000    0.000000    0.000000

# obabel command that triggers ASAN heap-buffer-overflow:
# $ obabel -i orca trigger.orca -o sdf

The root cause is a missing bounds check in the coordinate-writing loop inside `OrcaOutputFormat::ReadMolecule` (orcaformat.cpp line 215). The buffer `confCoords` is allocated as `nAtoms * 3 * sizeof(double)` bytes, but the loop that populates it uses an independent counter with no upper bound, so each extra coordinate row writes 8 bytes (one `double`) past the allocation.

The patch at commit b239d06e adds an explicit check that breaks out of the loop when the running atom index reaches `nAtoms`, ensuring the write never exceeds the allocated size. The companion CVE-2022-46289 covered a separate integer-overflow path in the same allocation, so both fixes were needed to fully close the ORCA nAtoms attack surface.

The fix

Upgrade openbabel to 3.2.0 or later. The fix is commit b239d06eb724bb684eea0040e9d87cf07072b081, which adds an index-vs-nAtoms guard inside the coordinate loop in orcaformat.cpp. A regression test under ASAN+UBSAN is included in test/files/fuzz_regress/ and runs on every CI build.

Reported by Claudio Bozzato, Cisco Talos.

References: [1][2][3][4][5][6]

Related research