This table represents the known exploitable and non-exploitable vulnerabilities in third party packages used in the project.

RepositoryGroupProblem Code

Effective/Ineffective

Resolvable by ProjectImpact AnalysisAction
usecase-ui-servercom.eclipsesource.jaxrs
CVE-2017-7525IneffectiveYesA deserialization flaw was discovered in the jackson-databind, versions before 2.6.7.1, 2.7.9.1 and 2.8.9, which could allow an unauthenticated user to perform code execution by sending the maliciously crafted input to the readValue method of the ObjectMapper. The application is vulnerable by using this component, when default typing is enabled.Plan to update the no vulnerability version in F version
usecase-ui-servercom.eclipsesource.jaxrs
N/AIneffectiveYesjackson-core is vulnerable to Denial of Service (DoS). The writeNumber() method in files UTF8JsonGenerator.class and WriterBasedJsonGenerator.class converts a big decimal value to its plaintext value without validating the size of the input exponent, when WRITE_BIGDECIMAL_AS_PLAIN setting is enabled. This leads to an overconsumption of Java heap memory and causes DoS. The application is vulnerable by using this component when WRITE_BIGDECIMAL_AS_PLAIN is explicitly enabled. By default, WRITE_BIGDECIMAL_AS_PLAIN is disabled. If upgrading is not an option, disable the WRITE_BIGDECIMAL_AS_PLAIN option.Plan to update the no vulnerability version in F version
usecase-ui-servercom.eclipsesource.jaxrs
N/AIneffectiveYesjackson-core is vulnerable to Denial of Service (DoS). The _reportInvalidToken() function in the UTF8StreamJsonParser and ReaderBasedJsonParser classes allows large amounts of extraneous data to be printed to the server log. An attacker can exploit this vulnerability by crafting a POST request containing large amounts of data. When the data contains invalid JSON, an exception is thrown, which results in the consumption of available disk space when the error message is written to server.log along with the request data.Plan to update the no vulnerability version in F version
usecase-ui-servercom.eclipsesource.jaxrs
N/AIneffectiveYesThe jackson-databind package is vulnerable to XML eXternal Entity Reference ('XXE') attacks. The parserFactory object, an instance of the DocumentBuilderFactory type in the DOMDeserializer.class file does not prevent expansion of external entities by default. An attacker can exploit this vulnerability by submitting crafted XML which when parsed by the application leads to XXE attacks and further security issues.Plan to update the no vulnerability version in F version
usecase-ui-servercom.fasterxml.jackson.core
N/AIneffectiveYes

jackson-databind is vulnerable to Remote Code Execution (RCE). The createBeanDeserializer() function in the BeanDeserializerFactory class allows untrusted Java objects to be deserialized. A remote attacker can exploit this by uploading a malicious serialized object that will result in RCE if the application attempts to deserialize it.

Note: This vulnerability exists due to the incomplete fix for CVE-2017-7525, CVE-2017-15095, CVE-2017-17485, CVE-2018-5968, CVE-2018-7489, CVE-2018-11307, CVE-2018-12022, CVE-2018-12023, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, and CVE-2018-14721. Evidence of this can be found at https://pivotal.io/security/cve-2017-4995. The application is vulnerable by using this component, when default typing is enabled and passing in untrusted data to be deserialization.

