COORDINATED DISCLOSURE
Report a vulnerability
Email security@ipscanner.pro with what you found and how to reproduce it. Report early rather than not at all: an unclear suspicion is worth more to us than silence. The same address is published in machine-readable form at /.well-known/security.txt.
Write to security@ipscanner.pro
What we ask of you
- Test only against your own installation and your own networks.
- Do not access, modify or keep anyone else’s data. If you come across someone else’s information, stop and tell us what you saw without collecting more of it.
- Do not degrade the service for other people, and do not run volumetric attacks.
- Give us a window to fix the problem before you publish.
What we will do
- Read what you send and take it seriously, including the reports that turn out to be nothing.
- Tell you what we concluded, even when the conclusion is that we will not change anything.
- Credit you in the fix notes if you want the credit.
- Not pursue or support legal action against you for research carried out in good faith under this policy.
We do not publish a response-time commitment, because one we cannot keep would be worth nothing. What we will not do is leave a report unanswered.
In scope
- The desktop application and the scanning Agent on macOS and Windows, including the local IPC boundary between them.
- How scan results and history are stored: the encryption of retained history, and the handling of its keys in macOS Keychain or Windows DPAPI.
- Anything that causes the application to send data off the machine that Local Only mode says it will not send.
- This website: the pages it serves, the headers it sends, and its handling of anything a visitor supplies.
- Distributed artifacts and their signatures, including a build that does not match a published checksum.
Out of scope
- Volumetric denial of service, load testing, or anything that degrades service for other people.
- Social engineering of the operator, and physical attacks.
- Reports produced only by a scanner with no demonstrated impact — a missing header on a page with nothing to protect, for example.
- Findings in third-party services we merely use, which should go to that vendor; tell us too if it affects users here.
- That the scanner scans networks. That is what it does, on a network you authorise it to scan.
What to include in a report
- What you found, in one or two sentences, before the detail.
- The steps to reproduce it, precise enough that we can follow them without guessing.
- The version and platform: the build you tested and the operating system it ran on.
- What an attacker gets out of it, and what they would need first.
- Anything you think we will disagree with. Say it — it is faster than us finding it later.
The machine-readable version
This channel is also published under RFC 9116 at /.well-known/security.txt, which names the same address and carries an expiry of 2027-09-11 so that a stale file is visibly stale rather than quietly trusted.
Common questions
Is there a bug bounty?
No, and we would rather say so plainly than let you find out after the work. There is no payment scheme today. Credit in the fix notes is offered if you want it, and declined gladly if you do not.
Can I publish what I found?
Please give us a reasonable window to fix it first — ninety days is the norm we work to, sooner when the fix is simple. If a fix is taking longer than that, we would rather agree a date with you than go quiet.
Do you have a PGP key?
Not published yet. If your report is sensitive enough that plain email worries you, say so in a first message without the detail and we will agree a channel before you send anything further.
I am not sure it is a real problem. Should I still write?
Yes. Deciding whether something is a vulnerability is our job, not a filter you have to pass first. An uncertain report costs us a few minutes; an unreported one can cost a user their network.
Not a security problem — just something broken, confusing, or wrong on a page? That goes to support, and it is just as welcome.