GHSA-h6cx-gjxx-v25c: Composer/sulu/sulu vulnerability

Published Sep 2, 2026
·
Updated

Impact

A media move authorization bypass (IDOR) lets a backend user move a media out of a collection they have no access to.

The media move endpoint resolves its permission check from the collection value in the request rather than from the media's real collection. MediaManager::move() then reassigns the media without re-checking its actual source collection. A user who has edit rights on collection A but no rights on a restricted collection B can move a media that lives in B by naming A in the request. The move succeeds, the media ends up in A, and the user can then view and download content they were never allowed to see.

This only affects installations that use per-collection (object level) permissions to restrict some collections. Exploitation requires an authenticated backend user with edit rights on at least one collection, and knowledge of the target media id.

Patches

Fixed in 2.6.25 and 3.0.8. MediaManager::move() now verifies edit permission on the media's real source collection and on the destination collection before moving it.

Workarounds

If you cannot upgrade immediately:

- Restrict the media edit permission to trusted users, so untrusted users cannot trigger a move. - Apply the fix manually by adding an edit permission check on the media's real source collection (and the destination) inside MediaManager::move().

Affected Software

2 affected componentsFixes available
composer/sulu/sulu>=3.0.0-alpha1<3.0.8
3.0.8
composer/sulu/sulu<=2.6.24
2.6.25

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade composer/sulu/sulu to a version that resolves this vulnerability.

    Fixed in 3.0.8
  2. Upgrade

    Upgrade composer/sulu/sulu to a version that resolves this vulnerability.

    Fixed in 2.6.25
  3. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 2.6.25
  4. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 3.0.8
  5. Configuration

    Apply the fix manually by adding an edit permission check on the media's real source collection (and the destination) inside `MediaManager::move()` so the authorization is resolved from the media's actual collection rather than the `collection` value in the request.

    MediaManager::move() media move endpoint Permission check source collection = Use media's real source collection and destination collection rather than the request's collection value
  6. Compensating control

    Restrict media edit permission to trusted users so untrusted users cannot trigger a move authorization bypass.

Event History

Sep 2, 2026
Advisory Published
via GitHub·02:57 PM
Data Sourced
via GitHub·02:57 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are exposed to this issue?

Only installations that use per-collection, object-level permissions to restrict access to some collections are affected. The issue enables movement of media from a restricted collection into one the attacker can access.

2

What does an attacker need to exploit it?

The attacker needs an authenticated backend account with edit rights on at least one collection and knowledge of the target media ID. They do not need permission on the collection where the target media actually resides.

3

Which releases contain the fix?

The issue is fixed in versions 2.6.25 and 3.0.8. The corrected move operation checks edit permission on both the media's real source collection and the destination collection.

4

What can be done if an upgrade is not immediately possible?

Restrict media edit permission to trusted users. This reduces the number of backend users able to use the affected move endpoint.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203