Author: engelen Date: Fri Jun 5 16:56:44 2026 New Revision: 1935041 Log: security model: describe Java deserialization
as discussed in https://lists.apache.org/thread/dwrom69bbkm839ppozh7t4fq8qsns890 Modified: commons/cms-site/trunk/content/xdoc/security.xml Modified: commons/cms-site/trunk/content/xdoc/security.xml ============================================================================== --- commons/cms-site/trunk/content/xdoc/security.xml Fri Jun 5 16:54:38 2026 (r1935040) +++ commons/cms-site/trunk/content/xdoc/security.xml Fri Jun 5 16:56:44 2026 (r1935041) @@ -74,7 +74,18 @@ Therefore, don't report a behavior as a Commons component's vulnerability if the same behavior would be considered legitimate for the JDK. We welcome suggestions for hardening the code base. </p> - + <p> + When applications applications use Java serialization to deserialize untrusted + input, we consider this a vulnerability in that application. To exploit such a + vulnerability, the attacker needs to find a 'gadget' class on the classpath. + Several Commons libraries contain classes that can be used as such a 'gadget'. + We do not consider this a vulnerability in Commons, but we do welcome + contributions that make Commons classes unusable for such attacks. If you want + to safely deserialize untrusted input in your application, consider using + <a href="https://commons.apache.org/proper/commons-io/description.html#Safe_Deserialization";>Commons IO</a>. + Also refer to <a href="https://docs.oracle.com/en/java/javase/25/core/addressing-serialization-vulnerabilities.html";>Addressing Deserialization Vulnerabilities</a> + in the Java SE Core Libraries documentation. + </p> </section> <section name="Known Security Vulnerabilities">
