CVE-2025-65111

### Impact If your schema includes the following characteristics: 1. You have a permission defined in terms of a union (`+`) 1. 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

SpiceDB: LookupResources with Multiple Entrypoints across Different Definitions Can Return Incomplete Results in github.com/authzed/spicedb