The PHP Foundation Explained: Funding, Governance and Security Audits

The PHP Foundation is a non-profit collective, announced on 22 November 2021 and run through Open Source Collective as its fiscal host, that pays a team of core developers to maintain, secure and improve the PHP language. Companies and individuals fund it through sponsorships, with grants from public and non-profit funders on top. It does not own or govern the language: PHP itself is still decided through the community RFC process and internals votes.

This guide goes one level deeper than our posts on open source foundation governance models and PHP security in general, and it is a sister piece to our explainer on the Python Software Foundation. We read the foundation's own governance document, its structure page, its impact and transparency reports for 2024 and 2025, its blog posts on the 2024 security audit, the Ecosystem Security Team and the October 2026 security release, the php.net supported versions page, the release cycle RFC, the php/policies repository and the Composer documentation. Every number and date below comes from those sources, and where two of the foundation's own pages disagree we say so.

Key takeaways

• What it is. The PHP Foundation was announced on 22 November 2021, after a core contributor stepped back from PHP and left only a handful of paid people working on the engine. It runs on Open Collective with Open Source Collective as fiscal host, which handles contracts, payments and legal compliance.
• How it is funded. Sponsorships from companies and individuals, plus grants. Total donations were $712,484 for 2021 to 2022, $478,767 for 2023, $683,550 for 2024 and $730,534 for 2025, with expenses of $784,376 in 2025. Every transaction is public on Open Collective.
• Who decides what. A volunteer Board of Directors (5 to 10 seats) sets strategy, an Executive Director runs operations, an Advisory Board of sponsors and community leaders gives non-binding input, and contracted developers do the technical work. The foundation states plainly that it does not govern the language.
• Who it pays. The structure page says the foundation contracts 13 full-time and part-time engineers. In 2025 its developers authored roughly 42% of all commits to PHP's core, according to its 2025 report.
• Security work. The foundation secured Sovereign Tech Agency funding for the first external security audit of php-src in years (carried out in 2024, results published 10 April 2025: 27 issues, 17 with security implications). In May 2026 it created an Ecosystem Security Team funded by an Alpha-Omega grant.
• Support cycle. Each PHP branch gets two years of active support and two years of security fixes, ending on 31 December. As of 24 October 2026, PHP 8.2 security support ends on 31 December 2026, and 8.3, 8.4 and 8.5 run to 2027, 2028 and 2029.
• What you should do. Check your branch's support date, verify release signatures against the release manager keyring, subscribe to php.net announcements and the php-src advisories, and run composer audit in CI so known vulnerable packages fail the build.

What is the PHP Foundation?

The foundation's home page describes it as "a collective of people and organizations relying on the PHP language", with a mission "to ensure the long-term prosperity of the PHP language". It names three lines of work:

1. Financial support for core developers. Paying PHP language developers to do maintenance, security work and implementation of features approved through the RFC process.
2. Community growth. Promoting PHP's public image, improving onboarding for new users and encouraging accessibility and inclusion.
3. PHP representation. Speaking for PHP in open source policy discussions and partnerships, which in practice includes work on the EU Cyber Resilience Act.

The most important sentence for anyone trying to understand the foundation sits in its 2025 impact report: the foundation "does not control the decisions made by the PHP community regarding the language, nor does it assume any governance over the language itself". PHP remains a community owned project. The foundation pays people who take part in that community process; it does not replace it.

When was the PHP Foundation formed, and why?

The founding announcement was published on the JetBrains PhpStorm blog on 22 November 2021 under the title "The New Life of PHP: The PHP Foundation". It explains the background. Discussion of a PHP foundation had been "floating around for a long time", and in May 2021 conversations started in earnest after a core developer's blog post about the risk of too few people knowing the engine. A long standing core developer then announced he was moving away from PHP work, which the post says "forced us to intensify our work on the foundation".

The announcement set out the founding plan:

• The foundation would be a non-profit whose mission is "to ensure the long life and prosperity of the PHP language".
• To start quickly, it would run through Open Collective rather than incorporating a new legal entity. The post describes Open Collective as a "foundation-as-a-service provider" that handles legal and accounting work.
• The participating companies were projected to raise about $300,000 per year, with JetBrains intending to contribute $100,000 annually.
• The main task would be to fund developers to work on PHP, at market salaries, part time or full time.
• Any contributor to php-src could apply for funding.
• A temporary administration would set up rules and bylaws, with a permanent one to follow.

