CVE-2026-46424
BaseFortify
Publication date: 2026-05-27
Last updated on: 2026-05-27
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| budibase | budibase | to 3.38.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-269 | The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in Budibase, an open-source low-code platform, prior to version 3.38.2. The issue is in the public API role unassignment endpoint, which updates user roles in the database but fails to invalidate the corresponding user cache stored in Redis. Because the authentication system relies on this cache to determine user permissions, a user whose roles have been revoked via the API can still retain those privileges for up to one hour until the cache expires.
How can this vulnerability impact me? :
The impact of this vulnerability is that users who should have lost certain privileges, such as admin, builder, or app-level roles, may continue to have those privileges for up to one hour after revocation. This could allow unauthorized access or actions within the Budibase platform during that time window.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, you should upgrade Budibase to version 3.38.2 or later, where the issue with the Redis user cache invalidation has been fixed.
Until the upgrade is applied, be aware that revoked roles may remain effective for up to one hour due to the Redis cache TTL of 3600 seconds.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows users whose roles have been revoked to retain their privileges for up to one hour due to the Redis cache not being invalidated immediately. This delay in revoking access could potentially lead to unauthorized access to sensitive data or administrative functions during that window.
Such unauthorized access, even if temporary, may impact compliance with standards and regulations like GDPR or HIPAA, which require strict access controls and timely revocation of user privileges to protect personal and sensitive information.
However, the vulnerability is rated as Moderate severity with limited impact on confidentiality and integrity, and it requires low privileges to exploit, which may somewhat mitigate the compliance risk.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves revoked user roles not being immediately reflected due to Redis cache entries not being invalidated after role unassignment via the public API. Detection involves verifying whether the Redis cache still holds outdated user role information after role revocation.
To detect this on your system, you can monitor or query the Redis cache for user role entries after performing a role unassignment through the API. If the cache still contains the old roles, the vulnerability is present.
Suggested commands include:
- Use the Budibase public API endpoint to unassign roles: POST /api/public/v1/roles/unassign
- Immediately after, connect to your Redis instance and check the cached user role entries, for example using redis-cli:
- redis-cli GET <user_role_cache_key>
- Compare the cached roles with the expected roles after unassignment.
If the cache still shows the revoked roles within the TTL period (3600 seconds), the vulnerability is active.