XLSX security fixes should be practical to adopt. When a familiar spreadsheet dependency raises alerts, developers need more than a warning: they need a verifiable update, a clear installation path and evidence that their existing workflows still work. That is why I started xlsx-community and published @angular-bootstrap/xlsx.
This is the story behind our independent community npm distribution, the two CVEs it addresses through upstream fixes, and the checks behind its first release candidate. The goal is to help developers and contribute constructively to the ecosystem while giving SheetJS full credit for its work.
Why XLSX security fixes became a distribution problem
Spreadsheet import and export sit inside many business applications. A library can become deeply embedded in reporting screens, administrative tools and backend jobs. Replacing it may affect far more than a single dependency entry.
At the time of this update, SheetJS installation guidance identifies its CDN as the authoritative distribution source and describes the public npm xlsx package, at version 0.18.5, as out of date. Newer upstream releases can be installed directly from official tarballs. The availability of those releases matters: an outdated npm endpoint does not mean the upstream project has stopped fixing its software.
However, teams built around npm registries and dependency approval processes can face extra adoption work. My motivation was to offer another transparent distribution path, not to claim ownership of upstream security research or describe the official CDN release as unpatched.
The two CVEs behind these XLSX security fixes
Two specific advisories shaped the initial verification work. Naming them is more useful than making a broad claim that a package is simply “secure.”
CVE-2023-30533: prototype pollution
CVE-2023-30533 concerns prototype pollution when affected SheetJS Community Edition versions read specially crafted files. The advisory identifies versions before 0.19.3 as affected. Importing untrusted workbooks is therefore an important exposure to consider; the advisory distinguishes export-only workflows.
CVE-2024-22363: regular-expression denial of service
CVE-2024-22363 affects SheetJS Community Edition versions before 0.20.2. It describes regular-expression denial of service, or ReDoS, where problematic input can consume excessive processing time.
Credit for the upstream fixes belongs to SheetJS. Our baseline, Community Edition 0.20.3, already includes those fixes. We did not discover these CVEs or create their original patches. Our contribution is an independent npm distribution, regression verification, additional handling improvements and documented maintenance controls.
From a contribution proposal to a community release
I began by preparing technical evidence and a contribution proposal for the upstream discussion. That came before treating a fork as the answer. The aim remains to help existing users and support a constructive route forward; no official endorsement or partnership is implied.
Preparing a distributable candidate involved more than renaming a package. We reviewed the source baseline, bundled license provenance, shims and mapping data. We also tested HTML hyperlink and rich-text handling changes across builds. Compatibility differences, including legacy codepage behavior, were documented instead of hidden behind a blanket drop-in replacement claim.
This distinction is central to the story: XLSX security fixes must remain traceable to real code and tests. A new package name alone does not fix a vulnerability. It can also change how scanners associate a dependency with upstream advisories, so a quieter report is not sufficient evidence.
How we verified the XLSX security fixes
We used affected-version controls alongside the candidate. A useful regression test should demonstrate the relevant problem in an affected build and then show that the candidate resists the same case. This gives more confidence than checking only a version string.
The final post-cleanup native matrix passed on Linux, Windows and macOS x64 with Node 22, 24 and 26. Its developer-security job also passed. The full local CommonJS and ESM suites each recorded 37,313 passing tests, one pending test and zero failures. The pending test is disclosed rather than counted as a pass.
Additional checks covered TypeScript compilation, Angular, React and Next.js production builds, and nine framework/browser combinations across Chrome, Firefox and WebKit. Reproducibility checks generated 12 distribution outputs identically in two clean builds. These are concrete test results, not a promise of compatibility with every workbook or application.
Install the npm release candidate
The first published version is 0.1.0-rc.1. It is a prerelease, not a stable release. Pin the explicit version when evaluating it:
npm install --save-exact @angular-bootstrap/xlsx@0.1.0-rc.1For example, a CommonJS Node.js script can create a workbook using the familiar utility APIs:
const XLSX = require("@angular-bootstrap/xlsx");
const worksheet = XLSX.utils.json_to_sheet([
{ project: "Community release", status: "Evaluation" }
]);
const workbook = XLSX.utils.book_new();
XLSX.utils.book_append_sheet(workbook, worksheet, "Status");
XLSX.writeFile(workbook, "community-release.xlsx");Projects that need to preserve a direct xlsx import can evaluate an npm alias:
{
"dependencies": {
"xlsx": "npm:@angular-bootstrap/xlsx@0.1.0-rc.1"
}
}An alias does not automatically replace every nested dependency. Review the lockfile, transitive consumers and scanner findings, then test representative files before deploying. For Angular teams, the same disciplined approach applies as in our Angular upgrade and migration guide: validate the application behavior as well as the installation.
What changed after the initial npm publication?
A later repository cleanup addressed ten known development dependency alerts involving serializer, esbuild and Vite tooling. As checked on October 24, 2026, GitHub reported zero open dependency alerts and audits of all seven final project lockfiles were clear.
Those development tools and private framework fixtures are excluded from the published npm archive. Updating them did not change the shipped parser bytes or require republishing the same version. These repository fixes should not be confused with the two upstream CVE fixes already included in the release candidate.
The GitHub prerelease now records the existing npm artifact. Its historical tag points to source commit 2c7f08a; all 69 archive files matched that commit byte-for-byte. The release includes the archive and its SHA-256 checksum. Creating the tag and release did not trigger another npm publication.
What these XLSX security fixes do not guarantee
No dependency audit can prove that every bundled parser path is vulnerability-free. A small malicious file may still cause excessive work through compressed content, declared ranges or expensive conversions. Process untrusted spreadsheets with external file-size, memory and execution-time limits, preferably in isolated workers or processes.
Timezone behavior also needs application-level testing. Explicit UTC workflows passed the tested matrix, while default local-time conversions have documented limitations. Read the repository’s security guidance and compatibility notes before adopting the candidate.
The first npm publication was an authenticated CLI bootstrap release and has no GitHub OIDC provenance attestation. The next approved npm release must use the guarded GitHub workflow and verify the actual registry attestation. A checksum, a GitHub source tag and an OIDC provenance attestation are different forms of evidence; none should be presented as another.
Help move the community release forward
The official SheetJS distribution remains a valid option. This independent package gives teams another npm path to evaluate, with explicit upstream credit, reproducible evidence and documented limits. The work is about making verified XLSX security fixes easier to adopt while taking maintenance responsibilities seriously.
If your application imports or exports spreadsheets, try the release candidate in a test environment. Compatibility reports, focused regression tests and license reviews are welcome in the community repository. Report suspected vulnerabilities privately using its security policy. Please avoid uploading customer workbooks, credentials or other confidential data in public issues.
