Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
33 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The implementation of ORDER BY and GROUP BY in ZendDbSelect remained prone to SQL injection when a combination of SQL expressions and comments were used. This security patch provides a comprehensive solution that identifies and removes comments prior to checking validity of the statement to ensure no SQLi vectors occur. The implementation of ORDER BY and GROUP BY in ZendDbSelect of ZF1 is vulnerable by the following SQL injection: The above $select will render the following SQL statement: instead of the correct one: This security fix can be considered an improvement of the previous ZF2016-02 and ZF2014-04 advisories. As a final consideration, we recommend developers either never use user input for these operations, or filter user input thoroughly prior to invoking ZendDb. You can use the ZendDbSelect::quoteInto() method to filter the input data, as shown in this example:
Recommended action: Upgrade to 1.12.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Zend Framework, ZendCaptchaWord (v1) and Zend\Captcha\Word (v2) generate a "word" for a CAPTCHA challenge by selecting a sequence of random letters from a character set. Prior to this advisory, the selection was performed using PHP's internal arrayrand() function. This function does not generate sufficient entropy due to its usage of rand() instead of more cryptographically secure methods such as opensslpseudorandombytes(). This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.
Recommended action: Upgrade to 1.12.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
We discovered several methods used to generate random numbers in ZF1 that potentially used insufficient entropy. These random number generators are used in the following method calls: In each case, the methods were using rand() or mtrand(), neither of which can generate cryptographically secure values. This could potentially lead to information disclosure should an attacker be able to brute force the random number generation. Moreover, we discovered a potential security issue in the usage of the opensslrandompseudobytes() function in ZendCryptMath::randBytes, reported in PHP BUG #70014, and the security implications reported in a discussion on the randomcompat library.
Recommended action: Upgrade to 1.12.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The PDO adapters of Zend Framework 1 do not filter null bytes values in SQL statements. A PDO adapter can treat null bytes in a query as a string terminator, allowing an attacker to add arbitrary SQL following a null byte, and thus create a SQL injection. We tested and verified the null byte injection using pdodblib (FreeTDS) on a Linux environment to access a remote Microsoft SQL Server, and also tested against and noted the vector against pdosqlite.
Recommended action: Upgrade to 1.12.16 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The implementation of the ORDER BY SQL statement in ZendDbSelect of Zend Framework 1 contains a potential SQL injection when the query string passed contains parentheses. For instance, the following code is affected by this issue: This code produce the string: instead of the correct one: The SQL injection occurs because we create a new ZendDbExpr() object, in presence of parentheses, passing directly the value without any filter on the string.
Recommended action: Upgrade to 1.12.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Using the Consumer component of ZendOpenId (or ZendOpenId in ZF1), it is possible to login using an arbitrary OpenID account (without knowing any secret information) by using a malicious OpenID Provider. That means OpenID it is possible to login using arbitrary OpenID Identity (MyOpenID, Google, etc), which are not under the control of our own OpenID Provider. Thus, we are able to impersonate any OpenID Identity against the framework. Moreover, the Consumer accepts OpenID tokens with arbitrary signed elements. The framework does not check if, for example, both openid.claimedid and openid.endpointurl are signed. It is just sufficient to sign one parameter. According to https://openid.net/specs/openid-authentication-20.html#positiveassertions, at least opendpoint, returnto, responsenonce, assochandle, and, if present in the response, claimedid and identity, must be signed.
Recommended action: Upgrade to 1.12.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ZendFilterStripTags 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.
Recommended action: Upgrade to 1.9.7, 1.8.5 or 1.7.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ZendServiceReCaptchaMailHide 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
Recommended action: Upgrade to 1.9.7, 1.8.5 or 1.7.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ZendJsonEncoder 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.
Recommended action: Upgrade to 1.9.7, 1.8.5 or 1.7.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.10.3 or 1.9.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ZendXmlRpc is vulnerable to XML eXternal Entity (XXE) Injection attacks. The SimpleXMLElement class (SimpleXML PHP extension) is used in an insecure way to parse XML data. External entities can be specified by adding a specific DOCTYPE element to XML-RPC requests. By exploiting this vulnerability an application may be coerced to open arbitrary files and/or TCP connections.
Recommended action: Upgrade to 1.11.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ZendDom, ZendFeed, ZendSoap, and ZendXmlRpc are vulnerable to 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.
Recommended action: Upgrade to 1.11.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ZendFilterStripTags is a filtering class analogous to PHP's striptags() function. In addition to stripping HTML tags and selectively keeping those provided in a whitelist, it also provides the ability to whitelist specific attributes to retain per whitelisted tag. The reporter discovered that attributes that contained whitespace, and in paricular, line breaks, surrounding the attribute assignment operator would not be stripped, regardless of whether or not they were whitelisted. As examples of input affected: When passed to the following code: then the "onclick" attribute would remain, even though it was not specified in the tag's whitelist. This could open potential cross-site scripting attack (XSS) vectors. Recommendations If you were using ZendFilterStripTags and utlizing the attribute whitelisting functionality, you should immediately upgrade to Zend Framework 1.7.6 or above; regardless, it is always best to run the most current version of the framework. Also, if relying on…
Recommended action: Upgrade to 1.7.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The default error handling view script generated using ZendTool failed to escape request parameters when run in the "development" configuration environment, providing a potential XSS attack vector. ZendToolProjectContextZfViewScriptFile was patched such that the view script template now calls the escape() method on dumped request variables. Zend Framework 1.11.4 includes a patch that adds escaping to the generated error/error.phtml view script, ensuring that request variables are escaped appropriately for the browser. Do note, however, that this will not update any previously generated code. You will still need to follow the next advice for previously generated error view scripts.
Recommended action: Upgrade to 1.11.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Numerous components utilizing PHP's DOMDocument, SimpleXML, and xmlparse 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.
Recommended action: Upgrade to 1.12.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ZendFeedRss and ZendFeedAtom 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 ZendFeed::import() factory method; however, the reporter of the issue discovered that the individual classes contained similar functionality in their constructors which remained vulnerable.
Recommended action: Upgrade to 1.12.1 or 1.11.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A number of classes, primarily within the ZendForm, ZendFilter, ZendForm, ZendLog and ZendView components, contained character encoding inconsistencies whereby calls to the htmlspecialchars() and htmlentities() functions used undefined or hard coded charset parameters. In many of these cases developers were unable to set a character encoding of their choice. These inconsistencies could, in specific circumstances, allow certain multibyte representations of special HTML characters pass through unescaped leaving applications potentially vulnerable to cross-site scripting (XSS) exploits. Such exploits would only be possible if a developer used a non-typical character encoding (such as UTF-7), allowed users to define the character encoding, or served HTML documents without a valid character set defined.
Recommended action: Upgrade to 1.9.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.11.6 or 1.10.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ZendDojoViewHelperEditor 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.
Recommended action: Upgrade to 1.9.7, 1.8.5 or 1.7.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ZendView 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. ZendView::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 ZendView::render(), that file would be rendered.
Recommended action: Upgrade to 1.7.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SQL injection vulnerability in Zend Framework before 1.12.9, 2.2.x before 2.2.8, and 2.3.x before 2.3.3, when using the sqlsrv PHP extension, allows remote attackers to execute arbitrary SQL commands via a null byte.
Recommended action: Upgrade to 1.12.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CRLF injection vulnerability in Zend\Mail (ZendMail) in Zend Framework before 1.12.12, 2.x before 2.3.8, and 2.4.x before 2.4.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via CRLF sequences in the header of an email.
Recommended action: Upgrade to 1.12.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
(1) ZendDom, (2) ZendFeed, and (3) ZendSoap in Zend Framework 1.x before 1.11.13 and 1.12.x before 1.12.0 do not properly handle SimpleXMLElement classes, which allow remote attackers to read arbitrary files or create TCP connections via an external entity reference in a DOCTYPE element in an XML-RPC request, aka an XML external entity (XXE) injection attack, a different vulnerability than CVE-2012-3363.
Recommended action: Upgrade to 1.12.0 or 1.11.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The (1) ZendFeedRss and (2) ZendFeedAtom classes in ZendFeed in Zend Framework 1.11.x before 1.11.15 and 1.12.x before 1.12.1 allow remote attackers to read arbitrary files, send HTTP requests to intranet servers, and possibly cause a denial of service (CPU and memory consumption) via an XML External Entity (XXE) attack.
Recommended action: Upgrade to 1.12.1 or 1.11.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
(1) ZendDom, (2) ZendFeed, (3) ZendSoap, and (4) ZendXmlRpc in Zend Framework 1.x before 1.11.13 and 1.12.x before 1.12.0 allow remote attackers to cause a denial of service (CPU consumption) via recursive or circular references in an XML entity definition in an XML DOCTYPE declaration, aka an XML Entity Expansion (XEE) attack.
Recommended action: Upgrade to 1.12.0 or 1.11.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.