#git

The package zendframework/zend-developer-tools provides a web-based toolbar for introspecting an application. When updating the package to support PHP 7.3, a change was made that could potentially prevent toolbar entries that are enabled by default from being disabled.

Zend_Filter_StripTags contained an optional setting to allow whitelisting HTML comments in filtered text. Microsoft Internet Explorer and several other browsers allow developers to create conditional functionality via HTML comments, including execution of script events and rendering of additional commented markup. By allowing whitelisting of HTML comments, a malicious user could potentially include XSS exploits within HTML comments that would then be rendered in the final output.

zend-diactoros (and, by extension, Expressive), zend-http (and, by extension, Zend Framework MVC projects), and zend-feed (specifically, its PubSubHubbub sub-component) each contain a potential URL rewrite exploit. In each case, marshaling a request URI includes logic that introspects HTTP request headers that are specific to a given server-side URL rewrite mechanism. When these headers are present on systems not running the specific URL rewriting mechanism, the logic would still trigger, allowing a malicious client or proxy to emulate the headers to request arbitrary content.

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`

zend-diactoros (and, by extension, Expressive), zend-http (and, by extension, Zend Framework MVC projects), and zend-feed (specifically, its PubSubHubbub sub-component) each contain a potential URL rewrite exploit. In each case, marshaling a request URI includes logic that introspects HTTP request headers that are specific to a given server-side URL rewrite mechanism. When these headers are present on systems not running the specific URL rewriting mechanism, the logic would still trigger, allowing a malicious client or proxy to emulate the headers to request arbitrary content.

`Zend_Service_ReCaptcha_MailHide` had a potential XSS vulnerability. Due to the fact that the email address was never validated, and because its use of `htmlentities()` did not include the encoding argument, it was potentially possible for a malicious user aware of the issue to inject a specially crafted multibyte string as an attack via the CAPTCHA's email argument

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`

`Zend_Json_Encoder` was not taking into account the solidus character (/) during encoding, leading to incompatibilities with the JSON specification, and opening the potential for XSS or HTML injection attacks when returning HTML within a JSON string.

zend-diactoros (and, by extension, Expressive), zend-http (and, by extension, Zend Framework MVC projects), and zend-feed (specifically, its PubSubHubbub sub-component) each contain a potential URL rewrite exploit. In each case, marshaling a request URI includes logic that introspects HTTP request headers that are specific to a given server-side URL rewrite mechanism. When these headers are present on systems not running the specific URL rewriting mechanism, the logic would still trigger, allowing a malicious client or proxy to emulate the headers to request arbitrary content.

In mid-March, 2010, the Dojo Foundation issued a Security Advisory indicating potential security issues with specific files in Dojo Toolkit. Details of the advisory may be found on the Dojo website: http://dojotoolkit.org/blog/post/dylan/2010/03/dojo-security-advisory/ In particular, several files in the Dojo tree were identified as having potential exploits, and the Dojo team also advised disabling or removing any PHP scripts in the tree when deploying to production.