The foundation's own "turns three" post, published 22 November 2024, recalls the starting point bluntly: three years earlier, "PHP had no organization behind it" and only two people were being paid to work on the language.

The ten founding members, as listed on the foundation's home page, were Acquia, Automattic, Craft CMS, JetBrains, Laravel, PrestaShop, Private Packagist, Symfony, Tideways and Zend by Perforce.

What kind of organisation is it legally?

This is where the PHP Foundation differs most from older language foundations. It is not a separately incorporated charity or trade association. Section 8 of the governance document says it "operates through Open Source Collective as its fiscal host", and that Open Source Collective "handles financial transactions, donations, and legal compliance".

In practice that means:

• Money flows in and out through the foundation's Open Collective page, and every transaction is visible to anyone.
• Open Source Collective holds the bank account, signs contracts, reviews expenses and deals with government requirements.
• The 2025 report says fees include a 10% Open Source Collective fiscal host fee plus 1% to 5% payment processing, depending on payment method.

The trade off is simple. A fiscal host is fast to set up and fully transparent, and it saves the foundation from running its own finance and legal back office. In exchange, roughly one dollar in nine goes to fees, and the foundation's legal identity is that of a hosted collective rather than a standalone corporation.

How is the PHP Foundation funded?

Sponsorship is the core. The home page lists sponsors in Platinum, Gold and Silver tiers, plus past sponsors and several hundred individual backers. At the time of writing the Platinum tier showed JetBrains, Automattic, the Sovereign Tech Agency and Alpha-Omega. Two of those four are not companies: the Sovereign Tech Agency is a German public body that invests in open source infrastructure, and Alpha-Omega funds security work in critical open source projects, managing grant money together with the Open Source Security Foundation (OpenSSF).

The money, year by year

The 2025 impact and transparency report, published 27 May 2026, gives a four year financial table in US dollars:

Three things stand out.

First, 2025 expenses exceeded money received by about $139,000. The foundation was spending reserves built up in the early years when it had not yet hired a full team. That is sustainable for a while, not forever.

Second, the sponsor base shrank. The report says 536 organisations and individuals sponsored the foundation in 2025, "substantially less than the previous year", and calls it a sign of "an increasingly challenging fundraising space in the open source ecosystem".

Third, from 2025 some funds were donated and paid in euro, so the report warns of small rounding differences.

Grants on top of sponsorship

Sponsorship pays the general team. Grants pay for specific projects:

• Sovereign Tech Agency, 2023 to 2024. The agency's own project page lists an investment of €205,000 in the PHP Foundation across 2023 and 2024. The scope covered four items: rewriting the PECL extension distribution system (which became PIE, the PHP Installer for Extensions), a security audit of the PHP codebase with a security research group, modernising the English documentation, and a testing tool for PHP-FPM and server integration.
• Sovereign Tech Fund, streams modernisation. The 2025 report describes a 530 hour project to modernise PHP's stream layer, including a new polling API, TLS 1.3 session resumption, redesigned stream error handling and an io_uring and IOCP abstraction, with more work planned for 2026.
• Alpha-Omega, 2026. On 18 May 2026 the foundation announced an Alpha-Omega grant to fund a six month, full time "Ecosystem AI Security Engineer in Residence" and the wider work of a new Ecosystem Security Team.

The October 2026 security release post makes the funding argument directly. It asks companies that build on PHP, hosting providers and distributions, and governments whose services run on PHP to fund the foundation, and it points to the Sovereign Tech Agency's audit funding as an example of what public money can achieve.

How is the PHP Foundation governed?

The foundation publishes a governance document on its website. It describes four bodies.

The board in detail

The board sets its own size each year at its fourth quarter meeting. The 2025 baseline is between 5 and 10 members, split as follows:

• Platinum sponsors: up to 3 seats, granted automatically to qualifying Platinum sponsors.
• Community representatives: at least 3 seats.
• Other sponsors: the remaining seats, no more than 4.

If more sponsors in a tier qualify than there are seats, those sponsors decide among themselves who sits. Directors serve three year terms and are not paid. The governance page says plainly that "Directors serve voluntarily without compensation", and the structure page repeats that the foundation "does not compensate board members". A director can be removed for misconduct or non performance, with missing six consecutive board meetings given as an example.

