How to report
Write to security@ethdns.com in English. Plain text is best. A useful report contains:
- the affected service, URL or hostname;
- what the problem is and what an attacker could actually do with it;
- steps to reproduce, from the start, as if we had never seen the service;
- a proof of concept, kept to the minimum needed to show the problem;
- the date and time of your tests, with the time zone, so we can find them in our logs.
Please report one issue per message and do not share it with anyone else until it is fixed.
Reports can be encrypted. Our OpenPGP public key is at /.well-known/pgp-key.txt. Fingerprint: 634F 7C36 1041 1415 FC9E C7AB 08EA EDFC F35C 0D63. It was created on 2 October 2026 and expires on 1 October 2029. Encryption is optional: a plain text report is just as welcome.
Scope
In scope are services run by the administrators under ethdns.com.
Out of scope:
- Third-party projects hosted with us. Their owners are responsible for their code. Report to the owner; if you cannot reach them, or the problem is being exploited, write to abuse@ethdns.com and we will pass it on.
- Providers we use. Problems in their platforms belong in their own security programmes.
- Hosts that only claim to be ours. A reverse DNS name under ethdns.com proves nothing by itself; see Is it ours?
Rules for testing
- Test only with your own accounts and your own data.
- Do not access, change or delete data that is not yours. If you come across someone else’s data, stop, do not keep a copy, and tell us.
- No denial of service, no load testing, no flooding of forms or mailboxes.
- No social engineering of the administrators or of anyone else, and no physical attempts.
- Automated scanners only at a gentle rate. If our monitoring notices you before we read your report, you were too loud.
- Give us reasonable time to fix the problem before anything is made public.
If you follow these rules and act in good faith, we will treat your report as help, not as an attack.
No bug bounty
ethdns is a private, non-commercial project. We do not run a bug bounty programme and do not pay for reports, in money, gifts or listings. Please do not ask before or after sending a report. A real problem, clearly described, gets our gratitude and a fix.
Reports we do not accept
The following are read, but not answered, unless they come with a demonstrated, exploitable impact:
- raw output of automated scanners;
- missing or “weak” HTTP headers (CSP, X-Frame-Options and the like);
- SPF, DKIM, DMARC or DNSSEC settings;
- clickjacking on pages without sensitive actions;
- software version numbers or banners;
- TLS cipher preferences and certificate details that browsers accept;
- self-XSS, logout CSRF and similar issues without a victim;
- issues that require a device or account that is already compromised.
Messages that combine such findings with a request for payment are treated as spam.
What happens next
- We confirm the issue and may ask questions while we reproduce it.
- We fix it or reduce the risk while a proper fix is prepared.
- We tell you when the fix is in place, so you can check it.
- Disclosure. After the fix you are free to write about it. We would appreciate seeing the text first, so that nothing still open is revealed.
There is no fixed response time (why); serious issues are handled first.
security.txt
Our security contact is also published in machine-readable form at /.well-known/security.txt, following RFC 9116. Tools and researchers who look there will find the same address as on this page.
Last updated 2 October 2026.