Summary
Ez Platform and Legacy are prone to an insecure interpretation of PHP/PHAR uploads
The eZ Platform and Legacy are affected by an issue related to how uploaded PHP and PHAR files are handled, and consists of two parts: 1. Web server configuration, and 2. Disabling the PHAR stream wrapper.
1. WEB SERVER CONFIGURATION
The sample web server configuration in our documentation can in some cases allow the execution of uploaded PHP/PHAR code. This can be abused to allow priviledge escalation and breach of content access controls, among other things. Please ensure that your web server will not execute files in directories were files may be uploaded, such as web/var/ and ezpublish_legacy/var/
As an example, here is how you can make Apache return HTTP 403 Forbidden for a number of executable file types in your eZ Platform var directory. Please adapt it to your needs. It is then possible to enable logging of HTTP 403 in a separate log file if you wish, you could do this to see if someone is trying to abuse the server.
RewriteEngine On
# disable .php(3) and other extensions in the var directory
RewriteRule ^var/.*(?i)\.(php3?|phar|phtml|sh|exe|pl|bin)$ - [F]
Here is the same configuration, but for the Nginx web server:
location ~ ^/var/.*(?i)\.(php3?|phar|phtml|sh|exe|pl|bin)$ {
return 403;
}
2. DISABLE PHAR STREAM WRAPPER
PHAR archives may be crafted such that its stream wrapper will execute them without being specifically asked to. With such files, any PHP file operation may cause deserialisation and execution. This may happen even if the file name suffix isn't ".phar". Any site that allows file uploads is at risk. Normally eZ Platform has no need for PHAR support. It's only used by Composer, and that is executed separately from eZ Platform. So one way to avoid this vulnerability is to disable the PHAR stream wrapper within eZ Platform. (If you know you need PHAR support, please consider other means to deal with this vulnerability. For example, enabling the wrapper only in those scripts/bundles that have to deal with such files.)
Disabling the stream wrapper should be done in:
eZ Platform (web/app.php)
CLI scripts (bin/console)
Legacy (index.php and CLI scripts)
To install, use Composer to update to one of the "Resolving versions" mentioned above, or apply these patches manually:
https://github.com/ezsystems/ezplatform/commit/9a0c52dc4535e4b3ce379f80222dc53f705a2cfd
https://github.com/ezsystems/ezpublish-legacy/commit/d21957bf202b091ab39dfb5be300f6c30be3933e
Impact
Untrusted input is evaluated as executable code within the application's runtime environment. Typical impact: arbitrary code execution within the application's privilege context.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
ezsystems/ezpublish-legacy to 2018.9.1.3 or later; ezsystems/ezpublish-legacy to 2018.6.1.4 or later; ezsystems/ezpublish-legacy to 2017.12.4.3 or later; ezsystems/ezpublish-legacy to 5.4.12.3 or later; ezsystems/ezpublish-legacy to 5.3.12.6 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-PQJM-XCP8-WGMM? GHSA-PQJM-XCP8-WGMM is a medium-severity code injection vulnerability in ezsystems/ezpublish-legacy (composer), affecting versions >= 2018.9.0, < 2018.9.1.3. It is fixed in 2018.9.1.3, 2018.6.1.4, 2017.12.4.3, 5.4.12.3, 5.3.12.6. Untrusted input is evaluated as executable code within the application's runtime environment.
- Which versions of ezsystems/ezpublish-legacy are affected by GHSA-PQJM-XCP8-WGMM? ezsystems/ezpublish-legacy (composer) versions >= 2018.9.0, < 2018.9.1.3 is affected.
- Is there a fix for GHSA-PQJM-XCP8-WGMM? Yes. GHSA-PQJM-XCP8-WGMM is fixed in 2018.9.1.3, 2018.6.1.4, 2017.12.4.3, 5.4.12.3, 5.3.12.6. Upgrade to this version or later.
- Is GHSA-PQJM-XCP8-WGMM exploitable, and should I be worried? Whether GHSA-PQJM-XCP8-WGMM is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-PQJM-XCP8-WGMM is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-PQJM-XCP8-WGMM?
- Upgrade
ezsystems/ezpublish-legacyto 2018.9.1.3 or later - Upgrade
ezsystems/ezpublish-legacyto 2018.6.1.4 or later - Upgrade
ezsystems/ezpublish-legacyto 2017.12.4.3 or later - Upgrade
ezsystems/ezpublish-legacyto 5.4.12.3 or later - Upgrade
ezsystems/ezpublish-legacyto 5.3.12.6 or later
- Upgrade