CVE-2022-37331: Open Babel Gaussian Output Parser Stack Buffer Overflow
A crafted Gaussian output file can overflow a fixed-size stack buffer in Open Babel's orientation block parser, letting an attacker write arbitrary data onto the stack and potentially execute code.
The problem
The Gaussian output reader in gaussformat.cpp copies atom coordinate rows from an orientation block into a fixed-size stack buffer without checking how many rows are present. There is no upper-bound guard on the loop, so a file with more rows than the buffer holds causes an out-of-bounds write on the stack.
Any application that calls Open Babel to parse untrusted Gaussian output files is affected, including the obabel CLI, the OBConversion C++ API, and all language bindings (Python, Ruby, Java, R, Perl, C#, PHP). CVSS 7.8 (local, high impact) because exploitation requires the victim to open a malicious file.
Proof of concept
A working proof-of-concept for CVE-2022-37331 in openbabel, with the exact payload below.
Gaussian 09 Revision D.01
#p HF/STO-3G
Title
Standard orientation:
---------------------------------------------------------------------
Center Atomic Atomic Coordinates (Angstroms)
Number Number Type X Y Z
---------------------------------------------------------------------
1 6 0 0.000000 0.000000 0.000000
2 1 0 0.000000 0.000000 1.089000
3 1 0 1.026719 0.000000 -0.363000
4 1 0 -0.513360 0.889165 -0.363000
5 1 0 -0.513360 -0.889165 -0.363000
6 6 0 1.000000 1.000000 1.000000
7 6 0 2.000000 2.000000 2.000000
8 6 0 3.000000 3.000000 3.000000
9 6 0 4.000000 4.000000 4.000000
10 6 0 5.000000 5.000000 5.000000
[... repeat N more rows until stack buffer at gaussformat.cpp:528 is overflowed ...]
---------------------------------------------------------------------
Normal termination of Gaussian 09.
The root cause is CWE-787: the ReadMolecule function in src/formats/gaussformat.cpp allocates a fixed-size stack buffer for atom rows in the coords_type orientation block, then loops reading rows with memcpy at line 528 without ever checking the row count against the buffer capacity.
Supplying more atom rows than the buffer holds writes directly past the end of the stack allocation.
The ASAN trace published by Talos shows WRITE of size 14 at 0xffff33c9 in __interceptor_memcpy called from GaussianOutputFormat::ReadMolecule at gaussformat.cpp:528, confirming the exact site. The companion translationVectors[3] bug (TALOS-2022-1666) in the same file follows the same unbounded-loop pattern: numTranslationVectors is incremented without a < 3 guard, so extra PeriodicType data rows also overflow the stack array.
The fix in commit 528c142f adds a bounds check before each write so the loop exits (or skips) once the buffer is full.
The fix
Upgrade Open Babel to 3.2.0 (released 2026-05-26), which includes commit 528c142f. That commit adds an explicit bounds check before the memcpy in the orientation block loop, preventing any write past the end of the stack buffer. If you cannot upgrade immediately, refuse to parse Gaussian output files from untrusted sources at the application level.
Reported by Claudio Bozzato, Cisco Talos.
Related research
- high · 7.8CVE-2022-46292CVE-2022-46292: Open Babel MOPAC Output Parser Out-of-Bounds Write (UNIT CELL TRANSLATION)
- high · 7.8CVE-2022-43467CVE-2022-43467: Open Babel PQS Parser Out-of-Bounds Write
- high · 7.8CVE-2022-43607CVE-2022-43607: Open Babel MOL2 Parser Stack Buffer Overflow
- high · 7.8CVE-2022-46291CVE-2022-46291: Open Babel Gaussian Parser Stack Buffer Overflow via translationVectors