By default, PowerShellOrg supports the latest minor release of the latest
major version of each module. Individual repositories may define a broader
support window in their own SECURITY.md; where they do, the repo-level policy
takes precedence over this document.
Version policy
Receives security fixes?
| Latest release |
Yes |
| Previous minor (same major) |
Best-effort; patch may not be backported |
| Older majors |
No |
If you are unsure whether a version is covered, open a discussion or check the
repo's own SECURITY.md.
Reporting a vulnerability
Please do not report security vulnerabilities in public GitHub issues.
Preferred method: GitHub Private Vulnerability Reporting
Use GitHub's built-in Private Vulnerability
Reporting on the affected repository:
- Navigate to the repository on GitHub.
- Click Security → Advisories → Report a vulnerability.
- Fill in the form with as much detail as you can provide.
This creates an encrypted draft security advisory visible only to maintainers
and the Org Admin.
If GitHub Private Vulnerability Reporting is unavailable or you prefer email:
privacy@powershell.org
A useful report includes:
- A description of the vulnerability and the potential impact
- The affected module name(s) and version(s)
- Steps to reproduce or a proof-of-concept
- Any known mitigations or workarounds
- Your preferred contact method for follow-up
Once we receive your report:
Milestone
Target
| Acknowledge receipt |
72 hours |
| Provide a status update |
7 days |
| Deliver fix or mitigation for critical severity |
14 days |
| Deliver fix or mitigation for high severity |
30 days |
| Deliver fix or mitigation for medium/low severity |
90 days |
These are targets, not guarantees. If we need more time, we will tell you why.
We follow a coordinated disclosure model:
- Reporter submits the vulnerability privately.
- Maintainers validate and develop a fix.
- We agree on an embargo period (typically 14–90 days depending on severity and
fix complexity).
- A patched release is published.
- A GitHub Security Advisory is published, credited to the reporter unless they
prefer to remain anonymous.
- For serious vulnerabilities we will request a CVE from a CNA; this typically
happens at or before public disclosure.
We ask that reporters:
- Allow us the agreed embargo window before public disclosure
- Avoid exploiting the vulnerability beyond what is needed to demonstrate it
- Avoid accessing or modifying data belonging to others
In return, we commit to:
- Keeping you informed throughout the process
- Crediting you in the advisory and release notes (unless you prefer anonymity)
- Acting in good faith to resolve the issue promptly
The following are generally not in scope for security reports:
- Vulnerabilities in PowerShell itself, the .NET runtime, or Windows — report
those to Microsoft
- Issues that require the attacker to already have administrative or write
access to the affected system
- Denial-of-service attacks that require significant resources from the attacker
- Social engineering of maintainers or contributors
If you are unsure whether your finding is in scope, report it anyway — we would
rather review a borderline finding than miss a real one.
General security questions (not vulnerability reports) can be asked in GitHub
Discussions on the relevant repository.