#git

In Zend Framework 2, `Zend\Mvc\Router\Http\Query` is used primarily to allow appending query strings to URLs when assembled. However, due to the fact that it captures any query parameters into the RouteMatch, and the fact that RouteMatch parameters are merged with any parent routes, this can lead to overriding already captured routing parameters, bypassing constraints defined in the parents. As an example, consider the following route definition: ``` array( 'user' => array( 'type' => 'segment', 'options' => array( 'route' => '/user/:key', 'defaults' => array( 'controller' => 'UserController', 'action' => 'show-action', ), 'constraints' => array( 'key' => '[a-z0-9]+', ), ), 'child_routes' => array( 'query' => array('type' => 'query'), ), ), ) ``` If the request URI was /user/foo/?controller=SecretController&key=inval...

Many Zend Framework 2 view helpers were using the `escapeHtml()` view helper in order to escape HTML attributes, instead of the more appropriate `escapeHtmlAttr()`. In situations where user data and/or JavaScript is used to seed attributes, this can lead to potential cross site scripting (XSS) attack vectors. Vulnerable view helpers include: - All `Zend\Form` view helpers. - Most `Zend\Navigation` (aka `Zend\View\Helper\Navigation\*`) view helpers. - All "HTML Element" view helpers: `htmlFlash()`, `htmlPage()`, `htmlQuickTime()`. - `Zend\View\Helper\Gravatar`

The `Zend\Http\PhpEnvironment\RemoteAddress` class provides features around detecting the internet protocol (IP) address for an incoming proxied request via the X-Forwarded-For header, taking into account a provided list of trusted proxy server IPs. Prior to 2.2.5, the class was not taking into account whether or not the IP address contained in PHP's `$_SERVER['REMOTE_ADDR']` was in the trusted proxy server list. The IETF draft specification indicates that if `$_SERVER['REMOTE_ADDR']` is not a trusted proxy, it must be considered the originating IP address, and the value of X-Forwarded-For must be disregarded.

Online Media Asset Handling (*`.youtube` and *`.vimeo` files) in the TYPO3 backend is vulnerable to denial of service. Putting large files with according file extensions results in high consumption of system resources. This can lead to exceeding limits of the current PHP process which results in a dysfunctional backend component. A valid backend user account or write access on the server system (e.g. SFTP) is needed in order to exploit this vulnerability.

The Install Tool exposes the current TYPO3 version number to non-authenticated users.

It has been discovered that cookies created in the Install Tool are not hardened to be submitted only via HTTP. In combination with other vulnerabilities such as cross-site scripting it can lead to hijacking an active and valid session in the Install Tool.

Failing to properly encode user input, login status display is vulnerable to cross-site scripting in the website frontend. A valid user account is needed in order to exploit this vulnerability - either a backend user or a frontend user having the possibility to modify their user profile. Template patterns that are affected are - ###FEUSER_[fieldName]### using system extension felogin - <!--###USERNAME###--> for regular frontend rendering (pattern can be defined individually using TypoScript setting config.USERNAME_substToken)

Failing to properly encode user input, notifications shown in modal windows in the TYPO3 backend are vulnerable to cross-site scripting. A valid backend user account is needed in order to exploit this vulnerability.

Failing to properly encode user input, online media asset rendering (`*.youtube` and `*.vimeo` files) is vulnerable to cross-site scripting. A valid backend user account or write access on the server system (e.g. SFTP) is needed in order to exploit this vulnerability.

### Summary Regardless of the role or privileges, no user should be able to inject malicious JavaScript (JS) scripts into the body HTML. an XSS (Cross-Site Scripting) vulnerability, specifically a Stored XSS, which affects all pages of the website. Once the JS script is embedded in the body HTML, the XSS will trigger on any page a victim visits, such as the about, blog, contact, or any other pages, except for the panel. ### Impact This vulnerability allows attackers to inject malicious JS or HTML through a crafted payload into the vulnerable spot, achieving persistence and attacking numerous visitors or anyone accessing the website. The attack can be widespread and affect many users because the malicious JS will execute on every page, unlike an injection on a specific page (e.g., injecting on the About page would only affect that page). In this case, a single injection point leads to the execution of the malicious JS on all pages. ### Patches - [**Formwork 1.13.1**](https://github.co...