Missing authorization in Metabase glossary API permits unauthorized data changes

Metabase versions before 0.63.1 fail to enforce data analyst permission checks on glossary API endpoints, allowing any authenticated user to create, modify, and delete glossary entries. Attackers can submit requests to POST, PUT, and DELETE glossary endpoints to tamper with instance-wide business glossary data without proper authorization.

• Metabase from vendor metabase: affected from 0.57.0 through versions less than 0.63.1, using semver.
• The record sets the default status to unaffected and identifies only the 0.57.0 through less than 0.63.1 range as affected.
• 0.63.1 is the release associated with the authorization fix. The status of parallel or other release branches should not be inferred unless verified separately.

Metabase is missing authorization checks in the mutation handlers under src/metabase/glossary/api.clj. The POST /api/glossary, PUT /api/glossary/:id, and DELETE /api/glossary/:id endpoints require an authenticated session but do not verify that the caller is a data analyst or administrator before performing database operations.

The create handler accepts term and definition, the update handler accepts an entry id, term, and definition, and the delete handler accepts an id. Before the fix, these handlers performed the necessary existence checks and then created, updated, or deleted records without calling api/check-data-analyst. As a result, an authenticated account without data analyst or administrator privileges can reach the mutation endpoints directly and change the instance-wide shared glossary.

The patch adds api/check-data-analyst to all three mutation handlers and adds tests to ensure that regular authenticated users are denied. The available evidence confirms a function-level authorization failure. It does not establish that the glossary read endpoint or unrelated administrative permissions can also be bypassed through this issue.

The flaw is remotely reachable through the Metabase API and requires an authenticated session. The attacker needs only low-level account access, no interaction from another user, and can send requests directly to the glossary mutation endpoints.

A public proof of concept is available, and the researcher reports validating creation, modification, and deletion with an account that was neither a superuser nor a data analyst on an affected build. The record does not identify a campaign, victim, or confirmed exploitation in the wild. The available evidence documents a reproducible PoC rather than a named real-world operation.

The flaw gives a low-privilege authenticated account unauthorized write and delete capability over the shared business glossary. The direct technical effect is modification of data within the same Metabase instance, not automatic elevation to administrator.

Organizations may need to investigate incorrect definitions, deleted entries, and decisions based on unreliable metadata. The available evidence does not establish confidentiality loss, code execution, or service unavailability. It also does not show that the flaw automatically permits access to or modification of Metabase resources outside the glossary mutation API.

• An authenticated user who is not a data analyst or administrator can change the instance-wide business glossary.
• Shared terminology can be poisoned, altered, or removed, reducing the reliability of documentation and business context used across the organization.
• Users, analysts, and data governance teams may make incorrect interpretations when they rely on glossary definitions that have been tampered with.
• The available evidence describes an integrity impact to glossary data. It does not confirm direct access to underlying analytics data, administrative control of the instance, or a direct availability impact.

1. Upgrade Metabase to 0.63.1, the release associated with the glossary authorization fix. Do not treat this as an open-ended statement about other branches unless each branch has been verified.
2. If an immediate upgrade is not possible, reduce exposure to the Metabase API and glossary functionality for accounts that do not require access, using existing access controls. This is precautionary containment, not a vendor-confirmed workaround.
3. Review glossary changes made by accounts that were not data analysts or administrators before patching, because the fix does not restore entries that were already created, modified, or deleted.
4. After upgrading, use a test account without data analyst or administrator privileges to verify that create, update, and delete operations on glossary entries are denied. The upstream patch adds tests for this authorization behavior.

1. Inventory every Metabase instance and compare its deployed version with the affected and fixed boundaries listed in affected_summary.
2. Review application, audit, or reverse proxy logs for POST requests to /api/glossary and PUT or DELETE requests to /api/glossary/:id, especially when the caller is not a data analyst or administrator. This is precautionary monitoring, not a vendor-confirmed indicator.
3. Compare glossary history and current contents for unexpected entry creation, definition changes, or deletion, and review the creator field where the deployment records it.
4. In a non-production environment, test with an authenticated account that lacks data analyst and administrator privileges and verify that all three mutation types are denied.
5. Do not treat the absence of suspicious logs or glossary changes as proof of safety. Version inventory and authorization testing are still required.