You maintain a PHP project. Someone (maybe Volker from the PHP Foundation, maybe an independent researcher) has just told you that your project may have a security vulnerability. You might be feeling overwhelmed, or unsure whether you can trust the report, or simply unsure what the correct next step is.

Take a breath. Nothing bad has happened. A report is not a breach. It is a head start: someone is telling you privately about a potential problem. You have time to validate it, assess it, and you get to decide what to do next. This guide walks you through the whole process, and it ends with concrete steps to make your project more resilient for the next time.

And at any point where you get stuck: you are not alone. You can always ask the Ecosystem Security Team for help. Contact details are at the end of this guide.

How to use this guide

• Do not read it front to back. Jump to the stage you are at. Each section starts with a short "You are here if…" signpost.
• Expect to come back over several days. Handling a security report properly usually takes more than one sitting, and that is fine.
• If you only have five minutes right now, read the Cheatsheet and section 1.

A word on your authority before we start: you are the maintainer. You decide what is in scope, what the timeline is, and whether a report is valid. Handling a report well does not mean dropping everything or working weekends. It means following a small number of steps in the right order, at a pace you can sustain. You do not owe anyone heroics; see Open Source Maintainers Owe You Nothing.

Cheatsheet

The whole process on one screen. Details in the numbered sections below.

1. Don't panic, don't go public. Keep the vulnerability private until a fix is released. → §1
2. Acknowledge the report within a few days, even before you have assessed it. → §2
3. Triage: understand the claim, then decide: valid, invalid, or out of scope. → §3
4. Reproduce safely. Never run proof-of-concept code on your own machine; use an isolated environment. → §4
5. Fix privately. Use a temporary private fork; do not push to any public branch. → §5
6. Write the advisory. For Composer packages, three fields decide whether the tooling works: set the ecosystem to Composer, use the exact Packagist package name, and give precise affected-version ranges. Composer will actively block installation of the versions you list. → §6
7. Publish in the right order: merge → tag & release → publish the advisory → submit it to FriendsOfPHP → announce. → §7
8. Wrap up: credit the reporter, check older branches, do a short retrospective. → §8
9. Improve your posture so the next report is easier: SECURITY.md, private vulnerability reporting, 2FA, hardened CI. → §9
10. Ask for help whenever you are unsure. → §10

1. Do not panic and do not go public

You are here if: a report just landed and your pulse went up.

The single most important principle is coordinated disclosure: the details of a vulnerability stay private until a fixed version exists and users can protect themselves. The moment the details are public, every attacker in the world has them, and your users do not yet have a fix. So until you publish:

• Do not open a public issue about it, reference it in a public pull request, or mention it in a public commit message.
• Do not push a fix to main or any public branch. A commit titled "fix SQL injection in login handler" is the disclosure.
• Do not post the details on social media, a blog, or a mailing list, and be careful with vague teasers, which invite people to go looking. Announcing an upcoming security release is a legitimate practice that many projects follow, so that users can plan to update quickly; if you do it, keep the announcement to the date and the fact that a security release is coming, never the component, the symptom, or the versions involved.
• Do not go silent on the reporter either. Silence is how well-meaning reporters become frustrated reporters who eventually publish on their own.

Also worth internalizing early: a report is a claim, not a verdict. It may be a serious finding, a minor issue, a duplicate, a bug without security impact, or simply wrong. Part of your job in the next steps is to find out which, and you make that call, ideally in dialogue with the reporter.

If the report came from the PHP Foundation Ecosystem Security Team, it has already been through triage and usually comes with a reproducer. That raises the odds it is real, but it does not take the decision away from you.

2. Acknowledge the report

You are here if: you have read the report once and have not replied yet.

Reply quickly, even if you have nothing substantial to say yet. A short message buys you time and goodwill:

Thanks for the report. I've received it and will look into it as soon as I can. I maintain this project in my spare time. I'll get back to you here.

That is genuinely all it takes. If you already know you can keep a commitment, adding a timeframe ("please allow up to two weeks for a first assessment") is a courtesy to the reporter, but only promise what you can meet: "two weeks" kept is better than "tomorrow" broken. If the report arrived by email but your repository has GitHub Private Vulnerability Reporting enabled (see §9), this is a good moment to move the conversation there: it keeps the discussion and the patch in one private place. Do not expect it to do your release planning, though — an advisory has no field for an embargo or a disclosure date, so the timeline is something you and the reporter agree on in the conversation and then keep to.

3. Triage the report

You are here if: you have acknowledged the report and now need to decide what it is.

Read the report carefully and try to answer four questions:

1. What is the claimed weakness? (e.g. SQL injection, path traversal, insecure deserialization, often given as a CWE identifier)
2. Who can trigger it, and from where? Does it require an authenticated admin, or can any anonymous user on the internet trigger it? Does it require unusual configuration?
3. What can an attacker actually achieve? Reading data, modifying data, executing code, denial of service?
4. Which versions are affected? Including older major and minor versions that people still use.

The answers determine everything downstream: severity, urgency, and what the fix and advisory should say. Three notes from practice:

• Ask questions. A good reporter would rather answer three clarifying questions than watch you guess. If the threat model is unclear ("is this exploitable if the attacker controls that config value? In my project, they never do"), say so. That discussion is the most valuable part of triage.
• "Works as designed" is a legitimate answer. If exploiting the issue requires the attacker to already have capabilities that your documented security model says are trusted, it may not be a vulnerability in your project. Explain your reasoning to the reporter; if they disagree, the Ecosystem Security Team can act as a neutral second opinion.
• A real bug without security impact is still worth fixing, just through your normal, public process, without an advisory.

If the volume or quality of reports is a problem in itself (for example, a flood of low-effort AI-generated reports), that is exactly one of the things the Ecosystem Security Team exists to help with. Forward them; do not let them eat your motivation.

4. Handle proof-of-concept code safely

You are here if: the report includes a script, a payload, a crafted file, or step-by-step exploitation instructions.

This section exists because it is the mistake with the worst possible failure mode.

Never run proof-of-concept code directly on your own machine. Not "just this once", not because the reporter seems trustworthy, not because you skimmed the code and it looked fine. Your development machine holds your SSH keys, your GPG keys, your Packagist and GitHub credentials, your password manager, and, if you use one, your authenticated AI coding agent. A malicious or merely careless PoC that runs with your user account can compromise all of it. For a maintainer, that is not just a personal problem: your credentials are a supply-chain attack on everyone who installs your package.

And remember what a PoC is: a program written by a stranger, designed to break software. Treat it with exactly the suspicion that description deserves. Even an honest reporter's PoC may delete files, open network connections, or hammer your CPU as a side effect of demonstrating the bug.

Instead, reproduce in an isolated, disposable environment. The best one is the one you will actually use, so start at the top of this list and only move down if the issue demands it:

• A microVM sandbox is the sweet spot: roughly as convenient as a container, but running its own kernel instead of sharing the host's, so the boundary is enforced by hardware. Docker Sandboxes (sbx) gives each sandbox its own filesystem, network stack, and Docker daemon, with network access denied by default. Benjamin Eberlei describes a ready-made sbx setup with PHP, Composer, and the usual extensions that you can lift straight into this workflow.
• A container (Docker/Podman) is convenient for typical PHP-level issues and fine for most web-application-class vulnerabilities. How much isolation you get depends on where you run it: on Linux, containers share the host kernel, so anything that smells like memory corruption, native extensions, or kernel interaction deserves a stronger boundary. On macOS and Windows, Docker Desktop and OrbStack already run your containers inside a lightweight Linux VM, so a kernel boundary sits between the container and your actual machine.
• A well-secured virtual machine is the belt-and-braces option: a fresh VM with a current OS, no credentials or personal data inside, no shared folders into your host, clipboard sharing disabled, and a snapshot taken before you run anything so you can roll back afterwards. If the PoC does not need internet access, disable networking entirely, or restrict it to host-only.
• A cloud throwaway (a short-lived VM at any provider, destroyed afterwards) works too, as long as no credentials of yours live on it.

Inside the isolated environment, the workflow is simple: check out the affected version of your project, install dependencies, run the PoC, observe. Read the PoC before running it. Not as a substitute for isolation, but because understanding how it triggers the bug is exactly the insight you need for the fix and for the regression test. In fact, this is the natural moment to turn the reproducer into a failing test (§5). Many maintainers treat "I have a test that fails" as the point at which they accept a report, on the grounds that you cannot accept what you cannot reproduce.

Two closing rules for this section:

• Crafted input files are code. A "harmless" .phar, image, XML document, or serialized payload attached to a report is an exploit delivery vehicle by definition. The same isolation rules apply to opening or parsing them.
• If you cannot reproduce safely, ask for help instead of taking the shortcut. Building reproducers in isolated environments is one of the Ecosystem Security Team's core services.

5. Prepare the fix privately

You are here if: the issue is confirmed and you are ready to write code.

