Summary
GHSA-p56x-m2v9-77x3 (fixed in 6.0.4) added Invalid collection / Invalid id type checks to the snapshot-fetch actions. The equivalent checks are still missing for the ids and version-map keys carried in bulk and query-resubscribe requests, so non-string values reach the database adapter and readSnapshots middleware unchecked.
Agent._checkRequest validates request.d for single-doc actions, and validates that request.b is an object for bulk actions — but it never validates the individual ids inside b, nor the ids in a query's reconnect r payload.
Reproduction
See scratchpad/server/poc10-bulk-id-types.js. A single-doc f with d: {$ne: null} is correctly rejected with Invalid id, but these all reach the adapter:
{a:'bf', c:'docs', b:[{$ne:null}, 42, '__proto__']} → getSnapshotBulk ids [{"$ne":null}, 42, "__proto__"], and readSnapshots sees snapshot ids of type object/number/string accordingly.{a:'bf', c:'docs', b:{x:{$gt:-1}}} → getOpsBulk fromMap {"x":{"$gt":-1}} (non-numeric version).{a:'qs', id:1, c:'docs', q:{}, r:[[{$ne:null}], ['y',{$gt:-1}]]} → same, via the query reconnect path.
Whether this is exploitable depends on the adapter (e.g. an adapter that uses the id directly as a query value, as noted in GHSA-p56x-m2v9-77x3). Within ShareDB core and MemoryDB it does not crash, so this is filed as hardening to finish the job that advisory started rather than as a separate vulnerability.
Suggested fix
Validate each id in b (array elements and object keys) and each id/version in a query's r payload with the same string/isDangerousProperty checks and version checks already applied to single-doc requests, centralised so all read paths share one validator.
Summary
GHSA-p56x-m2v9-77x3 (fixed in 6.0.4) added
Invalid collection/Invalid idtype checks to the snapshot-fetch actions. The equivalent checks are still missing for the ids and version-map keys carried in bulk and query-resubscribe requests, so non-string values reach the database adapter andreadSnapshotsmiddleware unchecked.Agent._checkRequestvalidatesrequest.dfor single-doc actions, and validates thatrequest.bis an object for bulk actions — but it never validates the individual ids insideb, nor the ids in a query's reconnectrpayload.Reproduction
See
scratchpad/server/poc10-bulk-id-types.js. A single-docfwithd: {$ne: null}is correctly rejected withInvalid id, but these all reach the adapter:{a:'bf', c:'docs', b:[{$ne:null}, 42, '__proto__']}→getSnapshotBulkids[{"$ne":null}, 42, "__proto__"], andreadSnapshotssees snapshot ids of type object/number/string accordingly.{a:'bf', c:'docs', b:{x:{$gt:-1}}}→getOpsBulkfromMap{"x":{"$gt":-1}}(non-numeric version).{a:'qs', id:1, c:'docs', q:{}, r:[[{$ne:null}], ['y',{$gt:-1}]]}→ same, via the query reconnect path.Whether this is exploitable depends on the adapter (e.g. an adapter that uses the id directly as a query value, as noted in GHSA-p56x-m2v9-77x3). Within ShareDB core and MemoryDB it does not crash, so this is filed as hardening to finish the job that advisory started rather than as a separate vulnerability.
Suggested fix
Validate each id in
b(array elements and object keys) and each id/version in a query'srpayload with the same string/isDangerousPropertychecks and version checks already applied to single-doc requests, centralised so all read paths share one validator.