Maintainers of the open-source PHP programming language have locked down the php.net website after discovering two of its servers were hacked to host malicious code designed to surreptitiously install malware on visitors' computers.

The compromise was discovered Thursday morning by Google's safe browsing service, which helps the Chrome, Firefox, and Safari browsers automatically block sites that serve drive-by exploits. Traces of the malicious JavaScript code served to some php.net visitors were captured and posted to Hacker News here and, in the form of a pcap file, to a Barracuda Networks blog post here. The attacks started Tuesday and lasted through Thursday morning, PHP officials wrote in a statement posted late that evening.

Eventually, the site was moved to a new set of servers, PHP officials wrote in an earlier statement. There's no evidence that any of the code they maintain has been altered, they added. Encrypted HTTPS access to php.net websites is temporarily unavailable until a new secure sockets layer certificate is issued and installed. The old certificate was revoked out of concern that the intruders may have accessed the private encryption key. User passwords will be reset in the coming days. At press time, there was no indication of any further compromise.

"The php.net systems team have audited every server operated by php.net and have found that two servers were compromised: the server which hosted the www.php.net, static.php.net and git.php.net domains and was previously suspected based on the JavaScript malware, and the server hosting bugs.php.net," Thursday night's statement read. "The method by which these servers were compromised is unknown at this time."

According to a security researcher at Kaspersky Lab, Thursday's compromise caused some php.net visitors to download "Tepfer," a trojan spawned by the Magnitude Exploit Kit. At the time of the php.net attacks, the malware was detected by only five of 47 antivirus programs. An analysis of the pcap file suggests that the malware attack worked by exploiting a vulnerability in Adobe Flash, although it's possible that some victims were targeted by attacks that exploited Java, Internet Explorer, or other applications, Martijn Grooten, a security researcher for Virus Bulletin, told Ars.

Grooten said the malicious JavaScript was served from a file known as userprefs.js hosted directly on one of the php.net servers. While the userprefs.js code was served to all visitors, only some of those people received an additional payload that contained malicious iframe tags. The HTML code caused visitors' browsers to connect to a series of third-party websites and eventually download malicious code. At least some of the sites the malicious iframes were pointing to were UK domains such as nkhere.reviewhdtv.co.uk, which appeared to have their domain name system server settings compromised so they resolved to IP addresses located in Moldova.

"Given what Hacker News reported (a site serving malicious JS) to some, this doesn't look like someone manually changing the file," Grooten said, calling into question an account php.net officials gave in their initial brief statement posted to the site. The attackers "somehow compromised the Web server. It might be that php.net has yet to discover that (it's not trivial—some webserver malware runs entirely in memory and hides itself pretty well.)"

Ars has covered several varieties of malware that target webservers and are extremely hard to detect.

In an e-mail, PHP maintainer Adam Harvey said PHP officials first learned of the attacks at 6:15am UTC. By 8, they had provisioned a new server. In the interim, some visitors may have been exposed.

"We have no numbers on the number of visitors affected, due to the transient nature of the malicious JS," Harvey wrote. "As the news post on php.net said, it was only visible intermittently due to interactions with an rsync job that refreshed the code from the Git repository that houses www.php.net. The investigation is ongoing. Right now we have nothing specific to share, but a full post mortem will be posted on php.net once the dust has settled."

This post was updated at 10:23pm PT to include new information provided by the php.net server team.