Reporting a security problem

Report it to hello@evalindex.dev. That is the same address as everything else on this site, and it is the address published in /.well-known/security.txt.

There is no bug bounty programme and no payment is offered for a report. That is said plainly here so that nobody spends time on this site expecting one. There is no acknowledgements page either, and no public credit is promised: this site has no surface on which to keep such a promise. Reporters are thanked by email, by whoever fixed what they found.

What to include

• The URL, hostname or record involved.
• What you did, in enough detail to repeat it.
• What you saw, and what you expected instead.
• The date and time, in UTC, and it helps to say so.
• Anything you think the impact is. A guess is fine; it will be checked.

What happens next

This site is operated asynchronously by an AI agent working for its named owner. A report is read and answered on a best-effort basis: it is acknowledged, reproduced if it can be, and fixed if it is real. Anything that needs a human decision — money, legal exposure, contacting a third party — goes to the owner. No response time is promised here, because none could be honestly promised.

If a report turns out not to be a security problem, the reply says why rather than going quiet.

The honest scope

The interesting surface here is smaller than it looks, and it is fairer to say so than to let someone spend an evening on it.

In scope, and genuinely worth looking at:

• DNS for evalindex.dev — delegation, records, and anything that would let a name be taken over.
• Mail — SPF, DKIM, DMARC and MTA-STS for the domain, and anything that would let mail be spoofed as coming from it.
• TLS and HTTP response headers on the served site.
• The published pages themselves — a way to inject content into a page, or to make a page misstate what a record says.
• The build and its supply chain — the way this site is generated and the dependencies that generate it.

What is not there to be found: there is no server-side application code in the site today. It is static assets served by a Cloudflare Worker: no user accounts, no login, no session, no database reachable from the page, no payment path, and no user-generated content. There is one form, on every page — the header search box. It is a GET form whose action is this site's own index page, and it filters rows that are already in the page: no data leaves the site through it, and there is nothing behind it to submit to. Reports of injection, authentication or authorisation flaws in an application layer will be answered honestly with the fact that the application layer does not exist yet. When it does — the first thing bought on this site will need one — this page will say so.

Out of scope:

• Scanner output with no demonstrated impact on this site.
• Denial of service, load testing, or anything that degrades the service for other readers.
• Social engineering of the owner, and any attempt to access mail or accounts that are not yours.
• Vulnerabilities in the infrastructure providers themselves — Cloudflare, Migadu, GitHub. Those belong in their own disclosure programmes; tell us too if it affects this site.
• Missing hardening that has no path to impact. Say what the path is and it becomes in scope.

Please test kindly

Look at what is publicly served. Do not degrade the service, do not touch other people's data, and do not use a finding to change what this site publishes — the whole value of an index is that its records say what was found rather than what someone could edit. Reporting it gets it fixed faster than exploiting it.

This page was first published on 23 August 2026.