Tag
#php
This security advisory fixes 4 separate vulnerabilities in eZ Publish Legacy, and we recommend that you install it as soon as possible if you are using Legacy by itself or via the LegacyBridge. First, it increases the randomness, and thus the security, of the pseudo-random bytes used to generate a hash for the "forgot password" feature. This protects accounts against being taken over through attacks trying to predict the hash. If the increased randomness is not available in your PHP installation, it will now log a warning. Second, it improves security of the information collector feature, by ensuring no collection emails will be sent from invalid manipulated forms. Third, it stops the possible leaking of the names of content objects that should not be readable for certain users, on installations where these users can create or edit XML text. Fourth, it protects against cross-site scripting (XSS) in the Matrix data type, on installations where users are allowed to edit content c...
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...
The recommended rewrite rules in eZ Platform prevent users from including the front-controller script (normally "app.php") in URLs. This prevents certain vulnerabilities related to caching. However, this is not possible when using eZ Platform Cloud (i.e. running eZ Platform on the Platform.sh cloud service), nor can it be done within the .platform.app.yaml configuration file. Therefore we need to reject such requests in the application itself. This advisory adds the prevention within the front controller script itself. If you use eZ Platform Cloud / Platform.sh we recommend that you install this security update as soon as possible. It is distributed via Composer as ezsystems/ezplatform 1.7.9.1, and 1.13.5.1, and 2.5.4. This is the commit: https://github.com/ezsystems/ezplatform/commit/34ce86722b36a172e587068fe64a84faa7320cc2
This Security Advisory is about two issues of low to medium severity. We recommend that you install the update as soon as possible. There is an XSS vulnerability in CKEditor, which is used by AlloyEditor, which is used in eZ Platform Admin UI. Scripts can be injected through specially crafted "protected" comments. We are not sure it is exploitable in eZ Platform, but recommend installing it to be on the safe side. It is fixed in CKEditor v4.14, AlloyEditor v2.11.9. It is distributed via Composer, for: eZ Platform v1.13.x: ezsystems/PlatformUIAssetsBundle v4.2.3 (included from ezsystems/PlatformUIBundle v1.13.x) eZ Platform v2.5.13: ezsystems/ezplatform-admin-ui-assets v4.2.1 eZ Platform v3.0.*: ezsystems/ezplatform-admin-ui-assets v5.0.1 eZ Platform v3.1.2: ezsystems/ezplatform-admin-ui-assets v5.1.1 Drafts that are sent to trash become visible in the Review Queue, even for users that were not able to see them before this action. It's not possible to preview them, but their title ...
datadog/dd-trace versions 0.30.0 prior to 0.30.2 are affected by a security and stability issue outlined in PR [#579](https://github.com/DataDog/dd-trace-php/pull/579). This pull request ensures that the ddtrace.request_init_hook remains bound by the open_basedir INI directive, effectively addressing potential vulnerabilities related to open_basedir restrictions. The update introduces a sandboxing mechanism to isolate the request init hook from errors or exceptions during execution, enhancing the library's stability and preventing adverse impacts on the main script.
PHP object injection vulnerability was identified in contao/core due to untrusted data being passed to `deserialize()` function.
contao/core versions 2.x prior to 2.11.17 and 3.x prior to 3.2.9 are vulnerable to arbitrary code execution on the server due to insufficient input validation. In fact, attackers can remove or change pathconfig.php by entering a URL, meaning that the entire Contao installation will no longer be accessible or malicious code can be executed.
OpenCFP, an open-source conference talk submission system written in PHP, contains a security vulnerability in its third-party authentication framework, Sentry, developed by Cartalyst. The vulnerability stems from how Sentry handles password reset checks. Users lacking a password reset token stored in the database default to having NULL in the reset_password_code column. Exploiting this flaw could allow unauthorized manipulation of any OpenCFP user's password, particularly those without an unused password reset token. Although successful login still requires correlating the numeric user ID with an email address, the identification of likely organizers (users 1-5) may facilitate this process.
cart2quote/module-quotation-encoded extension may expose a critical security vulnerability by utilizing the unserialize function when processing data from a GET request. This flaw, present in the app/code/community/Ophirah/Qquoteadv/controllers/DownloadController.php and app/code/community/Ophirah/Qquoteadv/Helper/Data.php files, poses a significant risk of Remote Code Execution, especially when custom file options are employed on a product. Attackers exploiting this vulnerability could execute arbitrary code remotely, leading to unauthorized access and potential compromise of sensitive data.
amphp/http versions before 1.0.1 allows an attacker to supply invalid input in the Host header which may lead to various type of Host header injection attacks.