This is a general authentication security hole with Confluence tested in version 2.10.2.

Here is how the attack works:
1.Attacker logs in via the login page and two things happen:
a.A cookie gets stored on their browser with name=JSESSIONID, value=cookie_val, path=/, domain= whaterver the domain is (perhaps A.B.example.com).
b.A record gets stored to some database tying the attackers account to cookie_val.
2.The attacker logs out via the logout.action script.
a.The record on the database tying the attacker's account to cookie_val gets deleted or inactivated.
b.The cookie on the attacker's browser doesn't get deleted (but even if it did they could restore it since the attacker has complete control over their own browser).
3.The attacker stores a cookie to the victim's browser:
a.The cookie that is stored has name=JSESSIONID, value=cookie_val, path=/, domain= the most general parent doman (perhaps .example.com) under which Confluence is located (this cookie will be submitted to every page in any subdomain of that parent domain and can be set in any subdomain of that parent domanin).
b.The most common way that an attacker would store a cookie on a victim's browser is through an XSS hole (http://www.owasp.org/index.php/XSS), but other vectors exist such as header injection.
4.The victim clicks on a link that the attacker provides (which stores the cookie on the victim's browser and redirects them to the login page) and then the victim logs in normally.
a.When the victim logs in, a record gets stored to some database tying the victim's account to cookie_val passed in.
5.The attacker (who has the same cookie as the victim now) goes to dashboard.action and can act as the victim.