Vulnerability Disclosure Policy

We welcome reports about security issues in our own infrastructure. This page sets out what is in scope, what we ask of you, what we can offer legally, and what you can expect back. This is also the policy referenced from our security.txt.

Kauz Security Services GmbH is a one-person consultancy. We do not run a bug bounty and we have no triage team. What we can offer is a prompt, technically competent reply from someone who does this work for a living.

Scope

In scope:

• kauz.gmbh, www.kauz.gmbh, mta-sts.kauz.gmbh
• Our DNS, mail, and TLS configuration
• Configuration issues specific to our storage.kauz.gmbh instance

Out of scope:

• Nextcloud itself. storage.kauz.gmbh is 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 our instance is in scope and we want to hear about it.
• Third-party services we consume but do not operate: Cloudflare, GitHub, mailbox.org, Hetzner. Please report those to the vendor.
• Our 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 we will not act on

This list exists so you do not spend time on something we 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. Our pages contain no inline script or style at all; blocked inline code on our 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 we will look properly.

What we 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 us.
• Do not pivot, establish persistence, or move laterally.
• Give us a reasonable chance to fix the issue before publishing. We would rather agree a timeline with you than impose one; if we cannot agree, 90 days from your report is a norm we will not argue with.

Not authorised under any circumstances: denial-of-service or load testing, physical access attempts, social engineering of us or anyone connected to us, 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 us offer, and where its limits are. It is our 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 we operate, and within the scope and rules set out above, this policy is that consent. Research that stays inside it is not a crime we choose not to prosecute; it is not a crime.

Where our consent does not reach. We can only consent for what is ours. The website is served by GitHub and Cloudflare, and storage.kauz.gmbh runs on Hetzner’s infrastructure. Our consent covers our content and our configuration on those services, not the provider’s platform underneath. It does not cover our 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 ours to make or withhold. For research carried out in good faith under this policy, including honest mistakes at the edge of scope:

• we will not file a Strafantrag, and will not support one;
• we will not bring civil claims arising from your research;
• if a third party questions your conduct, we will confirm in writing that your research was carried out with our knowledge and consent under this policy.

What we 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 our position where it sees a besonderes öffentliches Interesse (§ 205 Abs. 1 Satz 2, § 303c StGB). Our 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 us 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. Ours included. We 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 we have had time to reproduce it, normally within two weeks.
• Honest feedback. If we think a finding does not hold up, we will say so and explain why, rather than let it sit unanswered.
• We may decide not to act on a report. If so we 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.

We do not pay bounties and we are not going to pretend that is under review. We are also frequently in client engagements, which occasionally makes us slower than the times above; if that happens we will tell you rather than go quiet.