Board decisions start with an attempt at consensus. Any director can call a formal vote. Votes happen at monthly meetings or asynchronously in a private GitHub Discussions section with a three week window. Quorum is 50% of current members. Regular matters pass with a simple majority of votes cast; strategic matters need a two thirds majority of the whole board. A board size change that fails to reach two thirds after at least four attempts, each at least four weeks apart, can then be decided by simple majority in a special session.

The Executive Director

The Executive Director must present a strategy to the board at least once a year in the fourth quarter, report on the previous year's performance in the first quarter, publish board meeting notes on GitHub (with an optional private executive session), and produce quarterly operations summaries and financial statements. Board approval is needed for major strategic changes, any commitment above 1% of the annual budget, changes to the mission or policies, and any partnership that creates a public association with an outside organisation.

The governance document also covers how the Executive Director is paid. The role may be funded by the foundation or by an outside sponsor, but any outside funding must be disclosed to and approved by the board, free of conflicts, documented, and reviewed every year. The 2025 report notes that at the end of 2025 the Executive Director was sponsored by JetBrains.

The founding Executive Director held the role from the start until early 2026. The foundation announced it was seeking a new Executive Director on 10 November 2025, and on 27 February 2026 it announced the appointment of Elizabeth Barron, chosen by a search committee of two board members and two community representatives, matching the process the governance document describes. The announcement said the founding Executive Director was moving to focus on his role at JetBrains while staying on the board.

Who sits on the board today

The board changed three times in 2026, each announced on the foundation blog:

The structure page, read on 24 October 2026, lists ten board members, the Executive Director and a Director of Fundraising, and shows the founding Executive Director as an emeritus board member. The appendix of the governance document still lists an older composition with him in an active Platinum sponsor seat. Treat the structure page and the dated blog announcements as current and the governance appendix as lagging. Ten members is the top of the 5 to 10 range the governance document allows.

How the foundation relates to PHP's own decision making

This is the part people most often get wrong. The PHP language has its own governance, separate from the foundation:

• RFCs and internals votes. New features and significant changes go through the RFC process on the PHP wiki. The voting RFC (first accepted in 2011, last updated in 2019) says the primary vote on an RFC needs a two thirds majority, votes stay open for at least two weeks, and the voters are people with php.net VCS accounts who have contributed code to PHP, plus community representatives chosen by them. The release cycle RFC described below, for example, was decided by "a normal 2/3rd majority vote" for each of its proposals.
• The php/policies repository. The project's formal rules, including the release process and the security classification, live as versioned documents in a public GitHub repository described as "a collection of the policies and guidelines that set out PHP's development". The security classification document notes it was originally published on the PHP wiki.
• Release managers. Each PHP version has a release manager team of two hands on managers and one hands off manager. The release process policy says their role is "about being a facilitator", and that it is not their role to decide which features get in.
• The PHP security team. A mix of community volunteers and foundation funded developers, which the foundation's 14 October 2026 post says "runs on its own, separate from the Foundation".

The foundation's developers take part in all of these as individual contributors. They write RFCs, review pull requests, triage bugs, serve as release managers and sit on the security team. The 2025 report lists 20 RFCs authored or co-authored by foundation contractors in 2025, from the URL parsing API that shipped in PHP 8.5 to a type juggling deprecation that was declined. A declined RFC from a funded developer is a useful signal: being paid by the foundation does not buy a feature into the language.

What do the foundation's developers work on?

The structure page says the foundation "contracts 13 full-time and part-time engineers to maintain and develop the PHP language and to support the PHP ecosystem". It then lists 14 people under that heading, one of whom holds the Ecosystem AI Security Engineer in Residence role funded by the Alpha-Omega grant, so the count depends on whether you include that grant funded position. The governance document says developers may be direct employees or contractors, are reviewed quarterly by the Executive Director, and are renewed each year based on performance and funding. The foundation opens applications for funded positions each autumn; the call for 2027 was published on 30 September 2026.

The numbers

The home page reports, for 2025, 2,929 commits, 1,685 code reviews and 662 authored pull requests merged by foundation developers. The 2025 report says the team authored "roughly 42% of all commits to PHP's core". It also gives individual figures: one developer authored 173 merged pull requests, about 16% of all merged pull requests to php-src in 2025, and another was the team's leading committer with 565 commits.

The foundation is careful about these metrics. The report says "very rarely do metrics accurately represent the full scenario", for example because a one line commit and a hundred line commit count the same.

