Quick quiz before you read:

<?php
var_dump(0.1 + 0.2 === 0.3);

This returns false. Now, as developers who proudly know IEEE's floating rules, many of you may take a sip of your coffee and say: Hey, that's not news anymore. We all know this classic case that warns generations of junior developers that calculating directly with floats might cause bugs.

However, let's see this case here (64-bit):

<?php
var_dump((9223372036854775808 - 1) === 9223372036854775807);

Well, obviously this is an integer calculation. This is surely not affected by any strange floating-point behavior and should return true. We don't need to consider using any high-precision math extensions (BCMath, GMP) here, right?

Right?

How PHP floats work

PHP's float type is platform-dependent, but it normally uses the IEEE 754 binary64 format which has a sign, an exponent and 53 bits of binary precision. The PHP manual describes the practical result as roughly 14 decimal digits of precision and a maximum relative rounding error on the order of 1.11e-16.

The important word is binary. A float represents a finite sum of powers of two. Fractions such as 0.5 (1/2) and 0.125 (1/8) have finite binary representations, so they can be stored exactly. 0.1 (1/10) cannot: its binary representation repeats forever, just as 1/3 repeats forever in decimal.

PHP therefore stores the nearest representable binary value. We can make those approximations visible by printing enough digits:

<?php
printf("%.17g\n", 0.1);         // 0.10000000000000001
printf("%.17g\n", 0.2);         // 0.20000000000000001
printf("%.17g\n", 0.1 + 0.2);   // 0.30000000000000004

Where precision gets lost

Playing with floats

Both sides of the original comparison are floats, but they arrive at different nearby binary values:

<?php
$sum = 0.1 + 0.2; // float(0.30000000000000004)

var_dump($sum === 0.3);              // false
var_dump(abs($sum - 0.3) < 1e-12);   // true

Playing with big integers

PHP integers are signed and platform-dependent. The maximum value of an integer is given by PHP_INT_MAX.

On a 64-bit build, their range normally ends at 9223372036854775807. According to the manual's integer overflow rules, a literal or operation outside the integer range becomes a float:

<?php
var_dump(PHP_INT_MAX);       // int(9223372036854775807)
var_dump(PHP_INT_MAX + 1);   // float(9.223372036854776E+18)

Bingo! A binary64 float has enough range to hold a number of this magnitude, but not enough precision to distinguish every integer around it. So, let's go back to the example at the beginning.

<?php
var_dump(((PHP_INT_MAX + 1) - 1) === PHP_INT_MAX);           // false
var_dump((9223372036854775808 - 1) === 9223372036854775807); // false (64-bit)

Once an integer has overflowed into a float, converting it back cannot recover the lost low-order digits.

How to calculate floats in PHP correctly

Fine fine fine, floats are strange, many may say. But, is there a way in PHP to do those calculations correctly? Surely yes!

Working safely with native floats

Floats are compact, fast, and well suited to approximate quantities. Using them correctly means accepting that their last digits are not exact. Here are some recommendations to work with PHP's native floats correctly:

Do not blindly cast floats to integers!

Quiz time again! What does the following code output?

<?php

$value = 0.58 * 100;

echo $value, "\n";
var_dump(intval($value));
var_dump((int) $value);

The output value is:

58
int(57)
int(57)

Interesting, isn't it? intval() and an (int) cast do not round to the nearest integer. They discard the fractional part by rounding towards zero. If this particular calculation is supposed to produce the nearest whole number, calling round() first gives the expected result:

<?php
$value = 0.58 * 100;
$result = (int) round($value);

var_dump($result); // int(58)

So be careful when casting a float to an integer.

One may ask: wait, why does echo $value, "\n"; return 58 in this case? That leads to the second question:

The INI setting precision does NOT fix the calculation

<?php
ini_set('precision', '14'); // 14 is the default value.

$value = 0.58 * 100;

