General terms
- applies to websites explicitly and directly (no sub-domains): geizhals.at, geizhals.de, geizhals.eu, compare.eu, skinflint.co.uk, cenowarka.pl,
- in some cases, multiple reports for seemingly different websites might refer to the exact same problem / piece of code, because e.g. skinflint.co.uk uses the same code as geizhals.at etc. – here we will consider these multiple reports as one at our discretion.
- do not submit reports for other (sub-) domains, since they may be hosted by a 3rd party provider and we only have limited hardening options. For example, gct.geizhals.at or unternehmen.geizhals.at and blog.geizhals.at are hosted by wordpress.com, so security issues should be reported to them.
- we are not interested in vulnerabilities with a CVSS 3 score lower than 4.0, unless it can be combined with other vulnerabilities to achieve a higher score.
- we may offer to pay bounties in the form of Amazon vouchers (we will let you choose from Amazon.de, Amazon.co.uk and possibly others if we can pay them without tax issues)
- we will publish information about submissions with as much detail as we choose to
- first come, first serve – bounties are paid to first submitter only and only once per type of vulnerability (not for different ways of exploiting the same or for each account compromised etc.)
- damages caused unnecessarily will be subtracted from bounties (we’ll be fair). If too much avoidable damage was caused, we may refuse to pay bounties (please don’t do it, this bug bounty program does not exist in order to invite people to cause damage to us)
- known vulnerabilities we are trying to fix and published by us already, are excluded
- if multiple cases below apply, the highest is paid, except for vulnerable 3rd party code (i.e. Debian packages), where we pay only the bounty for that category (the best matching)
- all submissions must be sent to bugbounty@geizhals.at, readable using MUAs without HTML support and potential vulnerabilities described comprehensively in written form.
- exploit details must not be published elsewhere before we’ve had reasonable time to fix the problem
- we may update the terms / bounties however we wish at any time without prior notice, however for submitted bugs sent before new terms are announced, the old terms will apply
- we must be able to reproduce reported bugs without an unusual/exotic platform/configuration
- we will try to be as fair and objective as possible, however if we cannot afford some bounties or if we made stupid mistakes in the terms published that allow exploitation in an unintended way, we reserve the right to refuse bounties. Please be fair and reasonable too!
Qualifying Vulnerabilities
Any reproducible vulnerability that has a severe effect on the security or privacy of our users is likely to be in scope for the program. Common examples include XSS, CSRF, SSRF, RCE, SQLi, and privilege escalation. When a particular request/URL causes effective DoS with 1 hit per 60 seconds.
| Class of Vulnerability | Bounty (in EUR) | Extra Terms (if any) |
|---|---|---|
| XSS, SSRF, Clickjacking | 200 | |
| CSRF | 200 | If user data can be manipulated through 3rd party websites. |
| SQL Injection | 400 | |
| Capturing a user account | 400 | Brute-forcing, phishing or MITM are not applicable. Using XSS or Clickjacking: the lesser bounty will take precedence. |
| Severe DoS opportunity | 400 | |
| Remote code execution/login | 750 | |
| Remote code execution as root | 1500 | |
| Any of the above when caused by a 3rd party bug with a fix available for 48h or longer | 200 | |
| Any of the above when caused by a 3rd party bug where the fix was available within 48h | 0 | Because we’ll hopefully fix that automatically. |