The work, by category

From the 2025 report and the "turns three" post:

The "turns three" post says feature development is "only about 20%" of what the team does. The rest is the unglamorous work that keeps a language safe to run: triage, security reports, reviews, documentation and infrastructure.

One detail from the 2025 report deserves attention from anyone running PHP on Windows. It says a single foundation developer authored about 95% of commits to the Windows build tooling and 98% of commits to the web downloads repository, and that without that work "PHP would have no Windows distribution maintainer". That is a concrete example of the bus factor problem the foundation was formed to address.

How does the PHP release and support cycle work?

The release cycle is decided by the PHP project, not the foundation, but foundation developers wrote the RFC that changed it.

Two years active, two years security

The php.net supported versions page says each branch is "fully supported for two years from its initial stable release", then supported "for two additional years for critical security issues only". After four years the branch reaches end of life.

That four year cycle is relatively new. The release cycle update RFC, version 0.2 dated 21 March 2024 and marked Accepted, proposed four changes, each voted on separately with a two thirds majority:

1. Disallow new features in release candidates and bug fix releases.
2. Extend security support by one year, giving two years of bug fixes and two years of security fixes.
3. Allow fixes for recent regressions during security support.
4. Align end of bug fix and end of security support dates with 31 December.

The foundation's "turns three" post lists "We extended security support for PHP versions by one year" among its achievements, and the RFC's author is a foundation funded developer.

The current calendar

As shown on php.net on 24 October 2026:

PHP 8.1 is no longer on the supported list. PHP 8.6 is in release candidate testing; php.net announced 8.6.0 RC4 on 21 October 2026. For a deeper look at the 8.1 and 8.2 dates, see our post on whether PHP 8.1 is end of life and when PHP 8.2 security support ends.

What each phase allows

The release process policy in php/policies spells out what changes are allowed in each year after GA:

Two practical consequences follow. If you run PHP on Windows, the policy says ABI incompatible versions of bundled dependent libraries stop being updated after year 3, so in a branch's final year you need to track those libraries yourself. And because security only releases happen "only when there is a security issue", a quiet month on an older branch does not mean you missed anything.

The yearly schedule

The policy says the process "starts the first Tuesday of July of each year" and runs through alphas, betas and release candidates to a November GA. Releases are tagged on Tuesdays and published before Thursday 24:00 UTC. Feature freeze arrives at the third beta. That is why new minor versions consistently land in the second half of November.

What security work has the foundation done or funded?

The 2024 external audit of php-src

The foundation announced the results on 10 April 2025. Key facts from that post:

• Funder. The Sovereign Tech Agency commissioned the audit, as part of the 2023 to 2024 investment described above.
• Organiser. The Open Source Technology Improvement Fund (OSTIF), a non-profit, organised the collaboration.
• Who did it. An external security firm carried out the work; the full report is linked in Sources.
• Duration and method. About two months in 2024, covering a threat model for php-src, manual code review, dynamic testing and cryptographic assessment.
• Scope. Not the whole codebase. The post says that "due to budget constraints" the audit focused on the most critical components, and invites sponsors to fund a more complete one.
• Findings. 27 issues, 17 with security implications: 3 high, 5 medium and 9 low severity, plus 10 informational findings.
• CVEs. The post says four vulnerabilities received CVE IDs and lists three: CVE-2024-9026 (log tampering in PHP-FPM), CVE-2024-8925 (multipart form data parsing) and CVE-2024-8929 (a malicious MySQL server causing the client to disclose heap content from other requests). The fourth is not named on the page we read.
• Resolution. The foundation says the PHP team addressed all identified issues and urges users to upgrade.

The "turns three" post calls it "the first external security audit for PHP in 10 years".

The Ecosystem Security Team

Announced on 18 May 2026, the Ecosystem Security Team exists because of two pressures the foundation describes: AI assisted tools are finding real vulnerabilities in open source faster, and projects are receiving far more reports, many of them low quality. The team's stated goals are to help triage vulnerability reports and disclose them responsibly, build tooling to discover, classify and remediate vulnerabilities, help ecosystem projects adopt that tooling, respect maintainer bandwidth, support projects with few maintainers, and "find solutions for projects with no active maintainers at all".

The grant funds one six month, full time lead role, with a mandate to prepare a sustainability plan for after that first phase. Two further developers joined later in 2026: one in July to help the PHP security team triage and fix reports, and one in September for hardening work.

