Bug Bounty Program

Version 1.3 of 21 Oct 2026

Important Notice – Bug Bounty Testing Schedule

Updated: 5 November 2026

Due to the unexpectedly high level of interest in our Bug Bounty Program, we are introducing scheduled testing start dates to ensure effective coordination and timely review of vulnerability reports.

  • Existing registrations: Researchers who registered before 21 October 2026 may begin testing on or after 9 November 2026, provided their participation has been confirmed.
  • New registrations: Researchers who register on or after 21 October 2026 and before 25 October 2026 may begin testing no earlier than 16 November 2026, subject to registration approval.
  • Registrations from 25 October 2026: Researchers registering on 25 October 2026 or later must not begin testing before 1 December 2026, subject to registration approval.
  • Research already underway: Security researchers who have already registered, or who have already started and found a bug, may submit that finding today, 21 October 2026. The report will be accepted.

Registrations remain open, and we welcome new security researchers to participate.

Important: Security testing must not begin before the assigned start date and must comply with the program’s scope and rules. Researchers who have already received explicit authorization to conduct testing may continue under their existing authorization. Researchers who have already registered, or who have already started and found a bug, may submit that finding today, 21 October 2026, and it will be accepted.

We appreciate the security community’s strong interest, understanding, and continued support in helping us improve the security of our services.

Important Notice – Features, non-vulnerabilities, and known issues

Reports of a feature, or of other behaviour that is not a security vulnerability, and issues we know about and are not fixing, are published on their own page. That list is separate from the Hall of Fame.

Features, non-vulnerabilities, and known issues

Changelog

Security is core to everything we do at wservices. We invite security researchers to responsibly discover and report vulnerabilities in our infrastructure and web interface (wcenter). Verified, previously-unknown reports are rewarded.

Scope

In scope

  • APIs, DNS infrastructure, mail servers and web servers operated by wservices
  • Services operated and maintained by wservices, including webmail.wservices.ch, gitlab.wservices.ch and agents.wservices.ch
  • The wcenter control panel
  • djangoeurope.com hosting infrastructure operated by wservices

Out of scope

  • aiswarmhive.com, which is in alpha staging
  • Customer-owned or customer-managed services, including certain subdomains under *.wservices.ch and *.djangoeurope.com. Websites under *.sites.djangoeurope.com belong to customers (report those to the site owner)
  • The entire djangoviet.com domain, including all subdomains
  • Services and sub-processors that wservices does not operate
  • Vulnerabilities in third-party software or vendor products, unless an available security patch has not been applied within 3 days (Critical), 7 days (High) or 30 days (Medium and lower) after its official release. This applies only to services that are otherwise in scope, and does not authorize testing of customer-owned systems or excluded domains
  • Social engineering and phishing of our staff or customers
  • Physical attacks against data centers or offices
  • Denial-of-service (DoS/DDoS) and volumetric attacks
  • Automated scanner output without a working proof-of-concept

Informational findings we do not accept

Findings without a demonstrated security impact are out of scope and will not be rewarded. Please do not report the following:

  • Missing, weak or unset HTTP security headers (Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection and similar)
  • Cookie attribute findings (Secure, HttpOnly, SameSite) without a demonstrated exploit
  • SSL/TLS configuration recommendations (cipher suites, protocol versions, certificate pinning, CAA records, HSTS preload) without a practical exploit
  • SPF, DKIM or DMARC issues, email spoofing and other mail-hardening recommendations
  • Clickjacking, logout CSRF, self-XSS and issues that require unlikely user interaction with no demonstrated impact
  • Open redirects, mixed content, CORS misconfigurations and host-header issues without proven data theft or account takeover
  • Missing rate limiting, credential stuffing or username/email enumeration without a working bypass of existing controls
  • Information disclosure with no security impact (software versions, server banners, public directory listings, verbose errors that do not leak secrets)
  • Best-practice or hardening recommendations, theoretical issues, and findings that only affect outdated browsers