Plan to update the no vulnerability version in F version
usecase-ui-servercom.fasterxml.jackson.core
CVE-2019-12086IneffectiveYesA Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.x before 2.9.9. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint, the service has the mysql-connector-java jar (8.0.14 or earlier) in the classpath, and an attacker can host a crafted MySQL server reachable by the victim, an attacker can send a crafted JSON message that allows them to read arbitrary local files on the server. This occurs because of missing com.mysql.cj.jdbc.admin.MiniAdmin validation. The jackson-databind component contains an Insecure Deserialization Vulnerability. The validateSubType() function in the SubTypeValidator class allows untrusted input to be deserialized as a com.mysql.cj.jdbc.admin.MiniAdmin instance. A remote attacker can exploit this behavior by submitting a crafted JSON payload to a deserializing endpoint that uses jackson-databind. The attacker's deserialized Java object may then create a connection with an attacker controlled MySql server. When running a mysql-connector-java jar versioned 8.0.14 and earlier, the attacker's MySql server may read arbitrary files accessible by the vulnerable application when the connection is established. The application is vulnerable by using this component if a mysql-connector-java jar versioned 8.0.14 or lower is in the classpath while Default Typing is enabled.Plan to update the no vulnerability version in F version
usecase-ui-serverdom4j
CVE-2018-1000632IneffectiveYesdom4j version prior to version 2.1.1 contains a CWE-91: XML Injection vulnerability in Class: Element. Methods: addElement, addAttribute that can result in an attacker tampering with XML documents through XML injection. This attack appear to be exploitable via an attacker specifying attributes or elements in the XML document. This vulnerability appears to have been fixed in 2.1.1 or later. The dom4j package is vulnerable to XML Injection. The QName() function in the QName class file does not properly sanitize the QName input attribute value(s). A remote attacker can exploit this vulnerability by injecting an XML object that contains arbitrary code in the element and attribute names, hence leading to XML Injection.Plan to update the no vulnerability version in F version
usecase-ui-serverquery
N/AIneffectiveYesThe jquery package is vulnerable to Prototype Pollution. The jQuery.extend and jQuery.fn.extend functions defined in many files allow an untrusted object to extend Object.prototype. An attacker can modify and add prototype properties to JavaScript objects and can potentially leverage those changes to crash the application or execute remote code.Plan to update the no vulnerability version in F version
usecase-ui-serverjquery
N/AIneffectiveYesThe jQuery package is vulnerable to Cross-Site Scripting (XSS). The parseHTML() function in the parseHTML.js, jquery.js files allow JavaScript to be executed immediately when it's embedded within the event attributes. An attacker can exploit this vulnerability by injecting malicious JavaScript containing events handlers which, when rendered, results in the execution of arbitrary script.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.apache.tomcat.embed
CVE-2018-8014IneffectiveYesThe defaults settings for the CORS filter provided in Apache Tomcat 9.0.0.M1 to 9.0.8, 8.5.0 to 8.5.31, 8.0.0.RC1 to 8.0.52, 7.0.41 to 7.0.88 are insecure and enable 'supportsCredentials' for all origins. It is expected that users of the CORS filter will have configured it appropriately for their environment rather than using it in the default configuration. Therefore, it is expected that most users will not be impacted by this issue. Apache Tomcat is vulnerable to a Cross-Origin attack due to the insecure default configuration of the CORS filter. The CorsFilter class allows requests from all origins by default due to the wildcard initialization value (*) of the DEFAULT_ALLOWED_ORIGINS field. The class also, by default, enables credential transmission due to the initialization value (true) of the DEFAULT_SUPPORTS_CREDENTIALS field. According to the CORS standard, Origin: * and Credentials: true must not be used in parallel. In this case, since both are enabled by default, the handleSimpleCORS() method converts the wildcard origin value to a user-supplied origin value and effectively ignores the CORS security protocol. A remote attacker can exploit this vulnerability through Cross-Site Scripting (XSS) or by crafting a malicious website. After inducing a victim into interacting with the malicious JavaScript, cross-domain requests can be issued on the victim's behalf. Due to the default Credentials: true configuration, the attacker is able to make use of the victim's cookies and other credential information in the requests. The attacker can leverage this vulnerability to perform various attacks against the vulnerable server in an attempt to steal sensitive information.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.apache.tomcat.embed
CVE-2017-12617IneffectiveYesWhen running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server. Apache Tomcat is vulnerable to Remote Code Execution. The AbstractFileResourceSet class allows arbitrary files to be uploaded when running on the Windows operating system. A remote attacker can craft a PUT request that will upload a JSP file with malicious code. After uploading, the attacker can then request the file from the server causing the malicious code to execute on the server. The application is vulnerable by using this component on the Windows operating system and enabling the HTTP PUT method by “setting the readonly initialisation parameter of the Default servlet to false”.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.apache.tomcat.embed
CVE-2019-0232IneffectiveYesWhen running on Windows with enableCmdLineArguments enabled, the CGI Servlet in Apache Tomcat 9.0.0.M1 to 9.0.17, 8.5.0 to 8.5.39 and 7.0.0 to 7.0.93 is vulnerable to Remote Code Execution due to a bug in the way the JRE passes command line arguments to Windows. The CGI Servlet is disabled by default. The CGI option enableCmdLineArguments is disable by default in Tomcat 9.0.x (and will be disabled by default in all versions in response to this vulnerability). For a detailed explanation of the JRE behaviour, see Markus Wulftange's blog (https://codewhitesec.blogspot.com/2016/02/java-and-command-line-injections-in-windows.html) and this archived MSDN blog (https://web.archive.org/web/20161228144344/https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/).Plan to update the no vulnerability version in F version
usecase-ui-serverorg.apache.tomcat.embed
CVE-2018-1336IneffectiveYesAn improper handing of overflow in the UTF-8 decoder with supplementary characters can lead to an infinite loop in the decoder causing a Denial of Service. Versions Affected: Apache Tomcat 9.0.0.M9 to 9.0.7, 8.5.0 to 8.5.30, 8.0.0.RC1 to 8.0.51, and 7.0.28 to 7.0.86. The tomcat-util component of Apache Tomcat is vulnerable to a Denial of Service (DoS) attack. The decodeHasArray method in Utf8Decoder.java does not properly handle overflow when decoding certain UTF-8 supplementary characters. This flaw can result in an infinite loop, causing the thread to consume a large amount of CPU and/or memory resources. An attacker can exploit this vulnerability by submitting a maliciously crafted piece of UTF-8 data containing supplementary characters. This malicious input may trigger the infinite loop and result in a Denial of Service.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.apache.tomcat.embed

