Please report security vulnerabilities by emailing: responsible.disclosure@processingfoundation.org
- Security Advisories in a specific repository are received by p5.js admins/maintainers
- Responsible Disclosure email reports are received by Processing Foundation staff
- We will acknowledge your email within 72 hours
- We will provide regular updates about our progress
- Once the issue is confirmed and fixed, we may ask you to verify the solution
- Please do not disclose the vulnerability publicly until we have had a chance to address it
- We do not offer bounties as we are a non-profit organization
- We appreciate your efforts to responsibly disclose your findings
You can use the above email to report vulnerabilities in p5.js and related repositories managed by the processing org, including the reference website.
Please do not report security vulnerabilities in a public channel. If you notice a vulnerability being disclosed in a public channel (whether on Discord, the forum, GitHub, or other platforms), please flag it to a moderator immediately.
If any moderator in our online community spaces notices something that is plausibly a security vulnerability disclosure (you don’t need to verify deeply at this stage, false positive is OK), they should:
- screenshot and send to responsible.disclosure@processingfoundation.org
- delete the public content if possible
- reach out to the poster with a link to SECURITY.md in the correct project and a brief explanation that the content was taken down for security reasons
Who handles incoming reports of security vulnerabilities? Who responds to security incidents? A mix of Processing Foundation staff, current p5.js maintainers, and p5.js contributors, taking on the following roles and responsibilities:
| Role | Responsibility |
|---|---|
| Finder / Reporter | Credited when all reporter expectations (below) are met. |
| Incident Lead | First responder; owns the report end-to-end. By default, this is the Project Lead. Handoffs only with a written status summary. Owns advisory publication, and reporter notification. |
| Implementer(s) | Develops the fix; may be a maintainer or contributor nominated by Incident Lead or maintainer(s). |
| Reviewer(s) | At least one other maintainer reviews in the private fork before release. |
| Merge and Deploy | Deploys the updated/patched version. |
Whoever is available to claim the Incident Lead role starts as soon as they can with Phase 0.
Incident Lead:
- Notifies relevant people per project, to see which potential implementers are available
- Moves the conversation into a GitHub Security Advisory, if it is not already on there.
Acknowledge receipt to the reporter within 72H, along with triage & classification (below).
Reproduce the issue, potentially iterating with the reporter for more information.
Notify along private maintainer chat channels.
Is something a security vulnerability or incident? Use CIA (Confidentiality, Integrity, Availability):
-
(0) Not a problem: cannot reproduce, or behavior already documented as accepted risk in the threat model. Close with explanation.
-
(1) Public bug: problem is real but no CIA impact. Respond to the reporter with explanation, but fix openly in a normal PR.
Example: decompression bomb patch added in p5.js 2.3.3
-
(2) Vulnerability: impacts CIA (confirmed or plausibly demonstrated), but no evidence of exploitation. Move on to Phase 3 (Fix)
-
(3) Incident, including a High-Severity Vulnerability without logs to rule out past exploit: Move on to Phase 2 (Expedited Report) and then 3 (Fix)
Example: account takeover vulnerability fixed in p5.js Editor 2.22.8
In case of an incident, we have some specific reporting responsibilities, which are also fulfilled within 72H from the initial report.
The GitHub Security Advisory (GHSA) thread is the main place for technical discussion, and enables working on a fix in a private repository with a specific set of collaborators. In the GHSA workflow, there is a severity scoring tool that uses CVSS.
Timing of the fix depends on the CVSS score:
- Critical: act immediately, as soon as possible
- High/medium: target patch completion or release within about a week
- Low: batch into routine releases
- Merge + deploy the fix, verify it is patched on production
- Publish advisory and describe patch in release notes
- Notify the reporter(s) and everyone who worked on the fix
Reporters are offered credit in GHSA if their GitHub username is known and if their report:
- Contains a brief and useful summary, plus clear steps to reproduce
- Focuses on one report per defect, and avoids spurious LLM-generated reports
- Is supportive of the community