#vulnerability

When using the zend-mail component to send email via the `Zend\Mail\Transport\Sendmail` transport, a malicious user may be able to inject arbitrary parameters to the system sendmail program. The attack is performed by providing additional quote characters within an address; when unsanitized, they can be interpreted as additional command line arguments, leading to the vulnerability. The following example demonstrates injecting additional parameters to the sendmail binary via the From address: ``` use Zend\Mail; $mail = new Mail\Message(); $mail->setBody('This is the text of the email.'); // inject additional parameters to sendmail command line $mail->setFrom('"AAA\" params injection"@domain', 'Sender\'s name'); $mail->addTo('hacker@localhost', 'Name of recipient'); $mail->setSubject('TestSubject'); $transport = new Mail\Transport\Sendmail(); $transport->send($mail); ``` The attack works because zend-mail filters the email addresses using the RFC 3696 specification, where the string...

Numerous components utilizing PHP's `DOMDocument`, `SimpleXML`, and `xml_parse` functionality are vulnerable to two types of attacks: - XML eXternal Entity (XXE) Injection attacks. The above mentioned extensions are insecure by default, allowing external entities to be specified by adding a specific DOCTYPE element to XML documents and strings. By exploiting this vulnerability an application may be coerced to open arbitrary files and/or TCP connections. - XML Entity Expansion (XEE) vectors, leading to Denial of Service vectors. XEE attacks occur when the XML DOCTYPE declaration includes XML entity definitions that contain either recursive or circular references; this leads to CPU and memory consumption, making Denial of Service exploits trivial to implement.

`Zend_Feed_Rss` and `Zend_Feed_Atom` were found to contain potential XML eXternal Entity (XXE) vectors due to insecure usage of PHP's DOM extension. External entities could be specified by adding a specific DOCTYPE element to feeds; exploiting this vulnerability could coerce opening arbitrary files and/or TCP connections. A similar issue was fixed for 1.11.13 and 1.12.0, in the `Zend_Feed::import()` factory method; however, the reporter of the issue discovered that the individual classes contained similar functionality in their constructors which remained vulnerable.

Developers using non-ASCII-compatible encodings in conjunction with the MySQL PDO driver of PHP may be vulnerable to SQL injection attacks. Developers using ASCII-compatible encodings like UTF8 or latin1 are not affected by this PHP issue, which is described in more detail here: http://bugs.php.net/bug.php?id=47802 The PHP Group included a feature in PHP 5.3.6+ that allows any character set information to be passed as part of the DSN in PDO to allow both the database as well as the C-level driver to be aware of which charset is in use which is of special importance when PDO's quoting mechanisms are utilized, which Zend Framework also relies on.

`Zend_Dojo_View_Helper_Editor` was incorrectly decorating a TEXTAREA instead of a DIV. The Dojo team has reported that this has security implications as the rich text editor they use is unable to escape content for a TEXTAREA.

Numerous components utilizing PHP's DOMDocument, SimpleXML, and xml_parse functionality are vulnerable to two types of attacks: - XML eXternal Entity (XXE) Injection attacks. The above mentioned extensions are insecure by default, allowing external entities to be specified by adding a specific DOCTYPE element to XML documents and strings. By exploiting this vulnerability an application may be coerced to open arbitrary files and/or TCP connections. - XML Entity Expansion (XEE) vectors, leading to Denial of Service vectors. XEE attacks occur when the XML DOCTYPE declaration includes XML entity definitions that contain either recursive or circular references; this leads to CPU and memory consumption, making Denial of Service exploits trivial to implement.

Zend_View is a component that utilizes PHP as a templating language. To utilize it, you specify "script paths" that contain view scripts, and then `render()` view scripts by specifying subdirectories within those script paths; the output is then returned as a string value which may be cached or directly output. `Zend_View::setScriptPath()` in versions up to and including 1.7.4 include a potential Local File Inclusion vulnerability. If untrusted input is used to specify the script path and/or view script itself, a malicious attacker could potentially specify a system directory and thus render a system file. As an example, if the user-supplied string `/etc/passwd` or a relative path that resolved to that file, was supplied to `Zend_View::render()`, that file would be rendered.

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\Debug`, `Zend\Feed\PubSubHubbub`, `Zend\Log\Formatter\Xml`, `Zend\Tag\Cloud\Decorator`, `Zend\Uri`, `Zend\View\Helper\HeadStyle, Zend\View\Helper\Navigation\Sitemap`, and `Zend\View\Helper\Placeholder\Container\AbstractStandalone` were not using `Zend\Escaper` when escaping HTML, HTML attributes, and/or URLs. While most were performing some escaping, because they were not using context-appropriate escaping mechanisms, they could potentially be exploited to perform Cross Site Scripting (XSS) attacks.