Part 1.2 of NODE-7598

What: new Binary(Buffer.alloc(0), Binary.SUBTYPE_VECTOR) produces a subtype-9 (Vector) value with no dtype/padding metadata, yet both BSON.serialize and EJSON.stringify emit it without complaint. A one-byte vector is correctly rejected, so this is specifically a missing minimum-length invariant, not a fully disabled validator.

Root cause: validateBinaryVector in src/binary.ts reads vector.buffer[0] (dtype) and vector.buffer[1] (padding) without first checking that those two bytes exist. With a zero-length payload both reads are undefined, so every dtype-specific branch is skipped and validation passes. The typed helper constructors (fromInt8Array, etc.) always allocate byteLength + 2, so the invariant is "every subtype-9 value carries 2 metadata bytes" — just not enforced on the raw constructor path.

Conditions required: an application must wrap caller-controlled bytes in the raw Binary(buf, SUBTYPE_VECTOR) constructor (rather than the typed helpers) and then treat js-bson serialization as its validation boundary before persisting/exporting. The impact is integrity (malformed vector data emitted), not memory safety or a server-side acceptance claim.

Pinned ref: 5b42c5a1535d45ec89ab9f1ed3bb249d09730e3c

Details & PoC: int-mongodb-js-bson-empty-vector-serialization-bypass/README.md and int-mongodb-js-bson-empty-vector-serialization-bypass/poc/ (run bash poc/run.sh).

Suggested fix: Reject subtype-9 Binary with fewer than 2 bytes in validateBinaryVector.

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