CVE-2026-61834 in scim-patch
Summary
by MITRE • 09/23/2026
scim-patch is a library for applying SCIM patch operations. Prior to 0.9.2, navigate() reads inherited properties and assign() uses prototype-chain membership checks while resolving attacker-controlled SCIM PATCH paths. A path or one of the dotted value keys beginning with an inherited property such as toString can therefore traverse into a shared built-in function object and add attacker-controlled properties, causing process-global mutation that may affect application logic reading inherited-method properties. This issue is fixed in version 0.9.2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The scim-patch library serves as a utility for processing System for Cross-domain Identity Management patch operations, which are commonly used to update user attributes and group memberships within identity management systems. Prior to the release of version 0.9.2, this library contained a critical prototype pollution vulnerability stemming from how it resolved nested object paths during the application of patches. The core technical flaw lies in the interaction between the navigate function, which traverses object structures based on provided path strings, and the assign function, which determines property existence using standard JavaScript prototype-chain membership checks rather than strict own-property verification methods such as Object.prototype.hasOwnProperty or Reflect.has. This architectural choice allows an attacker to manipulate the traversal logic by supplying a SCIM PATCH request with a carefully crafted path that targets inherited properties from the base Object prototype.
When an attacker submits a patch operation specifying a dotted value key that begins with an inherited property, such as toString, constructor, or _proto_, the library fails to distinguish between own properties and those inherited through the prototype chain. Consequently, instead of treating these keys as invalid paths within the target user object, the traversal logic proceeds into the shared built-in function objects associated with the Object prototype. This behavior enables the addition of attacker-controlled properties directly onto the global Object.prototype or other shared constructor prototypes. Because JavaScript objects inherit from their constructors' prototypes, this action results in process-global mutation rather than isolated instance-level modification. Any subsequent code within the same Node.js process that reads inherited-method properties or iterates over object keys will encounter these maliciously injected attributes, leading to unpredictable behavior and potential logic bypasses.
The operational impact of this vulnerability is severe due to its scope affecting the entire application runtime environment. By polluting the global prototype chain, an attacker can inject arbitrary data into every new object created within the process or modify existing objects that rely on standard inheritance patterns. This can lead to information disclosure if sensitive properties are exposed through iteration methods like for...in loops. Furthermore, it poses a significant risk of denial-of-service conditions by corrupting internal application state or causing unhandled exceptions when code expects specific property types but receives attacker-controlled values such as functions or complex objects instead of expected primitives. In identity management contexts, this could potentially allow an unauthorized user to impersonate another user if the authentication logic relies on checking properties that have been polluted with malicious data from a previous request processed by the same worker thread.
To mitigate this vulnerability and prevent prototype pollution attacks in similar implementations, developers must ensure that all path resolution mechanisms strictly validate property existence against own properties only. This can be achieved by replacing standard membership checks like prop in obj or obj.hasOwnProperty(prop) without proper context with safer alternatives such as Object.prototype.hasOwnProperty.call(obj, prop) or using libraries specifically designed to handle deep object merging safely while guarding against prototype pollution. Additionally, input validation should reject any path segments that correspond to known dangerous inherited properties of the base prototypes before they are processed by traversal logic. Upgrading to scim-patch version 0.9.2 or later is essential for applications relying on this library, as it addresses these flaws by implementing stricter checks during property resolution. From a defensive perspective, organizations should also consider deploying runtime application self-protection tools that can detect and block attempts to modify prototype chains dynamically. This vulnerability aligns with CWE-1321: Prototype Pollution in the Common Weakness Enumeration database and maps to ATT&CK technique T1559.004: Dynamic Linker Hijacking, although more accurately it represents a form of state manipulation akin to T1608: Install Rootkit which involves modifying system-level structures for persistent influence over application behavior.