A flaw was found in the way the XMLEntityScanner and XML11EntityScanner classes in the JAXP component of OpenJDK handled and normalized newlines in XML entities. A specially-crafted XML document could cause a Java application to enter an infinite loop when parsed.
IBM Cognos Analytics 11.1.7, 11.2.4, and 12.0.0 could be vulnerable to information leakage due to unverified sources in messages sent between Windows objects of different origins. IBM X-Force ID: 254290.
IBM Cognos Analytics 11.1.7, 11.2.4, and 12.0.0 is vulnerable to form action hijacking where it is possible to modify the form action to reference an arbitrary path. IBM X-Force ID: 255898.
IBM Cognos Analytics 11.1.7, 11.2.4, and 12.0.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 260744.
IBM Cognos Analytics 11.1.7, 11.2.4, and 12.0.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 267451.
IBM Cognos Analytics Mobile Server 11.1.7, 11.2.4, and 12.0.0 is vulnerable to Denial of Service due to due to weak or absence of rate limiting. By making unlimited http requests, it is possible for a single user to exhaust server resources over a period of time making service unavailable for other legitimate users. IBM X-Force ID: 230510.
An unspecified vulnerability in Java SE related to the JNDI component could allow an unauthenticated attacker to cause no confidentiality impact, low integrity impact, and no availability impact.
Eclipse Openj9 could allow a remote attacker to bypass security restrictions, caused by a flaw in the jdk.internal.reflect.ConstantPool API. By sending a specially-crafted request, an attacker could exploit this vulnerability to call static methods or access static members without running the class initialization method.
Overview
Versions <=8.5.1 of jsonwebtoken library can be misconfigured so that passing a poorly implemented key retrieval function (referring to the secretOrPublicKey argument from the readme link) will result in incorrect verification of tokens. There is a possibility of using a different algorithm and key combination in verification than the one that was used to sign the tokens. Specifically, tokens signed with an asymmetric public key could be verified with a symmetric HS256 algorithm. This can lead to successful validation of forged tokens.
Am I affected?
You will be affected if your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function.
How do I fix it? Update to version 9.0.0.
Will the fix impact my users?
There is no impact for end users