GHSA-6mhr-52mv-6v6f is a critical-severity (CVSS 9.1) CWE-285 vulnerability in @keystone-6/core. 1 public exploit reference exists, so weaponization risk is real. O3 Security confirms whether GHSA-6mhr-52mv-6v6f is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Field-level access-control bypass for multiselect field
Real-World Exposure
@keystone-6/coreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Impact
@keystone-6/[email protected] || 2.3.0 users who are using the multiselect field, and provided field-level access control - are vulnerable to their field-level access control not being used.
List-level access control is NOT affected.
Field-level access control for fields other than multiselect are NOT affected.
Example, you are vulnerable if you are using field-level access control on a multiselect like the following:
const yourList = list({
access: {
// this is list-level access control, this is NOT impacted
},
fields: {
yourFieldName: multiselect({
// this is field-level access control, for multiselect fields
// this is vulnerable
access: {
create: ({ session }) => session?.data.isAdmin,
update: ({ session }) => session?.data.isAdmin,
},
options: [
{ value: 'apples', label: 'Apples' },
{ value: 'oranges', label: 'Oranges' },
],
// ...
}),
// ...
},
// ...
});
Mitigation
Please upgrade to @keystone-6/core >= 2.3.1, where this vulnerability has been closed.
Workarounds
If for some reason you cannot upgrade your dependencies, you should stop using the multiselect field.
Credits
Thanks to Marek R for reporting and submitting the pull request to fix this problem.
If you have any questions around this security advisory, please don't hesitate to contact us at [email protected], or open an issue on GitHub.
If you have a security flaw to report for any software in this repository, please see our SECURITY policy.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @keystone-6/core | ≥ 2.2.0&&< 2.3.1 | 2.3.1 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @keystone-6/core. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @keystone-6/core to 2.3.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6mhr-52mv-6v6f is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-6mhr-52mv-6v6f is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-6mhr-52mv-6v6f. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-6mhr-52mv-6v6f in your dependencies?
O3 detects GHSA-6mhr-52mv-6v6f across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.