GitHub Security Advisories give you a temporary private fork for exactly this purpose. On the advisory page, click "Start a temporary private fork". Then:

1. Do all of the work in the private fork and open the pull request there, never against your public repository.
2. Write the regression test first. A test that fails on the vulnerable code is the proof that you have really understood and reproduced the issue, and once the fix is in you can no longer watch it fail. If you built a reproducer during triage (§4), you already have most of it; distill it into a safe, minimal test case that demonstrates the condition rather than shipping a working exploit. This is the part of the work that keeps paying off: the bug can never quietly come back.
3. Then write the fix, and keep commit messages neutral while working; the advisory will tell the full story later. (Referencing the GHSA ID in the final commit is fine, since it only resolves to something public after publication.)
4. Sweep for the same class of bug before you go any further. Publishing an advisory puts a spotlight on that weakness class, for human readers and for the people pointing LLMs at your code, so you want to be reasonably confident that the same mistake is not sitting three files over, waiting to be found the day after you publish.
5. Invite the reporter as a collaborator on the advisory and let them verify the fix. They already have a working reproducer, so it costs them little. How much weight their confirmation carries is your judgement call: a researcher who handed you a precise reproducer is the best-qualified person to confirm the hole is closed, while a report generated in bulk by a tool is not.
6. Decide which versions get the fix. If you still support older major versions, users on those versions deserve a patched release too, or an explicit statement in the advisory that they must upgrade. Severity, the age of the older version, and the effort a backport would take should all feed into that decision.

Gotchas that bite first-timers:

• CI does not run in temporary private forks. Run your test suite locally (in a safe environment) before merging.
• Don't git push --no-verify out of habit. Hooks that scan for secrets or enforce checks exist for days exactly like this one.
• The temporary private fork does not outlive the advisory: depending on where you are in the process, publishing removes it, or GitHub asks you to delete it before it lets you publish. Either way, make sure everything you need (the commits, the discussion outcomes) has landed somewhere permanent first.
• Do not fix silently. A patch released without an advisory leaves every downstream user blind: composer audit won't warn them, Dependabot won't open a PR, and most people do not update their dependencies often, so they stay vulnerable until they happen to. The advisory is not an admission of failure; it is the mechanism by which your fix actually reaches people.

6. Write the GitHub Security Advisory

You are here if: the fix exists and you are filling in the advisory form.

You create the advisory in your repository under Security → Advisories → New draft security advisory. The click-by-click walkthrough of that form (every field, the CVSS calculator, adding credits, adding multiple affected products) is GitHub's Creating a repository security advisory. (If the report arrived via private vulnerability reporting, the draft advisory already exists; you edit that one rather than creating a new one.) This section focuses on the part the walkthrough cannot do for you: what to put into the fields.

The advisory is a machine-readable document as much as a human-readable one. Tools across the ecosystem, among them the GitHub Advisory Database, OSV.dev, Dependabot, Packagist, and composer audit, consume it to warn your users automatically. Getting the metadata right is what makes that machinery work.

For PHP packages installable via Composer, the crucial details are:

• Ecosystem: select Composer. Not "Other", not "GitHub Actions", not left empty. Only advisories filed under the Composer ecosystem are matched against composer.json/composer.lock files, which is what makes composer audit and Dependabot alerts fire for your users.
• Package name: the exact Packagist name, in vendor/package form. For example phpunit/phpunit, not PHPUnit and not the GitHub repository slug if it differs. A typo here silently breaks the matching. The check takes five seconds: append what you typed to https://packagist.org/packages/ and it must land on your package, the way packagist.org/packages/phpunit/phpunit does.
• Affected version ranges: precise and Composer-flavored, e.g. >= 10.0.0, < 10.5.17, and one Affected product entry per affected release series if you patched several (a single field cannot hold multiple ranges). The exact syntax has non-obvious rules (supported operators, spacing, how suffixes like -beta1 are ordered), documented in GitHub's Best practices for writing repository security advisories, which is worth five minutes before you fill in this field. It is what version constraint resolution runs against; "all versions before X" prose in the description does not replace it. And getting these ranges right matters more than it used to, because Composer no longer merely reports your advisory. It enforces it. Read on.
• Patched version: the version you are about to release, the one you want users to move to. It is what the tooling offers people as the way out, so it belongs in the form even though you have not tagged it yet at the time you draft the advisory.

Composer blocks the versions your advisory lists

Since Composer 2.9, security advisory enforcement lives in the dependency resolver itself, on by default for every PHP project. When Composer resolves dependencies (composer update, require, remove), versions covered by a published advisory are removed from the candidate pool before the solver runs. As far as the resolver is concerned, they simply do not exist. Composer 2.10 generalized this into a unified dependency policy framework that also covers packages flagged as malware (those are blocked even during composer install from an existing lock file) and abandoned packages. This machinery replaced the older roave/security-advisories conflict-package approach. For the full mechanics (pool filtering, config.policy configuration, ignore rules, escape hatches), see The Bouncer in the Dependency Resolver and Packagist's supply chain security update.

For you as the advisory author, this has three practical consequences:

1. Your advisory directly protects users, even those who never read it. This is the strongest argument against fixing silently (§5): an advisory does not just inform, it actively keeps the vulnerable versions out of vendor/ directories across the ecosystem.
2. Overbroad version ranges cause real breakage. Once your advisory data reaches Composer (see step 4 in §7 for what governs how long that takes), every version it covers becomes uninstallable by default, everywhere, for everyone. If the ranges sweep in versions that were never vulnerable, users of those versions face failing builds, and their bug reports will land in your inbox. This is not hypothetical: for a PHPUnit advisory in April 2026, GitHub silently rewrote the carefully specified affected versions (12.5.21 and 13.1.5) into broad ranges, which made every older PHPUnit version uninstallable overnight, including all of PHPUnit 11, which was never affected. The full timeline is documented in The Bouncer in the Dependency Resolver.
3. Know the FriendsOfPHP route, in both directions. Packagist aggregates advisories from the GitHub Advisory Database and from FriendsOfPHP/security-advisories, and the FriendsOfPHP data takes precedence. That makes a pull request there both the fastest way to get your advisory in front of Composer in the first place (§7) and the fastest way to fix what Composer enforces if the published affected-version data turns out to be wrong, whether through your own mistake or an edit on GitHub's side. For a correction, send a PR to the GitHub Advisory Database as well, so that the two sources do not disagree.

The flip side is worth telling your users about, too (in your announcement or your documentation): with a current Composer, they are protected by default, and composer audit in CI tells them when an already-locked version has since gained an advisory.

The rest of the form:

• Title: one line, specific, no drama. "SQL injection in report export via sort parameter" beats "Critical security issue".
• Description: enough for a user to understand whether they are affected and what to do (upgrade to which version; workaround if one exists). Aim for the middle ground: too much detail hands attackers a ready-made exploit, too little starves the tools and the humans reading it. You do not need to include the PoC.
• CWE: pick the closest weakness class. The reporter's suggestion is usually right.
• CVSS / severity: score honestly. If required conditions lower the practical severity (authentication needed, non-default configuration), reflect that in the vector rather than in an argument in the description. Keep this in proportion, though: the score is far less important than the advisory itself. If CVSS makes your eyes glaze over, an LLM will produce a reasonable first vector for you, and the Ecosystem Security Team will happily check it; scoring help is a two-minute favor. Do not let the number hold up the publication.
• CVE: you can request a CVE ID through GitHub from the advisory (GitHub is a CNA and this is the normal path for Composer packages). Be clear about what it buys you. A CVE ID is a stable identifier for people outside your immediate ecosystem: Linux distributions shipping your code, corporate vulnerability management, other CNAs coordinating a shared issue. What actually protects the average user of your package is the GHSA, which is what Composer, composer audit, and Dependabot act on. CVE requests through GitHub currently take weeks to come back, so treat the ID as something that arrives when it arrives: request it once you have accepted the report, and never delay the fix, the release, or the advisory while waiting for it. If a coordinating party such as a CNA has already reserved a CVE for this issue, use "I have an existing CVE ID" instead of requesting a second one.
• Credit: add the reporter (and anyone who helped) in the credits section. It costs you nothing and it is a large part of what makes responsible reporting worth a researcher's while.

7. Coordinate the release and publication

You are here if: fix ready, advisory drafted, everyone in the private thread agrees.

Order matters. On the day you have chosen for your release, follow these steps:

1. Merge the fix from the private fork.
2. Tag and release the fixed version(s), and confirm the release actually shows up on Packagist before continuing.
3. Publish the advisory. From this moment the vulnerability is public, which is fine, because the fix already is too.
4. Send a pull request to FriendsOfPHP/security-advisories. Do not skip this on the grounds that you have already filed a GHSA. Composer does not look at the advisories published on individual repositories; it goes through Packagist, which consumes the reviewed GitHub Advisory Database, and GitHub's review step currently lags behind repository-level publication by days or even weeks. Until your advisory clears that queue, composer audit stays quiet and the dependency resolver keeps handing out the vulnerable versions. The FriendsOfPHP pull request is what closes that gap promptly. And if your project is not hosted on GitHub at all, this is not an optimization: it is the only route into the ecosystem's tooling.
5. Announce through your normal channels (release notes, Mastodon, Discord, blog), linking to the advisory. Keep it factual: what the issue is, who is affected, which version to upgrade to.

