Missing access controls in loadattachmentversions action

Type atlassian
Reporter phillip.langlois
Modified 2019-05-31T12:20:41


The loadattachmentsversions action is accessible to any user of Confluence and returns version history information for an attachment. No access controls appear to be implemented for this action and any user of Confluence can obtain version history for any attachment, including those on pages in inaccessible spaces, simply by specifying the appropriate resource identifier. Whilst this is a relatively minor information leak, it should be noted that the HTML returned by this action discloses the attachment file name, the users who made modifications to the attachment and any comments associated to each version. It is not inconceivable that this information may be of use to an attacker, although the risk is likely to be low.

On a test instance of Confluence, A GET request to the following URL as user “phill” returns version data for the attachment with resource id 884781:


This attachment resides on a page in a space that the user “phill” has no access to. The following HTML is returned:

<table class="aui"> <thead> <th colspan="4">Version history</th> </thead> <tbody> <tr class="history-884781" data-attachment-version="1"> <td class="attachment-version"> <a class="filename" href="/download/attachments/524789/argggghhh.js?version=1&amp;modificationDate=1380714865070&amp;api=v2" data-type="text/plain" >Version 1</a> (current version) </td> <td class="version-modified-by"> Created by <a href=" /display/~admin" class="url fn confluence-userlink" data-username="admin" >admin</a> </td> <td class="version-comment">   </td> <td class="version-modified-time">Oct 02, 2013 </td> </tr> </tbody> </table>

In this case, a single version of the attachment exists and the file name, creator user name and comments (blank in this case) are clearly visible. Note that appropriate access controls are applied if the link is accessed and the attachment itself is not accessible.