How the PHP security team handles reports

The foundation's 14 October 2026 post, written by a member of the PHP security team, explains the process from the inside:

• Reporting channel. Use the GitHub security advisory form on php/php-src. The repository's security policy also gives security@php.net for questions that may not be bugs. Keep public issues, pull requests and social media out of it.
• Classification. The security classification policy in php/policies defines high, medium and low severity. High covers issues that can be triggered on typical installations without exotic settings, or in frequently used functions such as session, json, mysql and openssl. Low covers issues where practical attack is "usually impossible or extremely hard", plus misleading documentation or configuration. Issues only in unstable branches are low by definition.
• What is not a vulnerability. Malicious code that is valid PHP, unsanitised input passed to functions such as mysqli_query(), FFI, open_basedir bypasses, non standard builds and the built in web server all fall outside the policy. Many are still bugs and belong in the public tracker.
• CVE IDs. The PHP Group is a CVE Numbering Authority for php-src and has assigned its own CVE IDs since 2019, so advisories do not wait on an outside queue.
• Volume. Since 1 July 2026 the team published 15 CVEs and closed 106 reports that were not vulnerabilities, were duplicates or did not reproduce.
• Reproduction. The team reproduces on Linux, macOS, Windows and other platforms, with AddressSanitizer and UndefinedBehaviorSanitizer builds configured like CI.
• AI tools. The team uses AI tools to validate reports and to group reports that share a root cause. The post is explicit that "the models don't make the calls": a person sets every severity and writes or reviews every patch.

The post asks for small reproduction scripts, the exact PHP version or commit, OS and configure flags, sanitizer output, and above all a clear statement of impact.

What the October 2026 security release said about the foundation

On 21 October 2026, php.net published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 alongside a security advisory titled "Critical remote code execution vulnerabilities, update now". We cover the vulnerabilities themselves in our PHP2Shell explainer and the upgrade work in finding and patching every PHP runtime; this is not an incident post, and the point here is narrower.

The foundation's own post that day is unusually candid about governance. It says a foundation funded developer first saw signs of one of the underlying memory problems in 2024, while fixing an issue from the external audit. The security team developed competing fixes, each with trade offs, and, operating by consensus with a small team, struggled to choose. Work "stall[ed] and restart[ed] repeatedly over months". The post calls the delay "a structural failure", caused by both the security team's decision process and its lack of resources. After outside researchers showed the full impact in August 2026, fixing it became the top priority for every foundation developer working on security.

The lessons the foundation draws are about structure rather than tools: serious issues stuck on hard trade offs should reach foundation leadership sooner, processes are being changed so leadership can help steer to a timely fix, and more engineers with deep knowledge of the engine are needed. Funding is the constraint it names.

Which adjacent projects has it taken on?

PIE, the PHP Installer for Extensions

PIE replaces PECL as the way to install PHP extensions, and the Sovereign Tech Agency commissioned its development. The pre-release was announced on 19 November 2024. Extensions are distributed through Packagist like ordinary PHP packages, with a composer.json describing them. The 2025 report says PIE 1.0 shipped in June 2025, that an RFC to deprecate PECL and adopt PIE was accepted, and that the formal PECL deprecation process began.

PIE 1.5, announced on 7 October 2026, matters for supply chain hygiene in two ways:

• Explicit package selection for unattended installs. Earlier versions had a flag that let PIE pick packages for missing extensions automatically. The release notes call that "risky, as there are no guarantees which package a missing extension would actually resolve to". Non interactive installs now require an explicit --select=extension=vendor/package choice.
• Attestation verification. PIE verifies its own authenticity using Sigstore. The 1.5 release reports that its verification library now passes most of the Sigstore conformance suite, 131 tests passed with a handful skipped or expected to fail because the library only verifies.

FrankenPHP

On 15 May 2025 the foundation announced that FrankenPHP, a PHP application server built on Go and the Caddy web server, is "now officially supported by the PHP Foundation". The source code moved to the PHP project's GitHub organisation and foundation developers contribute to its maintenance. The post is clear that FrankenPHP's governance is unchanged: its existing maintainers keep control of releases and code review. It also notes that other ways of running PHP, such as PHP-FPM, remain fully supported. FrankenPHP's optional worker mode keeps application state in memory between requests, which is faster but changes the classic "share nothing" model, so code that leaks state between requests behaves differently.

