CVE-2023-46943 is a critical flaw in the @evershop/evershop npm package, scored 9.1. The HMAC secret used to sign tokens was hardcoded as the word secret, so tokens are predictable. Versions before 1.0.0-rc.8 are affected. Upgrade to 1.0.0-rc.8 or later and treat tokens issued by older versions as untrusted.
What's affected
The NVD record says @evershop/evershop before 1.0.0-rc.8 uses a hardcoded HMAC secret, the string secret, for generating tokens. Because the secret is public knowledge in a sense, anyone who knows it can create valid JSON Web Tokens, which the record says gives access to important information and actions in the application.
As with the related EverShop issue CVE-2023-46942, the CPE list in the record names the 1.0.0 beta builds, while the description covers all versions before rc.8. Treat everything earlier than rc.8 as affected.
The fix is 1.0.0-rc.8 or later. The advisory I could read states the affected range and does not describe how the new version sources its secret, so check the release notes for the version you adopt.
The NVD record was published on 2024-01-13, scores 9.1 (Critical), and carries the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Weakness class: CWE-798.
How to check if you're exposed
Confirm your installed version, then check how your deployment configures token signing.
npm ls @evershop/evershop
npm view @evershop/evershop version
Search your configuration and environment for any signing secret you set yourself, and make sure it is a long random value kept in a secret store. If your site ran an affected build on the public internet, assume tokens signed with the default secret could have been created by others.
What to do now
- Upgrade @evershop/evershop to 1.0.0-rc.8 or later and redeploy.
- Rotate any signing secret or session key, which invalidates tokens minted under the old value.
- Review admin accounts, recent admin actions and API activity for anything you do not recognize.
- Store secrets outside the repository and rotate them on a schedule.
- Scan your repositories for other constants that look like keys or secrets.
Why it matters
Hardcoded credentials are CWE-798. A signing secret only protects tokens if it is secret and unpredictable. When it ships inside the package, every installation shares the same key and anyone can read it.
This is a different failure from a bug in code logic. Patching removes the default, but it does not undo trust already granted, which is why rotation belongs in the response. The record's KEV flag is false, so this CVE is not on the CISA Known Exploited Vulnerabilities list.
Secrets that sit in source or defaults are a common supply chain problem, and they are easy to miss in a code review.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why rotate secrets after upgrading?
Tokens signed with the old known secret stay valid until the secret changes. Rotation is what ends that trust.
Sources
Last reviewed: 19 October 2026.
