diff --git a/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java b/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java
index 52398e909e2fb89e09a94be7516b463ce292c0cb..fae77efbe83440fc65090a74b014fabe61d65c71 100644
--- a/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java
+++ b/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java
@@ -44,14 +44,16 @@ public class AttackInterceptor extends InMemoryOperationInterceptor {
         // Another approach would be to exploit (de-)serialization of objects which is also supported by LDAP,
         // but for this the system property 'com.sun.jndi.ldap.object.trustURLCodebase' must
         // have been set to 'true' for almost all Java versions.
+        // You can read more about it on https://www.innoq.com/en/articles/2022/04/java-jndi/.
+        // However, the approach can be used in combination with certain classes of libraries for RCE attacks.
+        // Those classes are also called gadgets, read more about it on: https://github.com/mbechler/marshalsec.
 
-        // Other approach: https://www.innoq.com/en/articles/2022/04/java-jndi/
-
-        // With this approach, it's not required to set the property for Java version <= 8u191.
+        // With the factory approach, it's not required to set the property for Java version <= 8u191.
         // https://news.ycombinator.com/item?id=29505027
         // https://www.lunasec.io/docs/blog/log4j-zero-day/
         // We've confirmed this with JDK & JRE 1.8.0u111 available at
         // https://www.oracle.com/de/java/technologies/javase/javase8-archive-downloads.html
+        // We suppose the problem is caused by CVE 2018-3149: https://bugzilla.redhat.com/show_bug.cgi?id=1639834.
 
         try {
             // Sends the newly generated malicious entry back to the requester