CVE-2023-0842

What it actually does

xml2js 0.4.23 and affected downstream consumers can allow prototype pollution when untrusted input is converted into JavaScript objects without rejecting dangerous property names such as __proto__. An unauthenticated remote attacker can supply crafted input that causes new properties to be added to Object.prototype or otherwise alters object inheritance behavior. The direct rated impact is low integrity impact, but consequences depend heavily on how the application uses parsed objects afterward; in vulnerable application logic this can lead to authorization bypass, configuration tampering, unsafe defaults being enabled, data corruption, or as a secondary step in more severe exploit chains.

Why it matters to the business

Applications that parse attacker-controlled XML or JSON-like data with the vulnerable xml2js code may make incorrect trust, permission, routing, or configuration decisions. This can result in unauthorized changes to application behavior, inaccurate records, or exposure to follow-on compromise if polluted properties influence security-sensitive logic. The issue is not listed in CISA KEV and has a low EPSS score, but public exploit knowledge exists and the flaw has been public since April 2023, so internet-facing or API-exposed services should still be remediated as part of normal vulnerability management.

How an attack unfolds

An attacker first identifies an endpoint or integration that accepts XML or structured input that is parsed by xml2js 0.4.23 or an affected downstream component such as vulnerable revisions of Nextcloud Contacts. The attacker submits a crafted payload containing a dangerous key, most notably __proto__, or equivalent encoded forms intended to survive transport and parsing. When the application parses the input and merges or trusts the resulting object, the malicious key can modify inherited properties on JavaScript objects. The attacker then triggers application code paths that read those inherited properties, potentially changing authorization checks, feature flags, validation outcomes, or other business logic. Successful exploitation usually requires that the parsed object be used in a sensitive way after parsing; the parser flaw alone does not automatically imply code execution.

How to fix it

Upgrade affected code to a fixed version. For leonidas-from-xiv/node-xml2js, use a revision containing commit cf3e061e22e98152b88068c2345bc02581f4d6c7 or a later maintained release that includes the fix. For nextcloud/contacts, use a revision containing commit d8168c7a407953b48ab3a44512eee5e1a9c5f008 or a later maintained release. If package-manager versions are used, ensure xml2js is not pinned to 0.4.23 and refresh lockfiles so transitive dependencies resolve to a patched version. As defense in depth, reject or sanitize keys named __proto__, prototype, and constructor in all attacker-controlled structured input before parsing or merging; avoid unsafe deep-merge behavior; create dictionaries with Object.create(null) where appropriate; and enforce schema validation that denies unknown fields. Where immediate upgrade is not possible, restrict access to affected parsing endpoints, add WAF/API-gateway rules for prototype-pollution keys, and disable nonessential import or synchronization paths that process untrusted XML.

How to confirm the fix worked

Confirm that dependency inventory, SBOMs, package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls, or equivalent build artifacts no longer show xml2js version 0.4.23 in deployed applications. Verify source or deployed artifacts include the fixed commits for the listed Git-based products where applicable. Exercise regression tests with payloads containing __proto__, constructor.prototype, and nested prototype-pollution keys and confirm they are rejected, ignored, or treated as inert data rather than modifying Object.prototype. In a safe test environment, parse a malicious sample and verify that expressions such as {}.polluted remain undefined after parsing and merge operations. Also confirm that WAF/API validation controls log and block encoded variants of prototype-pollution keys on exposed endpoints.

Typical attack path

1. Identify an application endpoint, import feature, synchronization interface, API, or file-processing workflow that accepts attacker-controlled XML or structured data.
2. Confirm the application or dependency tree uses vulnerable xml2js 0.4.23 or an affected downstream revision.
3. Send crafted input containing __proto__ or related prototype-pollution keys, potentially URL-encoded, Unicode-escaped, or embedded as XML element or attribute names.
4. Cause the application to parse the malicious input and create or merge the resulting JavaScript object.
5. Trigger subsequent application logic that reads inherited properties from objects affected by the polluted prototype.
6. Abuse the changed behavior to alter data integrity, bypass validation, influence authorization or configuration decisions, or support a broader exploit chain.

How to detect it

Look for evidence in HTTP access logs, API gateway logs, WAF events, reverse proxy logs, application request logs, XML import or synchronization logs, file-upload audit logs, and Node.js application error logs. Focus on requests to endpoints that accept XML, contact imports, synchronization payloads, webhooks, uploaded files, or structured request bodies. Search for dangerous property names in raw request bodies, query strings, multipart filenames, XML element names, XML attribute names, and encoded payloads. Useful signs include __proto__, constructor.prototype, constructor[prototype], Unicode-escaped underscore sequences, and URL-encoded equivalents. Review application logs after suspicious requests for unexpected changes in validation behavior, authorization decisions, feature flags, object defaults, or errors such as type confusion, unexpected inherited properties, or serialization anomalies. If telemetry allows, compare request timestamps with changes to application records or configuration modified by the same session, IP address, API token, or unauthenticated client. Because prototype pollution may leave little persistent host-level evidence, absence of filesystem or process artifacts does not rule out exploitation; request-level logging and business-object audit trails are the highest-value sources.

• __proto__
• %5F%5Fproto%5F%5F
• %5f%5fproto%5f%5f
• \u005f\u005fproto\u005f\u005f
• <__proto__>
• </__proto__>
• "__proto__"
• '__proto__'
• constructor.prototype
• constructor[prototype]
• constructor%5Bprototype%5D
• constructor%2Eprototype
• [constructor][prototype]
• prototype][polluted]
• __defineGetter__
• __defineSetter__
• Object.prototype
• polluted=true
• "polluted":true
• <constructor>
• <prototype>

What your security team should do

• Prioritize inventory of Node.js services, Nextcloud Contacts deployments, import features, API endpoints, and background integrations that parse untrusted XML or structured data.
• Upgrade xml2js and affected downstream components to fixed revisions, specifically node-xml2js commit cf3e061e22e98152b88068c2345bc02581f4d6c7 or later and nextcloud/contacts commit d8168c7a407953b48ab3a44512eee5e1a9c5f008 or later where those Git sources are used.
• Regenerate and redeploy lockfiles and container images to remove vulnerable transitive copies of xml2js 0.4.23.
• Add schema validation and deny-list controls for __proto__, constructor, and prototype keys on all externally supplied structured input, not only endpoints known to use xml2js.
• Search historical API, web, WAF, and application logs for prototype-pollution payloads, especially on XML import, contact sync, webhook, and file-upload routes.
• Add detection rules for encoded and escaped variants of __proto__ and constructor.prototype in request bodies, query strings, headers, and uploaded XML files.
• Review application code for unsafe object merges, recursive merge utilities, use of inherited properties in authorization or validation checks, and missing Object.hasOwn/Object.prototype.hasOwnProperty checks.
• Treat confirmed exploitation as an integrity incident: identify objects, records, settings, sessions, or permissions processed during the suspicious request window and validate they were not altered unexpectedly.