chore: Fix critical security vulnerabilities#1349
Conversation
- Upgraded @nestjs/config to version 4.0.3 - Downgraded minio to version 7.0.26 - Added uuid package at version 11.0.3 - Updated @typescript-eslint/eslint-plugin and parser to version 8.56.0 - Upgraded eslint to version 10.0.0 - Updated various other dependencies to their latest compatible versions
|
What: minio@^8.0.0 depends on a vulnerable fast-xml-parser (DoS / entity encoding). npm audit reports it as critical. |
…dency - Introduced a new ESLint configuration file for TypeScript projects, specifying parser options, globals, and rules. - Updated minio dependency to version ^8.0.0 in package.json.
- Upgraded minio dependency to version ^8.0.0 in api package-lock.json. - Added luminary-shared package with its dependencies and devDependencies in cms package-lock.json. - Updated versions of several packages in cms package-lock.json, including brace-expansion and minimatch.
…rules - Simplified error handling in multiple catch blocks by removing error variable and using empty catch. - Updated ESLint rule for no-require-imports in validateMongoQuery.ts. - Added a placeholder comment in socketio.ts for clarity.
| docType == DocType.Content | ||
| ? // Include both Post and Tag doc types permission checks for content deletions | ||
| permissionCheckTypes.push(DocType.Post, DocType.Tag) | ||
| : permissionCheckTypes.push(docType as DocType); |
2 participants
ulnerabilities that were fixed
Critical – fast-xml-parser (minio)
Issue: DoS and entity-encoding bypass in the version of fast-xml-parser used by minio@^8.0.0.
Action: Downgraded minio from ^8.0.0 to 7.0.26. That version does not depend on the vulnerable fast-xml-parser range.
Reason: No overrides allowed, and minio 8.x does not yet ship a patched fast-xml-parser. Downgrading was the only way to clear the critical finding without overrides. validated that S3/MinIO behavior (uploads, storage status, error handling) still works with 7.0.26.
Moderate – lodash prototype pollution (@nestjs/config)
Issue: @nestjs/config@^3.1.1 depended on a vulnerable lodash (e.g. _.unset / _.omit).
Action: Upgraded @nestjs/config from ^3.1.1 to ^4.0.3, which uses a patched lodash.
Reason: Direct upgrade path; v4 has different config semantics (e.g. read order), so config usage was checked after the upgrade.
High – minimatch / glob ReDoS (ESLint tooling)
Issue: ESLint and @typescript-eslint at ^6 depended on vulnerable minimatch/glob (ReDoS in pattern matching).
Action: Upgraded eslint to ^10.0.0 and @typescript-eslint/eslint-plugin and @typescript-eslint/parser to ^8.56.0, which pull in patched minimatch/glob.
Reason: These are dev-only (linting). Upgrading them fixes the vulnerability in the lint toolchain without changing production runtime.
Build fix – uuid
Action: Added uuid as a direct dependency (^11.0.3) and kept it after the other changes.
Reason: The app imports uuid in several places; it was previously satisfied transitively and disappeared after dependency updates. Making it explicit restores the build and avoids future breakage from transitive changes.
Why remaining high and moderate findings are acceptable
After the above changes, npm audit can still report high and moderate issues. They are acceptable for these reasons:
@nestjs/platform-fastify / fastify / @fastify/middie (high)
What: Path bypass, DoS (unbounded memory), body validation bypass.
Why it’s acceptable: The fix is to move to Nest 11 (and thus newer fastify/middie). That’s a major framework upgrade with migration effort and regression risk. Staying on Nest 10 is a conscious trade-off.
Mitigation: Don’t rely on path-string middleware for security-critical checks; document that this stack is on Nest 10 and accept the risk until you plan a Nest 11 migration.
ajv (moderate, ReDoS)
What: ReDoS when using the $data option in JSON Schema.
Why it’s acceptable: The vulnerable ajv lives under @nestjs/cli and @nestjs/schematics (code generation / dev tooling). It is not in the production runtime.
Mitigation: Dev-only exposure; no user-facing or production impact. Acceptable to leave as-is until a future CLI/schematics upgrade updates the dependency.
Other minimatch/glob (high) in Jest and related dev deps
What: ReDoS in file-pattern matching used by Jest and other dev tools.
Why it’s acceptable: Again dev-only (tests, config resolution). Not used in production.
Mitigation: Fixing would require upgrading or replacing Jest and related packages, which can break tests and config. Acceptable to accept this risk in the dev pipeline.