It has been officially confirmed that the php.net website of the open-source PHP programming language has been hacked and infected with malware. The successful breach of the site came to light yesterday morning when the Google Safe Browsing service started flagging php.net as serving up malicious scripts. This was, at first, denied by php.net which Tweeted claims that it was down to a false negative by Google. However, that position has changed and now it has been officially confirmed that two servers at php.net had been hacked and were, indeed, hosting malicious code in order to install malware on the computers of unsuspecting visitors.

It would appear that the breach occurred on Tuesday, and the infection window was open through until Thursday morning when spotted by Google. The site has now been relocated to a clean set of servers, and there is absolutely no suggestion that any of the PHP code itself has been compromised in any way so developers can breathe a sigh of relied there at least. If you have visited the php.net site during that attack window period though, it might be a good idea to double-check that your systems have not been infected.


It seems that the breach itself was surprisingly straightforward in approach, rather old-school in fact, with the use of an iFrame injection technique pointing to the Magnitude exploit kit and ultimately dropping a Trojan known as Tepfer onto the visiting computer. Up to date AV scanners should be able to detect if your computer was infected or not, in case you are concerned.

Official statements from officials at the php.net site reveal that the attack was at first thought to be a false positive by Google as "we had some minified/obfuscated javascript being dynamically injected into userprefs.js" and while this looked suspsicious "it was actually written to do exactly that so we were quite certain it was a false positive". However, analysis of the static.php.net access logs revealed it was periodically serving up userprefs.js with the wrong content length and then reverting back to the right size after a few minutes. "This is due to an rsync cron job" the statement continues "So the file was being modified locally and reverted. Google's crawler caught one of these small windows where the wrong file was being served, but of course, when we looked at it manually it looked fine."

The statement goes on to confirm that after a quick git fsck --no-reflog --full --strict on all the PHP repos plus a manual check of the md5sums for PHP distribution files "we see no evidence that the PHP code has been compromised".

In the meantime, as there is a possibility that the attackers could have accessed the private key of the php.net SSL certificate, this has been revoked by the owners who are currently in the process of getting a new one. Access to those php.net sites requiring SSL, which includes bugs.php.net and wiki.php.net, should be back real soon now folks.

Keep an eye on the updates on Twitter from @official_php.

Edited by Dani: unstickied

Votes + Comments
good info

As Editorial Director and Managing Analyst with IT Security Thing I am putting more than two decades of consulting experience into providing opinionated insight regarding the security threat landscape for IT security professionals. As an Editorial Fellow with Dennis Publishing, I bring more than two decades of writing experience across the technology industry into publications such as Alphr, IT Pro and (in good old fashioned print) PC Pro. I also write for SC Magazine UK and Infosecurity, as well as The Times and Sunday Times newspapers. Along the way I have been honoured with a Technology Journalist of the Year award, and three Information Security Journalist of the Year awards. Most humbling, though, was the Enigma Award for 'lifetime contribution to IT security journalism' bestowed on me in 2011.

3 Years
Discussion Span
Last Post by Mohammed_9

It seems that the breach itself was surprisingly straightforward in approach, rather old-school in fact, with the use of an iFrame injection technique pointing to the Magnitude exploit kit and ultimately dropping a Trojan known as Tepfer onto the visiting computer. Up to date AV scanners should be able to detect if your computer was infected or not, in case you are concerned.

I didn't know about this til now. That is pretty old school.

I haven't heard about PHP.net site being malware hack attack til now. I think I been really busy.

I think someone (hacker) read your article:

Are PHP SuperGlobals putting Web applications at risk?

and to proof a point how php is vulnerable. Someone like this happened.


While the hack happened 3 months ago, the above really did not cover it completely,
The Trojan Tepfer only infects Windows PCs. It pretends to be svchost.exe, Win32.exe or other Windows-only application that keeps attempting to entice users to open something, thus infecting themselves.

Normally, w/ Tepfer, the infection vector is via eMail with a malicious attachment. In this case it appears that the exploit vector was Javascript/Flash, using an iframe, the javascript got put into server memory and kept replacing this code in memory after the cron job ran that removed the malicious code and replaced it with the good code. Those two servers were pulled offline while a new SSL key was enabled.

Thanks to Google for catching this one. The payload would have only worked on Windows PC.

About Tepfer specifically:

Tepfer infects Windows machines ONLY. (No proof of any Linux or MacIntosh computers getting infected)
Some side effects of an infection are (c/o : http://www.yac.mx/en/guides/trojan-horse-guides/20131203-how-to-remove-Trojan/Tepfer-E-through-yac-virus-removal-tool.html:)

    Trojan/Tepfer-E may keep opening up cmd exe, notepad exe, calc exe, word exe;
    Trojan/Tepfer-E is really difficult to be traced and removed.
    Trojan/Tepfer-E creates high resource-consuming files.
    Steal sensitive data like passwords, credit card, bank account information,etc
    Trojan/Tepfer-E often takes up high resources and strikingly slows down your computer speed.

About iframes:

Thanks to W3School (http://www.w3schools.com/html/html_iframe.asp), we know that an iframe uses a src="" stmt, while this is usually a website, a htm or html file. And of course Javascript files are loaded when those .html files load (userperfs.js for example).

I also checked into that infection vector: iFrames + Tepfer + Javascript + exploit for more information. Again it appears that its Windows ONLY.

About MacBook Pros: (non-issue)

http://www.clamxav.com/BB/viewtopic.php?t=3326&p=18252 ~ Macbook pro user was getting false positive on infection until he removed the report created from his Anti-virus program. One responder mentioned being careful about using quarantine or deleting files and worth a read.

In a nut shell, this could not happen for a MacBook Pro user. My guess is the same for a Linux user, but lets look at a couple more sites to be sure.

Per arstechnica, (http://arstechnica.com/security/2013/10/hackers-compromise-official-php-website-infect-visitors-with-malware/) the infection vector was an exploit vulnerability in Adobe Flash.

The arstechnica article also suggests that it might be possible that some victims were targeted by vulnerabilities in Java, Internet Explorer or other applications (...wtf, other applications, they really did not know ~ did they.) The article mentions Java, but I could not confirm any Java infections, which would be my only concern for Linux, from Java. Too many cloud sites depend on Java these days.

Per LavaSoft (http://www.lavasoft.com/mylavasoft/securitycenter/whitepapers/lavasoft-security-bulletin-may-2013), the focus appeared to be only Windows PCs. Check it out if you want to read about how it infects .DLL files via JavaScript via iFrames and the top 20 Malicious programs infected on Windows PC.

Thankfully a non-issue for Linux and MacIntosh PCs. Gotta love Linux/Unix operating systems.

For users of WINE, if you only play the non-Linux windows-ONLY game in Wine and get out of wine when done with the game, than surfing the web with Linux only, its still a non issue.

The best explanation I came across is from infosecurity-magazine (http://www.infosecurity-magazine.com/view/35261/google-blocks-phpnet-claims-it-serves-malware/) and Jamie Biasco of AlienVault "The server redirects the browser to a server that makes another redirection very likely depending on the plugins detected on the victim," writes Blasco. The destination is a server (incidentally, one already flagged by AlienVault as malicious) that appears to host the Magnitude exploit kit. If successful, the exploit kit installs the information stealing Tepfer trojan (also known as Fareit)".

Alienvault (http://www.alienvault.com/open-threat-exchange/blog/phpnet-potentially-compromised-and-redirecting-to-an-exploit-kit) stats that the payload is Win32 EXE.

If you are not a Windows OS user, this exploit would have been of no concern.


Thanks for your info. its usefull.

Edited by pritaeas: Removed link.

Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.