Stop the Presses!
Microsoft has announced the discovery of a cross-site scripting vulnerability in the SharePoint 2007 (and WSS 3.0) Help system. Although they are still investigating the root cause and working on a long-term solution, they have provided a workaround which will mitigate the only known (at the time of this writing) attack vector. You can read the details of the vulnerability and a server-side workaround in Security Advisory 983438. The Security team have also posted some more explanations about this class of vulnerability and some client-side mitigations in this blog post.
A Little More Info
The vulnerability is what is known as an "injection attack". Essentially, arbitrary JavaScript can be run by being passed as a carefully crafted parameter to the built-in SharePoint Help page. This script will run in the context of the current user's client session, and can therefore perform any actions against the SharePoint site that the user could.
This does not turn the user into an administrator, or otherwise elevate their own privileges. As far as I can tell, it does not (as some reports have suggested) expose the user's password. Update: This is with the default SharePoint authentication. Custom authentication methods could potentially store credentials in an accessible manner. I have no way to test that scenario, but any attacker would need intimate knowledge of how that authentication module worked in order to exploit it. So, while your passwords are probably safe, this vulnerability could allow an attacker to probe for and read any information in SharePoint that the user does have access to, or to vandalize or destroy information the user is permitted to update. Therefore, for the time being I strongly suggest disabling the help.aspx file in the Layouts folder of your SharePoint servers, either by following the instructions in the security advisory or through other means. (At this time, I don't suggest just deleting the file.)
Update #2
It has been pointed out that, although the attack itself cannot (usually) directly glean the user's credentials, an injected script could prompt an unsuspecting user into providing them, thinking the request was coming from your site. This does not change my advice (applying the mitigation procedures), but it should increase your priority in doing so.