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-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
- high · 7.8CVE-2022-46293CVE-2022-46293: Open Babel MOPAC Output Parser Stack Buffer Overflow