CVE-2023-30533

What it actually does

The flaw is a prototype pollution vulnerability in SheetJS Community Edition versions before 0.19.3, reachable when the library parses a specially crafted spreadsheet or related input file. Malicious workbook content can cause attacker-controlled properties to be written onto JavaScript object prototypes rather than only onto intended data objects. Once polluted, those inherited properties may influence later application logic that trusts ordinary object properties, potentially causing data corruption, authorization bypasses, denial of service, or, in applications with dangerous prototype-pollution gadgets, code execution. The listed downstream package manugarg/pacparser is reported fixed at commit 0bf0636de624996fe202b51eec8a58abd774269e where applicable.

Why it matters to the business

Systems that accept or process spreadsheet files with vulnerable SheetJS code may be exposed to malicious document-based attacks. A successful attack can compromise the integrity of parsed data, disrupt processing jobs, or potentially expose sensitive information depending on how the application uses parsed workbook data. The vulnerability has a high CVSS score but low EPSS, is not listed in CISA KEV, has no reported ransomware association, and has no known mature public exploitation signal in the provided data; however, it is old enough that vulnerable dependencies should be treated as overdue technical debt and remediated during normal patch cycles or sooner for externally exposed file-upload workflows.

How an attack unfolds

An attacker first identifies an application, CLI workflow, automation job, or service that processes user-supplied spreadsheet files using a vulnerable SheetJS Community Edition release. The attacker creates a workbook containing property names or nested structures that target prototype-related keys. When the vulnerable parser reads the file, the malicious keys are merged or assigned into JavaScript objects in a way that modifies shared object prototypes. Subsequent code running in the same process may then observe attacker-injected inherited properties and make incorrect decisions, crash, leak data, or invoke unsafe behavior if the application contains a compatible gadget. User interaction is typically required in the sense that a user or automated workflow must open, import, upload, or process the crafted file.

How to fix it

Upgrade SheetJS Community Edition to 0.19.3 or later wherever it is directly used or vendored. If using the listed manugarg/pacparser Git dependency, update to a version including commit 0bf0636de624996fe202b51eec8a58abd774269e or later. Regenerate lockfiles and container images after upgrading, and verify that no transitive or bundled copies of vulnerable SheetJS remain. As defense in depth, validate uploaded spreadsheet content, restrict accepted file types and sizes, process untrusted documents in a sandboxed worker with minimal privileges, avoid unsafe deep-merge patterns, and use safe object creation patterns such as Object.create(null) for untrusted key/value data where practical.

How to confirm the fix worked

Confirm remediation by checking package manifests, lockfiles, SBOMs, and built artifacts for SheetJS Community Edition versions earlier than 0.19.3 and for downstream packages that bundle vulnerable code. For Git-based manugarg/pacparser deployments, verify the deployed source includes commit 0bf0636de624996fe202b51eec8a58abd774269e or a later commit. Run dependency scanning against source repositories and built images. Exercise file-import functionality with regression tests that include benign prototype-like field names and verify they do not alter Object.prototype or shared application objects. In Node.js applications, add a unit or integration test that parses representative files and then asserts that unexpected properties were not introduced on Object.prototype.

Typical attack path

1. Find an application or processing pipeline that accepts spreadsheet files or other SheetJS-supported workbook formats.
2. Confirm or infer that the application uses SheetJS Community Edition 0.19.2 or earlier, or a downstream package bundling vulnerable code.
3. Craft a spreadsheet containing prototype-pollution-oriented property names and object structures.
4. Deliver the file through an upload form, email attachment, shared document workflow, batch import directory, or other ingestion path.
5. Trigger parsing of the malicious file by the vulnerable library.
6. Rely on polluted JavaScript object prototypes to alter downstream application behavior, cause denial of service, corrupt data, or reach an application-specific gadget with higher impact.

How to detect it

Review application, web, API gateway, file-upload, email gateway, EDR, and batch-processing logs for suspicious spreadsheet ingestion events, especially uploads shortly followed by parser exceptions, process crashes, authorization anomalies, unexplained data changes, or unusual child-process activity from document-processing services. Hunt for uploaded or quarantined spreadsheet files containing prototype-pollution-oriented strings such as __proto__, constructor, and prototype in XML workbook parts, shared strings, CSV headers, JSON-like cells, or extracted archive contents. In Node.js environments, inspect runtime error logs for messages related to immutable prototypes, recursive object conversion, maximum call stack errors, or unexpected properties during workbook parsing. If suspicious files are found, analyze them offline in an isolated environment and compare application behavior before and after parsing. Since no specific public exploitation campaign or stable network signature is provided, detection should focus on malicious document artifacts and abnormal post-import application behavior rather than a single definitive IOC.

• __proto__
• constructor.prototype
• prototype.constructor
• constructor
• prototype
• Object.prototype
• Cannot set property __proto__
• Maximum call stack size exceeded
• RangeError: Maximum call stack size exceeded
• TypeError: Cannot set property
• TypeError: Cannot assign to read only property
• xlsx@0.19.2
• xlsx@0.19.1
• xlsx@0.19.0
• xlsx@0.18.
• xlsx@0.17.
• sheetjs

What your security team should do

• Inventory services, batch jobs, desktop tooling, and server-side import workflows that process spreadsheet files with SheetJS or downstream packages bundling it.
• Prioritize remediation for internet-facing upload endpoints, email/document ingestion systems, and privileged automation jobs that parse untrusted files.
• Upgrade SheetJS Community Edition to 0.19.3 or later and update manugarg/pacparser to a build containing commit 0bf0636de624996fe202b51eec8a58abd774269e where applicable.
• Search repositories, lockfiles, vendored JavaScript bundles, and container images for vulnerable SheetJS versions because bundled client-side or server-side copies may be missed by package-manager-only scanning.
• Add file-processing isolation controls: run parsers in low-privilege sandboxes, apply resource limits, and avoid sharing long-lived process state across untrusted document parses.
• Review recent file-upload and document-import telemetry for files containing prototype-pollution key names, unexplained parser failures, and unusual application behavior after spreadsheet ingestion.
• Because this is not in KEV and has low EPSS in the provided data, treat it as a high-severity dependency remediation item rather than an emergency internet-wide exploitation event unless local exposure is high.