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

CVE-2022-46289: Open Babel ORCA nAtoms Heap Buffer Overflow

Rohit Hatagale
AI Security Researcher, SecureLayer7

A crafted ORCA chemistry file can trick Open Babel into allocating a tiny heap buffer and then writing atom coordinates past its end, potentially giving an attacker arbitrary code execution.

Packageopenbabel
Ecosystempip
Affected< 3.2.0
Fixed in3.2.0

The problem

Open Babel's ORCA output format reader (orcaformat.cpp) parses a "Number of atoms" field directly from the input file into a signed int called nAtoms, with no validation.

Two flaws combine here. First, a large value of nAtoms causes nAtoms * 3 to integer-overflow and wrap around, so the heap allocation for confCoords becomes far smaller than expected. Second, the coordinate-writing loop has no bounds check against nAtoms, so it keeps writing as long as lines with at least four tokens exist.

Together these allow an attacker to write arbitrary doubles past the end of the confCoords heap buffer.

Any service or tool that parses untrusted ORCA files is affected, including the obabel CLI, the OBConversion API, and all language bindings (Python, Ruby, Java, R, Perl, C#, PHP).

Proof of concept

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

text
                                 Geometry Optimization Run

                         Number of atoms       1431655766


CARTESIAN COORDINATES (ANGSTROEM)
---------------------------------
  C   0.000000    0.000000    0.000000
  C   1.000000    0.000000    0.000000
  C   2.000000    0.000000    0.000000
  C   3.000000    0.000000    0.000000
  C   4.000000    0.000000    0.000000
  [... repeat atom lines to push i past nAtoms*3 allocation ...]

The advisory (TALOS-2022-1665) documents the exact integer wrap-around: nAtoms = 1431655766 causes nAtoms * 3 = 4294967298, which wraps to 2 on a 32-bit int, so new double[2] allocates only 16 bytes. The coordinate loop then writes each atom's x, y, z doubles into confCoords[i*3 .. i*3+2] without ever comparing i against nAtoms, so every atom line after the first overflows the 16-byte buffer.

CVE-2022-46290 is the companion bug: even with a sane nAtoms, declaring fewer atoms than coordinate lines achieves the same overflow. The patch (commit b239d06e) adds both an overflow-safe allocation check and a loop termination condition that stops at i == nAtoms.

The fix

Upgrade to Open Babel 3.2.0 (released 2026-05-26), which includes fix commit b239d06eb724bb684eea0040e9d87cf07072b081. The patch adds an integer-overflow guard on the nAtoms * 3 multiplication before allocating confCoords, and adds an i < nAtoms bounds check as a loop termination condition so the coordinate-writing loop cannot run past the allocated buffer.

Reported by Claudio Bozzato, Cisco Talos.

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

Related research