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
10 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 1.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact File validation can be configured to reject certain files by file type. When this happens, validation fails, and the content can't be published. However, the file can be saved when saving the content draft. This means unwanted files can be present in storage, even if they are not easily accessible due to the content not being published. The fix ensures these unwanted file types are never stored. An attacker would need to have existing access to create content with a file field type to exploit this. Patches See "Patched versions". Commit: https://github.com/ezsystems/ezplatform-kernel/commit/7e472317f7c75f45f72f74c38406952d8bea0de1 References https://developers.ibexa.co/security-advisories/ibexa-sa-2024-002-file-validation-and-workflow-stages
Recommended action: Upgrade to 1.3.35 or later, 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/ezplatform-kernel, see "Patched versions". An advisory is also published for ezsystems/ezpublish-kernel and ibexa/core, please see those repositories. Commit: https://github.com/ezsystems/ezplatform-kernel/commit/affa2520e5e986e477ca7f7c93b9ca2c30188063 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 1.3.34 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 1.3.19 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 1.3.26 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 1.3.26 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 1.3.19 or later, 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 frontend 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 1.3.17 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 1.3.12 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 1.3.1.1 or 1.2.5.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.