Other projects

The 2025 report also lists the official PHP SDK for the Model Context Protocol, developed with the Symfony team, and the streams modernisation work. In 2026 the foundation launched a PHP ambassador programme, an onboarding initiative for new contributors, and a community events coalition.

What has it said about the EU Cyber Resilience Act?

On 2 April 2024 the foundation announced that it had joined the Apache Software Foundation, Blender Foundation, OpenSSL Software Foundation, Python Software Foundation, Rust Foundation and Eclipse Foundation in an initiative, hosted by the Eclipse Foundation, to create common specifications for secure software development aligned with the CRA. The stated aim was to produce specifications that could "inform the formal standardisation processes" of European standards bodies. That initiative is now the Open Regulatory Compliance Working Group; our Eclipse Foundation explainer covers it and the CRA's open source steward role in detail.

The 2025 report confirms that a foundation developer represented the foundation in that working group. We did not find a foundation post that states whether the PHP Foundation itself intends to act as an open source software steward for PHP under the CRA, so we do not claim it does. If your product ships PHP and falls under the CRA, the manufacturer obligations sit with you whatever the foundation's status.

How does the PHP Foundation compare with other language foundations?

No ranking here; the point is that "foundation" means quite different things.

Step by step: using what PHP publishes in your own pipeline

These steps work whether or not you sponsor the foundation. They turn its published support dates, signatures and advisories into checks you actually run.

Step 1. Find out which PHP you run and whether it is supported

Run this on every host and in every image you build:

php -v
php -r 'echo PHP_VERSION, PHP_EOL;'
php --ini   # which php.ini files are loaded
php -m      # which extensions are loaded

Then compare the branch against the php.net supported versions table. A simple CI check:

#!/usr/bin/env bash
# Fail if the PHP branch in this image is past its security support date.
set -euo pipefail
branch=$(php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;')
case "$branch" in
  8.2) eol="2026-12-31" ;;
  8.3) eol="2027-12-31" ;;
  8.4) eol="2028-12-31" ;;
  8.5) eol="2029-12-31" ;;
  *)   echo "PHP $branch is not on the supported list"; exit 1 ;;
esac
if [[ "$(date -u +%F)" > "$eol" ]]; then
  echo "PHP $branch reached end of life on $eol"; exit 1
fi
echo "PHP $branch is supported until $eol"

Update the table when php.net changes. Container images are where old branches hide: a base image tag pinned two years ago still says the same version today.

Step 2. Verify a PHP source download

If you build PHP from source, verify the tarball before you compile it. php.net publishes signature files next to each tarball and a keyring with all release manager public keys at /distributions/php-keyring.gpg, linked from its GPG keys page.

# Download the release, its detached signature and the release manager keyring.
curl -fsSLO https://www.php.net/distributions/php-8.5.12.tar.gz
curl -fsSLO https://www.php.net/distributions/php-8.5.12.tar.gz.asc
curl -fsSLO https://www.php.net/distributions/php-keyring.gpg

# Verify against the keyring only, not your personal keyring.
gpg --no-default-keyring --keyring ./php-keyring.gpg \
    --verify php-8.5.12.tar.gz.asc php-8.5.12.tar.gz

A good result says "Good signature" from one of the release managers listed for that branch on the GPG keys page. Compare the fingerprint gpg prints with the fingerprint listed there. Also compare the SHA-256 checksum on the downloads page:

shasum -a 256 php-8.5.12.tar.gz

If you install PHP from a distribution package or an official container image, the distribution's own package signing does this job, and you should check the distribution's advisory for the version that carries a given fix rather than comparing upstream version numbers.

Step 3. Subscribe to the right announcements

• php.net news. Releases and security advisories are posted on the php.net front page and archive, which has a feed.
• php-src security advisories. Published advisories, with their GHSA and CVE IDs and technical details, appear on the php/php-src security advisories page on GitHub. Check it after every php.net security announcement.
• The foundation blog. Context and retrospectives, such as the October 2026 security release post, appear on thephp.foundation/blog with a feed and a newsletter.
• Your distribution. If you use packaged PHP, subscribe to your distribution's security announcements too, since backported fixes often keep the original version number.

Step 4. Run composer audit in CI

The Composer documentation says composer audit checks installed packages "against defined dependency policies, such as security advisories", using the Packagist.org API by default or other configured repositories. It also reports abandoned packages. It exits with 0 when there are no issues and 1 when packages match a policy.

