diff --git a/site/src/site/pages/security.groovy b/site/src/site/pages/security.groovy
index 1e0f73b..8e3f610 100644
--- a/site/src/site/pages/security.groovy
+++ b/site/src/site/pages/security.groovy
@@ -11,6 +11,7 @@
                                     a(href: '#security', "Security updates")
                                     a(href: '#CVE-2015-3253', "CVE-2015-3253")
                                     a(href: '#CVE-2016-6814', "CVE-2016-6814")
+                                    a(href: '#CVE-2020-17521', "CVE-2020-17521")
                                     a(href: '#reporting', "Reporting problems")
                                 }
                             }
@@ -136,6 +137,98 @@
 * http://groovy-lang.org/security.html
 
 '''
+                            a(name: 'CVE-2020-17521') {}
+                            h2 'CVE-2020-17521 Apache Groovy Information Disclosure'
+                            asciidoc '''
+Severity: Important
+
+Vendor: The Apache Software Foundation
+
+Versions Affected:
+
+Unsupported Codehaus versions of Groovy from 2.0 to 2.4.4.
+Apache Groovy versions 2.4.4 to 2.4.20, 2.5.0 to 2.5.13,
+3.0.0 to 3.0.6, and 4.0.0-alpha-1.
+
+Fixed in versions 2.4.21, 2.5.14, 3.0.7, 4.0.0-alpha-2
+
+Impact:
+
+This vulnerability potentially impacts Unix-like systems, and very old
+versions of Mac OSX and Windows. On such OS versions, Groovy may create
+temporary directories within the OS temporary directory which is shared
+between all users on affected systems. Groovy will create such directories
+for internal use when producing Java Stubs (very low impact) or on behalf
+of user code via two extension methods[4,5] for creating temporary directories.
+If Groovy user code uses either of these extension methods, and stores
+executable code in the resulting temporary directory, then the risk is high,
+since this can lead to local privilege escalation. If such Groovy code is making
+use of the temporary directory to store sensitive information, then the risk is
+medium, since such information could be exposed or modified.
+
+When analyzing the impact of this vulnerability, here are the important
+questions to ask:
+
+Is the Groovy code running on a machine with an impacted operating system?
+Do other users have access to the machine running the Groovy code?
+Does the Groovy code create temporary directories using Groovy's
+createTempDir extension methods[4,5]?
+
+If you answer no to any of these questions, you are not affected.
+If you answered yes, does the Groovy code write or store executable code
+in the temporary directory? If you answer yes, the risk is high, and can lead to
+local privilege escalation. Does the Groovy code write sensitive information,
+like API keys or passwords, into the temporary directory? If you answer yes,
+the risk is medium, and information may be exposed or modified.
+
+Description:
+
+Groovy was making use of a method in the JDK which is now flagged as not
+suitable for security-sensitive contexts. In addition, Groovy wasn't checking
+a flag related to successful creation of the temporary directory which leads
+to a race condition whereby the vulnerability exists[1].
+
+For the fixed versions, Groovy 2.5 and above is now using a newer JDK method
+which creates a directory that is only readable by the user running the Groovy
+code. The same is true for the fixed Groovy 2.4 version except if running
+on a pre-JDK7 version of the JDK in which case a fallback implementation is
+used which now checks for successful creation of the temporary directory.
+This eliminates the high-risk scenario involving the race condition whereby
+executables or information could be modified, but still leaves the potential
+for sensitive information leakage. Groovy 2.4/JDK 6 users are recommended
+to use the `java.io.tmpdir` mitigation.
+
+Mitigation:
+
+Setting the `java.io.tmpdir` system environment variable to a directory
+that is exclusively owned by the executing user will fix this vulnerability
+for all operating systems and all Groovy versions.
+
+Users who cannot easily move to the fixed Groovy versions may wish to
+consider using the JDK's Files#createTempDirectory method instead of the
+Groovy extension methods.
+
+Credit:
+
+This vulnerability was discovered by Jonathan Leitschuh (https://twitter.com/jlleitschuh)
+
+Similar Vulnerabilities:
+
+* Jetty - https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6
+* JUnit4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp
+* Google Guava - https://github.com/google/guava/issues/4011
+* Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945
+* JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
+
+References:
+
+[1] CWE-379: Creation of Temporary File in Directory with Insecure Permissions (https://cwe.mitre.org/data/definitions/379.html)
+[2] "File.createTempFile" should not be used to create a directory (https://rules.sonarsource.com/java/tag/owasp/RSPEC-2976)
+[3] Groovy CVE list (https://groovy-lang.org/security.html)
+[4] https://docs.groovy-lang.org/latest/html/groovy-jdk/java/io/File.html#createTempDir()
+[5] https://docs.groovy-lang.org/latest/html/groovy-jdk/java/io/File.html#createTempDir(java.lang.String,%20java.lang.String)
+[6] related Jira issue: https://issues.apache.org/jira/browse/GROOVY-9824
+'''
 
                             a(name: 'reporting') {}
                             h2 "Reporting problems"