https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 12 Oct 2026 23:28:22 +0000 https://cve.radiocsirt.org/vuln/cnvd-2017-10711 cnvd-2017-10711 https://cve.radiocsirt.org/vuln/cnvd-2017-10711 https://cve.radiocsirt.org/vuln/euvd-2026-72961 EUVD-2026-72961 https://cve.radiocsirt.org/vuln/euvd-2026-72961 https://cve.radiocsirt.org/vuln/fkie_cve-2017-4995 <p>An issue was discovered in Pivotal Spring Security 4.2.0.RELEASE through 4.2.2.RELEASE, and Spring Security 5.0.0.M1. When configured to enable default typing, Jackson contained a deserialization vulnerability that could lead to arbitrary code execution. Jackson fixed this vulnerability by blacklisting known &#34;deserialization gadgets.&#34; Spring Security configures Jackson with global default typing enabled, which means that (through the previous exploit) arbitrary code could be executed if all of the following is true: (1) Spring Security&#39;s Jackson support is being leveraged by invoking SecurityJackson2Modules.getModules(ClassLoader) or SecurityJackson2Modules.enableDefaultTyping(ObjectMapper); (2) Jackson is used to deserialize data that is not trusted (Spring Security does not perform deserialization using Jackson, so this is an explicit choice of the user); and (3) there is an unknown (Jackson is not blacklisting it already) &#34;deserialization gadget&#34; that allows code execution present on the classpath. Jackson provides a blacklisting approach to protecting against this type of attack, but Spring Security should be proactive against blocking unknown &#34;deserialization gadgets&#34; when Spring Security enables default typing.</p> <p>An issue was discovered in Pivotal Spring Security 4.2.0.RELEASE through 4.2.2.RELEASE, and Spring Security 5.0.0.M1. When configured to enable default typing, Jackson contained a deserialization vulnerability that could lead to arbitrary code execution. Jackson fixed this vulnerability by blacklisting known &#34;deserialization gadgets.&#34; Spring Security configures Jackson with global default typing enabled, which means that (through the previous exploit) arbitrary code could be executed if all of the following is true: (1) Spring Security&#39;s Jackson support is being leveraged by invoking SecurityJackson2Modules.getModules(ClassLoader) or SecurityJackson2Modules.enableDefaultTyping(ObjectMapper); (2) Jackson is used to deserialize data that is not trusted (Spring Security does not perform deserialization using Jackson, so this is an explicit choice of the user); and (3) there is an unknown (Jackson is not blacklisting it already) &#34;deserialization gadget&#34; that allows code execution present on the classpath. Jackson provides a blacklisting approach to protecting against this type of attack, but Spring Security should be proactive against blocking unknown &#34;deserialization gadgets&#34; when Spring Security enables default typing.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2017-4995 https://cve.radiocsirt.org/vuln/ghsa-vhrg-v3cv-p247 <p><strong>Affected:</strong> Maven: org.springframework.security:spring-security-core</p> <p>An issue was discovered in Pivotal Spring Security 4.2.0.RELEASE through 4.2.2.RELEASE, and Spring Security 5.0.0.M1. When configured to enable default typing, Jackson contained a deserialization vulnerability that could lead to arbitrary code execution. Jackson fixed this vulnerability by blacklisting known &#34;deserialization gadgets.&#34; Spring Security configures Jackson with global default typing enabled, which means that (through the previous exploit) arbitrary code could be executed if all of the following is true: (1) Spring Security&#39;s Jackson support is being leveraged by invoking SecurityJackson2Modules.getModules(ClassLoader) or SecurityJackson2Modules.enableDefaultTyping(ObjectMapper); (2) Jackson is used to deserialize data that is not trusted (Spring Security does not perform deserialization using Jackson, so this is an explicit choice of the user); and (3) there is an unknown (Jackson is not blacklisting it already) &#34;deserialization gadget&#34; that allows code execution present on the classpath. Jackson provides a blacklisting approach to protecting against this type of attack, but Spring Security should be proactive against blocking unknown &#34;deserialization gadgets&#34; when Spring Security enables default typing.</p> <p><strong>Affected:</strong> Maven: org.springframework.security:spring-security-core</p> <p>An issue was discovered in Pivotal Spring Security 4.2.0.RELEASE through 4.2.2.RELEASE, and Spring Security 5.0.0.M1. When configured to enable default typing, Jackson contained a deserialization vulnerability that could lead to arbitrary code execution. Jackson fixed this vulnerability by blacklisting known &#34;deserialization gadgets.&#34; Spring Security configures Jackson with global default typing enabled, which means that (through the previous exploit) arbitrary code could be executed if all of the following is true: (1) Spring Security&#39;s Jackson support is being leveraged by invoking SecurityJackson2Modules.getModules(ClassLoader) or SecurityJackson2Modules.enableDefaultTyping(ObjectMapper); (2) Jackson is used to deserialize data that is not trusted (Spring Security does not perform deserialization using Jackson, so this is an explicit choice of the user); and (3) there is an unknown (Jackson is not blacklisting it already) &#34;deserialization gadget&#34; that allows code execution present on the classpath. Jackson provides a blacklisting approach to protecting against this type of attack, but Spring Security should be proactive against blocking unknown &#34;deserialization gadgets&#34; when Spring Security enables default typing.</p> https://cve.radiocsirt.org/vuln/ghsa-vhrg-v3cv-p247 https://cve.radiocsirt.org/vuln/gsd-2017-4995 gsd-2017-4995 https://cve.radiocsirt.org/vuln/gsd-2017-4995