incident update

Update on Incident

Hi everyone, I would like to provide an update regarding the security incident. To briefly summarize the most important information: We no longer believe the server has been compromised. However, it is possible that the user database leaked. has been migrated to a new system All passwords have been…

Hi everyone,

I would like to provide an update regarding the security
incident. To briefly summarize the most important information:

The following is a more detailed explanation of what happened and which
actions were taken.

When the first malicious commit was made under Rasmus’ name, my initial
reaction was to revert the change and revoke commit access for Rasmus’
account, on the assumption that this was an individual account compromise.
In hindsight, this action didn’t really make sense, because there was (at
the time) no reason to believe that the push occurred through Rasmus’
account in particular. Any account with access to the php-src repository
could have performed the push under a false name.

When the second malicious commit was made under my own name, I reviewed the
logs of our gitolite installation, in order to determine which account was
actually used to perform the push. However, while all adjacent commits were
accounted for, no git-receive-pack entries for the two malicious commits
were present, which means that these two commits bypassed the gitolite
infrastructure entirely. This was interpreted as likely evidence of a
server compromise.

Shortly after that, we made the decision to discontinue and
make GitHub our primary repository host instead. Retaining our own Git
infrastructure would have required setting up a new server
after determining the root cause of the compromise. This would take a lot
of time and disrupt PHP development in the meantime. A basic migration to
GitHub could be performed much more quickly, as most repositories were
already mirrored there. At this point, a lot of development was already
going through GitHub anyway, and our own Git infrastructure was mostly a
security liability and complication to the development workflow, so it was
not a hard decision to make the switch.

Something I was not aware of at the time is that
(intentionally) supported pushing changes not only via SSH (using the
gitolite infrastructure and public key cryptography), but also via HTTPS.
The latter did not use gitolite, and instead used git-http-backend behind
Apache2 Digest authentication against the user database. I’m
not sure why password-based authentication was supported in the first
place, as it is much less secure than pubkey authentication.

Based on access logs, we can determine that the commits were indeed pushed
using HTTPS and password-based authentication. An excerpt of relevant log
entries is shown below:

[redacted] – rasmus@[redacted] [27/Mar/2021:19:19:23 -0700] “GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1″ 401 941
[redacted] – rasmus@[redacted] [27/Mar/2021:19:19:28 -0700] “GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1″ 401 941
[redacted] – rasmus [27/Mar/2021:20:56:51 -0700] “GET
/push/php-src.git/info/refs?service=git-receive-pack HTTP/1.1″ 200 125315
[redacted] – rasmus [27/Mar/2021:20:58:13 -0700] “POST
/push/php-src.git/git-receive-pack HTTP/1.1″ 200 1080
[redacted] – nikita.ppv [28/Mar/2021:09:09:15 -0700] “GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1″ 401 941
[redacted] – nikita.ppv [28/Mar/2021:09:09:18 -0700] “GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1″ 401 941
[redacted] – nikitappv [28/Mar/2021:09:09:35 -0700] “GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1″ 401 941
[redacted] – nikitappv [28/Mar/2021:09:09:36 -0700] “GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1″ 401 941
[redacted] – nikita [28/Mar/2021:09:09:50 -0700] “GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1″ 401 941
[redacted] – nikita [28/Mar/2021:09:09:53 -0700] “GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1″ 401 941
[redacted] – nikic [28/Mar/2021:09:11:31 -0700] “GET
/push/php-src.git/info/refs?service=git-receive-pack HTTP/1.1″ 401 941
[redacted] – nikic [28/Mar/2021:09:11:31 -0700] “GET
/push/php-src.git/info/refs?service=git-receive-pack HTTP/1.1″ 401 941
[redacted] – nikic [28/Mar/2021:09:13:28 -0700] “GET
/push/php-src.git/info/refs?service=git-receive-pack HTTP/1.1″ 200 123263
[redacted] – nikic [28/Mar/2021:09:13:39 -0700] “POST
/push/php-src.git/git-receive-pack HTTP/1.1″ 200 1079

It is notable that the attacker only makes a few guesses at usernames, and
successfully authenticates once the correct username has been found. While
we don’t have any specific evidence for this, a possible explanation is
that the user database of has been leaked, although it is
unclear why the attacker would need to guess usernames in that case.

The system, which is used for authentication and various
management tasks, was running very old code on a very old operating system
/ PHP version, so some kind of vulnerability would not be terribly
surprising. We have made a number of changes to increase the security of
this system:

  • was migrated to a new system (running PHP 8) and renamed
    to at the same time. Among other things, the new system
    supports TLS 1.2, which means you should no longer see TLS version warnings
    when accessing this site.
  • The implementation has been moved towards using parameterized queries,
    to be more confident that SQL injections cannot occur.
  • Passwords are now stored using bcrypt.
  • Existing passwords were reset (use to generate a
    new one).

Previously, passwords were stored in a format compatible with HTTP Digest
authentication (essentially a plain md5 hash), which was required for HTTP
authentication on and As has been made
read-only as a result of this incident, we decided to make
read-only as well, and thus remove the need to store passwords in an
insecure format. Only a small handful of PECL extensions were still using
the SVN server. The following SVN repositories had semi-recent activity and
have been migrated to GitHub:

Please contact me at if additional migrations or permission
adjustments are needed. Please also report any issues you encounter with — it’s likely that some things broke during the migration.


Read More

Leave a Reply

Your email address will not be published. Required fields are marked *