Summary
Tandoor Recipes contains a cache-key design flaw that can preserve a user's higher group-based permissions when they switch between spaces. An authenticated user who receives administrative access in one space may retain stale authorization decisions in another space, potentially bypassing intended permission restrictions and revocations.
Tandoor Recipes contains a cache-key design flaw that can preserve a user's higher group-based permissions when they switch between spaces. An authenticated user who receives administrative access in one space may retain stale authorization decisions in another space, potentially bypassing intended permission restrictions and revocations.
Affected context
The vulnerability affects Tandoor Recipes deployments that use space-specific group permissions with the affected permission cache behavior. The cache key identifies entries by user but does not include the active space, while the cache lifetime can be refreshed by subsequent requests. The issue becomes risky when a user has different group memberships or privilege levels across spaces.
The vulnerability affects Tandoor Recipes deployments that use space-specific group permissions with the affected permission cache behavior. The cache key identifies entries by user but does not include the active space, while the cache lifetime can be refreshed by subsequent requests. The issue becomes risky when a user has different group memberships or privilege levels across spaces.
Exploit preconditions
- Attack surface: Authenticated application views and permission checks involving multiple spaces
- Required access: A valid user account with the ability to create or access a space and switch the active space
- Trigger point: Permission evaluation and caching while moving between spaces
- Why exploitation is possible: Cached authorization results are associated with the user identity but not the active space, allowing a decision from one context to be reused in another
- Attack surface: Authenticated application views and permission checks involving multiple spaces
- Required access: A valid user account with the ability to create or access a space and switch the active space
- Trigger point: Permission evaluation and caching while moving between spaces
- Why exploitation is possible: Cached authorization results are associated with the user identity but not the active space, allowing a decision from one context to be reused in another
Why this happens
The underlying bug is an authorization cache-key design error. A permission decision that depends on both the user and the active space is cached using only the user identifier, so the result is not isolated between authorization contexts. Refreshing the time-to-live on each request can extend the lifetime of the incorrect decision. This maps to CWE-863: Incorrect Authorization, because the application may grant access based on a stale or contextually invalid permission result.
The underlying bug is an authorization cache-key design error. A permission decision that depends on both the user and the active space is cached using only the user identifier, so the result is not isolated between authorization contexts. Refreshing the time-to-live on each request can extend the lifetime of the incorrect decision. This maps to CWE-863: Incorrect Authorization, because the application may grant access based on a stale or contextually invalid permission result.
Potential impact
- An authenticated user may retain administrative permissions after switching spaces
- Access checks may be bypassed in spaces where the user has fewer privileges
- Group revocations, demotions, or membership changes may not take effect promptly
- Protected data or management functions may be exposed within affected spaces
- Unauthorized changes could be made through views using the stale permission decision
- An authenticated user may retain administrative permissions after switching spaces
- Access checks may be bypassed in spaces where the user has fewer privileges
- Group revocations, demotions, or membership changes may not take effect promptly
- Protected data or management functions may be exposed within affected spaces
- Unauthorized changes could be made through views using the stale permission decision
General mitigation guidance
Mitigation generally focuses on preserving authorization context throughout permission evaluation and caching.
Common defensive patterns include:
- Include every authorization-relevant dimension, including the active space, in cache keys
- Avoid caching authorization decisions when the context cannot be represented reliably
- Invalidate or recompute cached permissions after group, role, membership, or space changes
- Apply secure-by-default denial when authorization context is missing or ambiguous
- Enforce authorization independently at each sensitive view or operation
- Limit administrative capabilities according to least privilege
- Treat client-selected active-space values as untrusted and resolve them against server-side membership data
Mitigation generally focuses on preserving authorization context throughout permission evaluation and caching.
Common defensive patterns include:
- Include every authorization-relevant dimension, including the active space, in cache keys
- Avoid caching authorization decisions when the context cannot be represented reliably
- Invalidate or recompute cached permissions after group, role, membership, or space changes
- Apply secure-by-default denial when authorization context is missing or ambiguous
- Enforce authorization independently at each sensitive view or operation
- Limit administrative capabilities according to least privilege
- Treat client-selected active-space values as untrusted and resolve them against server-side membership data
How teams detect issues like this
Organizations can assess this class of issue through:
- Static analysis and code review of permission-cache key construction
- Searches for cached authorization results keyed only by user, session, or token identifiers
- Tests that switch users between spaces, tenants, projects, or organizations with different roles
- Regression tests covering role changes, revocations, demotions, and cache expiration behavior
- Monitoring for access to administrative views that is inconsistent with current group membership
- Policy checks requiring authorization caches to encode all relevant resource and tenant context
Automated security review tools may help identify cache usage and authorization checks that lack context-bound identifiers.
Organizations can assess this class of issue through:
- Static analysis and code review of permission-cache key construction
- Searches for cached authorization results keyed only by user, session, or token identifiers
- Tests that switch users between spaces, tenants, projects, or organizations with different roles
- Regression tests covering role changes, revocations, demotions, and cache expiration behavior
- Monitoring for access to administrative views that is inconsistent with current group membership
- Policy checks requiring authorization caches to encode all relevant resource and tenant context
Automated security review tools may help identify cache usage and authorization checks that lack context-bound identifiers.
