Reporting a vulnerability
Email [email protected]. Include the affected URL or plugin slug, the version you tested, and enough detail for us to reproduce the issue. A short proof-of-concept helps more than a scanner report.
You do not need to encrypt the first message. If the finding warrants it, we will agree an encrypted channel in the reply. We currently publish no PGP key, and we would rather say that plainly than list a key file that does not exist.
We answer in English, Polish and German.
What this policy covers
It covers wppoland.com, plogins.com, and every plugin we publish under the plogins name, whether distributed through the WordPress.org directory or from our own site.
It does not cover third-party plugins, themes or hosting that we merely install or maintain on a client’s behalf. Those belong to their authors and we will forward a report if you ask, but we cannot patch someone else’s code. If you found something in a component we recommended, we still want to know, because that changes what we recommend.
What we commit to
| stage | our commitment |
|---|---|
| acknowledgement of your report | 2 working days |
| first assessment, confirmed or not | 5 working days |
| patch for a confirmed critical issue in our plugin | 7 days from confirmation |
| patch for a confirmed high or medium issue | next scheduled release |
| public advisory after the patch ships | within 14 days |
For a critical issue, if a patch cannot ship inside those 7 days, we will pull the plugin from distribution rather than leave a known hole in circulation, and we will tell you that is what we did.
The clock starts when we receive your report, not when the issue was introduced. If we go quiet for more than 10 working days without explaining why, treat that as a failure on our side and escalate to the second contact listed in our security.txt.
When we cannot fix it in time
Sometimes a fix is not ready, or it is ready but breaks something that would hurt users more than the vulnerability does. In that case we publish a workaround and say why the fix is late. What we will not do is stay silent and hope the finder loses interest.
If you have a disclosure deadline, tell us in the first message. We will work to it or negotiate it openly. We do not ask for indefinite embargoes.
Safe harbour
If you follow the rules below, we will not pursue or support legal action against you over the research, and we will say so in writing if you need it.
Test only against your own installation, or against a site you are explicitly authorised to test. Do not run denial-of-service tests. Do not send spam or bulk messages. Do not use social engineering against our people, our clients or our suppliers. Do not access, modify, exfiltrate or retain data that belongs to anyone else, and stop the moment you have enough to prove the issue.
If you accidentally access someone else’s data, stop, do not save it, and tell us what happened in the report. We would rather hear it from you.
Credit, not cash
We run no bug bounty and pay no rewards. We are a small company and we would rather be honest about that than advertise a programme we cannot fund.
What we do offer: we credit reporters by name or handle in the release notes and in the advisory, if they want the credit, and we will confirm in writing that a report was valid and what we did about it. For a researcher building a track record, that written confirmation is usually the thing that matters.
What we publish about our own plugins
Two commitments that follow from how the plugin ecosystem actually behaves. We measured the WordPress.org directory in August 2026 and found that more than half of all listed plugins had received no update in two years, almost always without any announcement.
So: when we stop maintaining a plugin, we will say so on its page and in a final release, rather than letting it go quiet. And when we ship a security release, the changelog will say that it is a security release, so anyone tracking our plugins can tell the difference between a fix and a feature.
For clients under regulatory obligations
If you operate under NIS2 or the Polish national cybersecurity act and you use a plugin we publish, you may need to document us as a supplier in your ICT supply chain. This page, plus the timelines above, is the document to reference. Ask us and we will confirm the details in writing on company letterhead, including the versions you run and when they were last updated.
We are not able to file incident notifications to authorities on your behalf. That obligation sits with the covered entity, not with its supplier. We can supply the technical detail you need for your own filing, and we will do it inside your reporting window if you tell us what that window is.
Contact
- [email protected] for vulnerability reports
- The contact form for anything else
- Machine-readable version: security.txt
Last verified: 11 August 2026.
