♻️ Replace xlsx dependency with exceljs and xls-reader for spreadsheet handling

Author: sercanuste

SECURITY.md

@@ -37,50 +37,29 @@ Out of scope unless explicitly tied to this repository:
 
 ## Known Dependency Vulnerabilities
 
-The following vulnerabilities exist in transitive (indirect) dependencies and have been reviewed by the maintainers. They are tracked here for transparency. Direct/path-of-fix vulnerabilities are pinned through `overrides` in `package.json`.
-
-### GHSA-5v7r-6r5c-r473 — `file-type` (moderate) — Resolved
-
-- **Advisory**: https://github.com/advisories/GHSA-5v7r-6r5c-r473
-- **Description**: Infinite loop in ASF parser on malformed input with zero-size sub-header.
-- **Severity**: Moderate
-- **Dependency chain**: `@cognipeer/to-markdown` → `file-type`
-- **Upstream fix available**: Yes — fixed in `file-type` 21.3.1. `@cognipeer/to-markdown` (now resolved to 3.3.0) pulls in `file-type` 22.0.2, which is not affected.
-- **Impact assessment**: Was triggered only by specially crafted malformed ASF input. Worst case was a process hang (DoS); no data exfiltration or code execution path.
-- **Mitigation**: Resolved by upgrading dependencies via `npm audit fix` (no application code changes required). File uploads remain size-capped via `FILE_UPLOAD_MAX_MB` and optionally MIME-allowlisted via `FILE_UPLOAD_ALLOWED_MIME_TYPES` as defense-in-depth.
-- **Last reviewed**: 2026-08-27
-
-### `image-size` — DoS via infinite loop in ICNS/JXL/HEIF parsers (high) — Resolved (dependency replaced)
-
-- **Advisories**: https://github.com/advisories/GHSA-w3rx-r6r6-pgpr (ICNS parser), https://github.com/advisories/GHSA-5p2g-fcmc-qvqq (JXL/HEIF parsers)
-- **Severity**: High
-- **Dependency chain (historical)**: `@cognipeer/to-markdown` → `image-size`
-- **Upstream fix available**: No — `image-size` was never patched; `2.0.2` is the last version ever published to npm and both advisories report no patched version.
-- **Impact assessment**: Was triggered only by specially crafted malformed image input processed during Markdown conversion. Worst case was a process hang (DoS); no data exfiltration or code execution path.
-- **Mitigation**: Not an accepted risk — `@cognipeer/to-markdown` (bumped 3.1.0 → 3.3.0 via `npm audit fix`) dropped `image-size` entirely in favor of `image-dimensions` 2.5.1, which is unaffected by these advisories. `image-size` is no longer present anywhere in the dependency tree.
-- **Last reviewed**: 2026-08-27
-
-### `xlsx` — SheetJS prototype pollution + ReDoS (high)
-
-- **Advisories**: https://github.com/advisories/GHSA-4r6h-8v6p-xvw6 (Prototype Pollution), https://github.com/advisories/GHSA-5pgg-2g8v-p4x9 (ReDoS)
-- **Severity**: High
-- **Dependency chain**: Direct dependency of `cognipeer-console` (root `package.json` → `xlsx@^0.18.5`). Previously also reached transitively via `@cognipeer/to-markdown`, but `to-markdown` 3.3.0 replaced its own spreadsheet handling with `exceljs`; the direct root dependency is now the only installation of `xlsx` in the tree.
-- **Upstream fix available**: SheetJS Community Edition (`xlsx` on npm) is no longer published with fixes; the maintained build is on `cdn.sheetjs.com`. Migration to `exceljs` (already used elsewhere in the stack) or pinning to the CDN build is under evaluation.
-- **Impact assessment**: `xlsx` is used client-side only, to parse user-selected `.xlsx`/`.xls` files in the browser for the Evaluations dataset importer (`src/components/evaluations/datasetImport.ts`) and the Analysis conversation importer (`src/components/analysis/conversationImport.ts`). It is no longer invoked server-side via `@cognipeer/to-markdown`. Exploitation requires an authenticated user to import a maliciously crafted spreadsheet into their own browser session; blast radius is scoped to that user's own client, not the shared backend.
-- **Mitigation**: Operators concerned about malicious spreadsheet imports should advise users to only import trusted files. Migration off `xlsx` (to `exceljs`) is tracked separately.
-- **Last reviewed**: 2026-08-27
-
-### `thrift` (high) — Milvus SDK — Resolved
-
-- **Advisories**: https://github.com/advisories/GHSA-r67j-r569-jrwp (Uncontrolled Recursion), https://github.com/advisories/GHSA-526f-jxpj-jmg2 (Path Traversal / Request Splitting)
-- **Severity**: High
-- **Dependency chain**: `@zilliz/milvus2-sdk-node` → `@dsnp/parquetjs` → `thrift`
-- **Upstream fix available**: Yes — fixed in `thrift` 0.23.0 (resolves both advisories). Resolved via `npm audit fix`; `@dsnp/parquetjs` now resolves to the patched `thrift` and no longer appears in `npm audit` output.
-- **Impact assessment**: Was loaded only when reading Parquet files retrieved from Milvus. Console does not expose the Thrift HTTP server. Risk path required a malicious Parquet file returned by Milvus — only relevant when operators trusted their Milvus instance.
-- **Mitigation**: Resolved by upgrading dependencies via `npm audit fix` (no application code changes required).
-- **Last reviewed**: 2026-08-27
+The following have been reviewed by the maintainers and are tracked here for transparency. This section lists only outstanding items — accepted risks and surfaces under active monitoring. Resolved issues are removed once their fix has landed.
 