echo $value, "\n";        // 58
var_dump(intval($value)); // int(57)

Why can the same value, displayed as 58 by echo, be converted to 57 here? Printing the value with echo uses the configured precision that "hides" the final digits. Integer conversion does not use that rounded text obviously. It reads the stored float directly, and the stored value is slightly smaller than 58.

The precision php.ini directive only controls how many digits are used when a float is converted to a string. It does not change the value in memory or the arithmetic performed by the processor:

<?php
$sum = 0.1 + 0.2;

ini_set('precision', '17');
echo $sum, "\n"; // 0.30000000000000004

ini_set('precision', '14');
echo $sum, "\n"; // 0.3

var_dump($sum === 0.3); // bool(false)

Both echo statements read the same float. One representation hides the final digits and the other reveals them, but neither changes the result of the strict comparison.

PHP also has a separate serialize_precision directive. Despite its name, it controls the textual representation of floats produced not only by serialize(), but also by functions such as json_encode() and var_dump(). It does not affect the arithmetic that produced them. They are NOT math features.

Comparing floats for equality based on tolerance

When approximate values are appropriate, the PHP manual recommends comparing them using an acceptable error bound instead of direct equality. The simple check shown earlier works when all values have a similar and known scale:

<?php
$actual = 0.1 + 0.2;
$expected = 0.3;

var_dump(abs($actual - $expected) < 1e-12); // bool(true)

The tolerance must come from the domain. 1e-12 is suitable for this small demo, but it is certainly not a magic value that fits every calculation.

PHP_FLOAT_EPSILON describes the spacing between representable floats around 1.0; it is not automatically the right tolerance for every magnitude or every application. See the manual's guidance on comparing floats for the basic epsilon approach.

Exact fixed-scale arithmetic with integers

When a value has a fixed smallest unit, storing that unit as an integer avoids binary fractions completely. For example, money is often stored as cents:

<?php
$unitPriceInCents = 58;
$quantity = 3;
$totalInCents = $unitPriceInCents * $quantity;

var_dump($totalInCents); // int(174)

The conversion into minor units must also be exact. Do not receive 0.58 as a float and assume (int) ($value * 100) is safe; that is the same conversion bug we saw above. Parse a validated decimal string or use decimal arithmetic at the input boundary.

Native integers still have the PHP_INT_MAX limit. If the scaled values may exceed it, use an arbitrary-precision representation from the start.

Core extensions can help!

Yelk. I don't want to remember these rules nor convert all my floats to integers by changing the units for precision. Well, here come the core extensions that might help you.

Playing with floats? Use BCMath

BCMath performs arbitrary-precision decimal arithmetic. Its traditional functions receive and return strings, so the decimal input does not pass through a binary float first:

<?php
$sum = bcadd('0.1', '0.2', 1);
$scaled = bcmul('0.58', '100', 0);

var_dump($sum);    // string(3) "0.3"
var_dump($scaled); // string(2) "58"

PHP 8.4 and later also provide the immutable BcMath\Number object with support for ordinary arithmetic operators:

<?php
use BcMath\Number;

$sum = new Number('0.1') + new Number('0.2');

echo $sum, "\n"; // 0.3

The quotation marks are important. Construct the calculation from decimal strings such as '0.1', but NOT from floats that may have already lost precision. Converting an approximate float to a BCMath value later cannot reconstruct the original exact decimal input.

BCMath is a good fit for prices, balances, rates, and other values where decimal places have an exact meaning.

Playing with big integers? Use GMP

The GMP extension works with arbitrary-length integers. It is not enabled by default and requires the external GMP library. It can calculate the large-integer example from the beginning without overflowing into a float:

<?php
$number = gmp_init('9223372036854775808', 10);
$result = gmp_sub($number, '1');

echo gmp_strval($result), "\n"; // 9223372036854775807

Likewise, large inputs must be strings. Writing 9223372036854775808 as a PHP numeric literal first would allow PHP to convert it to a float before GMP receives it, which is already too late.

