CVE-2026-38567: Pimcore Datahub SVG upload stored XSS
CVE-2026-38567 is a high-severity Pimcore Datahub vulnerability tied to unsafe handling of uploaded SVG files. Based on the public description, the practical impact is stored XSS: a malicious SVG can execute attacker-controlled JavaScript in a victim’s browser when it is rendered. For defenders, this should be treated as a browser-context code execution issue rather than confirmed server-side RCE.
If you manage Pimcore environments, review your broader hardening baseline alongside this issue, especially media handling and admin workflow exposure. Related guidance may help in our internal resources on pimcore security hardening and how to detect stored xss in admin panels.
Vulnerability at a glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-38567 |
| CVSS | 7.2 HIGH |
| Attack vector | Network (AV:N) |
| Authentication required | Yes |
| Privileges required | High |
| Patch status | Yes, a fixing commit is referenced; exact released fixed version was not confirmed from retrieved sources |
What this vulnerability is
CVE-2026-38567 affects Pimcore Datahub and appears to stem from insufficient validation or sanitization of uploaded SVG content. SVG files are XML-based and can contain active elements such as scripts, event handlers, and embedded objects. If the application stores and later renders attacker-supplied SVG without proper controls, that file can become a stored cross-site scripting payload.
That distinction matters operationally. Some advisories use broad language like “code execution,” but the currently available technical details align more closely with stored JavaScript execution in the browser than with server-side remote code execution. In practice, a privileged authenticated user could upload a malicious SVG, and a later viewer could trigger JavaScript execution simply by loading the affected asset in the application interface.
This is especially important in administrative workflows. If the victim is an admin, operator, or integration user with broad permissions, successful exploitation may lead to:
- session theft
- unauthorized actions performed as the victim
- configuration changes
- data exposure
- pivoting deeper into the application
The supplied research notes map the weakness to CWE-617, but defenders should focus on the practical risk: unsafe SVG handling can become stored browser-side code execution.
Who is affected
The product identified in the available material is Pimcore Datahub. That is clear from the advisory trail and reference set.
What is not clearly confirmed from the retrieved materials is the full affected version range. No exact vulnerable versions were reliably established for this article, so teams should avoid assuming only old builds are exposed. If your deployment uses Datahub workflows that accept and render SVG files, it is reasonable to treat it as potentially affected until validated.
A fix commit has been publicly referenced:
2f8e0d1cb40ff4a01745193ed429d3191fdaab43
However, the first released package version containing that fix was not confirmed from the source set used here. You should verify your deployed version against upstream release notes, repository history, or vendor guidance before marking the issue resolved.
Organizations should prioritize investigation if they allow authenticated, high-privilege users to upload, manage, or render SVG assets through Datahub.
CVSS score and severity context
The published severity is CVSS v3.1 7.2 (High) with this vector:
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Key points:
AV:N: exploitable over the networkAC:L: low attack complexityPR:H: requires high privilegesUI:N: scored as not requiring separate user interactionC:H/I:H/A:H: high potential impact
The privilege requirement is the biggest limiting factor. This is not an unauthenticated internet-scale bug. But in environments where privileged users regularly upload and view content, stored XSS can still become serious very quickly.
The UI:N component deserves practical interpretation. Even if the scoring model treats the condition as not requiring extra user interaction, real exploitation still depends on the malicious SVG being rendered in a browser context. For defenders, the meaningful takeaway is that a trusted application workflow can trigger the payload during normal use.
Exploitation status
Based on the retrieved materials used for this article:
- no public in-the-wild exploitation was confirmed
- no public proof-of-concept was confirmed
- the issue is associated with ZDI-CAN-26592
That does not prove no exploit exists elsewhere. It only means exploitation status could not be verified from the source set reviewed here. Internal reporting should use careful language: this issue appears exploitable and important to remediate, but there is no confirmed public PoC or active exploitation in the available references.
How to detect potential abuse
Start with the simplest signal: SVG uploads by high-privilege users. Review application logs, audit records, reverse proxy logs, and storage metadata for .svg uploads tied to admin or elevated accounts.
Inspect stored SVG assets for active content that should not appear in ordinary business graphics. Useful indicators include:
<script>tags- event handlers like
onload=,onclick=, oronbegin= <foreignObject>javascript:URIs- external resource references
- obfuscated XML structures or unusual namespaces
A quick local scan can help identify suspicious content:
grep -RinE '<script|onload=|onclick=|foreignObject|javascript:' /path/to/uploaded/assets --include='*.svg'
Also look for timeline correlation:
- a privileged account uploads an SVG
- another privileged user views the related content
- unexpected state-changing requests follow
If you collect browser or web security telemetry, review:
- CSP violation reports
- EDR browser events
- secure web gateway logs
- repeated requests to uploaded
.svgassets followed by authenticated admin actions
Because the exact vulnerable rendering path was not fully documented in the retrieved sources, validate behavior in a test environment before making assumptions. Upload a harmless test SVG and observe whether Pimcore sanitizes it, rasterizes it, serves it with restrictive headers, or renders it directly.
Mitigation and patching
The primary remediation is to apply the upstream fix associated with commit:
2f8e0d1cb40ff4a01745193ed429d3191fdaab43
Because the exact fixed release version was not confirmed from the available sources, the safest guidance is:
Upgrade to the first Pimcore Datahub release that includes commit 2f8e0d1cb40ff4a01745193ed429d3191fdaab43.
Before closing remediation, confirm that version mapping through official release notes, package tags, changelogs, or vendor advisory material.
If you cannot patch immediately, use temporary controls:
Disable SVG uploads
If business requirements allow it, remove .svg from accepted upload types and permit only non-active formats like PNG or JPEG.
Rasterize uploaded SVG files
If SVG is operationally necessary, convert uploaded SVG assets to raster images such as PNG before serving them back to users.
Block direct delivery of user-supplied SVGs
At the web server, reverse proxy, or application layer, prevent direct rendering of untrusted SVG files until patching is complete.
Quarantine existing SVG uploads
If operationally safe, isolate previously uploaded SVG files pending review:
find /path/to/uploaded/assets -type f -name '*.svg' -print -exec mv {} /path/to/quarantine/ \;
Test carefully before doing this in production, as it may break content workflows.
Reduce upload permissions
Because exploitation requires high privileges, reducing the number of users who can upload or manage media is a meaningful short-term control.
A strong password manager can also help reduce follow-on account abuse risk if you are responding to suspected admin-session compromise. If your team is standardizing credentials after an incident, Try 1Password → can be useful for securing shared and privileged access. Likewise, if responders need safer remote access while investigating admin interfaces from untrusted networks, Check NordVPN pricing → may be relevant, but neither product mitigates the underlying vulnerability itself.
Practical response checklist
Use this as a fast triage list:
- identify whether Pimcore Datahub is deployed
- determine whether SVG upload and rendering are enabled
- review who has permission to upload SVG content
- inspect existing uploaded SVG assets for active content
- patch to a release containing the referenced fix commit
- disable or restrict SVG handling until verification is complete
- review logs for suspicious admin-linked SVG activity
- reset or protect sensitive sessions if compromise is suspected
If you suspect browser-based compromise from uploaded files, consider running endpoint and browser checks on affected admin workstations. For teams that want an endpoint-focused follow-up after incident review, Get Malwarebytes → may be useful as part of broader workstation hygiene, though it should be treated as a supplementary tool, not a direct fix.
References
The following references are the best starting points for validation and patch tracking:
- NVD entry for CVE-2026-38567
- GitHub Security Advisory: https://github.com/pimcore/data-hub/security/advisories/GHSA-9qmp-jq3x-wx8v
- Fix commit: https://github.com/pimcore/data-hub/commit/2f8e0d1cb40ff4a01745193ed429d3191fdaab43
- Zero Day Initiative advisory: https://www.zerodayinitiative.com/advisories/ZDI-26-262/
Because the exact affected version range and exact fixed release version were not confirmed from the retrieved source set, defenders should validate package-level exposure in their own environment before closing the issue.
Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.