The gap between step 2 and step 3 should be minutes to hours, not days: a public fix without an advisory is a window in which attackers can diff your release while your users have no warning to upgrade.

Two coordination notes:

• If the report came through a coordinator such as a CNA, agree on the publication date with them in advance so CVE publication and any wider announcement can happen in step. The Ecosystem Security Team does not normally ask you to coordinate your release with us; if a particular case ever calls for it, we will say so explicitly. We do not want to stand between a report and a fix.
• If details leak early (someone tweets, a public issue appears, you spot the bug being discussed), the embargo is effectively over. Publish what you have as soon as possible, even if the situation is not as tidy as you wanted.

8. Wrap up

You are here if: the advisory is published and the adrenaline is fading.

• Verify the pipeline worked: the advisory appears in the GitHub Advisory Database, composer audit flags the vulnerable version in a test project, and Dependabot alerts fire where expected. Do not expect all of this on publication day: the advisory on your repository has to clear GitHub's review queue before Composer sees it, which is exactly what the FriendsOfPHP pull request (§7) is there to short-circuit. If it still has not arrived after a few days, check the ecosystem and package-name fields first (§6); those are the usual suspects when matching silently fails.
• Verify the blocking is not too eager: in a scratch project, check that the fixed version and unaffected release series still install and update cleanly. Compare the affected-version ranges shown in the GitHub Advisory Database against what you wrote (they have been known to change during publication), and keep an eye on your issue tracker for "cannot install version X" reports in the first days after publishing. The correction path is described in §6.
• Thank the reporter once more, in public if they are comfortable with that.
• Check your other supported branches one final time; it is easy to patch the current major and forget the LTS branch.
• Hold a fifteen-minute retrospective with yourself: How did this bug get in? Would a static analyzer, a stricter type, or a test convention have caught it? The sweep for siblings of this bug should already be behind you at this point (§5); what you are looking for here is the one structural change that stops the whole class from recurring. One such improvement per incident compounds quickly.

9. Improving your security posture for the long term

You are here if: the storm has passed and you want the next one to be smaller. This section is also the right starting point if no report has arrived yet and you simply want to prepare.

You do not need to do all of this in one weekend. The list is roughly ordered by value-for-effort; even the first three items put you ahead of most projects.

Make it easy to report to you

1. Enable GitHub Private Vulnerability Reporting (repository → Settings → Advanced Security → Private vulnerability reporting → Enable). Without it, reporters must choose between emailing you cold and opening a public issue, and some will choose the public issue.
2. Add a SECURITY.md stating how to report (ideally: "use private vulnerability reporting on this repository"), which versions you support with security fixes, and roughly what response time to expect. Three honest sentences beat a page of boilerplate.
3. Watch your own security tab. Two different things land there and both are worth a notification: security advisories, which is where a report about your code arrives, and Dependabot alerts, which tell you that a dependency you use has a published vulnerability. Make sure you are notified about both: watch the repository with security alerts enabled, and check the notification settings on your GitHub account, so that neither sits unseen for months.

Protect your accounts and releases

4. Strong 2FA/MFA everywhere that can publish: GitHub, Packagist, your email account (which can reset the other two). Prefer passkeys or hardware keys over SMS. Audit who else has publish rights and remove stale access. On Packagist this is becoming a visible property of your packages, not just private hygiene: Packagist.org will surface maintainer MFA status publicly in its transparency log and on profiles, with mandatory MFA as the stated long-term direction. Most of the recent supply-chain attacks in the PHP ecosystem began with a taken-over maintainer account.
5. Protect your release path: branch protection on main, tag protection for release tags, and no long-lived personal access tokens with broad scopes lying around in CI secrets or on disk.
6. Never re-tag a released version. If a release has a problem, ship a new version; do not overwrite the tag. Mirrors, scanners, and lock files already hold copies of the original, and two variants of "the same" version circulating is a mess your users cannot untangle. Packagist.org now enforces this: stable versions are immutable, and upstream re-tagging is detected and rejected, not least because silently rewritten tags were the core move in recent attacks on compromised packages.

Reduce your attack surface

7. Delete what does not need to exist. Every branch in your repository is a door: a target for pull requests that carry along modified workflow files, build scripts, or configuration the pipeline will happily execute. This class of attack is known as Poisoned Pipeline Execution (OWASP CICD-SEC-4). A branch that does not exist cannot receive a poisoned pull request, and no door protects better than the one that was never built. Review your branches and remove stale experiments, leftovers from old sprints, and "we might still need this" remnants. The same goes for unused workflows, third-party actions, and permissions nobody questions anymore. See The attack surface begins in the repository for the full argument, including real-world PPE incidents from SolarWinds to PyTorch.

Harden your automation

8. Treat your workflow files as security-relevant code. They run with credentials, network access, and write permission to your repository. The five weakness classes that show up almost everywhere, PHPUnit's own workflows included (52 findings before hardening, zero after):

   • Template injection: never interpolate ${{ ... }} expressions (branch names, PR titles, and other attacker-controllable values) directly into shell scripts; pass them through env: variables instead. This is the GitHub Actions equivalent of SQL injection.
   • Credential persistence: set persist-credentials: false on actions/checkout, so the workflow token does not sit in .git/config for every later step (or exfiltrated artifact) to read.
   • Unpinned actions: pin every action to a full commit SHA with the tag as a comment. A floating tag like @v4 can be repointed at malicious code by anyone who compromises the action, which is exactly how the tj-actions/changed-files attack reached 23,000 repositories. Let Renovate or Dependabot keep the SHAs current.
   • Overly broad permissions: set permissions: {} at the workflow level and grant minimal scopes per job, with a comment explaining each grant. Set the baseline for the whole repository, too: under Settings → Actions → General → Workflow permissions, choose read-only, so that a workflow which forgets to declare permissions: does not start out with write access to your repository.
   • Unnecessary third-party actions: if the runner's built-in tooling (e.g. the gh CLI) can do the job, drop the wrapper action. Every action is more code running next to your secrets, and one more upstream that can be compromised to reach you.

   You do not need to memorize this list: run zizmor against .github/workflows, fix what it finds, and add it to CI so regressions are caught immediately. A full walkthrough, taking each weakness in turn with an example exploit and its fix, is in Hardening GitHub Actions workflows. Be especially careful with the pull_request_target and workflow_run triggers, which run with the base repository's permissions against fork contributions.

9. Run composer audit in CI so you learn about vulnerable dependencies from your pipeline rather than from your users, and know that with a current Composer, your users' resolvers block advisory-affected and malware-flagged versions of your dependencies too (§6). Add a static analyzer (PHPStan or Psalm) at a level that at least catches the classics: unvalidated input flowing into queries, file paths, or unserialize().

Build habits

10. Keep an isolated reproduction environment ready (§4), so that "spin up the VM" is a two-minute routine rather than a reason to take the dangerous shortcut.
11. Treat security reports as a normal category of work, with the small process from this guide, rather than as emergencies. The calmer the routine, the better every individual case goes.
12. Know who to call. Which brings us to the final section.

10. Getting help

You never have to work through any of this alone. The PHP Foundation Ecosystem Security Team exists precisely to support maintainers like you: with triage, reproduction of findings in isolated environments, impact analysis, deduplication of report floods, fix validation, severity scoring, and coordinated disclosure. Asking early is always better than guessing; there is no question too basic.

• Email: volker@thephp.foundation (Volker Dusch, Ecosystem AI Security Engineer in Residence at the PHP Foundation)
• Discord: #ecosystem-security on the phpc community server (invite), where Volker is @edorian
• Background on the team: Announcing the Ecosystem Security Team · One Month of Ecosystem Security Engineering

Further reading

• The Maintainer's Guide to GitHub Security Advisories (Alpha-Omega): the in-depth, ecosystem-agnostic companion to this document, with a cheatsheet, FAQ, and workarounds for GitHub platform limitations
• GitHub Docs: Privately reporting a security vulnerability
• GitHub Docs: Creating a repository security advisory: the click-by-click walkthrough of the advisory form, including the CVSS calculator and credit types
• GitHub Docs: Best practices for writing repository security advisories: the reference for ecosystem, package name, and affected-version syntax, including operators and prerelease-suffix pitfalls
• Composer: composer audit and the dependency policy configuration
• The Bouncer in the Dependency Resolver (Sebastian Bergmann): how Composer's advisory and malware blocking works under the hood, including a real-world case of an advisory blocking too much
• An update on Composer & Packagist supply chain security and the Composer 2.10 release announcement (Packagist): the current state and roadmap covering dependency policies, version immutability, the transparency log, and MFA
• The attack surface begins in the repository and Hardening GitHub Actions workflows (Sebastian Bergmann): Poisoned Pipeline Execution and the concrete workflow weaknesses behind §9
• CWE (Common Weakness Enumeration) and CVSS (Common Vulnerability Scoring System)
• EEF CNA Maintainer Process: the Erlang ecosystem's equivalent process, a model for this guide

