Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as store-update back-office admin
-
DeliveryUpload SVG logo/banner with onload payload
-
ExploitSanitizer bypassed, stored and mirrored to public cache
-
ExecutionVictim loads page referencing og:image or /admin/store-media/logo
-
ImpactScript executes on shop/admin origin, enabling session/CSRF abuse
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Output encoding, context-aware escaping
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated back-office administrator with store update permission (PR:H) who reaches Configuration → Store, where the logo_file and banner_file fields accept image/svg+xml via a bare new Image() constraint and are the only upload path that skips FileProcessorService::sanitizeUpload(), so the SVG's onload/script content is stored intact. Exploitation also needs victim interaction (UI:A): a higher-privileged admin must load /admin/store-media/logo in an authenticated session, or any visitor/crawler must fetch the public cache/images/store/<uniqid>-logo.svg URL that every front-office page's og:image meta publishes. Limiting factors: the high-privilege prerequisite for planting the payload confines the initial step to trusted or compromised operator accounts; the public reach depends on the core image cache mirroring the original into the document root, which the advisory states occurs in both supported original_image_delivery_mode settings. Per the vendor fix, updating to 3.1.1 (and back-office default-twig template 1.1.1) is the remediation. |
| Impact | This is a genuine but constrained stored-XSS issue rather than a drop-everything emergency. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:A) scores 4.6 (medium), and the key limiter is PR:H - exploitation requires an authenticated back-office administrator holding store update permission to plant the payload, so the initial write is a privileged/insider or compromised-admin action, not a remote-unauthenticated one. What raises this above a typical self-XSS is the delivery side confirmed by the GHSA source-code analysis: the malicious SVG is mirrored by the core image cache into the document root and advertised in every front-office page's og:image meta, giving the payload anonymous public reachability (no session needed) plus admin-origin execution via /admin/store-media/logo, which can be chained to CSRF-token theft and back-office mutations against higher-privileged admins. Signals are mostly consistent: the vulnerability is patched (3.1.1), VulnCheck is the reporter, and the GHSA advisory carries a detailed PoC. However, there is NO EPSS score in the input and the CVE is NOT listed in CISA KEV, so there is no evidence of active or widespread exploitation; the vuln.today Decision label is 'this_month', indicating scheduled remediation rather than emergency patching. Net: prioritize patching this cycle, weighted by whether the shop grants store-update permission beyond fully trusted operators. |
| Exploit ScenarioDerived | An attacker who controls or compromises a back-office admin account with store update permission uploads a store logo or banner as an SVG containing an onload JavaScript payload, which bypasses Thelia's SVG sanitizer and is stored unmodified. The file is then served as image/svg+xml both at /admin/store-media/logo (executing in a viewing administrator's authenticated session) and, mirrored into public/cache/images/store/, via the og:image meta printed on every front-office page, so any anonymous visitor or crawler that navigates to that URL triggers script execution on the shop origin. The GHSA advisory includes a step-by-step proof-of-concept with a working alert(document.domain) SVG payload. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 01, 2026
Stored cross-site scripting in Thelia's back-office store configuration lets an authenticated administrator holding store update permission upload SVG logo or banner images whose event handlers and script content are stored intact, creating a persistent script implant on the shop origin. The same bytes execute against higher-privileged administrators at /admin/store-media/logo and against anonymous visitors, crawlers and link-preview fetchers via the image cache copy mirrored into the document root and advertised in every front-office page's og:image meta. The vendor fixed the flaw in Thelia 3.1.1 and back-office default-twig template 1.1.1, and the GitHub advisory carries a step-by-step PoC walkthrough, so a public PoC reference exists; it is not verified as working exploit code, and the issue is not confirmed actively exploited (CISA KEV).
RemediationAI
Vendor-released patch: upgrade to Thelia 3.1.1 (thelia/thelia and thelia/core) and back-office default-twig template 1.1.1, per the advisory at https://github.com/thelia/thelia/security/advisories/GHSA-gvcv-hvpp-89gx and the release at https://github.com/thelia/thelia/releases/tag/3.1.1; the individual fix commits are 2c691e5c3bb8536ca901fcf7d2780301bd111ba9 (core image action and FileProcessorService), d79780eafc5b17ac75554c836a1853610d89a090 and f690a649cbbcee9543647cb7ed5018df68f66658 (default-twig store configuration controller and form). Updating is the remediation the vendor prescribes; the code change routes logo, banner and favicon uploads through validateUpload() with an explicit mime-type allowlist and through sanitizeUpload(), and it also republishes any already-stored SVG as a sanitized copy while removing the previously published symlink, so legacy payloads stop being served once the upgrade is in place. Until the upgrade is applied, the exposure is bounded by the privilege the flaw requires: tightening back-office roles so that store update permission is held only by fully trusted operators removes the initial upload step, at the cost of slowing routine merchandising changes, and note that this does nothing for payloads already planted, which continue to be served from the image cache and the /admin/store-media/logo endpoint until the patched code republishes them sanitized.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 3 packages in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Thelia is a PHP/Symfony e-commerce platform whose back-office store settings form (ConfigStoreType) validated the logo_file and banner_file fields with a bare new Image() constraint defaulting to image/*, while the neighbouring favicon field already demonstrated the narrower mimeTypes pattern. ConfigStoreController::writeStoreMedia() then moved the uploaded file into local/media/images/store/ without ever calling FileProcessorService::sanitizeUpload(), the platform-wide routine (with its SVG sanitizer) that strips script elements, event handlers, javascript:/data: URIs and foreignObject nodes from every other image upload. The root cause is the CWE-79 class: active content in an attacker-supplied SVG is neither neutralized on input nor neutralized on output. StoreMediaController serves the stored bytes at GET /admin/store-media/logo as image/svg+xml with no CSP and no Content-Disposition, and separately Thelia\Action\Image mirrors the original into public/cache/images/store/ inside the document root in both supported original_image_delivery_mode settings, while the front-office base.html.twig calls media_url('logo') on every page to build the og:image meta. The fix factors the sanitizer into a dedicated SvgSanitizer class consumed by both FileProcessorService and the image action, forces every store media upload through validateUpload()/sanitizeUpload(), and makes the image action publish only a sanitized copy - replacing any pre-existing symlink so previously published SVGs are no longer served as uploaded.
Know when Thelia gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
PR:H because only a store-update admin can plant the SVG; UI:R and S:C because a victim must load the page and script runs against other users' browsers/sessions; C:L/I:L, A:N as impact is script execution, not availability.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Thelia before 3.1.1 contains a stored cross-site scripting vulnerability that allows authenticated back-office administrators with store update permission to inject scripts by uploading unsanitized SVG logo_file or banner_file images. Attackers can upload an SVG with an onload payload served from /admin/store-media/logo or the public cache/images/store/ directory to execute scripts against visitors and higher-privileged administrators.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.
Authenticated back-office users of Thelia through 2.6.1 can chain a path traversal flaw in the translation editor with a
Server-side template injection in the back-office Email/Messages feature of Thelia 3.0.0 lets an authenticated user hold
Remote code execution in the Thelia e-commerce platform (all versions before 3.1.2 and 3.2.x before 3.2.1) allows an aut
Stored cross-site scripting in Thelia before 3.1.0 lets anyone who self-registers a front-office customer account plant
Remote code execution in Thelia v2.6.0 is achievable by an authenticated administrator who abuses the document update en
Authenticated attackers holding a Thelia administrator account can achieve remote code execution on the underlying serve
Thelia Page Module through 2.0.3 exposes back-office delete routes for page tags, documents and images without CSRF toke
The Thelia back-office Twig template bundle (thelia/backoffice-default-twig-template) before 1.1.1 exposes two admin cat
An open redirect in Thelia's address-creation workflow (versions up to and including 2.6.0) lets an attacker craft a URL
Reflected cross-site scripting in Thelia versions up to 2.6.0 allows remote attackers to execute arbitrary JavaScript in
Cross-site request forgery in Thelia's back office lets a crafted link or hostile page make a logged-in administrator de
Authenticated administrators of Thelia 2.6.0 and earlier can achieve remote code execution by injecting malicious Smarty
EUVD-2026-114745
GHSA-xxr4-v6q3-9x28
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB