CVE-2026-33228

What it actually does

The vulnerable flatted parse() implementation can treat attacker-controlled string values as JavaScript Array indexes without confirming they are numeric references. When the supplied reference key is "__proto__", JavaScript resolves it through the array prototype chain and returns Array.prototype. That live prototype object can then be attached to the parsed output. If application code later writes to that parsed property, it can modify Array.prototype globally within the Node.js process, causing prototype pollution. Depending on how polluted properties are used by the application or dependencies, this may lead to data corruption, security control bypass, denial of service, unexpected logic execution, or, in some application patterns, code execution.

Why it matters to the business

Applications that parse untrusted flatted-encoded data may be vulnerable to process-wide JavaScript behavior changes. A successful attack can destabilize services, corrupt business logic, bypass assumptions in authorization or validation code, and create difficult-to-trace failures across requests handled by the same process. Although this issue is not currently listed in CISA KEV, has no reported ransomware association, and has a low EPSS score, its CVSS severity is critical because exploitation is network-reachable, requires no authentication or user interaction, and can affect confidentiality, integrity, and availability in exposed applications.

How an attack unfolds

An attacker first identifies an endpoint, API, webhook, message consumer, or file-ingestion workflow that accepts data serialized with the flatted format and passes it to flatted.parse(). The attacker submits a crafted payload containing a reference value such as "__proto__" where the parser expects an internal numeric array index. In vulnerable versions before 3.4.2, the parser uses that string as an array key and receives Array.prototype through JavaScript prototype inheritance. The parsed object can then contain a property referencing the live global array prototype. If downstream application code mutates that property, merges it, assigns fields to it, or otherwise treats it as a normal object, the mutation changes Array.prototype for the process. Subsequent application logic using arrays may then observe attacker-influenced inherited properties or behavior, enabling application-specific impact such as authorization bypass, tampering with processed data, crashes, or execution through polluted callback/configuration paths.

How to fix it

Upgrade webreflection flatted to version 3.4.2 or later everywhere it is used, including transitive dependency paths. Regenerate and commit lockfiles after the upgrade, then rebuild and redeploy affected artifacts. For npm, use package-manager controls such as overrides; for Yarn, use resolutions; for pnpm, use overrides, where necessary to force transitive consumers to a safe version. Treat all flatted-encoded data from clients, partners, queues, webhooks, files, and caches as untrusted. As defense in depth, reject parser reference values that are not numeric where numeric references are expected, reject dangerous keys such as "__proto__", "prototype", and "constructor" in untrusted structured input where feasible, and avoid mutating parsed objects before validation. Do not rely on WAF signatures alone, because payload shape can vary by transport and encoding.

How to confirm the fix worked

Confirm dependency exposure with commands such as npm ls flatted, yarn why flatted, pnpm why flatted, and by searching package-lock.json, yarn.lock, pnpm-lock.yaml, bundled node_modules, container images, and SBOMs for flatted versions below 3.4.2. Validate the deployed runtime, not only source repositories, because vulnerable copies may be bundled into build artifacts. Add a regression test that passes a malicious flatted payload containing a "__proto__" reference into flatted.parse() and verifies the result does not expose Array.prototype and that Array.prototype gains no new properties. After patching, verify production artifacts resolve flatted to 3.4.2 or later and run application smoke tests focused on JSON/flatted ingestion paths.

Typical attack path

1. Find an internet-facing or internally reachable service that accepts flatted-serialized input from an untrusted source.
2. Confirm the service or one of its dependencies uses webreflection flatted before version 3.4.2 to parse that input.
3. Send a crafted flatted payload containing a non-numeric reference key such as "__proto__" where a parser reference is expected.
4. Cause the vulnerable parser to attach a live reference to Array.prototype into the parsed output object.
5. Trigger downstream code that writes, merges, or assigns data to the attacker-influenced parsed property.
6. Leverage the resulting Array.prototype pollution to alter application behavior, cause denial of service, corrupt data processing, or reach an application-specific privilege or code-execution path.

How to detect it

To determine whether exploitation already occurred, examine logs and artifacts from systems that parse flatted-encoded data. Useful sources include HTTP access logs, API gateway logs, WAF logs, reverse proxy logs, application request logs, webhook payload archives, message queue dead-letter payloads, file-ingestion records, and error/exception telemetry. Search for submitted payloads containing "__proto__" in data fields handled by flatted.parse(), especially near serialized array/reference structures. Also search for signs of prototype pollution at runtime: unexpected enumerable or custom properties appearing on Array.prototype, unusual array behavior across unrelated requests, sudden TypeError exceptions in array-processing code, serialization anomalies, authorization or validation decisions changing unexpectedly, and crashes following malformed structured-input submissions. Because this vulnerability may not leave a unique network signature and exploitation impact is application-specific, combine payload searches with forensic review of application logs around suspicious requests, process restarts, and anomalous errors. If threat hunting finds suspicious payloads, preserve raw request bodies or queue messages, correlate them to process logs and user/session/IP metadata, and inspect whether any unexpected Array.prototype properties existed during or after handling those inputs.

• "__proto__"
• '__proto__'
• \"__proto__\"
• %22__proto__%22
• __proto__
• Array.prototype
• flatted.parse
• node_modules/flatted
• node_modules/flatted/cjs/index.js
• node_modules/flatted/esm/index.js
• package-lock.json:flatted
• yarn.lock:flatted
• pnpm-lock.yaml:flatted
• "flatted"
• "version": "3.4.1"
• "version": "3.4.0"
• "version": "3.3.
• "version": "3.2.
• "version": "3.1.
• "version": "3.0.

What your security team should do

• Prioritize inventory of all services, serverless functions, workers, CLIs, and build artifacts that include webreflection flatted, especially those that parse externally supplied data.
• Upgrade or override flatted to 3.4.2 or later and redeploy affected applications.
• Focus first on internet-facing APIs, webhook receivers, message-ingestion services, file importers, and any service that deserializes client-controlled flatted payloads.
• Search historical HTTP, API gateway, WAF, application, queue, and file-processing logs for suspicious flatted payloads containing "__proto__" in reference-like positions.
• Review application code paths that write to, merge, clone, or enrich objects returned by flatted.parse(), because exploitation generally requires a downstream mutation to convert the leaked prototype reference into pollution.
• Add automated dependency scanning and CI policy checks that fail builds when flatted versions below 3.4.2 are present.
• Add runtime or test instrumentation to detect unexpected additions to Array.prototype in Node.js processes that parse untrusted structured data.