Security reporting

Security reports need a private path so maintainers can confirm the impact, prepare a fix, and coordinate disclosure before details become public.

Use private vulnerability reporting

The preferred channel is GitHub private vulnerability reporting.

Private vulnerability reporting is enabled for the ++PHP repository. If GitHub does not present the private report form, do not move the report to a public issue. Wait and try the private link again or contact the project without disclosing the vulnerability publicly.

Do not use ordinary GitHub Issues for an unpatched vulnerability. Public issues are appropriate for normal compiler defects that do not expose a security weakness.

Include enough detail to reproduce the problem

A useful report includes:

• The exact compiler version from vendor/bin/ppphp --version
• Operating system and PHP version
• The affected command and relevant ppphp.json settings
• A minimal source example or project layout
• Expected behavior and observed behavior
• The practical impact and any mitigation you have tested

Remove access tokens, credentials, personal information, production data, and unrelated secrets before attaching logs or a reproduction.

What happens next

Maintainers will acknowledge the report, reproduce the issue, assess the impact, and coordinate a fix and disclosure window. Reporters can request credit. Response and resolution time depends on severity and how reliably the problem can be reproduced, so the project does not promise a fixed deadline.

Security fixes are made for supported Stable releases and for the current release candidate. An older release candidate may need to be upgraded before a fix applies to it.

For ordinary bugs, use GitHub Issues. For release integrity, read Verify downloads.