There are numerous references to HTTP Response Splitting (HRS) vulnerabilities with PHP having been resolved since 4.4.2 and 5.1.2 (E.g. https://en.wikipedia.org/wiki/HTTP_response_splitting), or for around 9 years.
And yet CVE-2013-2652 reported a vulnerability in WebCollab using PHP, even though the proof-of-concept (http://archives.neohapsis.com/archives/bugtraq/2013-10/0117.html) specified a PHP version of 5.4.7. The problem identification uses "%0d%0a" in its problem statement.
I have experimented with PHP myself and it does indeed avoid allowing insertion of the 2-byte hex sequence 0x0d0x0a, but it does not prevent insertion of the %-encoded equivalent 6-character sequence %0d%0a.
On the surface at least, this seems to be a bit of a contradiction. I.e. that either 1) PHP is not as HRS-safe as suggested since it allows the 6-character sequence "%0d%0a" to be inserted into a header or 2) the stated vulnerability in CVE-2013-2652 (that "%0d%0a" was allowed to be written by a PHP application) was at least significantly overstated.
Which of those is true? (Or is it something else entirely?)
(Notes: a) I fully understand that it's better to validate or sanitize user-supplied data regardless of what other protections are in place. b) The WebCollab fix was quite straightforward and does just that: validate the user-supplied input for allowed characters. I'm more interested here in the robustness of PHP's HRS-safety, and the nature of any danger, if it exists.)