IDEA! Get Alerted: to get immediate alerts of high priority security issues, please join the low-volume foswiki-announce list - details at MailingLists

txt plain text

Security Alert: Foswiki Script Insertion Vulnerability via unchecked user registration fields

This security advisory alerts you to an issue concerning the registration process of new users.

When a new user registers, the new user can add arbitrary HTML and script code into the user topic which is generated by the RegistrationAgent via standard registration fields such as "FirstName" or "OrganisationName".

By design, Foswiki's normal editing features allow arbitrary HTML markup, including script code, to be inserted into any topic anyway, assuming the authenticated user has CHANGE permission - which is the case on many Foswiki sites. However, the assumption that only authenticated users with CHANGE permission may create script content is false if new users exploit the vulnerability detailed in this alert to manipulate the registration agent into creating that content for them.

Severity Level

Severity 3 issue: Foswiki content or browser is compromised

The severity level was assigned by the Foswiki SecurityTaskTeam as documented in SecurityAlertProcess

MITRE Name for this Vulnerability

The Common Vulnerabilities and Exposures project has assigned the name CVE-2012-1004 to this vulnerability.

Vulnerable Software Versions

Fixed in Foswiki 1.1.5

All versions 1.0.0 - 1.1.4 inclusive for sites that use the standard user registration process

Attack Vectors

Foswiki's /bin/register (see Foswiki/UI/ does not perform any validation or sanitization of registration fields submitted for the UserForm. These input fields (Eg. "FirstName", "OrganisationName", "OrganisationUrl", etc.) could then be used to inject arbitrary HTML markup, including script code, into the user topic which is generated by the RegistrationAgent.

E-mail notifications to site administrators and other subscribed users may provide exposure to injected HTML, especially if templates have been modified to send HTML email.

If the site does not use the provided bin/register script and the UserRegistration topic and instead uses an external mechanism like LDAP, then the site is not vulnerable.


If your Foswiki installation already allows newly registered users CHANGE permission anywhere in the wiki, they have already been able to inject arbitrary HTML markup including script code, and will continue to have that ability even after the fix at has been applied. The ability of using JavaScript in Foswiki pages is a feature.

However, not all Foswiki installations have their access controls configured to immediately trust newly registered users. If your site uses a variation of the practice suggested at Support.BestPracticeTip26, that is:
  • the site allows registrations
  • newly registered users have zero CHANGE permission anywhere in the wiki
  • requires a member of AdminGroup or some ModeratorGroup to explicitly grant CHANGE permission so that new users can modify content
Then this vulnerability provides an attack vector which could allow an attacker to perform actions on the wiki on behalf of whoever visits a compromised user topic.

For example:
  • A moderator notices a suspicious user topic (Eg. via WebChanges)
  • The moderator visits the user topic, intending to delete it
  • The malicious script injected via the /bin/register vulnerability is executed
  • The malicious script makes requests on behalf of the moderator user, potentially without their knowledge
Foswiki is designed to prevent several forms of cross site scripting (XSS) and cross site request forgeries (CSRF), and we will make our best effort to continue to both pro-actively review code for security holes and react to vulnerability reports sent to us.


Foswiki has made a hot fix available for Foswiki which "safe encodes" the registration fields in the register script. The fix, detailed below, adds 3 lines of code to lib/Foswiki/UI/

Foswiki 1.1.5 will contain a more extensive fix that adds pluggable validation in the User Mapper code. This permits installations using customized mappers to do additional validations specific to their installation. Date of release of 1.1.5 not yet decided.

  • For 1.1.4 Apply the hotfix made available by replacing the lib/Foswiki/UI/
  • For earlier releases make a manual edit of as described below. Or better - upgrade to 1.1.4 and apply patch.
  • Upgrade to the latest patched production Foswiki 1.1.5 once it is released.

Hotfix for Foswiki Production Releases 1.1.0-1.1.4

This fix is currently tested on all versions of Foswiki since 1.1.0. It assumes that <, >, %, ' and " cannot occur in any field except the password. The other fields listed below are validated elsewhere.In lib/Foswiki/UI/, search for the line "#DO NOT UNTAINT THESE DATA HERE" and insert the code as shown in here marked with ">":

>            unless ( $name =~ m/^(?:wikiname|name|loginname|username|password|confirm)$/i ) {
>                $value =~ s/([<>%'"])/'&#'.ord($1).';'/ge;
>            }
            $data->{$name} = $value;

Action Plan with Timeline

# Action Date/ Deadline Status Who
1. Uncoordinated reports are made public 2012-02-02 N/A Sony
2. Developers verify issue 2012-02-02 Done Sven Dowideit, George Clark
3. Security team triage the issue 2012-02-03 Done George Clark, Paul Harvey
4. Developer fixes code, Tasks.Item11501 2012-02-08 Being worked on George Clark
5. Security team creates advisory with hotfix 2012-02-09 Done George Clark, Paul Harvey
6. Send alert to foswiki-announce and foswiki-discuss mailing lists 2012-02-09 Done Paul Harvey
7. Publish advisory in Support web and update all related topics 2012-02-09 Done Paul Harvey
8. Reference to public advisory on Download page and Known Issues 2012-02-09 Done Paul Harvey
9. Issue a public security advisory (,,,, 2012-02-09 Done Paul Harvey
The following sites are known to be reporting this issue:

Topic attachments
I Attachment Action Size Date Who Comment
Register.pmpm manage 49.7 K 09 Feb 2012 - 00:12 GeorgeClark Patched from Foswiki 1.1.4
Topic revision: r18 - 13 Apr 2012, PaulHarvey
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License