SquirrelMail release tarballs enabled remote file inclusion

SquirrelMail's December 2007 compromise was found the boring way: the published MD5 sums for 1.4.12 did not match the package sitting on the download servers. The project investigated and concluded that the final release package had been altered after release, likely through a compromised account belonging to one of the release maintainers. The source-control history was not the delivery path; the tainted code was in the official packaged archives.

The first public note sounded cautious because the inserted code seemed to depend on a PHP global variable the maintainers could not immediately trace. Within a day, outside review had turned that uncertainty into a concrete exploit path. The injected logic let a request-supplied HTTP_BASE_PATH value define SM_PATH, which in SquirrelMail's PHP include flow could become remote file inclusion and then server-side code execution.

The scope also widened from 1.4.12 to 1.4.11. SquirrelMail released 1.4.13 on December 14 and told users of both affected versions to upgrade immediately. Red Hat and Fedora bug traffic is useful context: those distributions determined their shipped packages were based on clean tarballs, while the upstream archives themselves were treated as compromised.

The episode is a compact early example of why release artifacts need their own verification trail. The attacker did not need a public commit, a plugin ecosystem, or a complex installer. Replacing the source archive on trusted project infrastructure was enough to put a remote-execution primitive in front of administrators who believed they were downloading a routine webmail maintenance release.