In general, to fix this kind of issue, you must ensure that user-controlled data is treated strictly as values and not as query/update operators. For MongoDB/Mongoose updates, that means never passing a raw user object directly to operators like $set, but instead constructing a new object that only contains whitelisted, expected fields and simple literal values. This both prevents operator injection and guards against mass‑assignment of unintended properties.

For this specific case, the fix is to build updateData explicitly from allowed fields of RegisterDeviceInputDTO instead of { ...input }. Additionally, for any nested object like simInfo, we should build that subdocument field-by-field and/or treat the entire simInfo as a literal by placing it under a non-operator key. We should also ensure we do not allow users to override internal fields (e.g., user, _id) or to add arbitrary top-level keys.

Concretely, in api/src/gateway/gateway.service.ts:

• In registerDevice, instead of const deviceData: any = { ...input, user }, construct deviceData by whitelisting known properties of RegisterDeviceInputDTO (e.g., model, brand, buildId, name, appVersionCode, simInfo, enabled, etc.). This ensures that deviceData cannot contain unexpected MongoDB operators on properties that will later be reused in updates.
• In updateDevice, replace const updateData: any = { ...input } with a new object that only includes explicitly allowed properties (same whitelist as above) and builds simInfo as a plain object. Because findByIdAndUpdate is using { $set: updateData }, we must ensure updateData itself cannot contain any $-prefixed keys.
• Preserve existing logic for setting default name, normalizing enabled, and enriching simInfo.lastUpdated.

This change is localized to gateway.service.ts and does not change API behavior from a legitimate client’s perspective, but it removes the reliance on a tainted, unstructured object.

In general, to fix this kind of NoSQL injection risk, you must ensure that any user-controlled data used in a MongoDB query is treated strictly as a literal value and cannot be interpreted as a query object or operator. This is commonly done by (a) validating that the input is of an expected primitive type (string/number/boolean) before using it in the query, or (b) explicitly wrapping the value in an operator like $eq, which forces MongoDB to interpret the data as a scalar comparison value.

For this specific code, the best minimal fix without changing existing functionality is to (1) add runtime checks that dto.sender and dto.message are strings and that receivedAt is a valid Date, and (2) wrap the user-controlled fields in $eq in the findOne query. This keeps the semantics (find an SMS with exact same device, type, sender, message, and a receivedAt within a tolerance window) but prevents any possibility of passing an object that Mongo could interpret as query operators.

Concretely in api/src/gateway/gateway.service.ts:

• In receiveSMS, augment the existing validation block to also verify typeof dto.sender === 'string' and typeof dto.message === 'string'. Also check that receivedAt resolves to a valid Date (i.e., not Invalid Date) before using it.
• Update the this.smsModel.findOne({ ... }) call so that sender and message are expressed as { $eq: dto.sender } and { $eq: dto.message }. device and type are either ObjectId/enum from server-side code, so they do not need this treatment.

No new methods or external libraries are required; only in-place validation and query changes in receiveSMS are needed. All changes occur within the shown snippet of GatewayService.receiveSMS.