Report a Vulnerability

We take security seriously. If you've found a vulnerability in MagicAuth, OpenTrust, or any other Ettic plugin, please report it privately so we can fix it before public disclosure.

Report a vulnerability privately

GitHub Security Advisories (preferred)

Each Ettic plugin repository has private vulnerability reporting enabled. This is the fastest path and keeps the discussion private to you and the maintainers.

• MagicAuth: github.com/nolderoos/magicauth/security/advisories/new
• OpenTrust: github.com/nolderoos/opentrust/security/advisories/new

You'll need a free GitHub account. Reports stay private until a coordinated disclosure date.

Email

If you can't or don't want to use GitHub, email security@ettic.nl. Include the same details listed below. We monitor this inbox during business hours (Europe/Amsterdam). PGP is available on request.

What to include

A useful report typically has:

• Plugin name and version (e.g. MagicAuth 1.4.0).
• WordPress and PHP versions you reproduced on.
• A clear description of the issue and its security impact.
• Step-by-step reproduction, ideally with a minimal proof of concept.
• Any relevant logs, screenshots, or HTTP requests.
• Whether you've already disclosed the issue elsewhere (Patchstack, WPScan, WordPress.org Plugin Team, etc).

We're a small team, so the more reproducible the report, the faster we can ship a fix.

Scope

In scope

• The latest released version of any Ettic plugin.
• The main branch of an Ettic plugin repository when it materially differs from the latest release.
• Bundled assets that ship with the plugin (templates, JavaScript, CSS, REST routes).

Out of scope

• WordPress core itself. Report those to HackerOne.
• Third-party plugins, themes, hosts, or CDNs.
• Issues that require an attacker who already has administrator privileges.
• Self-XSS, missing best-practice headers without a demonstrable impact, version disclosure, and other low-impact informational findings.
• Volumetric or denial-of-service testing against production sites.

How we handle reports

Acknowledgement and triage

We aim to acknowledge new reports within 2 business days. Triage and severity assessment usually happen within a week.

Fix and coordinated disclosure

Once we've confirmed the issue, we'll keep you in the loop on the fix, target release, and disclosure timeline. Default coordinated disclosure window is 90 days from initial report, shorter for trivial fixes, longer if a coordinated upstream change is required. We'll request a CVE on your behalf when applicable.

Credit

We credit reporters in the plugin changelog and the GitHub Security Advisory unless you ask us not to. Let us know how you'd like to be named (real name, handle, organisation, link).

What not to do

• Don't run automated scanners against sites you don't own.
• Don't access, modify, or destroy data that isn't yours.
• Don't pivot from one finding to attack other tenants on the same host.
• Don't disclose publicly before the agreed disclosure date.

Acting in good faith and within this policy means we won't pursue legal action.