Prototype Pollution in scim-patch Library via Unfiltered PATCH Operations

Vulnerability Description:

The scim-patch library fails to sanitize keys in the value object during SCIM PATCH operations. When a malicious PATCH request contains a key structured as __proto__.someProp, the library's recursive merge/patch logic treats this as a legitimate object path and modifies Object.prototype directly. This is a prototype pollution vulnerability (CWE-1321) with process-wide scope—any subsequent object created or checked against a plain object will inherit the polluted properties. The root cause is insufficient input validation on object keys before mutation.

PoC Significance:

The PoC is significant because it demonstrates that any SCIM-compliant endpoint accepting PATCH operations from external Identity Providers (IdPs) becomes an exploitation vector with minimal privilege requirements. The attack surface is broad: most organizations provision users via SCIM with low authentication barriers. The PoC proves the pollution is reliable and deterministic—a single malicious PATCH operation permanently taints the runtime for all subsequent code execution.

Detection Guidance:

Monitor for SCIM PATCH requests containing JSON payloads with __proto__, constructor, or prototype keys in nested objects. Log all incoming PATCH bodies at the application layer; flag any with these signature strings. Search application logs for property access patterns against user/auth objects that should fail but succeed (e.g., unexpected .isAdmin, .admin, or .role properties appearing on objects that never defined them). Monitor process-level anomalies: if legitimate code suddenly behaves differently when checking object properties, prototype pollution may have occurred. YARA rule pattern: detect __proto__.*: or prototype.*: in JSON payloads to SCIM endpoints.

Mitigation Steps:

1. Immediate: Upgrade scim-patch to a patched version > 0.9.0 once released.
2. Workaround: Implement a JSON schema validator that explicitly forbids keys matching /__proto__/, /constructor/, or /prototype/ at any depth before calling scimPatch().
3. Defense-in-depth: Use Object.freeze() on critical prototype properties (isAdmin, role, permissions) in auth/middleware code to prevent polluted values from overriding them.
4. Runtime isolation: Consider running SCIM provisioning in a separate Node worker/process with restricted access to sensitive code paths.
5. Input validation: Whitelist allowed PATCH operation keys rather than blacklisting; reject any operation that modifies unexpected object properties.

Risk Assessment:

Likelihood of exploitation is very high in the wild because: (1) SCIM is standard for enterprise identity provisioning, (2) most implementations accept IdP input with minimal vetting, (3) the attack requires no special privileges beyond authenticated SCIM client access, and (4) the PoC is simple to execute. Threat actors targeting SaaS platforms with federated identity will prioritize this. The ability to gain privilege escalation (by polluting .isAdmin or .permissions) or bypass authorization logic makes this attractive for post-compromise lateral movement or initial access if the SCIM endpoint is exposed.