I found src/runtime/server/system/schema-generator.ts:18 using z.array(z.string()) with no .max(), and src/runtime/server/controllers/command-export.controller.ts:81 using z.tuple([z.string().min(1), z.array(z.string())]), also with no .max(). The args.length > 10 guard at command-export.controller.ts:87 only runs after Zod has already parsed/allocated the full array, so a player can send a very large array or long strings to force allocation/validation work before that check ever rejects it — looks like a real DoS surface reachable by any connected client today.
I'd add .max(N) on the array and .max(len) on each string directly in the Zod schemas, so oversized payloads get rejected before allocation instead of after.
I found
src/runtime/server/system/schema-generator.ts:18usingz.array(z.string())with no.max(), andsrc/runtime/server/controllers/command-export.controller.ts:81usingz.tuple([z.string().min(1), z.array(z.string())]), also with no.max(). Theargs.length > 10guard atcommand-export.controller.ts:87only runs after Zod has already parsed/allocated the full array, so a player can send a very large array or long strings to force allocation/validation work before that check ever rejects it — looks like a real DoS surface reachable by any connected client today.I'd add
.max(N)on the array and.max(len)on each string directly in the Zod schemas, so oversized payloads get rejected before allocation instead of after.