How to temporarily shield yourself from any malicious exploits that may come of this hack in the meantime:
#1 - Best bet, use Firefox + NoScript, as had been mentioned already. This is the best possible combination for all sites, not just AT. Note, this will not prevent any buffer overruns caused by malicious images, but that's a browser security issue, so make sure your browsers are up to date.
#2 - NoScript does NOT exist for IE or Chrome, and I don't believe it exists for Safari or Opera either. Other browsers, well you're on your own.
#3 - IF you use IE, please take the time to upgrade to IE8 unless you're required to use an older version. I know most companies have validated IE7 by now, so you should be running at least that. In the mean time, if you're paranoid enough, you can disable scripting support completely (but not selectively) in IE under the Internet Options > Security tab. Scroll down until you see Active Scripting and set to either disabled or prompt (which gets you as close to selective blocking) as you can get. Note, this will not disable all scripts, but it will stop a lot of the simpler exploits from happening. This information should be good for IE6/7/8, god forbid you're running anything older than that.
#3.5 - IE8 does have some support to prevent and/or notify when a site is trying to use cross-site scripting (XSS). This would give you the potential to stop it before it happens without fully disabling scripting in the browser. I haven't tested it though, so I can't tell you how well it works.
#4 - IE8 and Chrome both have "anonymous browsing" modes, which basically puts your browser in an "isolated" environment for that and only that session, preventing any sharing of cookies and such from that session. You can enable this mode for a given session, and use that browser instance to browse AT. That doesn't mean you CAN'T get hijacked while in this mode, but it does limit what can be hijacked (only the private session data). Of course, because of this, you want to make sure that you ONLY visit AT in that particular session and nowhere else prior or post, because anything else you do during that session CAN be hijacked.
#5 - Chrome has a much better sandbox than IE8 does - each tab is its own process. So in most cases, even if an exploit manages to take down a particular browser instance, with Chrome it's MUCH less likely to exploit the whole browser and further your entire computer. I'm not advocating Chrome here, I'm just saying it's safer than IE8 if you're into that sort of thing. Firefox + NoScript imho is the best interim solution.
#6 - Sorry Safari and Opera users, I'm not as familiar with those browsers, so I can't tell you what to do. The only thing I can say is they should be similar to IE in that you can disable scripting support in order to patch this little hole. I think the latest version of Safari added some XSS mitigation, but can't be sure. I haven't touched Opera in about 13 years, so I can't tell you a thing about it.
------
Finally, as far as those complaining about it needing to be fixed, yes, you're absolutely right. Due to the nature of the design of FuseTalk though, it's not an easy fix for one person (like Derek) to slap together, as to properly fix it means changing a lot of how FuseTalk works all the way down to the database level. Certain little things can be done to mitigate it, but nothing short of overhauling how the forum front end (particularly the user profile page) talks to the database here and how the image URLs are stored/referenced will prevent the ability to insert errant text and possibly malicious scripts. It's not as simple as capping off < and />. The point is the mechanism that allows selection of avatars uses plain text to reference the avatar, and as such allows plain texts to be inserted into the database, and because of WHAT it is is exposed to the entire user base. A true fix would require this mechanism to change to something that doesn't use plain text and is VALIDATED by the back end, and this is particularly why this exploit is currently possible - because it isn't validated at all.
My suggestion in the mean time is that users do their due diligence to keep these boards running until either a back end fix happens (unlikely) or vB goes live (which will present hackers a whole new set of fun toys to play with). Lets cut the mods and Derek some slack here, because there's only so much THEY can do. I believe it was mentioned elsewhere that the boards only exist because the community is a good thing and out of the goodness of Anand's heart, not because it's a money maker.
And the last thing to note is that this is FuseTalk's issue. FuseTalk is riddled with holes like this, which is part of the reason why the boards are going to vB I'm sure. I'm sure this little exploit works even on AMD's forums (which are FuseTalk powered), so don't think it's just us.
Hopefully I've helped a bit, and anyone that doesn't feel safe can use my hints as listed above to help them out till they get us moved to vB.
PS - No, I'm not LoKe, and no, this wasn't my exploit, though I realized quite rapidly how dangerous it could get (and brought it to the mods' attention - yep, I'm a narc).