If anything here was unclear, took too long to figure out, or turned out to be wrong in practice, please tell us; that feedback directly improves the experience of the next maintainer. You can reach us at the addresses in §10.

I've run into that wall before. My immediate issue was that I didn't write C, followed pretty immediately by how overwhelming it felt to learn the entire RFC-and-mailing-list-driven contribution process.

Thankfully, it turns out there are many ways to contribute to PHP, and writing C or proposing an RFC are just two of many options. I'm glad to share I've found many other ways to give back, and I'm confident you can as well.

When we talk about "contributing to PHP," there are really two ways: contributing directly to the PHP project, and contributing to the broader PHP ecosystem. Both are needed and both are valid, so we'll walk through both in this guide. Wherever any potential path gets technical, we'll point you to the canonical instructions rather than duplicate them here.

PHP, the PHP Foundation, and the ecosystem

Before we go any further, I want to clear up the difference between a few different concepts with "PHP" in their names which we'll be referring to throughout this post:

• The PHP project — a language, and the open-source project around it: the implementation, tests, documentation, and releases, and the technical decision-making that guides it all.
• The PHP ecosystem — everything else built around PHP: packages, frameworks, tooling, conferences, education, communities, and publications.
• The PHP Foundation — an organization that supports the long-term health of PHP, including funding programmers and coordinating and supporting community initiatives.

And to clear up an important governance distinction, since this is posted on the PHP Foundation's blog: the Foundation does not own PHP, it doesn't govern its development, and it doesn't dictate RFCs. PHP is an independent open-source project with its own contributors and its own decision-making process, and we like it that way! The Foundation exists to support that work.

Part One: Contributing directly to PHP

Core contribution is broader than you might think

When most people picture the idea of "contributing to PHP core," the first thing that comes to mind is proposing a new language feature. But that's actually the deepest end of that pool, and it's only a small part of the work it takes to run a language.

There are so many other ways people can contribute to the project, including testing releases, reporting bugs, reproducing bugs others have reported, writing tests, improving documentation, reviewing changes, fixing issues, participating in internals discussion, and, yes, RFCs.

Let's walk through these, roughly from the lowest barrier to entry to the highest.

1. Test prereleases

Every new major, minor, or patch PHP version ships with a prerelease. Patch versions just get an RC (release candidate), and major/minor versions receive a series of prereleases — alphas, betas, and release candidates — before the final release. These exist so the community can catch problems while they're still cheap to fix. The more real-world code that runs against a prerelease, the more confident everyone can be that the final release won't break things.

If you maintain a package, run its test suite against the next prerelease. If you run a large real-world application, run its tests on the prerelease, or point a local or staging environment at it. When something breaks, you've found either a genuine regression worth reporting or a change you'll need to prepare for, both of which are valuable.

If you want to go a step further, test against PHP's master branch continuously rather than only at prerelease time; projects like PHPUnit and Xdebug already do this, so they catch regressions the moment they land. One caveat: don't gate your CI on it. Let a master-branch build fail without failing your whole suite, since you're deliberately testing against unreleased, in-progress code. PHPUnit's Sebastian Bergmann has written up how PHP and its ecosystem test each other this way.

PHP announces each alpha, beta, and release candidate on php.net, together with the source downloads and release schedule for that version. You can use your preferred version management or container tooling to install the prerelease, or build it yourself locally, and then run your application's or package's test suite against it. If you find something that looks like a regression in PHP itself, reduce it to the smallest reproduction you can and report it to the php-src issue tracker.

First step: Grab the current prerelease and run something you already maintain against it.

2. Report and reproduce bugs

A good bug report is itself a contribution, and so is confirming or reproducing someone else's.

Before you file anything, search the existing php-src issues in GitHub; this problem may already be known. If it isn't, the most valuable thing you can do is reduce it to a minimal reproduction: the smallest snippet of code that will reliably trigger the undesirable behavior, along with your PHP version, platform, and any other relevant environment details. The php-src contribution guide has additional guidance on filing and working with issues.

And to clear up a common misconception, it's still valuable to report a bug even if you don't know how to fix it.

First step: Search the issues, then either file your own issue or try to reproduce someone else's unconfirmed report.

3. Improve documentation

PHP's documentation is vast, and like all large (and long-running) documentation projects, it still contains plenty of unclear passages, missing examples, and pages describing behavior that has changed since its writing. Improving any of these helps every developer who lands on that page after you.

For small changes, you don't even need to set up the documentation project locally: the PHP manual's contribution guide explains how to propose an edit directly through GitHub. If you're interested in translation work, there's a separate translation guide.

Here are a few concrete examples: clarifying a confusing sentence, adding a clear example to a function that lacks (and needs) one, documenting an edge case you had to discover the hard way, correcting behavior that's drifted over versions, or improving a translation into your language. And "improving the docs" isn't only about what's written: the documentation project also has tooling (CI, linting, etc.) that welcomes contributions.

First step: The next time a docs page confuses you, propose a fix instead of just closing the tab in frustration.

4. Write tests

PHP has its own test format, called PHPT: plain-text files that describe a bit of PHP to run and the output it should produce. They're how the language guards against regressions, and they're a natural bridge between everyday PHP development and working in php-src.

A PHPT test is deliberately simple. At its core it's three sections: the description, a section describing the code to run, and a section describing the expected output:

--TEST--
strlen() returns the number of bytes in a string
--FILE--
<?php
var_dump(strlen("hello"));
?>
--EXPECT--
int(5)

The php-src testing guide walks through the full PHPT format and how to write useful tests; once you're working from a local PHP build, the test-running guide explains how to execute them.

Similar to how it's valuable to report an issue even if you don't know how to fix it, it's valuable to write a test for a bug even if you don't know how to fix it. If you can write PHPT that reliably fails on a known bug, you've pinned the problem down precisely and made the process of writing and validating a fix that much easier.

First step: Turn a bug you've reproduced into a failing PHPT.

5. Fix or review issues in php-src

This is the point where contribution moves into the implementation itself, and where knowing some C starts to matter. It's a bigger step, but still very clear. Here's generally how it works:

1. Get PHP building locally.
2. Find a scoped, well-defined existing problem to work on.
3. Comprehend the problem, and reproduce it for yourself locally.
4. Add or update tests that capture the correct behavior.
5. Implement the fix.
6. Open a pull request.
7. Work through any review with the maintainers.

I know "just get PHP building locally" is doing a lot of work in that first step. The php-src developer documentation and CONTRIBUTING.md are the best places to start with setting up a development environment and understanding the contribution workflow.

There's also the other half of this process: reviewing and testing someone else's pull request. Pull down an open PR, build it, check that it does what it claims, and then leave your findings on the PR. And this may actually be simpler than opening your first PR from scratch.

First step: Get PHP building locally, then browse the php-src issues for a narrowly scoped, already-verified bug in an area you understand.

6. Participate in internals

Technical discussion about the direction of PHP happens openly on the internals mailing list, PHP's long-running development mailing list. You don't have to write C to follow along, and you don't have to be an established contributor to add value.

In fact, many people participating in internals conversations aren't traditional core developers. That goes both ways: it means you, even as a newcomer, are as welcome to participate as anyone, but it also means not every reply you might receive should carry the same weight. That means a strong objection from one participant can't be seen as the same as a decision; weigh feedback by its reasoning and don't be discouraged by a single dissenting voice.

The internals mailing list also does have a written guide, which lays out how to participate. I'd recommend reading the whole thing before you post.

First step: Subscribe to the internals mailing list, or browse past and current discussions on externals.io, and just listen for a while.

7. RFCs: changing the language itself

RFCs (Requests for Comments) are the processes by which significant changes to the language are formally proposed and decided. They're the part of contributing to core that gets the most attention, so it's worth being clear about what they are and aren't.

First: not every code change requires an RFC. Plenty of bug fixes land through ordinary pull requests. RFCs exist for new features and other changes significant enough to need formal decision-making through the RFC process.

Second: an RFC is much more than an idea. A proposal that will be taken seriously requires research into prior art, careful design, analysis of backward-compatibility impact, a credible implementation plan (and often an implementation), a period of discussion, revision in response to feedback, a formal vote, and technical review throughout. The idea is the easy part; everything around it is the work.

Two things newcomers often miss:

