The fake e-mail appears to have been sent from "security@redhat.com" and was first spotted on Friday evening with a subject line: "RedHat: Buffer Overflow in 'ls' and 'mkdir'".
The e-mail contains instructions on how to load and install a 'patch', which Red Hat warns is likely to contain malicious code.
Red Hat said its official security messages are sent from secalert@redhat.com and are digitally signed.
According to the company's Web site: "All official updates for Red Hat products are digitally signed and should not be installed unless they are correctly signed and the signature is verified".
Windows users have been successfully targeted a number of times with malware disguised as a fake 'security update'.
One of the most successful worms of 2003, Swen or Gibe.F, was disguised as a Microsoft patch to fix a flaw in Internet Explorer.
Less than four months later the tactic was tried again, but this time the Xombe or Trojan.Xombe worm, posed as a critical update for Windows XP.
The most recent attempt to fool Windows users was the Sober.D worm that masqueraded as a fix for the MyDoom worm.
Verifying authenticity: Red Hat is less than clear on one important point in their bulletin, and that's that a signed message is not automatically safe. They refer people to their key info, but should really be saying more as the people who don't already understand From: address spoofing etc may not understand PGP digital signatures either.
A message that is digitally signed and purports to come from 'security@redhat.com' or some other trusted address can NOT be assumed to be safe - Even if the signature is valid. Anybody can create a PGP key and send signed mail as that address.
You should only trust the message if it is signed with the CORRECT KEY AS SHOWN ON RED HAT'S SECURITY WEB SITE. GPG warns you about being unable to verify trust for a key for a good reason - heed it.
Download that key, 'gpg --import' it, and make sure it's signed by trustworthy folks. Establish a trust path from folks you know if you can. Most importantly, PLEASE do not trust mail just because it is signed, make sure it is signed by the right person (validated through a different communication channel) before doing anything.
Finally, a key being listed on a keyserver is not grounds for assuming trust. Anybody can upload a key to the keyserver network, claiming to be anybody. Only trust the key if you can verify it is correct from the vendor's SSL-protected security site, and preferably only if you can also confirm it by independent means.