GMP represents integers rather than decimal fractions, so it cannot directly store 0.1. It can handle fixed-scale values if the application represents every amount as an integer number of minor units. BCMath is usually clearer when the decimal scale itself is part of the data.

Conclusion

How to calculate 0.1 plus 0.2 correctly in PHP?

So, how should PHP calculate 0.1 + 0.2? If the values are approximate, native float addition is already performing the expected binary calculation. Compare the result with an appropriate tolerance and format it for display. If the answer must be the exact decimal 0.3, start with a decimal representation:

<?php
echo bcadd('0.1', '0.2', 1); // 0.3

There is no php.ini switch that changes a binary float into an exact decimal. Correctness comes from choosing the representation before the calculation begins.

Still evolving

Both BCMath and GMP are in active development. For example, PHP 8.6 adds two new functions to GMP: gmp_prev_prime and gmp_powm_sec. Those are useful functions! The PHP language is moving fast to make every PHP developer's life easier.

The PHP language is alive forever, with all the passion, work and pure love our dear contributors put in. Thank you for reading and using PHP!

As predicted, the increasing popularity of AI tools has brought an influx of security reports and PRs from the community to php-src itself. The triaging, reviewing, and handling of issues that do not fall within PHP’s definition of a “security vulnerability,” but that do improve the quality of PHP are tasks that are time-consuming for both php-src maintainers and for Volker and the team. Even if these are not security issues, they are useful hardening work and impactful nonetheless. These fixes also prevent future reports that would generate increased workload for the team.

To help manage this influx, the PHP Foundation is happy to add Daniel Scherzer to the Ecosystem Security Team on a short-term basis, as part of the aforementioned Alpha-Omega grant. Daniel will be working on this body of outstanding issues that harden PHP but that do not qualify as security vulnerabilities.

Daniel got his start in open-source software by contributing to PHP, where he currently serves as the maintainer of the Reflection extension, as a release manager for PHP 8.5, and as the veteran release manager for PHP 8.6. Daniel will be a huge asset not only to the Ecosystem Security Team but also to the PHP community, through his work on hardening PHP itself.

Welcome, Daniel!

The money is the budget for the eleventh version of the Government Site Builder, the German federal administration's standard content management solution: €26.88 million for product development and support, €73.2 million for migration and relaunch, €8 million for operations, phased over four years. More than 80 federal agencies and institutions already use it, and they have built well over 250 websites with it.

In 2025, The PHP Foundation received $730,534 in total contributions.

I am not going to argue from those two numbers that PHP deserves better treatment. What I want to describe is something that has gone largely unnoticed, including by those of us who work on PHP: across Europe, public administrations have already decided what their digital infrastructure runs on. They decided it in procurement documents, framework agreements, and coalition agreements. And when those documents say "digital sovereignty", what they describe, over and over, is a PHP application.

Where citizens actually reach their governments

The European Commission is the largest case: At the Drupal4Gov EU conference in Brussels in January 2026, the team behind the Europa Web Publishing Platform described what they operate: 770 live sites for 44 different Commission services, 700 million visits and 2.2 billion page views per year. The move to a shared Drupal platform began in 2019, because letting each Directorate-General maintain its own customised codebase had made security patching and consistent user experience progressively harder. The reusable parts are public, in the OpenEuropa and ec-europa organisations on GitHub.

The European Union Aviation Safety Agency runs its Sustainability Portal on Drupal: a regulatory compliance platform serving over 350 airlines and 31 national authorities for the ReFuelEU Aviation regulation. Analytics run on Matomo, email on Mautic. Three PHP applications carry an aviation compliance regime.

