GHSA-9M7R-G8HG-X3VR
Vulnerability from github – Published: 2025-11-21 18:06 – Updated: 2026-05-14 20:54
VLAI
Summary
SpiceDB: LookupResources with Multiple Entrypoints across Different Definitions Can Return Incomplete Results
Details
Impact
If your schema includes the following characteristics:
- You have a permission defined in terms of a union (
+) - That union references the same relation on both sides, but one side arrows to a different permission
Then you might have missing LookupResources results when checking the permission. This only affects LookupResources; other APIs calculate permissionship correctly.
A small concrete example:
relation doer_of_things: user | group#member
permission do_the_thing = doer_of_things + doer_of_things->admin
A CheckPermission on do_the_thing will return the correct permissionship, but a LookupResources on do_the_thing may miss resources.
A Comprehensive Example
If you have a schema with a structure like this:
definition special_user {}
definition user {
relation special_user_mapping: special_user
permission special_user = special_user_mapping
}
definition group {
relation member: user
permission membership = member + member->special_user
}
definition system {
relation viewer: user | group#membership
// This is the problematic permission
permission view = viewer + viewer->special_user
}
And these relationships:
system:somesystem#viewer@group:somegroup#membership
group:somegroup#member@user:someuser1
user:someuser1#special_user_mapping@special_user:specialuser
And you call LookupResources with:
subject_type: user
subject_id: someuser1
permission: view
resource_type: system
You would expect to receive system:somesystem in the results, but you do not.
Note that this only applies to LookupResources; if you CheckPermission for that resource specifically, it will return HasPermission.
Patches
The issue is fixed in v1.47.1. Upgrading to this version will remediate this issue.
Workarounds
N/A
References
N/A
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/authzed/spicedb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.47.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-65111"
],
"database_specific": {
"cwe_ids": [
"CWE-277"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-21T18:06:00Z",
"nvd_published_at": "2025-11-21T22:16:33Z",
"severity": "LOW"
},
"details": "### Impact\n\nIf your schema includes the following characteristics:\n\n1. You have a permission defined in terms of a union (`+`)\n1. That union references the same relation on both sides, but one side arrows to a different permission\n\nThen you might have missing `LookupResources` results when checking the permission. This only affects `LookupResources`; other APIs calculate permissionship correctly.\n\nA small concrete example:\n\n```\nrelation doer_of_things: user | group#member\npermission do_the_thing = doer_of_things + doer_of_things-\u003eadmin\n```\n\nA CheckPermission on `do_the_thing` will return the correct permissionship, but a LookupResources on `do_the_thing` may miss resources.\n\n#### A Comprehensive Example\n\nIf you have a schema with a structure like this:\n\n```\ndefinition special_user {}\n\ndefinition user {\n relation special_user_mapping: special_user\n permission special_user = special_user_mapping\n}\ndefinition group {\n relation member: user\n permission membership = member + member-\u003especial_user\n}\n\ndefinition system {\n relation viewer: user | group#membership\n // This is the problematic permission\n permission view = viewer + viewer-\u003especial_user\n}\n```\n\nAnd these relationships:\n```\nsystem:somesystem#viewer@group:somegroup#membership\ngroup:somegroup#member@user:someuser1\nuser:someuser1#special_user_mapping@special_user:specialuser\n```\n\nAnd you call LookupResources with:\n```\nsubject_type: user\nsubject_id: someuser1\npermission: view\nresource_type: system\n```\n\nYou would expect to receive `system:somesystem` in the results, but you do not.\n\nNote that this only applies to `LookupResources`; if you `CheckPermission` for that resource specifically, it will return `HasPermission`.\n\n### Patches\n\nThe issue is fixed in v1.47.1. Upgrading to this version will remediate this issue.\n\n### Workarounds\nN/A\n\n### References\nN/A",
"id": "GHSA-9m7r-g8hg-x3vr",
"modified": "2026-05-14T20:54:49Z",
"published": "2025-11-21T18:06:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/authzed/spicedb/security/advisories/GHSA-9m7r-g8hg-x3vr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65111"
},
{
"type": "WEB",
"url": "https://github.com/authzed/spicedb/commit/8c2edbe1e7bd3851fa2138f4cc344bfde986dcf2"
},
{
"type": "PACKAGE",
"url": "https://github.com/authzed/spicedb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "SpiceDB: LookupResources with Multiple Entrypoints across Different Definitions Can Return Incomplete Results"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…