This page attempts to summarize all the ESAPI Security Bulletins and GitHub Security Advisories in a table format. This started out as a lengthy email to the ESAPI User's Google group which you can find at "A word about Log4J vulnerabilities in ESAPI - the TL;DR version", but then morphed into this current format as more and more Log4J 1.x vulnerabilities were discovered as well as one in ESAPI itself that we felt compelled to detail.
Note that not all CVEs for ESAPI are reflected here as we only wrote ESAPI Security Bulletins for CVEs that we believed were either not exploitable via standard ESAPI configurations or that required special explanation above and beyond was provided in the description of the CVE.
| Relevant ESAPI Security Bulletin / GitHub Security Advisory | Summary | Relevant CWEs | Relevant Vuln ID | Notes regarding potential impact | ESAPI versions where default configuration is impacted |
| 1 | MAC bypass in ESAPI symmetric encryption | CWE-310 | CVE-2013-5679 | MAC check may be bypassed thus not assuring the authenticity of the received ciphertext. | ESAPI 2.x versions before 2.1.0 |
| 2 | Java deserialization vulnerability in Log4J 1 (via SocketServer) for ESAPI logging may lead to code injection | CWE-502 | CVE-2019-17571 | SocketServer is a class presumably intended for aggregating Log4J log events. It is a server-side class. ESAPI does not use it, nor any Log4J 1 classes that use it. | None.ESAPI 2.x versions 2.2.1.0 and later default to use JUL (java.util.logging) |
| 3 | This flaw allows a specially-crafted XML file to manipulate the validation process in processed by Xerces’ XMLSchemaValidation class in certain cases. | CWE-20 | SNYK-JAVA-XERCES-608891 (related to CVE-2020-14621) | An analysis of the ESAPI and Xerces code shows that ESAPI does not use the vulnerable Xerces class either directly or indirectly. | None, but fixed even with respect to SCA tools for ESAPI 2.2.3.0 and later which AntiSamy 1.6.2, which uses Xerces 2.12.1, where this vulnerability is fixed. |
| 4 | SMTPS (SMTP over SSL/TLS) can allow MITM attack if SMTPAppender is used with Log4J 1 ESAPI logging. | CWE-295 | CVE-2020-9488 | If you are using Log4J 1’s SMTPAppender in your code, you already have a direct dependency that makes it exploitable. ESAPI does nothing to cause or prevent that. | None. ESAPI uses ConsoleAppender as the default appender even if ESAPI logging is configured to use Log4J 1. |
| 5 | Invoking the method Commons IO method, FileNameUtils.normalize() with an improper input string could allow a limited path traversal. | CWE-22 | CVE-2021-29425 | Commons IO is being pulled in via AntiSamy, which pulls in Apache Batik-CSS. Batik-CSS is part of a larger Apache Xmlgraphics Batik family.Nothing in the Batik family of libraries uses org.apache.commons.io.FileNameUtils and neither ESAPI nor AntiSamy use Commons IO directly. Thus ESAPI is not affected by this CVE. | None. However may still show up in SCA output as AntiSamy using latest Apache Commons IO library version (2.6) that still support Java 7. AntiSamy 1.7 and later will require Java 8 as will ESAPI versions after 2.3. |
| 6 | Flaw in Log4J 1’s JSMAppender could cause insecure deserialization potentially leading to remote code execution. | CWE-502 | CVE-2021-4104 | All versions of ESAPI are vulnerable and impacted if your application is doing all 3 of the following:1) Using the deprecated ESAPI Log4J logging.2) You have changed your default log4j.xml (or log4j.properties) file to use JMSAppender.3) An attacker is able to overwrite the contents of your Log4J 1 configuration file. | None. ESAPI uses ConsoleAppender as the default appender even if ESAPI logging is configured to use Log4J 1. |
| 7 | Improper validation (or, specifically, not using parameterized SQL queries) of a SQL statement makes Apache Log4j JDBCAppender vulnerable to SQL Injection. This potentially could allow attackers to execute unintended SQL statements by entering data that is logged via Log4J 1. | CWE-89 | CVE-2022-23305 | All versions of ESAPI are vulnerable and impacted if your application is doing both of the following:1) Using the deprecated ESAPI Log4J logging.2) You have changed your default log4j.xml (or log4j.properties) file to use JDBCAppender. | None. ESAPI uses ConsoleAppender as the default appender even if ESAPI logging is configured to use Log4J 1. |
| 8 GHSA-q77q-vx4q-xx6q |
Improper sanitization of user-controlled input permitted by an incorrect regular expression in an ESAPI configuration file can result in that input being unintentionally executing javascript: URLs, resulting in Cross-Site Scripting (XSS). | CWE-79 | CVE-2022-24891 | A malformed regular expression in ESAPI’s default AntiSamy policy file, “antisamy-esapi.xml”, accidentally allowed the “:” character to match as a part of the “onsiteURL” regular expression. This allowed 'javascript:' pseudo-URIs to slip past ESAPI which could result in XSS vulnerabilities. Note that this vulnerability dates back at least to the ESAPI 1.4 release. | ESAPI 1.4 and all ESAPI 2.x versions before 2.3.0.0. |
| 9 | Apache Log4j 1’s JMSSink is vulnerable to insecure deserialization of untrusted logged data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service that the attacker has access to. This may resulting in remote code execution. | CWE-502 | CVE-2022-23302 | Remote Code Execution is possible. | None. ESAPI uses ConsoleAppender as the default appender even if ESAPI logging is configured to use Log4J 1. |
| 10 | There is an RCE flaw caused by an insecure deserialization vulnerability in Apache Chainsaw, a Java-based GUI log viewer. CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw 2.x prior to 2.1.0. However, prior to Chainsaw V2.0, Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists and remains unfixed. | CWE-502 | CVE-2022-23307 | Remote Code Execution is possible if you are running Apache Chainsaw 1.x from the Apache Log4J 1.2.x jar. | None. ESAPI uses ConsoleAppender as the default appender even if ESAPI logging is configured to use Log4J 1. |
| GHSA-8m5h-hrqm-pxm2 | The default implementation of Validator.getValidDirectoryPath(String, String, File, boolean) may incorrectly treat the tested input string as a child of the specified parent directory. This potentially could allow control-flow bypass checks to be defeated if an attack can specify the entire string representing the 'input' path. |
CWE-22 | CVE-2022-23457 | Control-flow bypass may be possible. | ESAPI 2.x, prior to the ESAPI 2.3.0.0 release. Version 2.3.0.0 and later are patched. |
| 11 | There is a DoS vulerablity in the FileUploadBase class of Apache Commons FileUpload for releases prior to 1.5. That DoS vulnerability is caused by not limiting the number of files that could be uploaded per single request. | CWE-770 | CVE-2023-24998 | None. ESAPI uses a subclass of the affected FileUpladBase abstract class from Apache Commons FileUpload to which a new setFileCountMax() method was added. | Addressed in ESAPI 2.5.2.0 and later. |
| GHSA-r68h-jhhj-9jvm | Decribes why ESAPI's Validator.isValidSafeHTML is being deprecated and will be removed one year after the ESAPI 2.5.3.0 release date. | CWE-80 | N/A (no CVE) | XSS may be possible depending on how the method is used. | All ESAPI versions (all 1.x and 2.x versions). No patch is available until the methods are deleted one year after the ESAPI 2.5.3.0 release date. |