The PHP Foundation, which supports the widely used programming language PHP for web applications and more, is facing a serious funding shortage. In an email interview with Reuters on October 23, 2026, Executive Director Elizabeth Barron said she is the foundation's only full-time employee and that she works alongside 14 contractors, most of them part-time. The picture that emerges is of an organization supporting PHP development and security response with limited staff and funding.
That said, having one full-time employee does not mean that is the total number of people working on PHP. The foundation operates by commissioning outside experts for development and code review, and PHP itself is maintained by a broad developer community. Looking at the 2025 financial report together with the security response summary published on October 21, it becomes clear that the problem goes beyond a simple shortage of people. It involves both the funding needed to secure experts' working hours and the structure needed to make difficult technical decisions.
One Full-Time Employee: How PHP Foundation Development Is Staffed
According to Barron, the foundation's directors serve without pay, and its operations are funded by donations and grants. The 2025 annual report the foundation published in May 2026 records its structure at the end of that year: eight volunteer directors, an executive director supported by JetBrains, and 11 contract developers, both full-time and part-time. In other words, the number of full-time employees and the number of contract developers the foundation has secured are separate metrics. Even with few full-time staff, a foundation can commission outside experts for ongoing development work.
Comparing the 11 contract developers at the end of 2025 with the 14 contractors Barron described in October 2026 also doesn't reveal how much the development team has grown. The counts were taken at different times, and "contract developers" and "contractors" may not cover the same group of people. Each contractor's working hours have not been published either, so an increase in headcount cannot simply be treated as an increase in development capacity. At the same time, the fact that multiple contractors can focus on a specific problem does not conflict with the foundation having only one full-time employee.
More importantly, the PHP Foundation is not the body that governs the PHP language itself. In its annual report, the foundation states clearly that PHP belongs to the community and that it holds no governing authority over the language. Even when the foundation funds developers, it cannot unilaterally decide changes to the language specification or critical fixes. This distinction between who provides funding and who makes decisions also affects how problems are handled when security issues are found.
About $140,000 in Excess Spending in 2025: What the Foundation Disclosed About Its Finances
The PHP Foundation's total donations in 2025 were $730,534. However, not all of this could be used for development and operations; after deducting various fees, the amount actually received was $645,191. Meanwhile, spending for the year reached $784,376, exceeding the amount received. The financial data in the official annual report can be summarized as follows.
| 2025 foundation finances | Amount (USD) |
|---|---|
| Total donations | 730,534 |
| Fees | 85,343 |
| Amount received after fees | 645,191 |
| Spending | 784,376 |
| Spending in excess of amount received | 139,185 |
The 2025 spending excess of $139,185 is calculated by subtracting the $645,191 received after fees from the $784,376 in spending. It compares spending with the funds the foundation actually received, not with total donations. The foundation also notes that because some transactions are conducted in euros, there are rounding differences from currency conversion.
Still, the fact that spending exceeded income does not mean the foundation's finances are on the verge of collapse. In its annual report, the foundation explains that it deliberately increased spending to maintain its investment in technical staff, and says it remains solvent and has healthy reserves. At the same time, it set narrowing the gap between income and spending as a priority for 2026. The point is that it needs to improve financial sustainability while continuing to invest in experts.
However, the financial figures available here are for 2025 and do not directly show the foundation's financial situation as of October 2026. The PHP Foundation's accounts are also separate from the budget of the PHP development community as a whole. Without considering the specific state of its reserves or future income, it is not possible to predict from this spending excess alone when funds might run out, or to calculate the current cost per contractor.
Delayed Security Fix Highlights Funding and Decision-Making Challenges
PHP Foundation contract developers authored 42% of the commits made in 2025 to php-src, the repository that manages PHP's core source code. They also reviewed 1,685 pull requests (PRs) submitted by the community. The 42% figure does not indicate the share of lines of code changed, hours spent, or development quality, and it is counted on a different basis from the number of PR reviews. Even so, it shows that the foundation is heavily involved not only in developing the PHP core but also in verifying changes proposed by other developers.
The work the foundation supports is not limited to writing and reviewing code. The annual report also includes release management, distribution for Windows, and maintenance of development infrastructure and documentation. When a serious vulnerability is discovered, the experts responsible for these ongoing tasks must investigate and fix it alongside their regular duties. This allocation of limited human resources, and the difficulty of deciding on a fix, also came to light in the security response summary the foundation published on October 21.
The issue dates back to 2024. While fixing problems identified in an external audit, a PHP core developer contracted by the foundation noticed signs of another problem related to memory exhaustion. At the time, however, no specific attack path could be identified, and opinions were divided on how to fix it. The proposals included one that would break compatibility with existing behavior, one that could lead to denial of service, and one that would require broad changes to PHP extensions, so the team could not settle on a safe way to fix it.
According to the foundation, the limited number of developers familiar with the issue, combined with a decision-making process that prioritizes consensus among those involved, led to the delay. The fix stalled and restarted repeatedly, and it took a long time to resolve. The foundation itself acknowledges that the delay stemmed not only from a lack of resources but also from structural problems in the decision-making process. In other words, the 2025 spending excess cannot be used to conclude that the funding shortage directly created the vulnerability. There was also a challenge in the development structure itself: who evaluates the possibility that a fix will cause other bugs or security risks, and who makes the final call when opinions don't converge.
The situation changed significantly on August 11, 2026. When Calif reported a concrete attack path that exploited the same root cause to execute code remotely, the foundation's security staff made the issue their top priority. The foundation explains that because funds had been secured, it was able to dedicate multiple experts to investigating and fixing the problem and to coordinate around the clock, including on weekends. This is an example of funding that secures experts' working hours supporting actual security response.
Meanwhile, the workload developers must handle keeps growing. Barron told Reuters that proposed code changes have nearly doubled compared with a year earlier, while the number of contributors has not grown at the same rate. The absolute number of proposals, how they were counted, and the share of the increase made up of AI-generated code have not been disclosed. Even so, the problem remains that when proposed changes increase, the number of people who can review them and judge their quality and safety does not necessarily increase in proportion.
According to the foundation's summary, it has published 15 CVEs since July 1, 2026, while also processing more than 100 reports judged invalid, duplicate, or non-reproducible. However, it is unclear whether the 15 CVEs and the 100-plus reports are figures from the same group of reports, so the two cannot be added together to calculate a rate of valid vulnerability reports. Invalid reports and duplicate reports are also different in nature. The foundation says AI can help verify reports and organize problems that share the same root cause, but that human experts are still needed for final judgment and fixes.
To address these challenges, the foundation is also revising its security structure. It set up the Ecosystem Security Team in May 2026, and Alexandre Daubois joined in July and Daniel Scherzer in September. It has also put in place a mechanism allowing the security team to decide by majority vote or compromise, and says it will seek higher-level judgment early on difficult cases. Beyond adding experts, it is trying to change how decisions are made so that disagreements do not halt fixes. How much these changes will shorten actual response times, however, will have to be confirmed through future operating results.
Keeping PHP Secure Also Requires Staff and Budgets on the User Side
Responsibility for maintaining PHP's security does not rest with the PHP Foundation alone. After upstream developers such as the foundation investigate and fix a problem, and each distributor incorporates the fix into its packages as needed, companies that use PHP must verify and apply the fix in their own applications and production environments. Even if funding for the foundation strengthens the upstream development structure, the security of real systems cannot be maintained if companies lack the staff and budget to carry out updates. This vulnerability response also highlights the importance of this division of roles.
According to the official PHP release information, the fixed versions published on October 21 are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, and the affected setups are those in which PHP handles web requests. Minimal source code fixes have also been prepared for PHP 7.4, 8.0, and 8.1, which are no longer under regular maintenance, and distributors are backporting them. However, the fact that a fix for a specific vulnerability has been provided does not mean regular support for older versions has resumed. Another vulnerability that occurs under different conditions was also announced on October 23, so applying the October 21 fixed versions alone does not eliminate all future security risks.
Under the official PHP support policy, each release series receives two years of regular support, followed by two more years of fixes for critical security issues. Security support for PHP 8.2 is scheduled to end on December 31, 2026. Companies that have applied the fixed PHP 8.2.35 will therefore still need a plan to migrate to a newer version if they intend to keep operating after support ends. Emergency response to vulnerabilities and ongoing updates with an eye on support deadlines must be pursued separately.
Companies that keep using old PHP environments also face technical and organizational constraints. In a notice published by IPA on October 22, factors that make updating difficult include application modifications and operational testing, as well as a lack of technical know-how, absent personnel, and expired maintenance contracts. IPA therefore urges not only technical staff on the front lines but also business owners and executives to consider staffing, budgets, and maintenance structures. If the necessary structure cannot be secured, migrating the system, scaling back functionality, ending public access, or decommissioning it are also options.
The problems facing the PHP Foundation once again illustrate the question of who bears the cost, and who makes the necessary decisions, to keep open-source software secure. The foundation is working to improve its fundraising and decision-making structure, but the results will need to be judged through future fixes and development track record. Companies that use PHP, for their part, are expected to invest continuously, not only in supporting upstream development but also in verifying and applying fixes in their own environments and moving to newer versions ahead of support deadlines. Keeping PHP secure requires both the development side and the user side to secure experts' time and budgets.