PHP Foundation 'Under-funded' With One Full-time Staff Member, Director Says (reuters.com) 8
Cloudflare reported millions of attempts to exploit two serious PHP flaws this week. The PHP foundation has "no evidence hackers were able to exploit the vulnerabilities before they were disclosed," reports Reuters, but the incident still shows how critical the three-decade-old programming language is.
"Yet the nonprofit foundation that supports PHP, which may underpin up to 70% of sites globally, operates on a shoestring budget." "We have one full-time staff member (that's me) and 14 mostly part-time contractors," Executive Director Elizabeth Barron of the PHP Foundation said via email in an interview on Friday. Board members are unpaid volunteers, and funding comes from donations and grants. The foundation works with outside researchers and companies, including OpenAI and cybersecurity firms Wiz and Calif, to investigate security flaws and coordinate fixes, including Wednesday's patches... "We received no further indication from OpenAI, Wiz or Calif, with whom we're working closely on this issue, regarding any issues on patched systems," she said...
Recent events have shown how heavily companies and governments rely on PHP, Barron said. "Given that reliance, it is clear that PHP is incredibly under-funded."
AI helps researchers find decade-old flaws, but "it is also increasing maintainers' workloads," the article points out. "The PHP project is receiving nearly twice as many proposed code changes as a year ago." But unfortunately, the foundation's executive director says "the number of contributors hasn't doubled," and reviewing contributions and bug reports requires "a massive amount of human input and experience."
Wednesday the foundation said they hope to increase the number of knowledgeable engineers, but also "give the security team the resources it needs. We can only achieve this goal with funding from those who depend on PHP."
Their blog post also acknowledged the first signs of the bug were discovered in 2024, but that work on a fix stalled and restarted repeatedly over months (when there was still no known path to remote code execution): We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources. The security team has since started changing its processes, and that work continues, so that decisions can be made by majority and compromises are encouraged...
The coordinated disclosure of these vulnerabilities worked well until 2 days ahead of the targeted release date. On Tuesday, October 20th, at around 15:00 UTC, the two CVE IDs began circulating on online forums and social media... In response, the PHP project brought its pre-announcement forward [and also the release date for the patch. But as a result of the leak and pre-announcement] one of the security firms that had reported the issues mistakenly published a video. It showed their proof of concept working against a number of targets and revealed a few additional, though limited, details about the vulnerabilities. Copies of the deleted video started circulating on social media soon after. The video contributed to accelerated development of various exploitation proofs of concept, which then increased circulation on October 21st. Mitigation advice we started providing to a few critical infrastructure providers around Oct 20th 23:00 UTC, may have leaked as well. The PHP security team closely monitored and inspected appearing proofs of concept after the leak but did not identify any functional exploits at the time of release/public disclosure.
On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.
But the PHP Foundation also said Wednesday's patch "shows the progress we're making in how PHP security is handled." Once the full impact of the OOM problem was understood in August, the security team, the foundation, and the release managers delivered a fix for this deeply rooted problem across all supported branches, and distributions and LTS vendors received the patch ahead of time so their users can update quickly... We are now prioritizing measures to make sure vulnerabilities that need similarly complex fixes get resolved faster when they are reported in the future.
Thanks to Slashdot reader Mirnotoriety for sharing the news.
"Yet the nonprofit foundation that supports PHP, which may underpin up to 70% of sites globally, operates on a shoestring budget." "We have one full-time staff member (that's me) and 14 mostly part-time contractors," Executive Director Elizabeth Barron of the PHP Foundation said via email in an interview on Friday. Board members are unpaid volunteers, and funding comes from donations and grants. The foundation works with outside researchers and companies, including OpenAI and cybersecurity firms Wiz and Calif, to investigate security flaws and coordinate fixes, including Wednesday's patches... "We received no further indication from OpenAI, Wiz or Calif, with whom we're working closely on this issue, regarding any issues on patched systems," she said...
Recent events have shown how heavily companies and governments rely on PHP, Barron said. "Given that reliance, it is clear that PHP is incredibly under-funded."
AI helps researchers find decade-old flaws, but "it is also increasing maintainers' workloads," the article points out. "The PHP project is receiving nearly twice as many proposed code changes as a year ago." But unfortunately, the foundation's executive director says "the number of contributors hasn't doubled," and reviewing contributions and bug reports requires "a massive amount of human input and experience."
Wednesday the foundation said they hope to increase the number of knowledgeable engineers, but also "give the security team the resources it needs. We can only achieve this goal with funding from those who depend on PHP."
Their blog post also acknowledged the first signs of the bug were discovered in 2024, but that work on a fix stalled and restarted repeatedly over months (when there was still no known path to remote code execution): We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources. The security team has since started changing its processes, and that work continues, so that decisions can be made by majority and compromises are encouraged...
The coordinated disclosure of these vulnerabilities worked well until 2 days ahead of the targeted release date. On Tuesday, October 20th, at around 15:00 UTC, the two CVE IDs began circulating on online forums and social media... In response, the PHP project brought its pre-announcement forward [and also the release date for the patch. But as a result of the leak and pre-announcement] one of the security firms that had reported the issues mistakenly published a video. It showed their proof of concept working against a number of targets and revealed a few additional, though limited, details about the vulnerabilities. Copies of the deleted video started circulating on social media soon after. The video contributed to accelerated development of various exploitation proofs of concept, which then increased circulation on October 21st. Mitigation advice we started providing to a few critical infrastructure providers around Oct 20th 23:00 UTC, may have leaked as well. The PHP security team closely monitored and inspected appearing proofs of concept after the leak but did not identify any functional exploits at the time of release/public disclosure.
On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.
But the PHP Foundation also said Wednesday's patch "shows the progress we're making in how PHP security is handled." Once the full impact of the OOM problem was understood in August, the security team, the foundation, and the release managers delivered a fix for this deeply rooted problem across all supported branches, and distributions and LTS vendors received the patch ahead of time so their users can update quickly... We are now prioritizing measures to make sure vulnerabilities that need similarly complex fixes get resolved faster when they are reported in the future.
Thanks to Slashdot reader Mirnotoriety for sharing the news.