In the Netherlands, DICTU's GovNL CMS brings government website deployment down from three months to ten minutes using design tokens, Drupal Recipes, and automated infrastructure. In France, the Drupal base theme for the state design system is monitored by the Service d'Information du Gouvernement and DINUM, so the French state supervises PHP code as part of its own design authority. In the United Kingdom and Ireland, LocalGov Drupal has over 58 councils sharing a common codebase and pooling development budgets, with reported savings of 50 to 80 percent against building a council website from scratch. In Australia, GovCMS hosts more than 370 websites for 115 government agencies, has been running for over a decade, and holds an OFFICIAL:Sensitive security classification.

Not one of these is a pilot project. Each of them carries the everyday traffic between a government and the people it serves.

Germany's shortlist only had PHP entries

The German case is worth looking at closely, because the decision is documented rather than inferred.

The Government Site Builder (GSB) became, in version 11, a measure under the federal Ministry of the Interior's service consolidation programme. It is built entirely from open-source components and published on the OpenCoDE platform, and it is based on TYPO3. The evaluation that led there had narrowed the field to Drupal and TYPO3: the shortlist for the German federal government's standard content management system consisted exclusively of PHP applications. The work was then split. A consortium led by CPS, with 3pc, brandung, DFAU, in2code, THE BRETTINGHAMS and queo, develops GSB 11 itself over four years. In March 2025, a consortium of 17 TYPO3 agencies led by the Materna Group won the migration lot and will move hundreds of federal websites across.

The most telling detail is not German at all: When Swiss parliamentarians criticised their own federal administration for procuring a closed-source CMS, they held up the German decision as the model to follow: "Deutschland machts vor", Germany is showing how it's done. A national decision to standardise on a PHP application is now cited in a foreign parliament as best practice.

The sovereign workplace is a PHP application

In these programmes, digital sovereignty is described in practice by naming specific pieces of software.

The ITZBund's Bundescloud includes the SIB-Box, built on Nextcloud, serving roughly 300,000 federal users. openDesk, the sovereign workplace built by the Zentrum für Digitale Souveränität, integrates Nextcloud alongside Collabora, Element, Open-Xchange, OpenProject, and XWiki. It is anchored in the German coalition agreement: by October 2028 the federal administration is to have a digitally sovereign alternative to proprietary IT workplaces. The state of Baden-Württemberg has already migrated close to 60,000 teacher workplaces; the Bundeswehr has a framework agreement; the Robert Koch Institute and several ministries run components in production. The International Criminal Court in The Hague intends to adopt it.

Nextcloud Server is a PHP application: versions 33 and 34 support PHP 8.2 through 8.5, and the administration manual still opens the installation chapter with PHP configuration. That claim needs a caveat, because the picture has changed: the Files High Performance Backend is written in Rust, and the ADA engine announced in 2026 rewrites the file access layer in PHP, Go, and Rust. PHP carries the application and the business logic, but the I/O-bound paths increasingly do not. MediaWiki, which runs Wikipedia, is built the same way.

The asymmetry

€108 million for one national migration. 770 sites at the European Commission. 370 across the Australian government. Around 300,000 users in the German federal cloud. Tens of thousands of teacher workplaces in one German state alone.

And $730,534 in contributions to The PHP Foundation in 2025, from 536 organisations and individuals, substantially fewer than the previous year, with expenses exceeding donations by roughly $139,000, a deliberate choice to maintain technical headcount. Thirteen contracted engineers maintain the language underneath all of it.

I want to be careful about the conclusion here, because nobody in this story has acted badly. What the numbers show is a structural gap: the institutions most dependent on PHP have no established mechanism by which that dependency turns into maintenance funding. Nobody designed that gap; it is what happens when infrastructure is free at the point of use.

One institution has already built the mechanism. The Sovereign Tech Agency, funded by the German government, commissioned work that produced the PHP-FPM Web Services Tool and the evolution of PHP's stream layer for async, security and performance. Public money went into the substrate and shipped capability came back out. The mechanism exists and it works. What it lacks is the habit of being used.

What would make it normal