The useful options:

A minimal GitHub Actions job:

name: composer-audit
on:
  pull_request:
  schedule:
    - cron: "17 6 * * *"   # daily, so new advisories surface without a code change
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: "8.4"
          tools: composer:v2
      - run: composer audit --locked --no-dev --format=plain

Auditing the lock file means you do not need to install dependencies first, and the daily schedule catches advisories published after your last change. Our composer audit guide covers ignore lists and output formats in more depth, and our post on the Composer and Packagist supply chain covers the registry side.

Step 5. Install extensions with PIE, explicitly

If you add extensions in Dockerfiles, PIE 1.5 lets you install several at once and requires explicit selections in unattended installs:

pie install php-amqp/php-amqp:^2.2
# Inside a project whose composer.json requires ext-redis, choose the package explicitly:
pie install \
  --select=redis=phpredis/phpredis
pie upgrade   # upgrades within the original version constraints

Pin version constraints the same way you would in composer.json, and rebuild images when an extension ships a fix.

Step 6. Report a vulnerability properly

If you find a bug in PHP itself, read the security classification policy first, then use the GitHub private advisory form on php/php-src. Include the smallest script that triggers it, the PHP version or commit, OS, configure flags, sanitizer output and a clear impact statement. Do not open a public issue to chase a reply.

Common mistakes

• Treating the foundation as PHP's owner. The foundation funds developers; the RFC process and internals votes decide the language. Lobbying the foundation for a feature is the wrong venue.
• Reading "supported" as "patched". A supported branch gets fixes only if you install the latest point release. Being on PHP 8.4 means little if it is 8.4 from a year ago.
• Missing the 31 December cliff. Since the 2024 RFC, support ends on 31 December, not on the anniversary of GA. PHP 8.2 security support ends on 31 December 2026.
• Comparing upstream version numbers on distribution packages. Distributions backport fixes without changing the upstream version. Check the distribution's advisory instead.
• Verifying signatures against whatever keys are lying around. Use the php.net keyring and check the fingerprint for the release manager of that branch.
• Running composer audit only on pull requests. Advisories are published after code is merged. Schedule a daily run on the default branch too.
• Using --ignore-severity as a permanent mute. Ignoring low severity advisories in CI is reasonable; ignoring everything below critical quietly hides real exposure.
• Assuming an audit means the code is safe. The 2024 audit covered the most critical components "due to budget constraints". An audit is a snapshot of a scope, not a guarantee.
• Opening a public issue to chase a security report. The PHP security team asks reporters not to, because it discloses the bug before a fix exists.
• Forgetting Windows dependency updates in year 4. The release policy stops updating ABI incompatible Windows dependencies after year 3.

FAQ

What is the PHP Foundation?

A non-profit collective, announced on 22 November 2021, that pays core developers to maintain, secure and improve PHP. It runs through Open Source Collective as its fiscal host and is funded by sponsors and grants.

Who owns PHP?

PHP is a community owned open source project. The foundation states that it does not control the community's decisions about the language and does not govern the language itself. Language changes are decided through the RFC process and internals votes.

How is the PHP Foundation funded?

Through tiered company sponsorships, individual donations and grants. Donations totalled $730,534 in 2025 against $784,376 in expenses, and 536 organisations and individuals sponsored it that year.

Who runs the PHP Foundation?

A volunteer Board of Directors of 5 to 10 members sets strategy, and an Executive Director, Elizabeth Barron since February 2026, runs day to day operations. An Advisory Board of sponsors and community leaders gives non-binding feedback.

How many developers does the PHP Foundation pay?

Its structure page says it contracts 13 full-time and part-time engineers. Its 2025 report listed 11 developers as of 1 January 2026, and more joined during 2026.

When does PHP 8.2 security support end?

On 31 December 2026, according to php.net. PHP 8.3 security support ends on 31 December 2027, PHP 8.4 on 31 December 2028 and PHP 8.5 on 31 December 2029.

Has PHP had a security audit?

Yes. An external security firm audited php-src over about two months in 2024, funded by the Sovereign Tech Agency and organised by OSTIF. Results published on 10 April 2025 reported 27 issues, 17 with security implications, all of which the foundation says were addressed.

How do I report a security vulnerability in PHP?