+### `xls-reader` — server-side legacy `.xls` parsing, memory-amplification DoS surface (no published advisory) — Accepted risk / monitor
+
+- **Advisories**: None published. This entry is a proactive supply-chain and robustness note, not a CVE; `xls-reader` does not appear in `npm audit` output.
+- **Severity**: Not scored (no advisory). Reviewed impact is denial of service, not remote code execution.
+- **Dependency chain**: `@cognipeer/to-markdown@3.3.0` → `xls-reader@^0.7.0` (resolved 0.7.0). Also declared directly in the root `package.json`, so it is both a direct and a transitive dependency.
+- **Upstream fix available**: N/A — no advisory to fix. `0.7.0` is the current latest.
+- **Impact assessment**: Server-side spreadsheet parsing was **transferred** from `xlsx` to `exceljs` + `xls-reader`, not eliminated. `@cognipeer/to-markdown` is invoked server-side from the crawler (`src/lib/services/crawler/engine/markdown.ts`, on content the crawler downloads from remote URLs), from RAG ingestion (`src/lib/services/rag/ragService.ts`), and from file uploads (`src/lib/services/files/fileService.ts`). Within `to-markdown`, the spreadsheet converter dispatches on the **buffer's OLE2/CFB magic bytes** (`d0 cf 11 e0 a1 b1 1a e1`), explicitly so that mislabelled files are still handled — therefore a file advertised as an OOXML spreadsheet, but whose bytes are a compound-binary blob, is routed to `xls-reader`. The residual concern found by source review is in `readChainBytes`, which allocates `new Uint8Array(chain.length * sectorSize)` sized by the sector chain rather than by the declared stream size. `followChain` and the DIFAT walk in `collectFatSectorIds` are both cycle-guarded by a `seen` set, but the collected **FAT sector ids are not de-duplicated**, so a crafted header can inflate the FAT and hence the chain length, driving an allocation disproportionate to the input file size. Worst case is memory exhaustion / process termination (DoS); there is no code-execution or data-exfiltration path, and the parser has no network or filesystem access.
+- **Mitigation**: Accepted and monitored rather than resolved, on the balance that `xls-reader` has **zero runtime dependencies**, is MIT licensed, and ships verified npm provenance (SLSA v1 attestation, Rekor `logIndex` 2208344690), and that a full read of its compound-file implementation found no memory-unsafe or injection-style pattern. Countervailing factors are that it is pre-1.0 (`0.7.0`, published 2026-07-20, 10 releases since 2026-07-06) with a single maintainer (`zanlucathiago`), so it carries normal early-stage supply-chain risk. Uploads remain size-capped via `FILE_UPLOAD_MAX_MB`, which bounds but does not eliminate the amplification. **Note that `FILE_UPLOAD_ALLOWED_MIME_TYPES` is not an effective control here**, because dispatch is by content signature rather than by MIME type or extension; operators who need to exclude legacy `.xls` handling must do so upstream of conversion. Operators running the crawler against untrusted origins should treat spreadsheet conversion as untrusted-input processing and constrain worker memory accordingly.
+- **Pre-existing status**: This surface exists on `main` today via `@cognipeer/to-markdown@3.3.0`. It is documented here because server-side spreadsheet parsing was **transferred** from `xlsx` to `exceljs` + `xls-reader` rather than eliminated — removing the `xlsx` package from this repository did not remove server-side spreadsheet handling.
+- **Last reviewed**: 2026-08-28
+
+### `vitepress` → `vite` → `esbuild` — development-only toolchain advisories (high / moderate) — Accepted risk
+
+- **Advisories**: https://github.com/advisories/GHSA-4w7w-66w2-5vf9 (`vite` — path traversal in optimized deps `.map` handling), https://github.com/advisories/GHSA-fx2h-pf6j-xcff (`vite` — `server.fs.deny` bypass on Windows alternate paths), https://github.com/advisories/GHSA-v6wh-96g9-6wx3 (`launch-editor` — NTLMv2 hash disclosure via UNC path handling on Windows), https://github.com/advisories/GHSA-67mh-4wv8-2f99 (`esbuild` — development server accepts cross-origin requests)
+- **Severity**: High (`vite`), Moderate (`esbuild`, `vitepress`)
+- **Dependency chain**: A single root — `vitepress@1.6.4`, a direct **devDependency** used only by the `docs:dev` / `docs:build` / `docs:preview` scripts. It pins `vite@^5.4.14` (resolved `5.4.21`), which in turn pins `esbuild@^0.21.3` (resolved `0.21.5`). Every advisory above enters through that one chain. The other copies in the tree are **not** affected and must not be conflated with it: `vite@6.4.3` (used by `vitest` and `@vitejs/plugin-react`) is outside the `<= 6.4.2` range, `vite/node_modules/esbuild@0.25.12` is outside both esbuild ranges, and `tsx/node_modules/esbuild@0.28.2` is likewise clean.
+- **Upstream fix available**: Patched releases exist (`vite` 6.4.3, `esbuild` 0.25.0) but are **unreachable from this tree**, which is a different situation from "no fix has been published". `vitepress@1.6.4` is the latest published release and still declares `vite@^5.4.14`, so the patched Vite 6.x cannot be resolved without overriding VitePress's own peer expectations, or dropping/replacing VitePress. `npm audit` reports `fixAvailable: false` for exactly this reason. An `overrides` entry was considered and rejected: forcing Vite 6.x under a VitePress release built against Vite 5.x risks breaking the docs build for a defect with no production exposure.
+- **Impact assessment**: Accepted. These are `devDependencies` and none of them are present in, or reachable from, the production runtime — the shipped application is built by Next.js and served by Fastify, neither of which loads Vite, VitePress, or esbuild's dev server. Every listed advisory requires an attacker to reach a locally running development server, and two of the four are Windows-only. There is no exposure in deployed environments; the residual risk is limited to a developer running the docs site while visiting a hostile page on the same machine.
+- **Mitigation**: Do not expose the VitePress or Vite dev servers beyond `localhost`. Revisit if a VitePress release adopts a patched Vite 6.x. **Caveat on the release gate**: `npm audit --omit=dev` is the audit used for releases, but it is not a complete model of the production dependency set — `tsx` is declared in `devDependencies` yet is loaded by the production `start` script (`node --import tsx src/server/index.ts`), so packages reachable only through `tsx` are excluded from that audit despite executing in production. `tsx` and its `esbuild` are currently clean, so this is a scope gap rather than an active exposure, but the classification should be corrected before it is relied on again.
+- **Last reviewed**: 2026-08-28
 
 ## Safe Harbor
 
-If you act in good faith, avoid data destruction, avoid privacy violations, and do not disrupt service availability, the project will treat your research as authorized for the purpose of coordinated disclosure.
+If you act in good faith, avoid data destruction, avoid privacy violations, and do not disrupt service availability, the project will treat your research as authorized for the purpose of coordinated disclosure.