A full walkthrough of the TryHackMe 'Byte Lotus — Poolside' room chains six exploitation stages: bypassing login via a MongoDB $ne NoSQL injection, achieving RCE through an EJS server-side template injection, pivoting via SSH local port-forward to reach a localhost-only Node.js Inspector debug port, writing a custom Python WebSocket client to bypass Node 22's Host-header validation and trigger Runtime.evaluate RCE, and finally escalating privileges by abusing disk group membership to read the root flag directly off the raw block device using debugfs. Remediation notes cover sanitizing MongoDB queries, avoiding raw EJS rendering of user input, disabling --inspect in production, and auditing disk-equivalent group memberships.
Questions this post answers
How do you bypass a login form vulnerable to NoSQL injection using the MongoDB $ne operator?
Send username[$ne]=toto and password[$ne]=toto as form fields instead of literal strings, so Express's body-parser turns them into objects like {$ne: 'toto'}. The resulting query becomes db.findOne({username:{$ne:'toto'}, password:{$ne:'toto'}}), which matches any real record whose username and password are not equal to 'toto', bypassing authentication entirely because the backend never strips operator keys from user input. Developers hardening login forms can find NoSQL injection defenses like input sanitization patterns on daily.dev.
Why does the Metasploit nodejs_v8_debugger module fail against a modern Node.js Inspector on Node 22?
Modern Node versions strictly validate the Host header on inspector WebSocket upgrade requests as anti-DNS-rebinding protection, a check added well after that 2016-era Metasploit module was written, so its handshake gets rejected with a 400 Bad Request before Node treats it as a WebSocket request. A hand-rolled Python client that sends the exact expected Host header can complete the CDP handshake and issue Runtime.evaluate for code execution instead. Anyone debugging Node.js inspector tooling against newer runtimes can track these protocol changes on daily.dev.
Why is Linux disk group membership considered dangerous for a service account?
Membership in the disk group grants raw read/write access to block devices, which completely bypasses normal filesystem-level permission checks since those checks are enforced at the filesystem layer, not the raw device layer. An attacker in that group can use debugfs to mount and browse an ext filesystem partition directly, reading files like /root/root.txt without ever needing actual root privileges or a sudo bypass. Teams auditing Linux privilege boundaries can follow real-world escalation techniques like this on daily.dev.