Published on October 14, 2026, Alexandre Daubois describes the work behind PHP’s core security reports. The team combines community members with developers funded by The PHP Foundation. It operates independently of the Foundation, while the Foundation’s Ecosystem Security Team works alongside it. A team member reads every report, attempts reproduction and checks the case against the classification policy before a decision.

Since July 1, the team has published 15 CVEs and closed 106 reports. The closures covered non-vulnerabilities, duplicate reports and cases that could not be reproduced. Some reports came from fuzzers using conditions unlike those found in production. Every report received a review. Cases that are not vulnerabilities but still reveal bugs can become hardening work. Daniel Scherzer recently joined the Ecosystem Security Team for that work.

The PHP Group is a CVE Numbering Authority for php-src and has assigned its own CVE identifiers since 2019. The team therefore controls the timing of its advisories. GitHub’s advisory queue can take weeks to review some reports in 2026. PHP does not have to wait for that process once a fix is ready.

A backlog of security reports remains. The team asks reporters not to use public issues, pull requests or social posts to pressure it, because that could expose a bug before a fix exists. Volunteers and PHP Foundation-funded developers handle the work. The Foundation says sponsorship helps provide the resources required for PHP security.

AI tools have increased the number of reports reaching php-src and reduced the effort needed to write them. The team responds with more automation. Reproduction covers Linux and macOS. It also covers Windows and any other platform required by a case. Builds use AddressSanitizer and UndefinedBehaviorSanitizer and follow the project’s CI setup.

The team has access to Daybreak Red, the highest tier of OpenAI’s Daybreak program. The program is restricted to approved defenders and supports vulnerability research and exploit validation. OpenAI made access available as part of its support for open-source maintainers. The team uses the system to follow proof-of-concept code through the engine, test the claimed impact and identify reports with a shared root cause. Earlier in 2026, it also used Claude Mythos, an Anthropic model focused on security work, through contacts at Alpha-Omega.

Models do not make the final decisions. A person assigns severity and writes or reviews each patch. The team does not send an analysis to a reporter until someone has attempted reproduction.

Reports should be submitted through the GitHub security advisory form at github.com/php/php-src/security/advisories/new. Public issues are intended for cases outside the security process. A useful report starts with the smallest PHP script that triggers the problem. It should state the PHP version or commit. The operating system and configure flags are also needed. Full sanitizer output helps when available.

The report should explain which input an attacker controls, in what type of application and what result the attacker can obtain. Impact is often the least detailed part of a submission, even though it determines severity. Long, dramatic reports slow down simple investigations. The security classification policy is available at github.com/php/policies/blob/main/security-classification.rst.

The policy does not classify valid PHP used maliciously as a vulnerability. It also excludes unsanitized input passed to functions such as mysqli_query(), FFI issues, open_basedir bypasses, non-standard builds and problems limited to the built-in web server. These cases may still be bugs and can go to the public issue tracker.

AI-assisted reports are welcome when the sender reproduces the problem on a PHP build, checks the policy and understands the claim. A model-generated crash that cannot be reproduced takes the team time to dismiss and will be closed.