@alexdoandev/jev-laya-dsh

The server is bound to 127.0.0.1 only, but the two admin routes take no body, no token and no Origin check, so they are reachable by any local process and even by a cross-origin 'simple' POST from a web page the developer visits (text/plain POST does not trigger a CORS preflight; the handler never reads the body). An attacker page or local process can therefore force repeated weight loads (the file itself states a Python load costs ~7-11 min of CPU) or unload the weights at will, degrading routing to fail-open and burning the machine. The Node (onnx-server/laya-onnx-server.mjs) and Rust (onnx-

The declared content-length is parsed and then explicitly discarded (`void size;`) while every chunk is accumulated, so any caller that can reach 127.0.0.1 can stream an arbitrarily large body and exhaust the model server's memory. The Rust variant reads the whole body with read_to_string and the Python variant with self.rfile.read(int(content-length)) with the same absence of a cap. Loopback-only binding keeps this low, but combined with the unauthenticated routes any local process or browser-triggerable request can hit it.

npm install of this package mutates node_modules/@receptron/laya/dist/laya.js (the loaded model runtime) to read special tokens from tokenizer_config.json. The edit itself is benign, exact-string matched and idempotent, but it establishes an install-time code-modification pattern that silently bypasses dependency integrity: if the ORIGINAL string is ever found in a different context, or upstream ships different content, the behavior of the code the router actually executes changes without any lockfile-visible signal. Any process able to influence this path at install time (e.g. a compromised/l