Vulnerability disclosure policy
I welcome reports about security issues in my own infrastructure. This page says what is in scope, what I ask of you, what I can offer legally, and what you get back. It is the policy referenced from my security.txt.
Kauz Security Services GmbH is one person: me. There is no bug bounty and no triage team. What you get is a prompt, competent reply from someone who does this work for a living.
Contents
Scope
In scope:
kauz.gmbh,www.kauz.gmbh,mta-sts.kauz.gmbh- My DNS, mail, and TLS configuration
- Configuration issues specific to my
storage.kauz.gmbhinstance
Out of scope:
- Nextcloud itself.
storage.kauz.gmbhis a managed instance operated by Hetzner Online GmbH. Vulnerabilities in the Nextcloud software belong to the Nextcloud security team at https://hackerone.com/nextcloud. Misconfiguration of my instance is in scope and I want to hear about it. - Third-party services I consume but do not operate: Cloudflare, GitHub, mailbox.org, Hetzner. Please report those to the vendor.
- My clients’ systems. Nothing on this page authorises testing against any system belonging to a client, whether or not you found it referenced on this site.
Findings I will not act on
This list exists so you do not spend time on something I have already assessed. It is not a claim that these never matter, only that on a static brochure site with no accounts, no forms, and no state-changing actions, they do not.
- Missing or “weak” HTTP security headers, absent a concrete attack that follows from the omission
- Permitted TLS versions or cipher suites, absent a demonstrated downgrade or break
- Software, framework, or server version disclosure
- SPF, DKIM, DMARC, or MTA-STS configuration, unless you can show mail that passes authentication and shouldn’t
- Clickjacking on pages with no sensitive action to hijack
- Self-XSS, or issues requiring the victim to paste attacker-supplied content into their own console
- Missing rate limiting on endpoints with no authentication and no state change
- Content-Security-Policy violations originating from extensions in your own browser. My pages contain no inline script or style at all; blocked inline code on this site is, by construction, injected client-side.
- Output from an automated scanner submitted without a working proof of concept
- Reports asserting that a finding exists without saying what it is, as a preface to a sales conversation
If you believe one of these does have real impact here, send it with the impact demonstrated and I will look properly.
What I ask
- Test only assets in scope, at a volume an ordinary visitor would generate.
- Use an exploit only as far as needed to establish that the vulnerability is real.
- Do not access, modify, delete, or retain data that is not yours. If you encounter client data or personal data, stop immediately, do not keep a copy, and tell me.
- Do not pivot, establish persistence, or move laterally.
- Give me a reasonable chance to fix the issue before publishing. I would rather agree a timeline with you than impose one; if we cannot agree, 90 days from your report is a norm I will not argue with.
Not authorised under any circumstances: denial-of-service or load testing, physical access attempts, social engineering of me or anyone connected to me, and any action affecting a third party.
Legal position
German criminal law has no general concept of “authorised access” comparable to the US Computer Fraud and Abuse Act, and most published disclosure-policy templates are drafted for US law. What follows is what German law actually lets me offer, and where its limits are. It is my reading of the statute, not legal advice.
Consent. §§ 202a and 202b StGB penalise access that is unbefugt (unauthorised). Where the party entitled to the data consents to the access, the access is not unauthorised and no offence is committed. For the systems I operate, and within the scope and rules set out above, this policy is that consent. Research that stays inside it is not a crime I choose not to prosecute; it is not a crime.
Where my consent does not reach. I can only consent for what is mine. The website
is served by GitHub and Cloudflare, and storage.kauz.gmbh runs on Hetzner’s
infrastructure. My consent covers my content and my configuration on those services,
not the provider’s platform underneath. It does not cover my clients or any third
party.
Strafantrag. Offences under §§ 202a, 202b and 202d StGB, and under § 303a StGB, are prosecuted only on application by the injured party (§ 205 Abs. 1 and § 303c StGB), and that application is mine to make or withhold. For research carried out in good faith under this policy, including honest mistakes at the edge of scope, Kauz Security Services GmbH, represented by me:
- will not file a Strafantrag, and will not support one;
- will not bring civil claims arising from your research;
- will, if a third party questions your conduct, confirm in writing that your research was carried out with my knowledge and consent under this policy.
What I cannot offer. Three real limits, stated because pretending otherwise would be worthless to you:
- The Staatsanwaltschaft may prosecute §§ 202a, 202b and 303a StGB regardless of my position where it sees a besonderes öffentliches Interesse (§ 205 Abs. 1 Satz 2, § 303c StGB). My forbearance does not bind it.
- § 202c StGB (the Hackerparagraf) is not an Antragsdelikt at all. The Federal Constitutional Court reads it as requiring the intent to commit an offence under §§ 202a or 202b (BVerfG, 18.05.2009, 2 BvR 2233/07), which good-faith research under a consent-based policy lacks. But no statement by me changes how a prosecutor reads a specific case.
- The Federal Ministry of Justice’s draft of November 2024, which would have written a security-research exception into § 202a StGB, has not been enacted. Until it is, a disclosure policy in Germany is consent plus a private-law assurance, not statutory immunity. Mine included. I would rather you knew that than relied on boilerplate that implies otherwise.
Reporting
One channel: hello@kauz.gmbh. Please encrypt anything sensitive.
- Key: https://kauz.gmbh/pgp.asc
- Fingerprint:
5F01 B82C A56A 261D AAD4 64BC B270 C72F 4A0A 61AF - Also available via WKD:
gpg --locate-keys hello@kauz.gmbh
A useful report contains the affected URL or host, the request, what you observed, and
what an attacker gets from it. Put URGENT SECURITY in the subject line if it is
genuinely time-critical.
English or German, whichever you prefer.
What to expect
- Acknowledgement within five business days.
- An assessment once I have had time to reproduce it, normally within two weeks.
- Honest feedback. If I think a finding does not hold up, I will say so and explain why, rather than let it sit unanswered.
- I may decide not to act on a report. If so I will tell you, though not always in detail.
- Credit, by whatever name you choose, in any advisory or changelog, or none, if you would rather stay anonymous. Just say which.
I do not pay bounties and I am not going to pretend that is under review. I am also frequently in client engagements, which occasionally makes me slower than the times above; if that happens I will tell you rather than go quiet.