diff --git a/java/ql/src/experimental/Security/CWE/CWE-020/Log4jJndiInjection.qhelp b/java/ql/src/experimental/Security/CWE/CWE-020/Log4jJndiInjection.qhelp
index 2cddda46b27e..b2bd834465c6 100644
--- a/java/ql/src/experimental/Security/CWE/CWE-020/Log4jJndiInjection.qhelp
+++ b/java/ql/src/experimental/Security/CWE/CWE-020/Log4jJndiInjection.qhelp
@@ -5,19 +5,19 @@
 
 <overview>
 <p>
-Log4j versions prior to 2.15.0 are subject to a remote code execution vulnerability via the ldap JNDI parser.
+This query flags up situations in which untrusted user data is included in Log4j messages. If an application uses a Log4j version prior to 2.15.0, using untrusted user data in log messages will make an application vulnerable to remote code execution through Log4j's LDAP JNDI parser (CVE-2021-44228).
 </p>
 <p>
 As per Apache's Log4j security guide: Apache Log4j2 &lt;=2.14.1 JNDI features used in configuration, log messages, and parameters 
 do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or 
 log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. 
-From log4j 2.15.0, this behavior has been disabled by default.
+From Log4j 2.15.0, this behavior has been disabled by default. Note that this query will not try to determine which version of Log4j is used.
 </p>
 </overview>
 
 <recommendation>
 <p>
-This issue was remediated in Log4J v2.15.0. The Apache Logging Services team provides the following mitigation advice:
+This issue was remediated in Log4j v2.15.0. The Apache Logging Services team provides the following mitigation advice:
 </p>
 <p>
 In previous releases (>=2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true” 
@@ -25,14 +25,14 @@ or by removing the JndiLookup class from the classpath (example: zip -q -d log4j
 Java 8u121 protects against RCE by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
 </p>
 <p>
-You can manually check for use of affected versions of Log4J by searching your project repository for Log4J use, which is often in a pom.xml file.
+You can manually check for use of affected versions of Log4j by searching your project repository for Log4j use, which is often in a pom.xml file.
 </p>
 <p>
 Where possible, upgrade to Log4J version 2.15.0. If you are using Log4J v1 there is a migration guide available.
 </p>
 <p>
-Please note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we 
-recommend you migrate to Log4J 2.15.0 where possible.
+Please note that Log4j v1 is End Of Life (EOL) and will not receive patches for this issue. Log4j v1 is also vulnerable to other RCE vectors and we
+recommend you migrate to Log4j 2.15.0 where possible.
 </p>
 <p>
 If upgrading is not possible, then ensure the -Dlog4j2.formatMsgNoLookups=true system property is set on both client- and server-side components.
diff --git a/java/ql/src/experimental/Security/CWE/CWE-020/Log4jJndiInjection.ql b/java/ql/src/experimental/Security/CWE/CWE-020/Log4jJndiInjection.ql
index 47dfb11da1c9..646c1f4cdb12 100644
--- a/java/ql/src/experimental/Security/CWE/CWE-020/Log4jJndiInjection.ql
+++ b/java/ql/src/experimental/Security/CWE/CWE-020/Log4jJndiInjection.ql
@@ -1,11 +1,11 @@
 /**
- * @name Log4j JNDI Injection
+ * @name Log4j log injection and LDAP JNDI injection
  * @description Building Log4j log entries from user-controlled data may allow
  *              attackers to inject malicious code through JNDI lookups.
  * @kind path-problem
  * @problem.severity error
  * @precision high
- * @id java/log4j-jndi-injection
+ * @id java/log4j-injection
  * @tags security
  *       external/cwe/cwe-020
  *       external/cwe/cwe-074
@@ -168,7 +168,7 @@ private class LoggingSinkModels extends SinkModelCsv {
         "org.apache.logging.log4j;LogBuilder;true;log;(String,Object,Object,Object,Object,Object,Object,Object,Object);;Argument[0..8];logging",
         "org.apache.logging.log4j;LogBuilder;true;log;(String,Object,Object,Object,Object,Object,Object,Object,Object,Object);;Argument[0..9];logging",
         "org.apache.logging.log4j;LogBuilder;true;log;(String,Object,Object,Object,Object,Object,Object,Object,Object,Object,Object);;Argument[0..10];logging",
-        "org.apache.logging.log4j;LogBuilder;true;log;(String,Supplier);;Argument[0..1];logging",
+        "org.apache.logging.log4j;LogBuilder;true;log;(String,Supplier[]);;Argument[0..1];logging",
         "org.apache.logging.log4j;LogBuilder;true;log;(Supplier);;Argument[0];logging"
       ]
   }