Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
15 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
This Security Advisory is about an object injection vulnerability in the SiteAccessMatchListener of eZ Platform, which could lead to remote code execution (RCE), a very serious threat. All sites may be affected. Update: There are bugs introduced by this fix, particularly but not limited to compound siteaccess matchers. These have been fixed in ezsystems/ezplatform-kernel v1.0.3, and in ezsystems/ezpublish-kernel v7.5.8, v6.13.6.4, and v5.4.15.
Recommended action: Upgrade to 7.5.8, 6.13.6.4 or 5.4.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This Security Advisory is about a vulnerability in the way eZ Platform and eZ Publish Legacy handles file uploads, which can in the worst case lead to remote code execution (RCE), a very serious threat. An attacker would need access to uploading files to be able to exploit the vulnerability, so if you have strict controls on this and trust all who have this permission, you're not affected. On the basis of the tests we have made, we also believe the vulnerability cannot be exploited as long as our recommended vhost configuration is used. Here is the v2.5 recommendation for Nginx, as an example: https://github.com/ezsystems/ezplatform/blob/2.5/doc/nginx/vhost.template#L31 This vhost template specifies that only the file app.php in the web root is executed, while vulnerable configurations allow execution of any php file. Apache is affected in the same way as Nginx, and is also protected by using the recommended configuration. The build-in webserver in PHP stays vulnerable, as it doesn't…
Recommended action: Upgrade to 7.5.6.2, 6.13.6.2 or 5.4.14.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
7.2.4.17.3.2.16.7.9.16.13.5.15.3.12.15.4.13.1· Vendor fix available
Issue
This security advisory fixes a vulnerability in eZ Platform, and we recommend that you install it as soon as possible. The issue is that the REST API may be made to disclose the names of all available site accesses. The severity of this depends on your installation, please consider your response accordingly. To install, use Composer to update "ezsystems/ezpublish-kernel" to one of the "Resolving versions" mentioned above, or apply this patch manually: https://github.com/ezsystems/ezpublish-kernel/commit/1551723ec134878a4cb598bfc5d900ba6164117a
Recommended action: Upgrade to 7.3.2.1, 7.2.4.1, 6.13.5.1 or 3 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The route used for file downloads allows specifying the name of the downloaded file. This is an unintended side effect of the implementation, and means one could construct download URLs with filenames that have no relation to the actual file, which could lead to misunderstandings and confusion, and possibly other harm. As such it is a low severity vulnerability. It affects all supported versions of Ibexa DXP and eZ Platform, in installations where downloadable files exist. Patches The issue is fixed in all supported versions of ezsystems/ezpublish-kernel, see "Patched versions". An advisory is also published for ezsystems/ezplatform-kernel and ibexa/core, please see those repositories. Commit: https://github.com/ezsystems/ezpublish-kernel/commit/142152f9bae4c4835713df0bdfe22bc98d03f9a1 Workarounds None, other than blocking all downloads. References https://developers.ibexa.co/security-advisories/ibexa-sa-2023-005-vulnerabilities-in-solr-search-and-file-downloads
Recommended action: Upgrade to 7.5.31 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ibexa DXP is using random execution time to hinder timing attacks against user accounts, a method of discovering whether a given account exists in a system without knowing its password, thus affecting privacy. This implementation was found to not be good enough in some situations. The fix replaces this with constant time functionality, configured in the new security.yml parameter 'ibexa.security.authentication.constantauthtime'. It will log a warning if the constant time is exceeded. If this happens the setting should be increased.
Recommended action: Upgrade to 7.5.29 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Users with the Company admin role (introduced by the company account feature in v4) can assign any role to any user. This also applies to any other user that has the role / assign policy. Any subtree limitation in place does not have any effect. The role / assign policy is typically only given to administrators, which limits the scope in most cases, but please verify who has this policy in your installaton. The fix ensures that subtree limitations are working as intended.
Recommended action: Upgrade to 7.5.30 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Access control based on object state is mishandled. This is a policy you can use in your roles to limit access to content based on specific object state values. Due to a flawed earlier update, these limitations were ineffective in releases made since February 16th 2022. They would grant access to the given content regardless of the object state. Depending on how your frontent is designed, knowing the URL to the content may or may not be required to access it. If you are using object state limitations in your roles, this issue is critical. Please apply the fix as soon as possible.
Recommended action: Upgrade to 7.5.28 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Critical severity. Users with the Company admin role (introduced by the company account feature in v4) can assign any role to any user. This also applies to any other user that has the role / assign policy. Any subtree limitation in place does not have any effect. The role / assign policy is typically only given to administrators, which limits the scope in most cases, but please verify who has this policy in your installaton. The fix ensures that subtree limitations are working as intended.
Recommended action: Upgrade to 7.5.30 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ibexa DXP is using random execution time to hinder timing attacks against user accounts, a method of discovering whether a given account exists in a system without knowing its password, thus affecting privacy. This implementation was found to not be good enough in some situations. The fix replaces this with constant time functionality, configured in the new security.yml parameter 'ibexa.security.authentication.constantauthtime'. It will log a warning if the constant time is exceeded. If this happens the setting should be increased.
Recommended action: Upgrade to 7.5.29 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
eZ Publish Kernel before 5.4.14.1, 6.x before 6.13.6.2, and 7.x before 7.5.6.2 and eZ Publish Legacy before 5.4.14.1, 2017 before 2017.12.7.2, and 2019 before 2019.03.4.2 allow remote attackers to execute arbitrary code by uploading PHP code, unless the vhost configuration permits only app.php execution.
Recommended action: Upgrade to 7.5.6.2, 6.13.6.2 or 5.4.14.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Object state limitation is a policy you can use in your roles to limit access to content based on specific object state values. Due to a flawed earlier update, these limitations were ineffective in releases made since February 16th 2022. They would grant access to the given content regardless of the object state. Depending on how your frontent is designed, knowing the URL to the content may or may not be required to access it. If you are using object state limitations in your roles, this issue is critical. Please apply the fix as soon as possible.
Recommended action: Upgrade to 7.5.28 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When image files are uploaded, they are made accessible under a name similar to the original file name. There are two issues with this. Both require access to uploading images in order to exploit them, this limits the impact. The first issue is that certain injection attacks can be possible, since not all possible attack vectors are removed from the original file name. The second issue is that direct access to the images is not access controlled. This is by design, for performance reasons, and documented as such. But it does mean that images not meant to be publicly accessible can be accessed, provided that the image path and filename is correctly deduced and/or guessed, through dictionary attacks and similar.
Recommended action: Upgrade to 7.5.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ezsystems/ezpublish-kernel versions 7.5. before 7.5.26 are vulnerable to certain injection attacks and unauthorized access to some image files.
Recommended action: Upgrade to 7.5.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In file upload it is possible by certain means to upload files like .html and .js. These may contain XSS exploits which will be run when links to them are accessed by victims. Patches The fix consists simply of adding common types of scriptable file types to the configuration of the already existing filetype blacklist feature. See "Patched versions". As such, this can also be done manually, without installing the patched versions. This may be relevant if you are currently running a considerably older version of the kernel package and don't want to upgrade it at this time. Please see the settting "ezsettings.default.io.filestorage.filetypeblacklist" at: https://github.com/ezsystems/ezplatform-kernel/blob/master/eZ/Bundle/EzPublishCoreBundle/Resources/config/defaultsettings.yml#L109 Important note You should adapt this setting to your needs. Do not add file types to the blacklist that you actually need to be able to upload. For instance, if you need your editors to be able to…
Recommended action: Upgrade to 7.5.15.2 or 6.13.8.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This Security Advisory is about a vulnerability in eZ Platform v1.13, v2.5, and v3.2, and in Ibexa DXP and Ibexa Open Source v3.3. The /user/sessions endpoint can let an attacker detect if a given username or email refers to a valid account. This can be detected through differences in the response data or response time of certain requests. The fix ensures neither attack is possible. The fix is distributed via Composer. If you come across a security issue in our products, here is how you can report it to us: https://doc.ibexa.co/en/latest/guide/reportingissues/#toc
Recommended action: Upgrade to 7.5.15.1 or 6.13.8.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.