Security Policy

Last updated: April 15, 2026
Machine-readable version: /.well-known/security.txt

Reporting a vulnerability

Email security@getsocietypress.org with details. Please do not file security issues through the public bug-reports page — we need time to patch before details are public, and a public issue is a head start for anyone malicious.

A good report includes:

• The SocietyPress version you tested against.
• Steps to reproduce the issue, including any specific configuration required.
• What an attacker could do with this vulnerability.
• Your assessment of severity, if you want to share one (we'll do our own too).
• Whether you'd like to be credited publicly, and if so, how.

What we commit to

• Acknowledge receipt within 3 business days. If you don't hear from us, assume the email got lost and send a nudge.
• Initial assessment within 7 business days — whether we've reproduced it, our severity rating, and a rough timeline.
• Regular progress updates every 7 days until the issue is resolved.
• Credit in the release notes if you'd like to be credited. Anonymous reports are also fine — we respect that preference.
• No legal action against good-faith research. If you're testing within the scope below and you don't deliberately harm users or data, we're grateful, not litigious.

In scope

• The SocietyPress WordPress plugin (any release since 1.0.0).
• The SocietyPress parent theme.
• The five bundled child themes (Heritage, Coastline, Prairie, Ledger, Parlor).
• The one-click installer (sp-installer.php).
• The getsocietypress.org marketing website itself.
• The demo site at demo.getsocietypress.org.

Out of scope

• Individual society installations we do not operate. If you've found a vulnerability on a specific society's website, please report it directly to that society. If you believe the root cause is in SocietyPress itself, report it to us with a generic reproduction.
• Third-party WordPress plugins installed alongside SocietyPress. Report those to their respective maintainers.
• Vulnerabilities in WordPress core. Report to the WordPress Security Team at wordpress.org/support/wordpress-hackerone/.
• Vulnerabilities in hosting provider infrastructure. Report to the host.
• Stripe and PayPal payment processor implementations. Report to them directly.
• Missing security headers that don't meaningfully change the attack surface (e.g., HSTS, CSP nitpicks). We read these reports but they rarely warrant CVEs.

What qualifies as a vulnerability

The usual suspects — roughly in order of how much they concern us:

• Remote code execution
• SQL injection
• Authentication bypass or privilege escalation
• Stored XSS
• CSRF on state-changing actions
• Insecure direct object references (IDOR) exposing member data
• Zip-slip, path traversal, or file inclusion
• Server-side request forgery (SSRF)
• Cryptographic weaknesses (encryption at rest uses libsodium's XChaCha20-Poly1305; flaws there are high-priority)
• Information disclosure of PII or credentials

What doesn't qualify

• Self-XSS that requires the user to paste something into the address bar.
• Denial-of-service via obviously resource-intensive actions on your own site. (Yes, you can hammer your own installation. No, that's not a vulnerability.)
• Missing rate-limiting on actions an admin can already do via the REST API.
• Social engineering of project maintainers.
• Reports generated solely by automated scanners without evidence of exploitability.
• Vulnerabilities that require the admin to be running an EOL version of WordPress or PHP.

Disclosure timing

Our preference is coordinated disclosure: we patch, push an update, notify society administrators, and then publish details. For critical issues, expect 7–14 days from patch to public disclosure. For lower-severity issues, 30 days is typical.

If 90 days pass without a fix or a clear plan, you are free to disclose publicly. We'd rather that never happen — if we're struggling to reproduce or prioritize, tell us and we'll escalate.

Safe harbor

Research that complies with this policy is authorized, and we will not pursue legal claims against researchers acting in good faith. Specifically, you are authorized to:

• Run security tests on your own SocietyPress installation.
• Run security tests on the demo site at demo.getsocietypress.org — but please reset it after (there's a reset button) and avoid actions that could affect other testers.
• Inspect the source code, which is available under the GPL.

You are not authorized to:

• Access member data on a society's production installation without their explicit permission.
• Run denial-of-service attacks against our infrastructure.
• Perform social engineering against project maintainers or society administrators.

Bug bounty

SocietyPress is a free, volunteer-driven project with no revenue. We cannot offer monetary bounties. We can offer prominent credit in release notes, a permanent listing on the contributors page, and the warm regard of every society whose data you helped protect — which is not nothing.