#php

Users registering via the `user:register_form` tag will have their password confirmation stored in plain text in their user file. ### Impact This only affects sites matching **all** of the following conditions: - Running Statamic versions between 5.3.0 and 5.6.1. (This version range represents only one calendar week) - Using the `user:register_form` tag. - Using file-based user accounts. (Does not affect users stored in a database.) - Has users that have registered during that time period. (Existing users are not affected.) The password is only visible to users that have access to read user yaml files, typically developers of the application itself. ### Patches The issue has been patched in 5.6.2, however any users registered during that time period and using the affected version range will still have the the `password_confirmation` value in their yaml files. We recommend that affected users have their password reset. The following query can be entered into `php artisan tinker` and...

Yii2 supports attaching Behaviors to Components by setting properties having the format `'as <behaviour-name>'`. Internally this is done using the `__set()` magic method. If the value passed to this method is not an instance of the `Behavior` class, a new object is instantiated using `Yii::createObject($value)`. However, there is no validation check that verifies that `$value` is a valid `Behavior` class name or configuration. An attacker that can control the content of the $value variable can then instantiate arbitrary classes, passing parameters to their constructors and then invoking setter methods. ### Impact With some effort malicious code can be injected executed which might be anything ranging from deleting files to dropping database tables ### Patches Not yet patched. ### Workarounds No Work around available ### References Reported [Here](https://huntr.com/bounties/4fbdd965-02b6-42e4-b57b-f98f93415b8f?token=3bcfc5266870680af19a26170b8dbf3750e3b593ce192da8eaa6a03f96b99b52c4...

During the internal penetration testing of our product based on Yii2, we discovered an XSS vulnerability within the framework itself. This issue is relevant for the latest version of Yii2 (2.0.49.3). ### Conditions for vulnerability reproduction * The framework is in debug mode (YII_DEBUG set to true). * The php.ini setting zend.exception_ignore_args is set to Off (default value). * An attacker induces an exception in the application, leading to a stack trace page being displayed. ### Vulnerability description The issue lies in the mechanism for displaying function argument values in the stack trace. The vulnerability manifests when an argument's value exceeds 32 characters. For convenience, argument values exceeding this limit are truncated and displayed with an added "...". The full argument value becomes visible when hovering over it with the mouse, as it is displayed in the title attribute of a span tag. However, the use of a double quote (") allows an attacker to break out of ...

Unsafe direct use of $_SERVER['HTTP_REFERER'] in admin/tool/mfa/index.php. The referrer URL used by MFA required additional sanitizing, rather than being used directly.

Online Payment Hub System version 1.0 suffers from a remote SQL injection vulnerability that allows for authentication bypass.

BWL Advanced FAQ Manager version 2.0.3 suffers from a remote SQL injection vulnerability.

iMLog versions prior to 1.307 suffer from a persistent cross site scripting vulnerability.

It has been discovered, that calling a PHP script which is delivered with TYPO3 for testing purposes, discloses the absolute server path to the TYPO3 installation.

A request URL with arbitrary arguments, but still pointing to the home page of a TYPO3 installation can be cached if the configuration option config.prefixLocalAnchors is used with the values "all" or "cached". The impact of this vulnerability is that unfamiliar looking links to the home page can end up in the cache, which leads to a reload of the page in the browser when section links are followed by web page visitors, instead of just directly jumping to the requested section of the page. TYPO3 versions 4.6.x and higher are only affected if the homepage is not a shortcut to a different page.

It has been discovered that request handling in Extbase can be vulnerable to insecure deserialization. User submitted payload has to be signed with a corresponding HMAC-SHA1 using the sensitive TYPO3 encryptionKey as secret - invalid or unsigned payload is not deserialized. However, since sensitive information could have been leaked by accident (e.g. in repositories or in commonly known and unprotected backup files), there is the possibility that attackers know the private encryptionKey and are able to calculate the required HMAC-SHA1 to allow a malicious payload to be deserialized. Requirements for successfully exploiting this vulnerability (all of the following): - rendering at least one Extbase plugin in the frontend - encryptionKey has been leaked (from LocalConfiguration.php or corresponding .env file)