LinkAce — это автономный архив для сбора ссылок на веб-сайты. До версии 2.5.6 LinkAce содержала уязвимость «Небезопасная прямая ссылка на объект» на уровне политики авторизации, которая позволяла любому аутентифицированному пользователю изменять ресурсы, принадлежащие другим пользователям. Затронутые типы ресурсов — это ссылки, списки, теги и заметки.
И веб-интерфейс, и REST API уязвимы. Основная причина кроется в методах update() всех четырех политик модели: LinkPolicy, LinkListPolicy, TagPolicy и NotePolicy. Каждый делегирует метод проверки доступа (например, userCanAccessLink()), который возвращает true для любого ресурса с нечастной видимостью, независимо от того, кто им владеет.
Это означает, что любой зарегистрированный пользователь может редактировать любой общедоступный или внутренний ресурс во всем экземпляре. Методы delete() в тех же файлах политики правильно требуют владения через $link->user->is($user), что подтверждает, что обновление предназначено только для владельца. Тот же недостаток существует на уровне API через AuthorizesUserApiActions::userCanUpdateModel(), который отражает нарушенную проверку только видимости вместо проверки владения, используемой userCanDeleteModel().
Это также затрагивает операции массового редактирования через BulkEditController. Эта уязвимость исправлена в версии 2.5.6.
Показать оригинальное описание (EN)
LinkAce is a self-hosted archive to collect website links. Prior to 2.5.6, LinkAce contains an Insecure Direct Object Reference vulnerability in the authorization policy layer that allows any authenticated user to modify resources owned by other users. The affected resource types are links, lists, tags, and notes. Both the web UI and the REST API are vulnerable. The root cause is in the update() methods of all four model policies: LinkPolicy, LinkListPolicy, TagPolicy, and NotePolicy. Each delegates to an access-check method (e.g., userCanAccessLink()) that returns true for any resource with non-private visibility, regardless of who owns it. This means any registered user can edit any public or internal resource across the entire instance. The delete() methods in the same policy files correctly require ownership via $link->user->is($user), which confirms that update was intended to be owner-only. The same flaw exists in the API layer through AuthorizesUserApiActions::userCanUpdateModel(), which mirrors the broken visibility-only check instead of the ownership check used by userCanDeleteModel(). Bulk edit operations via BulkEditController are also affected. This vulnerability is fixed in 2.5.6.
Характеристики атаки
Последствия
Строка CVSS v4.0