Security

Last updated: 10 September 2026

GeneratePress products run on hundreds of thousands of websites. Keeping them secure is a shared effort, and we are grateful to the security researchers who take the time to report issues to us. This page explains what is covered, how to report a vulnerability, what you can expect from us, and what we ask of you in return.

What this policy covers

Everything we make and run:

• GeneratePress (the free theme on WordPress.org)
• GP Premium
• GenerateBlocks (the free plugin on WordPress.org)
• GenerateBlocks Pro
• GenerateCloud
• GeneratePress AI
• generatepress.com and generateblocks.com, including customer accounts, checkout, licensing and our update servers

GeneratePress products are made by EDGE22 Studios Ltd.

How to report a vulnerability

Use either channel. Both reach the same people.

1. Email security@generatepress.com. This inbox is read by the product owner and the support lead only.
2. Report through Patchstack, our managed vulnerability disclosure programme: patchstack.com/database/vdp/3910aedb-3fe0-4221-8b1e-ff4e4aea3495. Patchstack triages the report, assigns a CVE where appropriate and coordinates disclosure with us. Reports submitted through Patchstack are eligible for Patchstack’s researcher bounty pool.

Please do not report security issues through the public support forum, GitHub issues, social media or a normal support ticket. If one arrives there we will move it to a private channel, but the details are public in the meantime.

What to include

• The product and version you tested
• Steps to reproduce, ideally with a proof of concept, request/response pairs or screenshots
• The impact: what an attacker can do and which user role, if any, they need
• The name or handle you would like credited, or a note that you prefer to stay anonymous

What you can expect from us

• Acknowledgement within 2 business days. You will hear from a person, not an autoresponder.
• Triage within 7 days. We will confirm whether we can reproduce the issue, tell you the severity we have assigned, and give you a target fix date.
• Fix timelines. Critical issues (unauthenticated, actively exploited, or leading to site takeover) are fixed as fast as possible, usually within 7 days. High severity within 30 days. Medium and low within 90 days or in the next scheduled release, whichever is sooner.
• Credit. Unless you ask us not to, we credit you in the changelog and in the CVE record.
• No surprises. If a fix is going to take longer than these targets, we will tell you why and when to expect it.

We do not currently run a paid bug bounty of our own.

Coordinated disclosure

We ask that you keep the details private until a fix is released and has been available to users for a reasonable period. Our default is public disclosure no later than 90 days after your report, or sooner once a fix is out. If we need longer, we will ask and explain why. If we go quiet on you, that is a mistake on our side. Please chase us.

Safe harbour

If you make a good-faith effort to follow this policy, we consider your research authorised. We will not pursue or support legal action against you for it, and we will work with you if a third party raises a concern about your research. In return we ask that you:

• Only test against sites you own or have permission to test
• Do not access, modify or delete data that is not yours, and stop as soon as you have enough to demonstrate the issue
• Do not degrade service for other users
• Do not use social engineering, phishing or physical attacks against us, our team or our customers
• Give us a reasonable time to fix the issue before disclosing it

Out of scope

The following are not vulnerabilities in our products, or are things we will not act on:

• WordPress core, other plugins or themes, PHP, or your hosting environment. We are happy to point you to the right place to report them.
• Anything that requires an already-compromised administrator account, server or database
• Issues on customer sites that come from that site’s own configuration, custom code or third-party plugins
• Actions available by design to users with the capability to perform them, such as administrators or users with the unfiltered_html capability adding markup
• Denial of service, brute force, rate limiting and spam
• Reports from automated scanners without a working proof of concept
• Missing security headers, best-practice suggestions or version disclosure without a demonstrated impact
• Clickjacking on pages with no sensitive actions

How we publish fixes

Security fixes ship as a normal plugin or theme update. The changelog entry is prefixed with Security: and includes the CVE identifier once one is assigned. Details are published in the Patchstack vulnerability database so that security tools and site owners can act on them.

Please keep automatic updates enabled for our products, or update promptly when a security release is announced.

EU Cyber Resilience Act

Our products are used in the European Union and we take our obligations under the Cyber Resilience Act seriously. If we become aware that a vulnerability in one of our products is being actively exploited, we notify the relevant EU authorities within the required deadlines and inform affected users of the corrective measures. If you have evidence that a vulnerability in one of our products is being exploited in the wild, please say so clearly in your report. It changes how quickly we have to act.

If your site has been hacked

A compromised site is usually not a vulnerability report, and our support team can help you work out what happened. But if you have evidence that a GeneratePress product was the way in, for example server logs showing the request that did it, please send that evidence to security@generatepress.com. It matters.

Machine-readable contact

Our security.txt file, following RFC 9116, is at generatepress.com/.well-known/security.txt.