The Process

  1. 1

    Registration

    Register your intent by e-mailing security@wservices.ch with your name or handle and a short description of your research focus. You receive a confirmation and a reporting reference. Confirmation is not permission to test before your assigned start date.

  2. 2

    Testing

    Do not begin before the start date in the testing schedule above. Researchers who already have explicit authorization may continue. Researchers who have already registered, or who have already started and found a bug, may submit that finding today, 21 October 2026, and it will be accepted. Test only in-scope targets. If you are unsure whether a domain, subdomain or service is in scope, contact security@wservices.ch and wait for confirmation before testing. Never access, modify or destroy data that is not yours. Use a dedicated test account you control, tell us that address in the report, and confirm when you are done so we can clean it up. No DoS, no spam, no automated mass-scanning.

  3. 3

    Delivery (Report Submission)

    Submit a detailed report to security@wservices.ch including the affected target/URL, vulnerability type, step-by-step reproduction, a working proof-of-concept, an impact assessment and any suggested remediation. Include the exact request and the observed server response at the boundary you claim (for example the error when a used or expired token is submitted). Waiting without that response is not proof of missing expiry. Encrypt sensitive reports with our PGP key on request.

  4. 4

    Triage & Validation

    We acknowledge your report within 3 business days. We aim to give a triage verdict (accepted or not, and severity) within 10 business days. Submitted CVSS scores are re-rated from the attacker’s realistic starting position, not the reported vector. We may contact you for clarification.

  5. 5

    Resolution

    We fix confirmed issues and keep you updated on the progress. Please allow reasonable time for remediation before any public disclosure (coordinated disclosure, 90 days recommended).

  6. 6

    Reward

    Once the issue is fixed and verified, we aim to decide credit and the applicable reward within 10 business days (see below).

Rewards

We rate findings on the CVSS 3.1 base score. Submitted scores are re-rated during triage from the attacker’s realistic starting position, not the reported vector. Rewards are granted at wservices’ discretion based on that rating, impact and report quality. Duplicates are awarded to the first reporter only.

Severity / FindingReward
Low severity

Limited impact, no account takeover. Examples: XSS on a public marketing page, CSRF on a low-impact setting, open redirect without stealing a session, disclosure of non-sensitive configuration.

One year of a free djangoeurope X10 plan.
Medium severity

Access to a single account or limited customer data. Examples: session-stealing XSS in wcenter, IDOR on another customer’s tickets, CSRF that changes email forwarding or a password, SSRF to an internal HTTP service without credentials.

One year of a free djangoeurope X12 plan.
High severity

Cross-customer data access, admin-level control, or local root from an unprivileged SSH account after the 3-day CVE window. Examples: SQL injection on customer databases, authentication bypass or account takeover of arbitrary users, unauthorized wcenter admin, access to backups or mailboxes of other customers, a working local root exploit from an unprivileged SSH user when the CVE has been unpatched for more than 3 days. Does not count: a customer who has set their own home directory (/home/username) to chmod 755 (or otherwise world-readable). That is the customer’s choice and we cannot control it.

€250, plus one year of a free djangoeurope X14 plan.
Critical — Remote Code Execution as root (root RCE)

Remote code execution as root on in-scope production systems, without needing an existing SSH login. Examples: unauthenticated remote root RCE on the hosting fleet, wcenter host or mail/DNS servers; an exploit chain that yields a remote root shell. Local root from an unprivileged SSH account is High, not Critical.

€500, plus one year of a free djangoeurope X16 plan.

Additionally, every valid, previously-unknown finding in the Low, Medium, High or Critical category receives public recognition on our Security Hall of Fame.

Reports that describe a feature or other behaviour that is not a security vulnerability, and issues we know about but are not fixing, are listed separately. Other reports.

Rules & Safe Harbor

Contact

Please send all reports, registration requests and scope questions to our security team.

security@wservices.ch