As well as well known XSS vunerabilities the latest version 4.0 seems to have some other issues.

Unpatched releases of V4.0 allow the user to access the Template banning.cfm without any administrative privleages. All users of the software should check with fusetalk.com for the latest security patches to prevent this being misused.

Access to this template allows any user to ban any other users and seems to be particularly vunerable. Fortunately it does not affect the administration templates, merely the moderation ones so the chances of an attacker gaining higher levels of access seem unlikely.

Another issue seems to exist which I have only so far tested on Version 2.0 and am unsure if this also occurs in V3-4, it appears that within the administration templates adduser.cfm allows parameters to be passed by a get statement rather than a post statement.

This potential vunerability could allow a hostile to create a new account by tricking some other person with moderator powers. Although it may seem obvious that a link to 
http://www.victim.com/admin/adduser.cfm?FTVAR_FIRSTNAMEFRM=God&FTVAR_LASTNAMEFRM=God&FTVAR_EMAILADDRESSFRM=Attacker@acker.com&FTVAR_USERNAMEFRM=attacker&FTVAR_PASSWORDFRM=coolpass&FTVAR_PASSWORD2FRM=coolpass&FTVAR_USERFORUMSFRM=0&FTVAR_USERTYPEFRM=g&FTVAR_USERLEVELFRM=0&FTVAR_STATUSFRM=1&FTVAR_CITYFRM=&FTVAR_STATEFRM=70&FTVAR_COUNTRYFRM=36&FTVAR_SCRIPTRUN=self.close%28%29%3B&FTVAR_RETURNERROR=Yes&FT_ACTION=adduser
would create a new account, if the adress is hidden within an image tag [img][/img] then the event will fire the creation of the account when the administrators web browser attempts to download the image.

This could be extended by the variable FTVAR_SCRIPTRUN=self.close which even in not creating an account would be capable running malicious javascript when an administrative user attempted to follow the link.

Since fusetalk relies nearly entirely on POST based data the best fix for this is to restrict posting of data by a GET statement.