dot-access EUVD-2026-95146

Exploitation requires a consuming application to pass attacker-controlled input as the path argument to dot-access get() in versions 0.0.3 through 1.0.0; the flaw is in how that path is concatenated into a dynamically constructed Function body. There is no special library configuration toggle - the library is vulnerable by design in this range - but the practical limiting factor is reachability: if the application never exposes get()'s path to untrusted data, the vulnerability is not triggerable. No authentication or user interaction is imposed by the library itself (PR:N/UI:N), so wherever untrusted input reaches get(), exploitation is remote and unauthenticated.

All severity signals point the same direction: the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N with VC:H/VI:H/VA:H, score 9.3) describes remote, low-complexity, unauthenticated code injection yielding full confidentiality, integrity, and availability loss - consistent with CWE-94 and the described path-to-new-Function concatenation reaching constructor.constructor to load child_process for OS command execution. No EPSS score, no CISA KEV listing, and no explicit POC flag were supplied in the input; however, one reference is a public gist (R3tro16) that strongly suggests proof-of-concept exploit code exists, so this should be treated as 'publicly available exploit code exists' rather than confirmed active exploitation - the two are distinct and KEV is absent. The decisive risk modifier is NOT severity but reachability: dot-access is a tiny, obscure npm library, and exploitation only matters where a consuming application feeds attacker-controlled input into get()'s path argument. Net assessment: technically a critical RCE primitive, but real-world priority is tempered by very low deployment footprint and the requirement that a downstream app expose the vulnerable call to untrusted data. EPSS is missing, so widespread-exploitation probability cannot be quantified from the input.

An application uses dot-access get() to resolve object paths from user-supplied input (e.g., a query parameter or JSON body field). An attacker submits a crafted path string that breaks out of the intended property lookup and is concatenated into a dynamically built Function body, pivoting through constructor.constructor to require('child_process') and run OS commands. A public gist reference indicates proof-of-concept code is likely available, lowering the effort to reproduce.