• You can contribute to an RFC without being its author. Testing a proposed implementation, poking holes in the design, surfacing a compatibility problem, or providing real-world use cases all move a proposal forward.
• An accepted proposal still has to become good software. A "yes" vote is the beginning of the implementation's real life, not the end.

If you're not ready to author an RFC yourself, a great way to learn the process is to follow one that's currently under discussion. Read the proposal and its linked internals discussion, try the implementation if one is available, and look for places where your own experience can add useful evidence: compatibility concerns, interactions with existing features, real-world use cases, or behavior the proposal may not have considered. You don't need voting privileges to participate in the discussion or test the implementation.

First step: Browse the current RFC list, choose one that's under discussion, and follow it end to end. If you're considering proposing your own change, start with the official How to create an RFC guide.

Part Two: Contributing to PHP's ecosystem

The PHP project is only part of the story. Most developers spend more of their time in the ecosystem around it — the packages, frameworks, tools, communities, and education that make PHP an ecosystem, not just a language. Contributing here is not a consolation prize for people who can't work on core; for most of the community, it's where their highest-value contributions actually live.

1. Help existing open-source projects

The packages, frameworks, and tools you already use are maintained by real people; often very few of them, and often unpaid. They almost all need help: issue triage, pull-request review, documentation, testing against upcoming PHP versions, and general maintenance. Abandoned-but-widely-used projects sometimes need someone to step in and adopt them entirely — and that includes PHP's own bundled extensions, many of which have few or no active maintainers, so a domain you know well may be a genuine gap you can fill.

It's tempting to think the way to contribute is to build something new. But creating another package is not necessarily more valuable than maintaining one thousands of people already depend on. In fact, it's often worse. Strengthening what exists is often the more valuable choice.

First step: Pick a dependency you rely on and spend an hour in its issue tracker.

2. Teach and help developers

Teaching is infrastructure. An ecosystem is only as healthy as its ability to bring new people in and help existing developers level up, and that ability runs almost entirely on people who take the time to explain things.

That includes writing tutorials and documentation, producing upgrade guides, giving talks, mentoring, answering questions in forums and chat, and helping newcomers land their very first contribution. None of this requires permission, and all of it builds on the rest.

First step: Write up the last thing you had to figure out the hard way.

3. Strengthen PHP communities

The PHP community exists because people build and sustain the spaces it lives in: local meetups, conferences, online communities.

You don't need to start a conference. Consider volunteering to assist a local meetup, or simply working to make a newcomer feel welcome in one. Or, if you haven't attended one yet, just show up!

First step: Show up to a local or online PHP community and meet people; if you're already there and want to do more, ask how you can help.

4. Help PHP show up outside the PHP bubble

Plenty of the world's developers have formed their impression of PHP from someone else's read on the language from the '90s. The best way to update these impressions is to make sure PHP is represented accurately where non-PHP developers actually are.

That looks like giving PHP talks at general software conferences, contributing PHP SDKs or examples to language-neutral projects, adding modern PHP examples to developer education, publishing case studies from real applications, and improving PHP support in general-purpose developer tooling.

That outward-facing work is exactly what the Foundation's Ambassador Program is built to coordinate.

Part Three: PHP Foundation opportunities

In addition to everything above, the Foundation explicitly offers some structured ways to plug in. These are intentionally building space for contributions outside of code, like marketing, conference speaking, research, and more.

In 2026, the Foundation is launching six Special Interest Groups, covering the following areas: ecosystem security, PHP advocacy, onboarding, cryptography, community events, and accessibility and inclusion. The Foundation also periodically looks for community participation in surveys, consultations, and other initiatives.

And for people or organizations that don't have contributor time to spare, financial support to the Foundation is another way to enable this work — funding the contributors and initiatives that keep PHP moving.

When you get stuck (or hear nothing back)

At some point you'll get stuck in one of these processes, or you'll open a pull request and hear nothing back for a while. Both are normal, and neither means you necessarily did anything wrong. Contribution runs largely based on the work of volunteers, and volunteer attention is limited.

When you need help, there are a few good places to turn:

• General questions and getting unstuck: The PHP Community Discord is the most active real-time gathering spot, with channels ranging from beginner questions to core development. There's even a #php-src-help channel specifically for this sort of work. For longer-form questions, the r/PHP subreddit and the php tag on Stack Overflow are both well-trafficked.
• Core and internals questions: For questions specific to working on php-src, that same Discord has a #php-internals channel where core developers hang out, and the internals mailing list is the canonical venue for development discussion.
• A php-src PR or RFC that's gone quiet: The internals mailing list is the right place to politely follow up. A short, respectful message linking your PR or proposal is a normal and accepted way to ask for eyes on stalled work.

Pick one thing

You don't have to try everything in this article. Pick one that fits your current level of experience and available time, and run with it.

• If you have 30 minutes: fix a confusing docs page, confirm an open issue, or answer someone's question.
• If you have an afternoon: test a prerelease, build a minimal reproducible example, or investigate a bug.
• If you want a project: write a test, take on a scoped issue, or help maintain a package you depend on.
• If you want an ongoing role: review contributions, maintain software, organize community, or get involved in internals or Foundation work.

Whatever you pick, hold onto this:

If you write PHP, you are qualified to contribute to PHP. Don't let anyone tell you otherwise.

Not only did you all surpass that number by leaps and bounds, you continue to show up and join the group. We now have 150 people who have expressed interest in the Program. I couldn’t be more excited about your enthusiasm!

What we learned

Some things we’ve learned about this group:

• Maintain flexible infrastructure choices: When starting a new community, it's important to remember that it’s ok to try different options for infrastructure. Every community takes on a life of its own, and for this group, GitHub Discussions did not seem to take hold as a place where the community wanted to interact. As well, Google Meet did not provide us with the options for meeting management that we wanted. And third, inviting folks individually to meetings became unwieldy and got me flagged as a spammer. So instead of using GitHub, Google Meet, and Google invites, we are using Discord, Zoom, and a Google calendar to manage this community's interactions and these meetings.
• Divide and conquer: We had enough interest to break the larger group into smaller, more focused groups:
  • Research: focused on locating and vetting sources of information and truth that the community can use in their articles and presentations
  • Marketing: focused on the messaging of PHP (including the php.net website)
  • Speakers: focused on providing structure and resources for people who want to give talks outside the PHP ecosystem
• Give opportunities for overlap: As our topics of discussion became more focused, many people wanted to be in more than one group at a time. Also, a 30 minute breakout once a month is not enough to make real progress. For those reasons, we have afforded each group their own meeting space, while maintaining the monthly meeting that includes everyone. Allowing people to participate in more than one group at a time means there will be more opportunities for cross-pollination and coordination among the three subgroups.

Group Progress

Ideas are great, but what about actions? We have a goal in each group to build tangible assets and to keep momentum going. Launching is hard, but maintaining engagement and providing real outcomes is harder. So let's talk about what each of these groups is currently working on.

Research

As the smallest of the three groups, we tasked ourselves with identifying and listing the current available resources that are out there around PHP usage and other data points that might be of interest to our community. We felt that it was important to have a lay of the land as a starting point. We are still working on putting this into a format that we can share in the Research portion of the SIG-Ambassador Repo, but we have some notes started. If you know of a source of data that should be included, please share with us by opening an issue in the repo.

Group Info:

• Discord channel: #php-amb-research
• GitHub repo: Research subgroup
• Next meeting: Friday, August 28, 2026 at 13:00 UTC

Marketing

There is an active draft PR that proposes some initial structural updates to the php.net website. The original PR was created largely from the work of Mark Randall, and it has gone through several collaborative iterations. The php.net website was one of the things most mentioned to me in the Listening Tour as a place that could use some help, so it’s great to see this next iteration being created by the community. I would venture to say this is the first in many iterations to come! Thanks to Matt Stauffer for shepherding this group and keeping progress moving forward.

Group Info:

• Discord channel: #php-amb-marketing
• GitHub repo: Marketing subgroup
• Next meeting: Friday, August 14, 2026 at 14:00 UTC

Speakers

James Seconde from Vonage has done an amazing job shepherding this third and final group: the speakers. He has started a PR that offers guidelines for a more structured, Foundation-backed Speaker Program. The community has chimed in, but we are still open to receiving feedback on how a program like this might work. This group has also started compiling a spreadsheet of events outside our PHP bubble as a resource for PHP Ambassador speakers (or anyone else in the community). We would appreciate more eyes on this and the addition of more information. If you have thoughts on either of these things, we highly encourage you to join this group!

Group Info:

• Discord channel: #php-amb-speakers
• GitHub repo: Speakers subgroup
• Next meeting: Thursday, August 27, 2026 at 13:00 UTC

Join us!

If shaping the messaging around PHP and improving the perception of the language outside our bubbles is important to you, we would love to include you in this group!

Even if you aren’t sure where you fit in, you can participate in the larger effort:

• Discord: #php-ambassadors
• Repo: SIG-Ambassadors
• Calendar of meetings: Subscribe here
• Next meeting: Friday, August 14, 2026 at 13:00 UTC

To be added to the mailing list where you will be kept up-to-date on all the PHP Ambassador news, register your interest using this form. (Of course you can unsubscribe at any time, and we will still love you. We promise.)

Anne brings 15 years of technical and open source experience, and has spent the last 12 years at Automattic, dedicated to improving the experience of the WordPress community of users and contributors alike. They bring a balanced mix of thoughtful empathy and deep technical knowledge and will be a tremendous asset to the Foundation moving forward.

Open source comes down to people trying, caring, and showing up to benefit the collective. This feels like an especially powerful act in today's world so it's a real honor to join the PHP Foundation Board to support those who have given so much to PHP and all the other projects built with it. -- Anne McCarthy

You can find Anne mostly in Seattle, WA where mountains and dogs both fill their soul with a special kind of joy. Please join us in welcoming Anne to The PHP Foundation Governing Board!

Some of the identified issues in the PHP newcomer experience include:

• Where to begin: It is difficult for new PHP users to know where to start. There are many resources and tutorials available, but it is hard to know which ones are updated and accurate, and the sheer number of them is overwhelming. Building and helping people find resources that cater to their needs is something that would be helpful for newcomers.
• Minding the gap: The php.net Manual is a fantastic resource, but it is more of a reference than an educational resource for beginners that are learning to code. There is a current gap between documentation for complete beginners and users who already grasp the basics and use the manual differently.
• Limited presence in formal education: PHP is largely missing in universities and bootcamps. Although there are some places in the world where PHP (or a related framework/project) is taught, the presence of PHP is inconsistent. There won't be a "one-size-fits-all" approach to building more partnerships with educational institutions. But this is something that we can figure out together. (Also, this may overlap with the mission of the PHP Ambassadors Special Interest Group that has already launched.)
• Finding your people: The onboarding experience differs greatly among newcomers, with some having connections to the community, and others fending for themselves. It would be ideal if we could provide a more consistent approach to bringing newcomers together and connecting them with the community.
• Mentorship is hard to find: Although there have been previous attempts at mentorship programs, those have proven challenging to sustain. But research shows that mentorship can make all the difference when it comes to retaining users and turning them into potential contributors and community members, especially when it comes to those from marginalized and underrepresented groups.
• Installation process Ensuring that this process is as easy and straightforward as possible, and centering the experience of new users is something that we should continue to be mindful of. Because this will likely involve the php.net website, this is another potential overlap with the mission of the Marketing Subgroup of the PHP Ambassadors Special Interest Group.

These problems are not new and they aren't easy to solve, but one thing about the PHP community that I personally love is its dedication to sharing knowledge with new learners and helping newcomers find their way. This sense of community and support for newcomers is why many of us are still here (including myself!). Wouldn't it be great if we could come together and create a better and more consistent experience for newcomers to PHP?

If this is something that is of interest to you, we are hosting a kick-off meeting on Monday, August 24 at 13:00 UTC. To request an invite to this meeting, please register your interest using this form. Note: if you have already indicated your interest through this form, you do not need to submit it again.

If you cannot attend this meeting, that's okay! You are welcome to join the #the-php-foundation channel in the #phpc Discord server for access to this and the other Special Interest Group chats. We also have a GitHub repository where you can connect asynchronously.

Our core team consists of 13 people, distributed across 8 countries. Most of our contractors work part-time for The PHP Foundation and have other ventures aside from working on the PHP core. Also, this report is not meant to be a comprehensive list of everything our contractors shipped, but a high-level summary of their most impactful work.

In addition to our regular efforts around sustaining PHP through routine tasks like code reviews, bug fixes, issue triage and other maintenance work that we expect from all our developers, we want to highlight these particular efforts:

Arnaud Le Blanc

Arnaud worked out a general solution to two long-standing sources of engine bugs tied to error handlers and destructors, in collaboration with Ilija Tovilo (one of Arnaud's fixes builds on an earlier attempt made by him). The forthcoming RFC will add a fix for a related third bug source, all targeting a version after PHP 8.6. On the STF project, he's stepped back from I/O hooks and shifted with Jakub Zelenka to a dependency of hooks, also targeting a version after PHP 8.6.

David Carlier

David shipped AF_PACKET raw buffer support in PHP's sockets extension, so PHP can now work with low-level Linux packet sockets directly instead of shelling out or resorting to FFI. This PR closes a real gap with C, Python, Go, and Rust, and opens up native packet capture and injection for PHP. It's also safe by design, since like every other language it needs a privileged account (CAP_NET_RAW/root) to use, so it doesn't widen the attack surface for ordinary code.

Derick Rethans

Derick spent many hours investigating, trialing, and planning, and was able to complete a migration of the whole php.net infrastructure to a new CDN provider (more details on this are coming in a separate announcement).

Gina Banyard

Gina worked on ext/phar to cut unnecessary string allocations and improve its clarity, and investigated unifying PHP's type-checking code to remove redundant return-type checks (tied to her interface-only generic types proposal), both of which reduce duplication and improve performance and maintainability. She also explored replacing the get_constructor() object handler with an attribute, which would make constructors more predictable and could eventually let new MyClass(...) be used as a callable. This is a small but long-requested ergonomics win. In parallel, she's been preparing the mass deprecation RFC for PHP 8.6, investigating how often objects get treated as arrays, and keeping up with PR reviews and older bug fixes to prevent technical debt from piling up ahead of the next release. On top of the engineering work, she represented the project publicly: preparing and giving a talk at UNSOUND (her first academic conference), along with other conference talks and an opinion blog post, helping raise the project's visibility outside its usual community.

Ilija Tovilo

Ilija focused on ongoing security and regular issue handling and triage, work that keeps critical bugs from piling up and gets exploitable issues fixed before they reach users. He also continued work on the STF stream project, a core I/O abstraction where improvements pay off across many parts of the engine at once. In addition, he experimented with an 8-byte zval representation, which is a potentially high-leverage change, since zval is the fundamental value representation used throughout the engine, meaning a smaller size could meaningfully cut memory footprint and improve performance broadly. This is in the very early stages of experimentation. Finally, he drove improvements to gcovr accuracy from roughly 54% to 71%, giving the team a far more trustworthy picture of what's actually tested and better ability to catch under-tested code early.

Jakub Zelenka

Jakub delivered several major new PHP core APIs, including a new stream errors API, an internal and userspace polling API (Io\Poll), and significant OpenSSL/TLS enhancements such as configurable session resumption, PSK support, and crypto status exposure. He also patched a security vulnerability in the FPM status endpoint and fixed a number of memory leaks and long-standing stream bugs. Together these changes strengthened PHP's streams, I/O, and TLS capabilities.

James Titcumb

For the last few months, the PIE team has been hard at work on new features for the upcoming 1.5 release with several new key features. There's been a lot of background work to align the PIE interactions with Composer, which has allowed them to build several new requested features, including being able to install multiple extensions at once, adding a --select flag for unattended PIE installs for PHP projects, making re-installing an already installed extension a no-op, and being able to install locked extensions for a target PHP install with a new pie install --from-lock flag. Additionally, they have added support for some of the old PECL placeholder replacements, updated PIE to use the providers API, and kept up with maintenance of the 1.4.x series, bug-fixes, and security fixes for GitHub Security Advisories reported by the community.

Joe Watkins

Joe's work has centered on experimenting with ideas that improve the PHP language and experience for contributors. His latest experiment was creating a multi-engine parser that would feed into a larger framework for mapping and connecting the PHP core code across repos, documentation, and eventually issues, PR comments, and other pieces of contextual information, which would help new contributors understand the context, evolution, and functionality of the PHP core codebase. This project was recently put on hold in lieu of other priorities, but is available on GitHub.

Máté Kocsis

Thanks to Máté's work, the 'Followup improvements for ext/uri' RFC was accepted, and most of the work is already implemented. Once all changes land, it will become possible to build URIs and URLs via the new Builder classes, and some other, more advanced use cases will be better supported. Additionally, there is another RFC that has a fairly complete proposed implementation, which could revolutionize how query parameters are handled in PHP: https://wiki.php.net/rfc/query_params. Voting is not yet open for this RFC but it should be open in the next quarter. Finally, Máté was also experimenting with UUIDs (UUID v7 more specifically) and created a proof-of-concept implementation for a new extension. Work on this will continue after the pending URI proposals are wrapped up.

Saki Takamachi

Saki was responsible for various bug fixes and code reviews and is currently out for family leave.

Shivam Mathur

Shivam added support for the new Visual Studio 2026 (VS18) toolchain across PHP's Windows build infrastructure and dependency stack, laying the groundwork the ecosystem needs ahead of PHP 8.6. He strengthened the security and stability of official Windows builds by updating and testing critical dependencies (OpenSSL, curl, SQLite, Apache, ICU, and libssh2), effectively closing off known vulnerabilities that could otherwise affect every Windows install. Shivam also resolved Windows-specific PGO and ZTS crashes, directly improving reliability for Windows users on currently supported versions. And lastly, he also maintained and improved php-windows-builder, keeping Windows binaries flowing for new PECL extension releases and keeping the platform from falling behind Linux/macOS in build support.

Volker Dusch

Volker founded the PHP Ecosystem Security Team, a new effort to help PHP project maintainers find, fix, and handle security vulnerabilities. This is important because many maintainers, especially of smaller projects, lack the time or expertise to catch these issues themselves, leaving gaps that affect the wider ecosystem. Toward that end, he scanned over 500 of the most-used Composer packages and nearly every major framework, sharing 100+ fixes directly with maintainers, which translates into concrete, shipped security improvements across a large swath of the PHP ecosystem rather than just one project. He also worked alongside maintainers to help grow the team and support projects through specific security incidents (projects with a security need are encouraged to reach out).

Alexandre Daubois

Our 13th contractor, Alexandre Daubois, is brand new to the team, so we won't have updates to share until the next quarterly report.

The PHP Foundation Leadership

In addition to our team of developers, The Foundation's Executive Director (that's me!) and Director of Fundraising (Ben Marks) have also been hard at work making progress on our goals. Q2 focused on getting a lay of the land through a listening tour, creating and kicking off implementation of a strategy plan for the rest of the year, and onboarding new contractors, sponsors, and Board members. We launched the PHP Ambassador program, quarterly Advisory Board meetings, the State of PHP Survey, revived the monthly newsletter, and began publishing minutes from the Governing Board meetings. We continue to focus on increasing Foundation transparency and collaboration with the community, and expanding our mission to include other initiatives besides PHP core language development.

