CVE-2026-25993 is a critical SQL injection (CVSS 9.8) in EverShop, the TypeScript e-commerce platform. A category url_key stored in the database is later pasted into SQL during update and delete handling. Upgrade to EverShop 2.1.1 or later. The record does not list it in CISA's KEV catalog, and the advisory we read does not report exploitation.
What's affected
- EverShop (the @evershop/evershop package) before 2.1.1
- Patched from 2.1.1
The advisory lists no workaround. It does not say how an attacker would get a malicious value into url_key, so do not assume the path requires an account. The CVSS vector in the record says no privileges are needed.
How to check if you're exposed
If EverShop is a dependency of your store project, ask npm:
npm ls @evershop/evershop
Compare the result with 2.1.1. Check each environment, since staging and production often drift. Then look at your data: category url_key values should look like URL slugs. Anything with quotes, semicolons or SQL keywords deserves a look, and removing it is safe on a store you control.
Safeguard has a free in-browser dependency scan at https://gold.safeguard.sh/scan that reads a manifest or lockfile and flags known vulnerable packages, with no repository access needed.
What to do now
- Upgrade EverShop to 2.1.1 or later and redeploy.
- Query category records for url_key values that are not plain slugs, and clean them up.
- Check who and what can edit categories, including admin accounts and import jobs, and remove access that is not needed.
- Run the database account used by the store with the least privileges it needs, so a future injection has less to reach.
- Re-scan the project after the upgrade to confirm the finding is gone.
Why it matters
This is second-order SQL injection, class CWE-89. The dangerous input is not used when it arrives. It is stored first, looks like ordinary data, and becomes dangerous later when another code path builds a statement from it by string concatenation. The advisory says category update and delete event handling embeds path and request_path values, which come from url_key, straight into SQL passed to execute().
Second-order flaws get past input filters that only look at the request in front of them. The fix pattern is the same as for first-order cases: use parameterized queries everywhere, including for values that came out of your own database. Treating stored data as trusted is the mistake.
The 9.8 score reflects network reach, no privileges and full impact on confidentiality, integrity and availability of the database.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
If I validate url_key on input, am I safe?
Not by itself. Older rows, imports and other writers can still hold bad values, and the unsafe SQL building is in the code. Upgrade as well.
Does the advisory say this is exploited?
The advisory we read does not, and the record's KEV flag is false.
Sources
Last reviewed: 19 October 2026.
