Did you try using a profiler to confirm the leak as the Tomcat Find Leak message suggests? What are the results? Do you exclude weak/soft references to the ClassLoader? If you are unfamiliar with how to profile the application, you can try Eclipse MAT, YourKit, etc.
When I profiled the application you posted there are only Soft/Weak references holding on to the ClassLoader. Many of the references were internal to the JVM/Tomcat and as far as I am aware unavoidable from Spring Security's standpoint. For example:
There are other Soft/Weak references within Spring in general that may be able to be cleaned up. However, it should be noted that Soft/Weak references are allowed to be garbage collected at any time.
[Weak/Soft Reachable] org.springframework.security.web.savedrequest.DefaultSavedRequest
referent of java.io.ObjectStreamClass$FieldReflectorKey
key of java.util.concurrent.ConcurrentHashMap$HashEntry
 of java.util.concurrent.ConcurrentHashMap$HashEntry
table of java.util.concurrent.ConcurrentHashMap$Segment
 of java.util.concurrent.ConcurrentHashMap$Segment
segments of java.util.concurrent.ConcurrentHashMap
reflectors of java.io.ObjectStreamClass$Caches [Class]
In short, the behavior I am seeing is that the Garbage Collector can reclaim the space, but has not chosen to do so yet. This is causing Tomcat to give a false positive on the leak.