+I recommend upgrading. ([[!debcve CVE-2009-2944]])
+
+## javascript insertion via svg uris
+
+Ivan Shmakov pointed out that the htmlscrubber allowed `data:image/*` urls,
+including `data:image/svg+xml`. But svg can contain javascript, so that is
+unsafe.
+
+This hole was discovered on 12 March 2010 and fixed the same day
+with the release of ikiwiki 3.20100312.
+A fix was also backported to Debian etch, as version 2.53.5. I recommend
+upgrading to one of these versions if your wiki can be edited by third
+parties.
+
+## javascript insertion via insufficient htmlscrubbing of comments
+
+Kevin Riggle noticed that it was not possible to configure
+`htmlscrubber_skip` to scrub comments while leaving unscubbed the text
+of eg, blog posts. Confusingly, setting it to "* and !comment(*)" did not
+scrub comments.
+
+Additionally, it was discovered that comments' html was never scrubbed during
+preview or moderation of comments with such a configuration.
+
+These problems were discovered on 12 November 2010 and fixed the same
+hour with the release of ikiwiki 3.20101112. ([[!debcve CVE-2010-1673]])
+
+## javascript insertion via insufficient checking in comments
+
+Dave B noticed that attempting to comment on an illegal page name could be
+used for an XSS attack.
+
+This hole was discovered on 22 Jan 2011 and fixed the same day with
+the release of ikiwiki 3.20110122. A fix was backported to Debian squeeze,
+as version 3.20100815.5. An upgrade is recommended for sites
+with the comments plugin enabled. ([[!debcve CVE-2011-0428]])
+
+## possible javascript insertion via insufficient htmlscrubbing of alternate stylesheets
+
+Giuseppe Bilotta noticed that 'meta stylesheet` directives allowed anyone
+who could upload a malicious stylesheet to a site to add it to a
+page as an alternate stylesheet, or replacing the default stylesheet.
+
+This hole was discovered on 28 Mar 2011 and fixed the same hour with
+the release of ikiwiki 3.20110328. A fix was backported to Debian squeeze,
+as version 3.20100815.6. An upgrade is recommended for sites that have
+untrusted committers, or have the attachments plugin enabled.
+([[!debcve CVE-2011-1401]])
+
+## tty hijacking via ikiwiki-mass-rebuild
+
+Ludwig Nussel discovered a way for users to hijack root's tty when
+ikiwiki-mass-rebuild was run. Additionally, there was some potential
+for information disclosure via symlinks. ([[!debcve CVE-2011-1408]])
+
+This hole was discovered on 8 June 2011 and fixed the same day with
+the release of ikiwiki 3.20110608. Note that the fix is dependant on
+a version of su that has a similar hole fixed. Version 4.1.5 of the shadow
+package contains the fixed su; [[!debbug 628843]] tracks fixing the hole in
+Debian. An upgrade is a must for any sites that have `ikiwiki-update-wikilist`
+installed suid (not the default), and whose admins run `ikiwiki-mass-rebuild`.
+
+## javascript insertion via meta tags
+
+Raúl Benencia discovered an additional XSS exposure in the meta plugin.
+([[!debcve CVE-2012-0220]])
+
+This hole was discovered on 16 May 2012 and fixed the same day with
+the release of ikiwiki 3.20120516. A fix was backported to Debian squeeze,
+as version 3.20100815.9. An upgrade is recommended for all sites.
+
+## XSS via openid selector
+
+Raghav Bisht discovered this XSS in the openid selector. ([[!debcve CVE-2015-2793]])
+
+The hole was reported on March 24th, a fix was developed on March 27th,
+and the fixed version 3.20150329 was released on the 29th. A fix was backported
+to Debian jessie as version 3.20141016.2 and to Debian wheezy as version
+3.20120629.2. An upgrade is recommended for sites using CGI and openid.
+
+## XSS via error messages
+
+CGI error messages did not escape HTML meta-characters, potentially
+allowing an attacker to carry out cross-site scripting by directing a
+user to a URL that would result in a crafted ikiwiki error message. This
+was discovered on 4 May by the ikiwiki developers, and the fixed version
+3.20160506 was released on 6 May. The same fixes were backported to Debian
+8 "jessie" in version 3.20141016.3. A backport to Debian 7 "wheezy" is
+in progress.
+
+An upgrade is recommended for sites using
+the CGI. ([[!debcve CVE-2016-4561]], OVE-20160505-0012)
+
+## ImageMagick CVE-2016–3714 ("ImageTragick")
+
+ikiwiki 3.20160506 and 3.20141016.3 attempt to mitigate
+[[!debcve CVE-2016-3714]], and any
+future ImageMagick vulnerabilities that resemble it, by restricting the
+image formats that the [[ikiwiki/directive/img]] directive is willing to
+resize. An upgrade is recommended for sites where an untrusted user is
+able to attach images. Upgrading ImageMagick to a version where
+CVE-2016-3714 has been fixed is also recommended, but at the time of
+writing no such version is available.
+
+## Perl CVE-2016-1238 (current working directory in search path)
+
+ikiwiki 3.20160728 attempts to mitigate [[!debcve CVE-2016-1238]] by
+removing `'.'` from the Perl library search path. An attacker with write
+access to ikiwiki's current working directory could potentially use this
+vulnerability to execute arbitrary Perl code. An upgrade is recommended
+for sites where an untrusted user is able to attach files with arbitrary
+names and/or run a setuid ikiwiki wrapper with a working directory of
+their choice.
+
+## <span id="cve-2016-9645">Editing restriction bypass for git revert</span>
+
+intrigeri discovered that a web or git user could revert a change to a
+page they are not allowed to edit, if the change being reverted was made
+before the page was moved from a location where that user had permission
+to edit it. For example, if a file is moved from `drafts/policy.mdwn`
+(editable by less-trusted users) to `policy.mdwn` (only editable
+by more-trusted users), a less-trusted user could revert a change
+that was made to `drafts/policy.mdwn` prior to that move, and it would
+result in `policy.mdwn` being altered.
+
+This affects sites with the `git` VCS and the `recentchanges` plugin,
+which are both used in most ikiwiki installations.
+
+This bug was reported on 2016-12-17. A partially fixed version
+3.20161219 was released on 2016-12-19, but the solution used in that
+version was not effective with git versions older than 2.8.0.
+A more complete fix was released on 2016-12-29 in version 3.20161229,
+with fixes backported to Debian 8 in version 3.20141016.4.
+
+([[!debcve CVE-2016-10026]] represents the original vulnerability.
+[[!debcve CVE-2016-9645]]/OVE-20161226-0002 represents the vulnerability
+in 3.20161219 caused by the incomplete fix.)
+
+## <span id="cve-2016-9646">Commit metadata forgery via CGI::FormBuilder context-dependent APIs</span>
+
+When CGI::FormBuilder->field("foo") is called in list context (and
+in particular in the arguments to a subroutine that takes named
+arguments), it can return zero or more values for foo from the CGI
+request, rather than the expected single value. This breaks the usual
+Perl parsing convention for named arguments, similar to CVE-2014-1572
+in Bugzilla (which was caused by a similar API design issue in CGI.pm).
+
+In ikiwiki, this appears to have been exploitable in two places, both
+of them relatively minor:
+
+* in the comments plugin, an attacker who was able to post a comment
+ could give it a user-specified author and author-URL even if the wiki
+ configuration did not allow for that, by crafting multiple values
+ for other fields
+* in the editpage plugin, an attacker who was able to edit a page
+ could potentially forge commit authorship (attribute their edit to
+ someone else) by crafting multiple values for the rcsinfo field
+
+This was fixed in ikiwiki 3.20161229, with fixes backported to Debian 8
+in version 3.20141016.4.
+
+([[!debcve CVE-2016-9646]]/OVE-20161226-0001)
+
+## <span id="cve-2017-0356">Authentication bypass via repeated parameters</span>
+
+The ikiwiki maintainers discovered further flaws similar to CVE-2016-9646
+in the passwordauth plugin's use of CGI::FormBuilder, with a more
+serious impact:
+
+* An attacker who can log in to a site with a password can log in
+ as a different and potentially more privileged user.
+* An attacker who can create a new account can set arbitrary fields
+ in the user database for that account.
+
+This was fixed in ikiwiki 3.20170111, with fixes backported to Debian 8
+in version 3.20141016.4.
+
+([[!debcve CVE-2017-0356]]/OVE-20170111-0001)
+
+## <span id="cve-2019-9187">Server-side request forgery via aggregate plugin</span>
+
+The ikiwiki maintainers discovered that the [[plugins/aggregate]] plugin
+did not use [[!cpan LWPx::ParanoidAgent]]. On sites where the
+aggregate plugin is enabled, authorized wiki editors could tell ikiwiki
+to fetch potentially undesired URIs even if LWPx::ParanoidAgent was
+installed:
+
+* local files via `file:` URIs
+* other URI schemes that might be misused by attackers, such as `gopher:`
+* hosts that resolve to loopback IP addresses (127.x.x.x)
+* hosts that resolve to RFC 1918 IP addresses (192.168.x.x etc.)
+
+This could be used by an attacker to publish information that should not have
+been accessible, cause denial of service by requesting "tarpit" URIs that are
+slow to respond, or cause undesired side-effects if local web servers implement
+["unsafe"](https://tools.ietf.org/html/rfc7231#section-4.2.1) GET requests.
+([[!debcve CVE-2019-9187]])
+
+Additionally, if the LWPx::ParanoidAgent module was not installed, the
+[[plugins/blogspam]], [[plugins/openid]] and [[plugins/pinger]] plugins
+would fall back to [[!cpan LWP]], which is susceptible to similar attacks.
+This is unlikely to be a practical problem for the blogspam plugin because
+the URL it requests is under the control of the wiki administrator, but
+the openid plugin can request URLs controlled by unauthenticated remote
+users, and the pinger plugin can request URLs controlled by authorized
+wiki editors.
+
+This is addressed in ikiwiki 3.20190228 as follows, with the same fixes
+backported to Debian 9 in version 3.20170111.1:
+
+* URI schemes other than `http:` and `https:` are not accepted, preventing
+ access to `file:`, `gopher:`, etc.
+
+* If a proxy is [[configured in the ikiwiki setup file|tips/using_a_proxy]],
+ it is used for all outgoing `http:` and `https:` requests. In this case
+ the proxy is responsible for blocking any requests that are undesired,
+ including loopback or RFC 1918 addresses.
+
+* If a proxy is not configured, and LWPx::ParanoidAgent is installed,
+ it will be used. This prevents loopback and RFC 1918 IP addresses, and
+ sets a timeout to avoid denial of service via "tarpit" URIs.
+
+* Otherwise, the ordinary LWP user-agent will be used. This allows requests
+ to loopback and RFC 1918 IP addresses, and has less robust timeout
+ behaviour. We are not treating this as a vulnerability: if this
+ behaviour is not acceptable for your site, please make sure to install
+ LWPx::ParanoidAgent or disable the affected plugins.