We are happy to share these updates with you, and if you have any questions about what any of our contractors are working on, you can connect with us in The PHP Foundation Discord channel on the PHPC server.

In recent months, there has been a marked increase in the number of security reports to php-src, due to the increased availability of AI tools and the ease with which these reports can be generated. Some of these reports are not valid security issues or are basic duplicates of previously filed reports. But even so, every one of these reports must be triaged and validated, then if deemed valid, they must be classified, fixed, reviewed, and merged. There is a very small team that currently handles these reports, and it is becoming more difficult to not only keep up with the influx, but to address issues that already exist.

As a result, we are thrilled to add Alexandre Daubois to our team of contracted developers, focused on security. Alexandre will be spending a few hours a week helping with triage and the handling and fixing of incoming security reports.

As the current CTO of Les-Tilleuls.coop, Alexandre brings a wealth of experience in addressing and fixing security issues. He has deep knowledge of Symfony, FrankenPHP, PHP core, and Scrutineer, and has already been instrumental in implementing recommendations from The PHP Foundation’s Ecosystem Security Team. We are confident that his contributions will make a huge impact in our ability to process incoming reports and effectively harden the PHP language.

Please join us in welcoming Alexandre to The PHP Foundation team!

TYPO3 is an open-source enterprise content management system built with open web standards. It provides a robust feature set for scalable, multisite, multilingual, and highly connected digital platforms. TYPO3 is also a verified Digital Public Good and part of the Open Website Alliance through the TYPO3 Association.

PHP: the foundation behind TYPO3

PHP has been the technological foundation of TYPO3 for more than two decades. It supports the CMS, its extension ecosystem, and the digital platforms built and maintained by TYPO3 agencies, contributors, and users worldwide.

TYPO3 also builds on other established open-source technologies, including Symfony components. Its support for the PHP Foundation follows the same principle as its financial backing of Symfony 8.1 and its sponsorship of PHPverse online events: projects that benefit from shared open-source infrastructure also have a role in sustaining it. As a Silver Sponsor, TYPO3 contributes financially to the PHP Foundation’s work to support the continued development, maintenance, security, and stability of PHP.

Giving back to the PHP ecosystem

“We're proud and grateful to support the PHP Foundation - because without PHP, there is no TYPO3. Its long-term health matters to our project, our community, and everyone building on top of TYPO3. By contributing as a Silver Sponsor, we are supporting the shared infrastructure we rely on every day.” --Frank Nägler, CTO, TYPO3 Company

As a Silver Sponsor, TYPO3 is putting support behind the language that powers its CMS and many other projects across the open-source web. This sponsorship reflects a shared interest in keeping PHP secure, stable, and ready for what comes next.

Behind every official PHP for Windows release is a lot of infrastructure: compilers, SDKs, dependency libraries, extension compatibility, CI pipelines, and security updates that keep the supported PHP versions working.

As part of my work for The PHP Foundation, the focus has been on the Windows side of PHP: maintaining and improving the build infrastructure, updating dependencies, supporting extension builds, and making the process more reliable for current and future PHP releases.

This post is a look at that work, why it matters, and what goes into keeping PHP healthy on Windows.

Why Windows support still matters

PHP is widely used on Linux, as the most common use case is running web applications, but Windows support remains important for several reasons.

Many developers use Windows as their local development environment, and many companies run PHP applications on Windows servers. A lot of users depend on it for local testing environments, CLI tooling, and extensions that must work reliably on Windows. As per the Stack Overflow annual developer survey in 2025 close to 50% of respondents use Windows for development.

Official PHP builds for Windows matter because they provide a trusted baseline and are part of the PHP project’s release process.

That means Windows support is not only about producing the final PHP build. It is about maintaining the full chain that makes a reliable PHP runtime possible.

The build system is now a toolchain

Building PHP on Windows is very different from building PHP on Unix-like systems.

On Linux and macOS, building PHP usually depends on package managers for dependencies and easy-to-use popular build toolchains. On Windows, PHP uses a separate build system built around MSVC, Windows SDK that handles various MSVC versions, custom build scripts, and custom prebuilt dependencies with patches specific to PHP.

A PHP Windows build needs to know:

• Which Visual Studio toolset to use
• Which Windows SDK to target
• Which dependency packages are available
• Which library versions are compatible with each PHP branch
• Whether a build is x64, x86, thread-safe, non-thread-safe, debug, or release

A major part of my work has been consolidating this into a modern toolchain: php/php-windows-builder.

PHP extension builds for Windows

We started with the purpose of making it easier to build PHP extensions on Windows. The goal was giving extension authors a path to produce builds that are compatible with the newer PIE direction. But because this new way of distribution for PHP’s extensions using PIE is still evolving, we also revived Windows builds for extension releases on PECL. As part of that, we have released builds for more than 100 actively maintained extensions.

That matters because Windows extension builds have historically been challenging for maintainers. Extension authors often do not have the full Windows build environment locally, and many contributors are more familiar with Linux-based workflows. A builder with a unified interface with known inputs gives the ecosystem a common place to test, debug, and improve Windows builds.

- name: Build the extension
  uses: php/php-windows-builder/extension@v1
  with:
    extension-url: https://github.com/xdebug/xdebug
    extension-ref: '3.5.3'
    php-version: '8.5'
    ts: nts
    arch: x64
    args: --with-xdebug
    libs: zlib

This is not only about convenience. It changes what is possible. For most extensions, building for Windows is as easy as copying one of the example workflows we have.

Automating Windows release builds

In addition to improving support for building PHP extensions, we also improved how the PHP runtime is built and maintained on Windows. We now have automated workflows in php/php-windows-builder that build PHP on new tags in php/php-src, run tests, deploy them to the downloads server, and make them available on the PHP website. This is a huge improvement on what used to be a manual process with delays, where the builds were run manually by one person in the Windows team and tested after publishing.

Dependency updates and testing

As part of the PHP build infrastructure improvements, we also created a test bench workflow. It allows us to build PHP with unpublished builds of PHP dependencies directly from GitHub workflow artifacts rather than fetching them from the PHP servers. That allows us to test dependency updates.

Before this test-bench infrastructure existed, some dependency updates were delayed or avoided because testing them properly on Windows was too slow, too manual, or too challenging. With a dedicated builder and test bench, dependency updates can be tested more quickly across PHP branches and configurations. That helps us move faster on both compatibility and security work.

PHP 8.0 through PHP 8.3 use the Visual Studio 2019 toolset, while newer versions such as PHP 8.4 and PHP 8.5 use the Visual Studio 2022 toolset. PHP 8.6 will use the Visual Studio 2026 toolset. These transitions sound simple, but in practice they affect compiler flags, dependency builds, extension compatibility, CI base images, and long-term support decisions.

Keeping this working means constantly testing combinations of PHP branches, Visual Studio versions, and dependency packages. php/php-windows-builder gives us a structured way to do that instead of relying on one-off manual builds.

Security work: CVEs, dependency updates, and backported fixes

A big part of maintaining PHP for Windows is security work.

That often means updating the dependency libraries that PHP and its extensions rely on when they receive CVE fixes or when new features demand it. These include libraries such as libcurl, OpenSSL, ICU, SQLite, libxml2, libjpeg, and more than 40 others.

