CyberDilmeth publishes cybersecurity guidance. It would be indefensible for us to ask that of others and not accept it ourselves.

If you have found a security weakness in this website or its tools, we want to hear about it. This policy tells you what we consider fair game, how to report, what we promise in return, and how quickly we will act.

This is a small, independently run publication. We do not have a security team, an on-call rota, or a bug bounty budget. What we do have is a genuine commitment to fix what you find and to credit you for finding it.

In scope

• cyberdilmeth.com and its subdomains
• The browser-based tools published under /tools/, including Password Studio
• The Threat Intelligence application and its data handling
• Our DNS, email authentication and TLS configuration
• Any CyberDilmeth-controlled asset that handles reader data

Malvertising is the exception. If an ad served on this site delivers malware, redirects readers, or attempts anything abusive, we want to know immediately — that is in scope even though the ad network is not, because it is our readers being harmed on our pages. Send us the creative, the landing URL, and the page you saw it on.

If you find a misconfiguration on our side of any of these — a permissive DNS record, an exposed key, a subdomain we forgot to retire — that is in scope and we want to know.

If you make a good-faith effort to comply with this policy during your research, we will:

• Consider your research authorised and will not initiate or support legal action against you in relation to it
• Not report you to law enforcement or your employer
• Work with you to understand and resolve the issue quickly
• If a third party brings action against you for activity conducted under this policy, take steps to make it known that your actions were authorised

If at any point you are unsure whether a specific action is within scope, stop and ask first at [email protected]. We will answer, and asking will never count against you.

Email [email protected]. That address is monitored and goes to a real person.

To help us act quickly, please include as much of the following as you can:

Reports in any language are welcome, though English reaches us fastest.

If you need to send something sensitive and would like an encrypted channel, say so in your first email and we will arrange one before you send details.

To stay within this policy, please:

• Act in good faith. Test only to find and demonstrate a problem, not to exploit it.
• Use only your own data. Do not access, modify, save or destroy anyone else's data. If you encounter personal data, stop immediately and tell us.
• Take the minimum necessary. A single screenshot proving access beats a database dump, and we will treat it as equally convincing.
• Do not disrupt the service. No denial-of-service, no load or stress testing, no mass automated scanning that degrades the site for readers.
• Leave people alone. No social engineering, phishing or pretexting against us, our contributors, or our providers. No physical attempts against any facility.
• Do not plant anything. No backdoors, no persistence, no leaving test accounts or files behind. If your testing created something, tell us so we can clean it up.
• Give us a chance to fix it before going public (see section 7).

These are commitments we can actually keep, not aspirational numbers.

If we disagree with your severity assessment we will explain why rather than quietly downgrading it. If we cannot meet a target we will tell you before the deadline passes, not after.

Where a fix depends on a third party — a plugin author, our host, our CDN — we will say so and share what we can about their timeline.

We support public disclosure and we do not ask anyone to stay quiet indefinitely. We ask only for enough time to protect our readers first.

• Please give us 90 days from your initial report before publishing.
• If we fix the issue sooner, you are free to publish as soon as the fix is live.
• If you need a different timeline — because the issue is being actively exploited, or because you have a conference deadline — tell us and we will agree something workable.
• We will never use this policy, or the threat of legal action, to suppress publication of a legitimate finding.

If the issue affected reader data, we will publish our own account of what happened as well, in line with the corrections and transparency commitments in our Privacy Policy.

These are listed so you do not waste your time. We are happy to receive them as advice, but without demonstrated impact they will not be triaged as security issues:

• Missing security headers with no working exploit attached
• Missing cookie flags on cookies that carry no sensitive value
• Clickjacking on pages with no sensitive action
• Self-XSS, or attacks requiring an already-compromised browser or device
• Software version disclosure or "outdated component" findings without a working proof of concept against our installation
• Raw automated scanner output that has not been manually validated
• Missing rate limiting on unauthenticated, non-sensitive endpoints
• Email spoofing reports where our SPF, DKIM and DMARC records are correctly configured
• TLS configuration preferences, HSTS preloading, and similar hardening suggestions
• Issues affecting only end-of-life browsers
• Content, editorial or accessibility issues — these are real and we want them, just at [email protected]

If you believe one of the above does have real impact in our specific setup, show us the chain and we will look properly. The list is a default, not a wall.

Some things look like findings but are deliberate design decisions, already documented:

We do not operate a paid bug bounty. CyberDilmeth is independently run and has no security budget, and we would rather say that plainly than let you spend hours on the assumption that a payout is coming.

What we do offer:

• Public credit, in the form you choose — name, handle, or a link to your site or profile
• Acknowledgement in the changelog or advisory for the fix, where one is published
• A written reference confirming your finding and how you handled it, if that is useful to you professionally
• A straight, technical conversation with someone who will actually read your report

If you would prefer no credit at all, that is equally fine — tell us and we will keep your name out of everything.

Thank you for taking the time. Reporting a vulnerability properly takes effort and earns you nothing automatic — we do not take that for granted.