diff --git a/java/ql/src/experimental/Security/CWE/CWE-502/SpringExporterUnsafeDeserialization.qhelp b/java/ql/src/experimental/Security/CWE/CWE-502/UnsafeSpringExporterInConfigurationClass.qhelp
similarity index 95%
rename from java/ql/src/experimental/Security/CWE/CWE-502/SpringExporterUnsafeDeserialization.qhelp
rename to java/ql/src/experimental/Security/CWE/CWE-502/UnsafeSpringExporterInConfigurationClass.qhelp
index 04ddac33aaf2f..87a57b0a43cb6 100644
--- a/java/ql/src/experimental/Security/CWE/CWE-502/SpringExporterUnsafeDeserialization.qhelp
+++ b/java/ql/src/experimental/Security/CWE/CWE-502/UnsafeSpringExporterInConfigurationClass.qhelp
@@ -46,10 +46,6 @@ The following example shows how a vulnerable HTTP endpoint can be defined
using HttpInvokerServiceExporter
and Spring annotations:
-The next examples shows how the same vulnerable endpoint can be defined in a Spring XML config: -
-
+The Spring Framework provides an abstract base class RemoteInvocationSerializingExporter
+for creating remote service exporters.
+A Spring exporter, which is based on this class, deserializes incoming data using ObjectInputStream
.
+Deserializing untrusted data is easily exploitable and in many cases allows an attacker
+to execute arbitrary code.
+
+The Spring Framework also provides two classes that extend RemoteInvocationSerializingExporter
:
+
HttpInvokerServiceExporter
+SimpleHttpInvokerServiceExporter
+
+These classes export specified beans as HTTP endpoints that deserialize data from an HTTP request
+using unsafe ObjectInputStream
. If a remote attacker can reach such endpoints,
+it results in remote code execution in the worst case.
+
+CVE-2016-1000027 has been assigned to this issue in the Spring Framework. +It is regarded as a design limitation, and can be mitigated but not fixed outright. +
+
+Avoid using HttpInvokerServiceExporter
, SimpleHttpInvokerServiceExporter
+and any other exporter that is based on RemoteInvocationSerializingExporter
.
+Instead, use other message formats for API endpoints (for example, JSON),
+but make sure that the underlying deserialization mechanism is properly configured
+so that deserialization attacks are not possible. If the vulnerable exporters can not be replaced,
+consider using global deserialization filters introduced in JEP 290.
+
+The next examples shows how a vulnerable HTTP endpoint can be defined in a Spring XML config: +
+