When one of these libraries fixes a vulnerability, the Windows dependency stack has to be reviewed, rebuilt, and tested. The work is not as simple as bumping a version number.

A new dependency release can change ABI behavior, remove APIs, require another dependency to be rebuilt, expose new compiler warnings, or break an extension that used to compile cleanly.

For example, updating OpenSSL requires rebuilding curl and other libraries that depend on it. Updating ICU can introduce MSVC warnings or header-level changes that affect the intl extension. Updating Apache has to be evaluated carefully because PHP’s Apache module needs to remain compatible with the wider Windows ecosystem, including users running third-party installers lacking maintainers, but still have a large user-base.

There is also backporting work. Sometimes the safest path for a supported PHP branch is not to move an entire dependency stack forward, but to apply or adapt targeted security patches. That means reviewing upstream fixes, checking whether they apply cleanly to the version used by PHP for Windows, rebuilding the affected library, and validating that the patched build remains compatible with PHP and its extensions.

This balance matters. We want users to receive security fixes quickly, but we also need to avoid introducing regressions into supported PHP releases. Security maintenance on Windows is therefore a careful process of tracking CVEs, reviewing upstream changes, rebuilding dependencies, backporting fixes where appropriate, and validating the result through PHP’s test suites and real extension builds.

This is one of the less visible parts of the work, but also one of the most important. A secure PHP runtime depends not only on PHP source code but also on the native libraries that are shipped with it.

As part of this process, we updated these dependencies addressing a number of security issues reported for them over the last year.

We also refreshed these dependencies to newer releases for bug fixes and new features.

CI has become essential

Modern PHP Windows work depends heavily on CI.

It is not enough to build PHP once locally and release it. We need repeatable testing across branches, architectures, dependency versions, and runtime combinations.

As part of php/php-windows-builder, we now have a GitHub Actions-based approach to building PHP and its extensions; this is an improvement from the early days of building these on the Windows machine provided by Microsoft.

Preparing for the future

Windows support also has to look ahead.

One major area is architecture support. Historically, PHP for Windows has shipped x86 and x64 builds. But the value of x86 support continues to decrease as modern Windows systems are overwhelmingly 64-bit, while interest in ARM64 is growing.

That creates an important long-term question: what should the official PHP Windows build matrix look like in the future?

Dropping x86 and investing in ARM64 may make more sense for future versions. But that kind of decision cannot be made casually. It requires understanding who still depends on x86, what compatibility is actually being preserved, and what new users would benefit from ARM64 builds.

Part of the job is to make these transitions possible before they become urgent.

In closing

Open source maintenance is invisible by design. If everything goes well, users do not notice that a dependency was rebuilt, a compiler issue was fixed, an extension was patched, or a CI workflow was improved. They just download PHP and continue working.

That is the goal.

But it is also why it is worth talking about this work occasionally. The reliability of a project like PHP depends on many layers of maintenance that happen outside the spotlight.

The Windows side of PHP has its own set of challenges, and continuing to invest in it helps keep PHP accessible to more developers, more environments, and more use cases.

After a brief set-up period, I jumped into three main activities:

• assessing PHP community members' most pressing needs
• assembling a team of volunteers to help
• applying the resources granted to scan PHP ecosystem projects

Setup included getting started with building collaborative toolchains, ensuring access to scanning budgets and models, defining our metrics for reporting, and identifying effective ways to distribute security vulnerability findings and to support maintainers.

So far we talked to 35 project maintainers about our project scanning efforts and the security concerns they have. We shared hundreds of potential security vulnerability findings, leading to nearly a hundred publicly available fixes across the ecosystem already, and many great and useful conversations.

Additionally there were mass fixes of the same finding across many repositories. For example, in one case, we had around 200 repositories apply the same fix to their GitHub Actions as they are managed via a central template. I didn’t want to inflate the numbers so these instances are counted as a single fix.

In total, we scanned and rescanned over 300 of the most downloaded Composer packages and nearly all big frameworks. We got in touch with the respective maintainers or found people to jump in and help address security vulnerabilities where that was needed.

I want to extend a personal thank you to Graham Campbell, who has been very helpful in getting me started with ideas and initial issue validation in the first couple of days of my new role and who has continued to be responsive and helpful with solving issues in other projects.

Current efforts

Project scanning for security vulnerabilities continues at a steady pace to make the most use of the resources we've been provided with. We do not only search for vulnerabilities, but also help triage, reproduce issues, help with impact analysis, and where necessary supply fixes by using our access to AI models and their extended “Cyber” capabilities.

I will continue to talk to everyone who approaches me while providing a steady flow of public-facing communication about our efforts.

All maintainers who approached me so far were kind enough to offer to validate the generated findings themselves. I was able to focus primarily on generating reproducers and letting the experts figure out whether a particular finding represents a security issue, a bugfix, or an invalid report. The maintainers in these cases were handling their own reporting and disclosure on their own terms and in a way that fits their timeline.

I’m personally delighted by the great community response, both quantitatively and qualitatively: Nearly everyone has been supportive and I encountered only one negative maintainer interaction and one person we are still looking to get in touch with. I couldn’t be happier with the maturity, readiness and friendliness of the wider community. I didn’t expect anything else from PHP, but it’s great to be proven right.

Shared tooling: Scrutineer

When scanning many projects, we face challenges: Getting reproducible and reliable outputs, avoiding false positives, and using our resources effectively without duplicating work, all while allowing each person scanning to run multiple agents in parallel without human interaction during the initial scanning process. Security analysis needs to be performed in isolated containerized environments that keep the infrastructure we use for scanning secure.

To pool our efforts, we are working with the Ecosystem Security Engineers from other languages and the Team at Alpha-Omega on shared tooling for this purpose. Specifically we're collaborating on Scrutineer. I want to give a special shout out to Alexandre Daubois from Les-Tilleuls.coop. His contributions to Scrutineer have been very valuable in enabling more people to effectively scan PHP projects.

Scrutineer enables more structured results and an easier reporting process. It also helps to let people with access to different, otherwise unavailable, AI models, or with access to more resource capacity, scan projects on our behalf. Using Scrutineer we can tailor the containers used for analysis towards the PHP ecosystem to improve the quality of scanning results through tooling to create and validate reproducers. The report quality would be drastically lower and require more clean-up work without effective automated feedback loops.

Helping projects with individual approaches

We help projects and maintainers digest reports, create reproducers, deduplicate security vulnerability findings, and suggest and validate fixes.

When I accepted my new role, I was unsure how many projects would reach out for help with these tasks. I've received feedback that the quality of reports maintainers are receiving has gone up significantly in the last couple of months. So I've not received many requests to assist with processing reports and proposed fixes. Many maintainers report that they use their own coding agents to validate and reproduce received security vulnerability findings effectively. But for some more complex issues, currently available AI models cannot help or refuse to help with working on an exploit for a potential vulnerability. In these cases, I can be of help.

Sometimes, the automated scanning doesn’t produce clear results or the threat modeling or attack vectors are not clear enough. In these cases, I spend time with each project to better understand what the AI models should be assessing and steer them in that direction.

A special mention here is the PHP project itself: Many people like to try their new security tools on PHP, due to its popularity. The inherent complexity of a programming language runtime results in significantly lower quality results from agentic security approaches. The reports the PHP project receives are harder to digest than they are in userland PHP libraries with a clearer threat model and attack surface.

I was not yet able to help PHP itself much so far, due to time constraints. I intend to work on core PHP a lot more in the coming months. The communication with the PHP core developer team is great and I’m eager to get properly started and see where I can help them.

Assembling a team

I was delighted to see that the PHP Foundation is launching Community Special Interest Groups. One of them is the Ecosystem Security Team, which the PHP Foundation wishes to sustain far beyond the 6 months of the initial grant funding, so I've begun to assemble a team around these security and maintainer support efforts.

If you want to reach out and talk with like-minded people about security, you can find a couple of us in the #ecosystem-security channel on the phpc Discord. The PHP Community Foundation was kind enough to create a channel for us and #the-php-foundation in general. I’m “@edorian” on there, if you want to say hi.

For sensitive topics, you can always get in touch with me directly.

Next to Alexandre, who I already mentioned above, a name I’ve come across a lot when talking to maintainers was Ilia Alshanetsky. Ilia has been doing a lot of independent work and I asked him to join the Ecosystem Security Team so we can better coordinate our efforts.

Looking ahead

The goals I set myself for the next month are:

• Scan another 250 projects and report all collected findings
• Perform a dedicated, deeper analysis of core projects and libraries
• Spend more time helping out with php-src and PHP Extensions issues

I will continue to be available to help any project maintainers who reach out.

Get in touch

To repeat what was already mentioned above: We have capacity to scan and help more maintainers.

Discord: #ecosystem-security on the #phpc community server (Invite)

Email: volker@thephp.foundation