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.
Please do not report security vulnerabilities in public GitHub issues.
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:
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.