GHSA-2mxr-89gf-rc4v is a medium-severity (CVSS 6.8) CWE-285 vulnerability in com.yahoo.elide:elide-core. O3 Security confirms whether GHSA-2mxr-89gf-rc4v is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Read permissions not enforced for client provided filter expressions in Elide.
Real-World Exposure
com.yahoo.elide:elide-coreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Impact
It is possible for an adversary to "guess and check" the value of a model field they do not have access to assuming they can read at least one other field in the model. The adversary can construct filter expressions for an inaccessible field to filter a collection. The presence or absence of models in the returned collection can be used to reconstruct the value of the inaccessible field.
For example, a User model has two fields: name and role. The adversary has read permissions to see the name field of the User collection but not the role. By constructing a filter like the one below, the adversary can determine which users have admin role by presence or absence in the returned collection:
filter=role=="Admin"
Patches
Resolved in Elide 4.5.14 and greater.
Workarounds
The adversary can only access the fields if a model includes fields with different read permission levels (some less secure and some more secure). Model security can be adjusted by restricting read permissions on existing models.
References
Fixed in https://github.com/yahoo/elide/pull/1236
For more information
If you have any questions or comments about this advisory:
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | com.yahoo.elide:elide-core | all versions | 4.5.14 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for com.yahoo.elide:elide-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 com.yahoo.elide:elide-core to 4.5.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2mxr-89gf-rc4v 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-2mxr-89gf-rc4v 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-2mxr-89gf-rc4v. 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-2mxr-89gf-rc4v in your dependencies?
O3 detects GHSA-2mxr-89gf-rc4v across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.