CVE-2026-28696 — cms
Fix: craftcms/cms@4d98a07CVE-2026-28696 is a CWE-639 vulnerability in craftcms/cms. A fix is available for craftcms/cms — see the affected versions and patch details below.
Craft affected by IDOR via GraphQL @parseRefs
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-28696.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
craftcms/cms🐘craftcms/cmsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
The GraphQL directive @parseRefs, intended to parse internal reference tags (e.g., {user:1:email}), can be abused by both authenticated users and unauthenticated guests (if a Public Schema is enabled) to access sensitive attributes of any element in the CMS. The implementation in Elements::parseRefs fails to perform authorization checks, allowing attackers to read data they are not authorized to view.
Vulnerability Details
craft\services\Elements::parseRefs identifies reference tags and resolves them using _getRefTokenReplacement. This method fetches the referenced element and accesses the specified attribute via $element->$attribute.
- Missing Auth Check: It bypasses
canView()checks. - Polymorphic Access:
getElementTypeByRefHandleallows referencing any element type (entry, asset, user, category). - Custom Field Access: Since Craft elements use
__get()to resolve custom field handles, an attacker is not limited to core attributes. They can exfiltrate any custom field data by enumerating the field handle (e.g.{entry:123:privateNotes}).
Attack Vectors
- Privilege Escalation / User Data Leak
An attacker can enumerate sensitive attributes of administrators or other users.
- Payload:
{user:1:email}or{user:1:photoId}
- Arbitrary Property Reflection & Server-Side Logic Execution
The vulnerability allows reflecting any accessible property of the underlying Element model.
- Username/Admin Enumeration:
{user:1:username}(Confirmed: returns admin), {user:1:admin}. - Internal Path Disclosure: Accessing methods that trigger errors (e.g.,
{user:1:authKey}) exposes full server stack traces in the GraphQL error response (e.g., Exception: No user session token exists with paths like/var/www/html/...).
- IDOR on Private Entries & Assets (Polymorphism)
The vulnerability is not limited to Users. Reference tags can target any element type.
- Payload:
{entry:456:myConfidentialField}(Bypasses canView checks). - Asset Path Leakage:
{volume:1:path}can expose internal file system paths.
- Unauthenticated Exploitation (Public Schema)
Confirmed locally. The @parseRefs directive is active in the Public Schema. By injecting a payload into a public-facing field (e.g., a "News" entry title), an unauthenticated guest can trigger the resolution and retrieve the sensitive output.
Steps to Reproduce
- Setup (Admin Panel):
- Create a Section (e.g., "News") and an Entry Type.
- Create a new Entry in that section. Set the Title to the payload: {user:1:username} or {user:1:email}.
- Go to GraphQL > Schemas > Public Schema. Enable it, and ensure "Query for elements in the Site" and "News" section queries are checked.
- Execute Exploit (Unauthenticated):
- Send a POST request to http://localhost:8000/index.php?action=graphql/api:
curl -X POST \
-H "Content-Type: application/json" \
-d '{"query": "{ entries { title @parseRefs } }"}'
- Observation:
- The API returns
{"data":{"entries":[{"title":"admin"}]}}(or the email). - Using
{user:1:authKey}triggers an internal server error that leaks the full server path in string format.
Impact
- Critical Information Disclosure: Full PII enumeration (emails, usernames).
- System Information Leakage: Absolute server paths via stack traces.
- Authentication Bypass: Guest accounts can effectively query the database as the system user.
Recommended Fix
Modify Elements::parseRefs to enforce canView permissions on the resolved element before extracting attributes.
References
https://github.com/craftcms/cms/commit/4d98a07e47580f1712095825d3e3c4d67bc9f8b9
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | craftcms/cms | ≥ 4.0.0-RC1&&< 4.17.0-beta.1 | 4.17.0-beta.1composer require craftcms/cms:^4.17.0-beta.1 |
| 🐘Packagist | craftcms/cms | ≥ 5.0.0-RC1&&< 5.9.0-beta.1 | 5.9.0-beta.1composer require craftcms/cms:^5.9.0-beta.1 |
Affected Products
craft cmscraftcmsDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for craftcms/cms, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update craftcms/cms to 4.17.0-beta.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-28696 is resolved across your whole dependency graph.
Workarounds
Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.
Frequently Asked Questions
Is CVE-2026-28696 in your dependencies?
Find it across Packagist, including transitive dependencies.