Use the private GitHub security advisory form on the php/php-src repository, after reading the security classification policy in php/policies. Do not use public issues or social media.

What is PIE in PHP?

The PHP Installer for Extensions, a Composer style installer that replaces PECL. Extensions are published on Packagist, and PIE 1.5 (October 2026) added explicit package selection for unattended installs and stronger Sigstore verification of PIE itself.

Is the PHP Foundation a CVE Numbering Authority?

The CNA is the PHP Group, with php-src as its scope, and it has assigned its own CVE IDs since 2019. The PHP security team, which includes foundation funded developers, handles the advisories.

Where Safeguard fits

The PHP Foundation and the PHP security team decide when a fix exists. What happens next, finding every place your organisation runs the affected PHP version or depends on a vulnerable Composer package and getting the fixed version shipped, is your work. Safeguard helps with the parts that live in code and images you build: it scans repositories, container images and SBOM files for components and versions, matches them against vulnerability databases, shows which projects contain a given component and version, applies reachability analysis to rank findings, and evaluates policies and gates in the platform. It can open fix pull requests through autonomous remediation, which is off by default. It does not patch a PHP runtime you installed from a distribution on a host outside your images, and it does not replace your distribution's advisories.

PHP itself is maintained by a small funded team and volunteers, and the foundation's own October 2026 post shows how long a hard fix can take even with funding. Meanwhile most PHP applications pull dozens of Composer packages and ship in container images, and those open source dependencies are where teams carry most of their day to day exposure.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository; the assistant reads the finding and the advisory, asks before each command, edits the dependency to the fixed version, runs the install and the tests with your approval, prints a summary and pushes nothing. The demo uses an npm project, but the same flow applies when composer audit flags a vulnerable package in a PHP application: you ask for the upgrade, approve each command and review the change before anything lands.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard local runner on your own machine, approves it with its device code, then runs a scan from the terminal. For PHP teams whose application code and Dockerfiles live on internal machines, this is how you scan where the code already is, including the images that pin a PHP branch.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. If your team already works with an assistant, this lets it ask which projects carry a given PHP version or Composer package without handing over more access than you intend.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard and follow the CLI documentation.

Quick check

Sources

• The PHP Foundation: home page
• The PHP Foundation: Structure
• The PHP Foundation: Governance
• The PHP Foundation on Open Collective
• JetBrains PhpStorm blog: The New Life of PHP, The PHP Foundation (22 November 2021)
• The PHP Foundation Turns Three (22 November 2024)
• The PHP Foundation Impact and Transparency Report 2024 (31 March 2025)
• The PHP Foundation Impact and Transparency Report 2025 (27 May 2026)
• Seeking a new Executive Director (10 November 2025)
• Welcoming Elizabeth Barron as the New Executive Director (27 February 2026)
• PHP Core Security Audit Results (10 April 2025)
• PHP core security audit report (PDF, linked from the foundation post)
• OSTIF: PHP audit complete
• External security firm's blog post on the php-src audit
• Announcing the Ecosystem Security Team (18 May 2026)
• How the PHP Security Team Handles Your Reports (14 October 2026)
• Today's PHP Security Release, and How We're Strengthening PHP Security (21 October 2026)
• Announcing the Pre-Release of PIE (19 November 2024)
• PIE 1.5 Released (7 October 2026)
• FrankenPHP Is Now Officially Supported by The PHP Foundation (15 May 2025)
• Joining Forces for Open Source Cybersecurity Standards (2 April 2024)
• Applications for 2027 are open (30 September 2026)
• Welcoming Matt Stauffer to The PHP Foundation Board (March 2026)
• Anne McCarthy Joins The PHP Foundation Board (4 August 2026)
• Roman Pronskiy Leaves The PHP Foundation Board and Brent Roose Joins (1 September 2026)
• Sovereign Tech Agency: PHP (2023)
• php.net: Supported Versions
• php.net: GPG Keys
• php.net: Downloads
• php.net: news archive 2026
• PHP RFC: Release cycle update
• PHP RFC: Voting process
• php/policies: release process
• php/policies: security classification
• php/php-src: Security policy
• php/php-src: Security advisories
• Composer: Command-line interface, audit
• Rust Foundation: About
• Rust Foundation: Security Initiative
• OpenJS Foundation: Security

Last reviewed: 24 October 2026. Board membership, staff counts and support dates change; check the linked foundation and php.net pages before relying on a specific figure.