CVE-2019-0199

IneffectiveYesThe HTTP/2 implementation in Apache Tomcat 9.0.0.M1 to 9.0.14 and 8.5.0 to 8.5.37 accepted streams with excessive numbers of SETTINGS frames and also permitted clients to keep streams open without reading/writing request/response data. By keeping streams open for requests that utilised the Servlet API's blocking I/O, clients were able to cause server-side threads to block eventually leading to thread exhaustion and a DoS. The Apache tomcat-coyote package is vulnerable to a Denial of Service (DoS) attack. The Http2Protocol class, the reserveWindowSize() method in the Stream class, the process() method in the StreamProcessor class, the upgradeDispatch(), writeBody(), startRequestBodyFrame(), reprioritise(), setting(), and pingReceive() methods in the Http2UpgradeHandler class, the end() method in the Stream$StreamOutputBuffer class, and the doRead() method in the Stream$StreamInputBuffer class fail to enforce proper timeout restrictions on open connections and allow excessive numbers of SETTINGS frames. Consequently, clients are able to keep connections alive without reading or writing any request or response data. If the open streams utilize the Servlet API's blocking I/O capabilities, clients can abuse this functionality to block server-side threads. A remote attacker can exploit this vulnerability by establishing never-ending connections to the affected server, or by issuing excessive numbers of SETTINGS frames. These connections will exhaust server-side threads and eventually result in a DoS condition. The application is vulnerable by using this component if it utilizes the Servlet API's blocking I/O functionality.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.apache.tomcat.embed
CVE-2018-1305IneffectiveYesSecurity constraints defined by annotations of Servlets in Apache Tomcat 9.0.0.M1 to 9.0.4, 8.5.0 to 8.5.27, 8.0.0.RC1 to 8.0.49 and 7.0.0 to 7.0.84 were only applied once a Servlet had been loaded. Because security constraints defined in this way apply to the URL pattern and any URLs below that point, it was possible - depending on the order Servlets were loaded - for some security constraints not to be applied. This could have exposed resources to users who were not authorised to access them. Apache Tomcat Catalina does not always properly validate access to servlets. Security constraints defined in a servlet's annotations are applied when the servlet is loaded by the invoke method of AuthenticatorBase.java. Security constraints are hierarchical in the way that URLs are processed, which means that it is possible that the order in which the servlets are loaded could result in a situation wherein security constraints are not properly applied. This can allow users of the vulnerable application to access resources that they would not normally be able to otherwise.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.apache.tomcat.embedCVE-2019-0221IneffectiveYesThe SSI printenv command in Apache Tomcat 9.0.0.M1 to 9.0.0.17, 8.5.0 to 8.5.39 and 7.0.0 to 7.0.93 echoes user provided data without escaping and is, therefore, vulnerable to XSS. SSI is disabled by default. The printenv command is intended for debugging and is unlikely to be present in a production website. The tomcat-catalina package is vulnerable to Cross-Site Scripting (XSS). The process method in SSIPrintenv.class prints application environment variables without sanitizing them. A remote attacker could exploit this vulnerability by sending a malicious payload as part of the HTTP request, which may be automatically set as an environment variable. This can be used to inject JavaScript in a victim's browser. The application is vulnerable by using this component with SSI enabled, which is disabled by default. The SSI component is toggled on or off in the $CATALINA_BASE/conf/web.xml file. For more information see https://tomcat.apache.org/tomcat-7.0-doc/ssi-howto.htmlPlan to update the no vulnerability version in F version
usecase-ui-serverorg.apache.tomcat.embed
CVE-2018-1304IneffectiveYesThe URL pattern of "" (the empty string) which exactly maps to the context root was not correctly handled in Apache Tomcat 9.0.0.M1 to 9.0.4, 8.5.0 to 8.5.27, 8.0.0.RC1 to 8.0.49 and 7.0.0 to 7.0.84 when used as part of a security constraint definition. This caused the constraint to be ignored. It was, therefore, possible for unauthorised users to gain access to web application resources that should have been protected. Only security constraints with a URL pattern of the empty string were affected. Apache Tomcat Catalina does not always properly process security constraints. The findSecurityConstraints method in RealmBase.java ignores security constraints mapped to a URI path of “” instead of correctly parsing them as the root path. This could potentially allow users unintentional access to restricted resources. This vulnerability can be mitigated by ensuring that all security constraints set to an empty string are instead specifically mapped to the root directory (“/“).Plan to update the no vulnerability version in F version
usecase-ui-serverorg.apache.tomcat.embed
CVE-2018-8037IneffectiveYesIf an async request was completed by the application at the same time as the container triggered the async timeout, a race condition existed that could result in a user seeing a response intended for a different user. An additional issue was present in the NIO and NIO2 connectors that did not correctly track the closure of the connection when an async request was completed by the application and timed out by the container at the same time. This could also result in a user seeing a response intended for another user. Versions Affected: Apache Tomcat 9.0.0.M9 to 9.0.9 and 8.5.5 to 8.5.31. Apache Tomcat is vulnerable to Session Hijacking. The isClosed() method in the NioSocketWrapper and Nio2SocketWrapper classes, which is accessed from multiple threads, does not use volatile variables to store the closed field of their associated Socket objects. This means that one thread might query whether the Socket is closed while another thread is in the process of closing it; this results in a race condition, wherein a user session might be reused with a Socket that formerly belonged to another user, and was presumed closed. Because the Socket belonged to another user, the connection and session remains active. An attacker can exploit this vulnerability by attempting to trigger the race condition, allowing the attacker to possibly take control of another user's session. Note that the attacker cannot choose which session to hijack; it is entirely dependent on the non-deterministic nature of the race condition.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.apache.tomcat.embed
CVE-2017-7674IneffectiveYesThe CORS Filter in Apache Tomcat 9.0.0.M1 to 9.0.0.M21, 8.5.0 to 8.5.15, 8.0.0.RC1 to 8.0.44 and 7.0.41 to 7.0.78 did not add an HTTP Vary header indicating that the response varies depending on Origin. This permitted client and server side cache poisoning in some circumstances. Apache Tomcat is susceptible to Server Side Cache Poisoning. The handleSimpleCORS method in theCorsFilter.java class did not add a HTTP Vary header (Vary: Origin) indicating the HTTP server response should vary depending on the Origin header sent from the client. Without adding the Vary: Origin header to the HTTP response or ensuring other appropriate control directives are used to prevent caching of responses, an attacker could craft a request to the server which may lead to Server Side Cache Poisoning via HTTP header injection.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.apache.tomcat.embed
CVE-2018-11784IneffectiveYesWhen the default servlet in Apache Tomcat versions 9.0.0.M1 to 9.0.11, 8.5.0 to 8.5.33 and 7.0.23 to 7.0.90 returned a redirect to a directory (e.g. redirecting to '/foo/' when the user requested '/foo') a specially crafted URL could be used to cause the redirect to be generated to any URI of the attackers choice. The Apache tomcat-catalina package is vulnerable to an Open Redirect attack. The doDirectoryRedirect() method in the DefaultServlet class improperly handles leading slashes (/) in redirect URLs. A remote attacker can exploit this vulnerability by crafting a request containing a protocol-relative redirect URL to their malicious site. The attacker can then entice a victim into submitting this request, allowing the attacker to perform various other attacks. The application is vulnerable by using this component if it is configured to allow redirects to be issued from the DefaultServlet.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.jboss.netty
CVE-2015-2156IneffectiveYesNetty before 3.9.8.Final, 3.10.x before 3.10.3.Final, 4.0.x before 4.0.28.Final, and 4.1.x before 4.1.0.Beta5 and Play Framework 2.x before 2.3.9 might allow remote attackers to bypass the httpOnly flag on cookies and obtain sensitive information by leveraging improper validation of cookie name and value characters. Netty is vulnerable to Information Disclosure. Multiple methods in multiple files improperly validate cookie names and values. This allows the presence of single-quote and double-quote characters to break tokenization. A remote attacker can exploit this vulnerability by inducing a victim to send a crafted request containing quote characters in any parameter value that sets a cookie. If that tainted cookie gets reflected in the response, the attacker can then use Cross-Site Scripting (XSS) to potentially retrieve the entire cookie header, despite the presence of an HttpOnly flag. The application is vulnerable by using this component if it reflects any cookie information in a HTML page, and that page is also prone to Cross-Site Scripting (XSS) attacks.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.springframework.data
N/AIneffectiveYesThe jquery package is vulnerable to Prototype Pollution. The jQuery.extend and jQuery.fn.extend functions defined in many files allow an untrusted object to extend Object.prototype. An attacker can modify and add prototype properties to JavaScript objects and can potentially leverage those changes to crash the application or execute remote code.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.springframework.data
CVE-2018-14042IneffectiveYesIn Bootstrap before 4.1.2, XSS is possible in the data-container property of tooltip. The bootstrap package is vulnerable to Cross-Site Scripting (XSS). The show() function in the tooltip.js file allows HTML and scripts in the data-container tooltip attribute values in the DOM elements without proper sanitization. This can be misused to cause XSS.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.springframework.data
CVE-2019-8331IneffectiveYesIn Bootstrap before 3.4.1 and 4.3.x before 4.3.1, XSS is possible in the tooltip or popover data-template attribute. The bootstrap package is vulnerable to Cross-Site Scripting (XSS). The setElementContent method in the tooltip.js file accepts JavaScript within the input parameters without properly sanitizing the data in the elements that are being rendered on the webpage. This could lead to Cross-Site Scripting (XSS).Plan to update the no vulnerability version in F version
usecase-ui-serverorg.springframework.data
N/AIneffectiveYesThe jQuery package is vulnerable to Cross-Site Scripting (XSS). The parseHTML() function in the parseHTML.js, jquery.js files allow JavaScript to be executed immediately when it's embedded within the event attributes. An attacker can exploit this vulnerability by injecting malicious JavaScript containing events handlers which, when rendered, results in the execution of arbitrary script.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.springframework.data
N/AIneffectiveYesThe bootstrap package is vulnerable to Cross-Site Scripting (XSS). The data-target attribute in bootstrap.js interprets encoded HTML entities as standard HTML entities when data-target is based on user supplied input. A remote attacker can exploit this vulnerability by crafting input containing malicious JavaScript, and injecting it into a data-target attribute, which results in Cross-Site Scripting (XSS).Plan to update the no vulnerability version in F version
usecase-ui-serverpostgresql
CVE-2018-10936IneffectiveYesA weakness was found in postgresql-jdbc before version 42.2.5. It was possible to provide an SSL Factory and not check the host name if a host name verifier was not provided to the driver. This could lead to a condition where a man-in-the-middle attacker could masquerade as a trusted server by providing a certificate for the wrong host, as long as it was signed by a trusted CA. The postgresql package is vulnerable to Man-in-the-Middle (MitM) attacks. When using a non-default SSL Factory, the postgresql jdbc doesn't validate the hostname of SSL certificates. An attacker can potentially exploit this behavior to perform a MitM attack. The application is vulnerable by using this component when using SSL without the default LibPQFactory SSL factory.Plan to update the no vulnerability version in F version
usecase-ui-servercommons-codecN/AIneffectiveYesThe Apache commons-codec package contains an Improper Input Validation vulnerability. The decode() method in the Base32, Base64, and BCodec classes fails to reject malformed Base32 and Base64 encoded strings and consequently decodes them into arbitrary values. A remote attacker can leverage this vulnerability to potentially tunnel additional information via seemingly legitimate Base32 or Base64 encoded strings.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.elasticsearch
CVE-2019-7614IneffectiveYesA race condition flaw was found in the response headers Elasticsearch versions before 7.2.1 and 6.8.2 returns to a request. On a system with multiple users submitting requests, it could be possible for an attacker to gain access to response header containing sensitive data from another user.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.springframework.data
CVE-2019-3802IneffectiveYesThis affects Spring Data JPA in versions up to and including 2.1.6, 2.0.14 and 1.11.20. ExampleMatcher using ExampleMatcher.StringMatcher.STARTING, ExampleMatcher.StringMatcher.ENDING or ExampleMatcher.StringMatcher.CONTAINING could return more results than anticipated when a maliciously crafted example value is supplied. Spring Data JPA is vulnerable to Wildcard Injection. The getPredicates() method of the QueryByExamplePredicateBuilder class does not properly escape wildcards in fields when processing the predicate options STARTING, ENDING, and CONTAINING. A remote attacker can exploit this behavior by submitting a crafted request that propagates a wildcard character to a field which is later used to build a QBE. Attackers may leverage this vulnerability to modify queries to cover more entries than intended by the application.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.webjarsCVE-2018-14042IneffectiveYesIn Bootstrap before 4.1.2, XSS is possible in the data-container property of tooltip. The bootstrap package is vulnerable to Cross-Site Scripting (XSS). The show() function in the tooltip.js file allows HTML and scripts in the data-container tooltip attribute values in the DOM elements without proper sanitization. This can be misused to cause XSS.Plan to update the no vulnerability version in F version
usecase-ui-serverorg.webjarsCVE-2019-8331IneffectiveYesIn Bootstrap before 3.4.1 and 4.3.x before 4.3.1, XSS is possible in the tooltip or popover data-template attribute. The bootstrap package is vulnerable to Cross-Site Scripting (XSS). The setElementContent method in the tooltip.js file accepts JavaScript within the input parameters without properly sanitizing the data in the elements that are being rendered on the webpage. This could lead to Cross-Site Scripting (XSS).Plan to update the no vulnerability version in F version
usecase-ui-serverorg.webjarsN/AIneffectiveYesThe bootstrap package is vulnerable to Cross-Site Scripting (XSS). The data-target attribute in bootstrap.js interprets encoded HTML entities as standard HTML entities when data-target is based on user supplied input. A remote attacker can exploit this vulnerability by crafting input containing malicious JavaScript, and injecting it into a data-target attribute, which results in Cross-Site Scripting (XSS).Plan to update the no vulnerability version in F version