BabelDOC v0.7.0: Rust PDF parser, resource limits

1. PDF reading and rewriting move to Rust

Rust now handles PDF parsing, scanned-document detection, text and image layout, paragraph and style processing, translation coordination, typesetting for print, and PDF writing. Layout models, which position document elements, and translation service integration remain in Python. Python also remains the entry point.

According to the project announcement, PDF reading is faster and uses less memory than 0.6.4. The goal is to keep document output on the default processing path unchanged, except for the watermark change and new resource limits.

2. Blocking paths where small inputs exhaust memory

0.7.0 enables limits by default to prevent excessive resource growth while reading input PDFs. Exceeding a limit stops processing and raises an exception with the limit's name, value, and location. All limits can be disabled together, but doing so logs a warning.

The first security advisory concerns memory exhaustion from decompressing PDF data without limiting output size. It is like opening a compressed package and watching a small bundle expand into a huge load.

In the advisory's reproduction, BabelDOC 0.6.4 in a Python 3.11 slim container expanded 1,043,644 bytes into 1,073,741,824 bytes. Decompression took 2.70 seconds, and peak process memory rose from 1,068,544KiB to 2,116,024KiB.

Part of the core reproduction code follows.

stream = PDFStream(attrs={"Filter": LIT("FlateDecode")}, rawdata=payload)

mem_before = resource.getrusage(resource.RUSAGE_SELF).ru_maxrss
print(f"\nProcess RSS before decode(): {mem_before} KiB")

start = time.time()
stream.decode()  # <-- the real, unmodified vulnerable call: zlib.decompress(data), no max size
elapsed = time.time() - start

The second advisory concerns ToUnicode mappings, which map font character codes to actual characters. Expanding and storing character-code ranges one entry at a time consumed resources. The following reproduction fed the same input to the original and successor Python parsers in BabelDOC 0.6.4.

Table: ToUnicode range expansion reproduction results

Conditions: BabelDOC 0.6.4, Python in Docker, network disabled, direct parser calls with input bytes (results from October 16, 2026)

Units: time in seconds, counts in entries

All ranges in the table start at 00000000. Widening the range increased processing time within each parser. A separate test expanding 00000000~FFFFFFFF under a 1GiB memory limit was forcibly terminated with exit code 137. The new Rust parser stores ranges rather than individual entries and also applies default limits to retained mapping data.

3. Better security means rejecting documents that exceed limits

Both advisories list 0.6.4 and earlier as vulnerable, with fixes included in 0.7.0. Released on November 7, 2026, this version replaces Python parser implementations that caused resource amplification during input processing with Rust implementations. The maintainer said security fixes are available only in the latest release, with no official backports to older versions.

Resource limits reduce the risk of excessive memory use from malicious inputs but reject translation even for legitimate documents that exceed them. Service operators need a procedure for explaining failures to users. For documents that must be processed, guidance describes disabling the limits and applying external constraints.

The reproduction figures come from direct parser calls, not measurements of full translation or the new Rust implementation. The maintainer also recommends translation-process timeouts and container memory limits when handling untrusted PDFs.

4. Use prebuilt packages and check results with your own documents

Prebuilt, ready-to-install packages cover five platforms: Linux x86-64 and ARM64, Windows x86-64, and Intel and Apple silicon Macs. Supported Python versions are 3.10~3.13. Installing a source distribution containing code and build settings on other platforms, or building directly from the repository, requires a Rust toolchain for compilation and builds.

Public entry points remain, but external code directly importing removed internal Python modules must be updated. The maintainer advises checking results with your own documents before upgrading production environments.

The first-page watermark is no longer added. Related settings are still accepted but now affect only output filenames and file counts, another change to check when reviewing results.

0.7.0 limits dangerous resource amplification in PDF parsing but may reject some documents, so operators should prepare to handle jobs that exceed limits in production.