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
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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/ibexa/core/commit/7e472317f7c75f45f72f74c38406952d8bea0de1 References https://developers.ibexa.co/security-advisories/ibexa-sa-2024-002-file-validation-and-workflow-stages
Recommended action: Upgrade to 4.6.2 or 4.5.6 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 ibexa/core, see "Patched versions". An advisory is also published for ezsystems/ezpublish-kernel and ezsystems/ezplatform-kernel, please see those repositories. Commit: https://github.com/ibexa/core/commit/704f221031ea4e32bd5510fe4c1fa8e0f664cbd4 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 4.5.4 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 4.2.3 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 4.1.4 or 4.0.7 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 4.1.2 or 4.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.