Part 1.1 of NODE-7598

What: A 10-byte BSON document with a string element declaring length 0 passes the on-demand parser's size/terminator guards, advances the cursor to the declared document end, and then makes findNull scan from past the buffer. findNull has no bounds check, and out-of-range Uint8Array reads return undefined (undefined !== 0x00 is always true), so the loop never terminates — synchronous CPU hang.

Root cause: findNull in src/parser/on_demand/parse_to_elements.ts assumes the document is well-formed and omits a < bytes.length guard. The ordinary deserializer rejects stringSize <= 0 (src/parser/deserializer.ts), but that check is not mirrored on the on-demand path.

Conditions required: an application must call the experimental BSON.onDemand.parseToElements API directly on untrusted bytes, without a surrounding timeout / worker isolation. Applications using the standard BSON.deserialize path are not affected.

Pinned ref: 5b42c5a1535d45ec89ab9f1ed3bb249d09730e3c

Details & PoC: int-mongodb-js-bson-ondemand-zero-length-string-hang/README.md and int-mongodb-js-bson-ondemand-zero-length-string-hang/poc/ (run bash poc/run.sh).

Suggested fix: Add a < bytes.length bound to findNull and treat the overrun as the existing "null terminator not found" error.

Use Case

As a... (who is this for)
I want... (what is the desired change)
So that... (why is the change desired)

User Experience

• What is the desired/expected outcome for the user once this ticket is implemented?
• If bug: What is the number of impacted customers? How severe is the impact? Is anyone blocked or broken?

Dependencies

• upstream and/or downstream requirements and timelines to bear in mind

Risks/Unknowns

• What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
• Is there an opportunity for better cross-driver alignment or testing in this area?
• Is there an opportunity to improve existing documentation on this subject?

Acceptance Criteria

Implementation Requirements

• functional reqs, potential snafus to avoid, performance targets, etc

Testing Requirements

• unit test, spec test sync, etc

Documentation Requirements

• DOCSP ticket, API docs, etc

Follow Up Requirements

• additional tickets to file, required releases, etc
• if node behavior differs/will differ from other drivers, confirm with dbx devs what standard to aim for and what plan, if any, exists to reconcile the diverging behavior moving forward