Three Pimcore 2026.3.2 flaws are accessible to a PIM editor. How IDOR, Twig sandbox bypass and XSS work, and how to deploy patches within days.
Pimcore released a patch 2026.3.2 with three security fixes discussed here.
The advisories indicate that each of these three vulnerabilities requires a user already signed into administration or supplying a field value.
For a PIM used by dozens of people, we consider this scenario more likely than an external intrusion.
The release’s practical value depends on one number: how many days it takes to reach your production system.
### Someone else’s version on a schedule (GHSA-mfr4-5hr5-jqvg) Pimcore’s scheduler lets editors set a date to publish a particular document or object version.
The task stores a version ID and publishes it at the scheduled time.
According to the advisory, Pimcore did not check that the version belonged to the same element.
This is a classic IDOR, insecure direct object reference: the system retrieves an object using a supplied identifier without checking the user’s permission.
A user allowed to schedule publication for one product could supply another version ID and overwrite an arbitrary element. In a catalogue with hundreds of thousands of SKUs, the substitution might go unnoticed until a customer complaint or marketplace report. ###
A Twig sandbox allowlist bypass (GHSA-f5q9-27jc-vxm9) Twig is Pimcore’s template engine.
Its sandbox restricts the functions, filters and methods available in templates written by non-developers.
The allowlist logic accepted any name beginning with an allowed prefix.
The bypass allowed a template to read and delete arbitrary server files.
The PIM server holds database-password configurations, keys for 1C and marketplace integrations, and catalogue media. ### A link that executes code (GHSA-h78x-47qg-qjmq)
A DataObject Link field returns ready-made HTML through Data\Link::getHtml.
The href attribute and link text were rendered without escaping or sanitisation, so a javascript: link could reach the page unchanged.
This is stored XSS: an attacker enters a value once, and code runs for anyone opening the page, including fully privileged administrators.
Beyond security fixes, #19522 corrects a data-model issue: localised object-brick relations with identical field names were mixed between blocks, silently corrupting translations in multilingual catalogues.
A manufacturer’s or retailer’s PIM stores authoritative product data.
From there, data reaches the website, 1C, marketplace feeds and printed catalogues. Dozens of people use the administration panel: content managers, translators, agencies and sometimes suppliers through a portal.
Two risks therefore join the external attacker: a compromised contractor account and an employee given excessive permissions in the past.
All three vulnerabilities discussed here target this boundary.
A narrowly privileged user can change other people’s data, read server files or attack administrators through a product card.
Technically, installing the release takes one Composer command.
Yet many companies run year-old Pimcore versions, for an engineering reason.
Over time, a project accumulates its own bundles, overridden classes, custom field types and integrations. Data-model regression tests are often absent.
The team turns every update into a separate manually tested project, then postpones it until a convenient window that never arrives.
The relevant operational TTU is time from a patch release to its use in production.
By publishing the advisories, Pimcore disclosed the vulnerabilities to everyone, including potential attackers. Every unpatched day thereafter leaves an attack opportunity.
In KT.Team’s Pimcore projects, a patch reaches production through this process. - An unforked core.
Customisations live in separate bundles and event subscribers, so a core update rarely touches custom code. - Data-model tests.
Automated tests cover classes, object bricks, localisation and relations.
Automated tests catch an issue like #19522 in minutes; manual checking can easily miss it. - Static analysis with a pinned version.
Pimcore pinned Psalm 6.19.1 in CI for repeatable checks. We follow the same discipline in our projects. - Staging with a copy of production data.
We test the update against realistic catalogue volumes before rollout. - Role reviews.
We regularly review who can schedule publications, edit templates and retain contractor access. Product-description agents receive separate, narrowly scoped accounts, and their model requests pass through LLM & Security Gateway. - Integrations through a message bus.
When PIM exchanges data with 1C and marketplaces through Datareon or Apache Kafka, the integration contract is independent of the Pimcore version. An update therefore need not disrupt neighbouring systems. With that pipeline, we target one to two working days from a security release such as 2026.3.2 to production.
Three advisories in a patch release are a positive sign: Pimcore’s maintainers investigate vulnerabilities and fix them publicly. The system owner is then responsible, because a disclosed flaw remains dangerous until the update is installed. If a Pimcore update takes a month of approvals, improve operations. Start by checking your current PIM version and estimating how many days deploying 2026.3.2 will take.
Pimcore 2026.3.2 release notes on GitHub, Pimcore GmbH.
