fix(core): Refuse default superadmin credentials in production

[grolmus]

Summary

Vendure ships with the well-known defaults superadmin / superadmin for the initial admin user and has no built-in guard against running with them in production. This is a hard-coded-credentials issue (CWE-798): anyone with network access to a vanilla 3.6.x deployment can log in as superadmin if the operator did not override authOptions.superadminCredentials.

This PR adds a bootstrap-time check that:

• Refuses to start the server when NODE_ENV === 'production' and either the identifier or the password matches the default constants from @vendure/common.
• Logs a prominent Logger.warn with remediation hints in development / staging / any other non-test environment.
• Stays silent in NODE_ENV === 'test' so the existing e2e suite (which uses the defaults by design) keeps a clean output.

The remediation hint points operators at wiring superadminCredentials from environment variables, which is the same pattern most starters already use.

Scope

• No schema migration, no public API change.
• The well-known constants in @vendure/common are kept as-is — they are still exported because plugins and the e2e/testing layer rely on them.
• A more invasive follow-up (auto-generated random password on first init, forced password change on first login) is intentionally left for a future minor / major change. This PR is the minimum-blast-radius patch that closes the critical concern.

Changes

• New helper packages/core/src/service/helpers/utils/check-superadmin-credentials.ts containing the pure check (testable, no DI).
• AdministratorService.ensureSuperAdminExists now calls the helper before creating / reconciling the superadmin user.
• 7 new unit tests in the paired spec file covering production / development / staging / test / safe-credentials paths.

Test plan

• vitest run service/helpers/utils/check-superadmin-credentials.spec.ts — 7/7 pass
• Full @vendure/core unit suite (vitest run) — 819/819 pass; no existing tests regressed
• Manual smoke: boot dev server with default config (NODE_ENV unset) → expect a single Logger.warn line about default credentials, server starts normally
• Manual smoke: boot with NODE_ENV=production and default config → expect bootstrap to throw [Vendure] Refusing to start: Default superadmin credentials are configured…
• Manual smoke: boot with NODE_ENV=production and explicit override → silent, server starts normally

Notes

• Reported privately via responsible disclosure (internal Linear OSS-490 — Pratik Karan, 2026-04-03). No public GitHub issue exists.
• The check matches if either identifier or password equals the default. Strict logic ("only when both match") would let superadmin / weak-but-not-default through, which still keeps a well-known username paired with a weak password — same exploit class.

---

^{Need help on this PR? Tag @codesmith with what you need.}

• Let Codesmith autofix CI failures and bot reviews

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
vendure-storybook	Ready	Preview, Comment	May 11, 2026 1:46pm

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: e672447c-b013-474d-9929-3fc4275d8787

📥 Commits

Reviewing files that changed from the base of the PR and between 563e6b3 and e4eaad6.

📒 Files selected for processing (3)

• packages/core/src/service/helpers/utils/check-superadmin-credentials.spec.ts
• packages/core/src/service/helpers/utils/check-superadmin-credentials.ts
• packages/core/src/service/services/administrator.service.ts

---

📝 Walkthrough

Walkthrough

This pull request adds a security validation utility to detect and prevent usage of well-known default superadmin credentials at application bootstrap. The utility function checkSuperadminCredentials compares provided identifier and password against shipped defaults, then either throws an error in production (halting startup), logs a warning in development/staging, or remains silent in test environments. The check is integrated into AdministratorService.ensureSuperAdminExists() and includes remediation guidance to configure credentials via authOptions.superadminCredentials. A comprehensive test suite validates the environment-specific behavior across all code paths.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding a production-time guard against default superadmin credentials.
Description check	✅ Passed	The description covers all template sections with comprehensive details: summary explains the security issue, breaking changes are addressed, and the checklist shows completed work including tests.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}