At Drupal4Gov EU, Tiffany Farriss, now Interim CEO of the Drupal Association, proposed a set of procurement changes that translate directly to any language ecosystem. They are worth repeating here because they require no goodwill, only a change to how tenders are scored, and because the first of them fits inside a framework that European procurement already uses:

1. A sovereignty criterion with real weight: Twenty percent of tender evaluation points awarded for verified open-source contributions, as a distinct assessment criterion under the MEAT framework, the Most Economically Advantageous Tender. That puts software transparency and digital sovereignty next to the qualitative, environmental and social criteria a tender is already allowed to score.
2. A maintenance line item: A share of contract value allocated to upstream maintenance of the components the delivery depends on, budgeted at the outset rather than found later. Farriss deliberately does not fix the number and would rather see one settled in public: her own estimate is 2 to 5 percent, depending on the budget and the duration of the project, and up to 10 percent on complex ones.
3. A 30-day upstream rule: Non-sensitive code developed under public contract contributed back within 30 days, so that the next administration inherits it instead of paying for it again.

An administration that adopts these does not need to know or care that its CMS is written in PHP. It only needs to accept that the code it depends on has maintainers, and that maintainers have budgets.

What we are asking

If you work in or with a public administration: the software your organisation depends on almost certainly includes several PHP applications, and quite possibly the ones your sovereignty strategy is built around. The three proposals above belong in your next tender rather than in your next strategy document.

If you are an agency delivering these contracts: put the line item in the bid. You are in a better position than anyone to make upstream maintenance a normal cost of delivery rather than an act of charity.

And if you know a case we have missed, a ministry, a municipality, a health service, a statistics office running on PHP, tell us. This article covers Europe and one Australian platform because that is as far as the research went. We would like to publish those cases here, written by the people who built them.

Brent is a developer advocate for PHP at JetBrains, but he is also a writer, content creator, event organizer, community leader, and open source contributor. He is a well-recognized voice on PHP Annotated, maintains an active blog at stitcher.io, and is the creator of the Tempest framework for PHP, one of his bigger open source projects.

PHP has been my passion for over 15 years, and I'm happy to contribute to its success in any way I can. I'm looking forward to joining the Foundation board and see what the future holds for this amazing language and community. --Brent Roose

As Roman Pronskiy's term comes to an end, Brent will be replacing Roman as the JetBrains representative on the Board. As one of the founding members and first Executive Director of The PHP Foundation, Roman's impact is undeniable. The PHP Foundation would not be where it is today without his influence, his effort, and his guidance. We are incredibly grateful for his dedication and commitment to the Foundation's mission and the sustainability of the PHP language. Thank you for everything, Roman! ❤️🐘

As part of this effort, we are excited to be launching a monthly one-hour interactive podcast in partnership with the folks at PHP Architect. This podcast will be called The PHP Foundation Community Hour and will feature various Foundation staff, contractors, and friends who will be sharing tips and insight into different contribution paths. These will be hosted on the second Thursday of every month on the PHP Architect podcast platform.

The PHP Foundation Community Hour is meant to be a casual interactive session and we welcome your questions before and during the event. If you want to submit a question beforehand to our guests, you can use this form to do so. Please keep in mind that while we may choose to answer select questions that fall outside our topic, we are mostly focused on helping people understand how they can contribute to PHP.

Our first episode is coming in a few weeks! Here are the details:

• First Episode Time/Date: September 10, 2026 at 12:30 pm Eastern / 16:30 UTC
• Topic: Getting Started with Contributing to PHP
• Guest: Matt Stauffer
• Host: Elizabeth Barron
• Subscribe to the calendar through an .ics link to see upcoming guests
• Subscribe on Spotify, YouTube, and other platforms

We want to extend a heap of gratitude to the folks at PHP Architect for providing the infrastructure, platform, and technical support that enables us to host these events.

Hope you can join us on September 10!

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.