REDHAT-BUG-2524928: Medium severity Katello vulnerability
An object-level authorization bypass in Katello's Content View Filter Rules API.
Katello::Api::V2::ContentViewFilterRulesController#findfilter (app/controllers/katello/api/v2/contentviewfilterrulescontroller.rb) loads the parent filter with ContentViewFilter.find(params[:contentviewfilterid]). That beforeaction runs for every action. The rules route is top-level and carries no content view identifier, so this lookup is the only object resolution in the request. Authorization only checks whether the user may invoke the action (viewcontentviews for read, editcontentviews for write). It does not authorize the Content View Filter supplied by the user.
The adjacent ContentViewFiltersController already resolves filters with ContentViewFilter.readable.findby(...) for reads and ContentViewFilter.editable.findby(...) for modifications. ContentViewFilter has no default organization scope; readable and editable are explicit class methods and are unused here. Katello::Model does not include Authorizable, so there is no post-save permission rollback when a rule is created or deleted.
An authenticated, low-privileged user with Content View permissions scoped to one organization can therefore read, create, update, and delete filter rules on a Content View Filter belonging to another organization by supplying that filter's identifier, even when that filter is absent from ContentViewFilter.readable and ContentViewFilter.editable.
The disclosed data is filter-rule metadata. Modifications persist in the live filter configuration used for the next Content View publish. Already-published Content View versions are snapshots and are not rewritten by this endpoint. Publish and promote remain separate permissions.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated low-privileged user with Content View permissions scoped to one organization may be able to target a Content View Filter that is outside their authorized scope. The affected authorization checks only whether the user can invoke the API action, not whether they can access the specified filter.
What access does an attacker need?
The attacker needs an authenticated account and the relevant Content View permission: view_content_views for read actions or edit_content_views for write actions. They must also supply a content_view_filter_id for a filter they are not authorized to access.
Are organization boundaries enforced by this API endpoint?
Not for the parent Content View Filter lookup described here. The controller uses an unrestricted ContentViewFilter.find call, while the explicit readable and editable scoping methods used by the adjacent controller are not used.
Which operations are affected?
The unrestricted parent-filter lookup runs as a before action for every Content View Filter Rules API action. Read operations rely on view_content_views, while write operations rely on edit_content_views, without authorizing the referenced filter itself.