CVE-2026-105040 in NestJS auth service
Summary
by MITRE • 10/16/2026
The EnergizeLab Eilik NestJS auth service accepts a user-controlled user ID in account update requests (mass assignment). A registered user can set another account's identifier and take over that account.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
This vulnerability represents a critical authentication bypass resulting from improper implementation of access control mechanisms, specifically through mass assignment flaws within the EnergizeLab Eilik NestJS auth service. The core technical issue lies in how the backend API processes user profile update requests. When an authenticated user submits data to modify their account details, the application framework fails to strictly validate or filter which fields are permitted for modification by that specific session context. Instead of binding input parameters exclusively to the identity associated with the active authentication token, the service allows client-supplied values to overwrite arbitrary properties in the database record being updated. This architectural oversight creates a direct path for privilege escalation and account takeover attacks.
The operational impact of this flaw is severe, as it enables any registered user to seize control of other accounts within the system. By manipulating the request payload to include an identifier field corresponding to another victim's account ID, the attacker can effectively rewrite the ownership or authentication credentials associated with that target identity. This could involve changing passwords, resetting two-factor authentication settings, or updating email addresses linked to the compromised account. Consequently, the integrity of user identities is completely undermined, leading to unauthorized access to sensitive personal data, potential financial loss if payment methods are stored, and a significant breach of trust in the platform's security posture. Such vulnerabilities often lead to broader systemic risks where attackers can pivot from individual account compromise to more extensive lateral movement within connected services or databases that rely on these identity assertions.
From a classification perspective, this vulnerability aligns with CWE-284, which describes Improper Access Control, and is closely related to CWE-915, specifically the Modification of Assumed-Immutable Data such as Identity Fields. In terms of offensive security tactics, this technique maps directly to MITRE ATT&CK Tactic TA0001 (Initial Access) under the sub-technique T1078 (Valid Accounts), where attackers leverage legitimate credentials but exploit logic flaws to assume different identities or escalate privileges without needing additional exploits against underlying infrastructure. The flaw is not a failure of encryption or network security, but rather a logical error in how server-side business rules enforce data integrity and user isolation during state-changing operations.
Mitigation strategies must focus on implementing strict object mapping and validation layers within the NestJS application architecture. Developers should avoid binding incoming request bodies directly to database entities without explicit whitelisting of allowed fields. Instead, input DTOs (Data Transfer Objects) should be defined that contain only the specific properties intended for user modification, such as display name or avatar URL, while explicitly excluding immutable identifiers like userId, accountId, or role assignments from public-facing update endpoints. Additionally, implementing middleware to verify that the resource identifier in the database matches the subject ID embedded in the authentication token provides a necessary defense-in-depth layer. Regular security code reviews and automated static analysis tools configured to detect mass assignment patterns can further prevent regression of this vulnerability.