Pimcore 2026.3.2: три дыры, которые открывает свой же редактор

Pimcore выпустил патч-релиз 2026.3.2 с тремя исправлениями безопасности.

Судя по advisory, каждую из трёх уязвимостей запускает пользователь, который уже вошёл в админку или заполнил поле в карточке.

Для PIM, где доступ есть у десятков людей, такой сценарий, по нашей оценке, вероятнее внешнего взлома.

Поэтому пользу релиза определяет одна величина: сколько дней пройдёт, пока он попадёт на ваш прод.

### Чужая версия по расписанию (GHSA-mfr4-5hr5-jqvg) В Pimcore есть планировщик: редактор назначает дату, когда опубликуется конкретная версия документа или объекта.

Задача хранит ID версии и в назначенный момент публикует её.

Как сказано в advisory, Pimcore не проверял, что версия принадлежит тому же элементу.

Это классический IDOR (insecure direct object reference): система берёт объект по присланному идентификатору и не проверяет, имеет ли пользователь на него права.

Пользователь с правом планировать публикации у одного товара мог подставить чужой ID и перезаписать произвольный элемент. В каталоге на сотни тысяч SKU такую подмену, скорее всего, заметят только после жалобы покупателя или отчёта маркетплейса. ###

Песочница Twig с дырой в allowlist (GHSA-f5q9-27jc-vxm9) Twig - шаблонизатор Pimcore.

Его sandbox ограничивает набор функций, фильтров и методов в шаблонах, которые пишет не разработчик.

Ошибка была в логике списка разрешений: правило пропускало любое имя, которое начиналось с разрешённого префикса.

Через этот обход шаблон мог читать и удалять произвольные файлы на сервере.

На сервере PIM лежат конфиги с паролями к базе, ключи интеграций с 1С и маркетплейсами и медиафайлы каталога. ### Ссылка, которая исполняет код (GHSA-h78x-47qg-qjmq)

Поле типа Link в DataObject отдаёт готовый HTML через `Data\Link::getHtml`.

Атрибут `href` и текст ссылки выводились без экранирования и очистки, поэтому ссылка вида `javascript:` попадала в страницу без изменений.

Это хранимый XSS: злоумышленник вводит значение один раз, и код выполняется у любого, кто откроет страницу, в том числе у администраторов с полными правами.

Помимо безопасности, релиз исправляет баг в модели данных (#19522): локализованные связи в object bricks с одинаковыми именами полей смешивались между блоками. В мультиязычном каталоге этот баг незаметно портит переводы.

У производителя или ритейлера PIM хранит эталонные данные о товаре.

Оттуда данные уходят на сайт, в 1С, в фиды маркетплейсов и в печатные каталоги. В админку заходят десятки людей: контент-менеджеры, переводчики, агентства, иногда поставщики через портал.

Поэтому к внешнему злоумышленнику добавляются ещё два источника риска: украденная учётка подрядчика и сотрудник, которому когда-то выдали права шире нужного.

Все три уязвимости этого релиза бьют именно сюда.

Человек с узкой ролью может менять чужие данные, читать файлы сервера или атаковать администраторов через карточку товара.

Технически релиз ставится одной командой composer.

Но многие компании держат Pimcore на версии годичной давности, и у этого есть инженерная причина.

За годы проект обрастает своими бандлами, переопределёнными классами, кастомными типами полей и интеграциями. Регресс-тестов на модель данных, как правило, нет.

Команда превращает каждое обновление в отдельный проект с ручной проверкой и откладывает его до удобного окна, которое так и не наступает.

Здесь важен TTU в эксплуатации - время от выхода патча до работы на проде.

Опубликовав GHSA, Pimcore раскрыл механику уязвимостей всем, включая тех, кто захочет ими воспользоваться. С этого дня каждый день без обновления - открытое окно для атаки.

На проектах Pimcore в KT.Team путь патча до прода устроен так. - Ядро без форка.

Доработки живут в отдельных бандлах и подписках на события, поэтому обновление ядра почти не задевает кастомный код. - Тесты на модель данных.

Автотесты проверяют классы, object bricks, локализации и связи.

Баг вроде #19522 автотест ловит за минуты, а при ручной проверке его легко пропустить. - Статический анализ с закреплённой версией.

Разработчики Pimcore в этом релизе закрепили в CI Psalm 6.19.1, чтобы проверка давала одинаковый результат при каждом прогоне. В своих проектах мы держим ту же дисциплину. - Стейдж на копии прод-данных.

Обновление проверяем на реальных объёмах каталога до выката. - Ревизия ролей.

Регулярно пересматриваем, кто планирует публикации, кто редактирует шаблоны и у каких подрядчиков ещё остался доступ. AI-агенты, которые генерируют описания товаров, получают отдельные учётки с узкими правами, а их запросы к моделям идут через LLM & Security Gateway. - Интеграции через шину.

Когда PIM отдаёт данные в 1С и маркетплейсы через Datareon или Apache Kafka, контракт интеграции не зависит от версии Pimcore, и обновление не ломает соседние системы. С таким конвейером мы ставим цель для security-релиза вроде 2026.3.2: один-два рабочих дня от публикации до прода.