Skip to main content
Quorum

Vulnerability disclosure policy

Last updated: 11 October 2026

We welcome reports of security vulnerabilities in Quorum from researchers and customers. This policy explains what you may test, how to report what you find, what you can expect from us in return, and the assurance we give to anyone who follows it in good faith.

Quorum is operated by Creative Coders sp. z o.o., ul. Płk. Zoltána Baló 6 lok. 5, 02-793 Warszawa, Poland (“we”, “us”). The registry details are on the Company information page. The controls already in place are described on the Security & sub-processors page.

1. Scope

The following systems operated by us are in scope:

  • the Quorum web application and its APIs at the production origin, quorumwork.com;
  • the endpoints at that origin that receive requests from Slack, Microsoft Teams and Google Chat on behalf of the Quorum apps for those platforms; and
  • the Quorum browser extension and the Quorum add-ins for Outlook and Google Calendar, in the versions we publish.

The following are out of scope and must not be tested:

  • social engineering of our staff, customers or service providers, including phishing;
  • physical attacks on offices, equipment or data centres;
  • denial-of-service, load or volumetric testing of any kind;
  • services operated by third parties, including Render, Resend, Slack, Google, Microsoft, Merge, Kombo and the AI model providers listed as sub-processors, even where Quorum uses them. Report issues in those services to their operators under their own programmes.

The following findings are not eligible on their own, although we will consider them if you can demonstrate a concrete security impact:

  • spam, or missing or misconfigured SPF, DKIM or DMARC records;
  • missing HTTP security headers or cookie flags without a demonstrated exploit;
  • self-XSS and issues that require the victim to paste code into their own browser;
  • output from automated scanners without a working proof of concept;
  • clickjacking on pages without a state-changing action;
  • software version disclosure, banner grabbing and verbose error pages without sensitive data.

2. How to report

Send your report through the contact form, choosing the topic “Security review or DPA” and starting the message with “Vulnerability report”, or by email to support@quorumwork.com. Our machine-readable contact details are published at /.well-known/security.txt. If your report contains details you would rather not send through the form, say so and we will agree a suitable channel with you. Please include:

  • the affected component, URL or endpoint, and the type of vulnerability;
  • step-by-step instructions to reproduce it, with a proof of concept where possible;
  • the impact you believe an attacker could achieve;
  • the date and time of your testing and the account or workspace you used; and
  • how to reach you, and whether you would like to be acknowledged by name.

Do not include personal data belonging to anyone else in your report. Describe what you were able to access instead.

3. Rules of engagement

When testing, you must:

  • test only against an account and workspace that you created or own, or for which you hold the owner’s written permission;
  • not access, modify, delete or retain data belonging to other people, other workspaces or other customers;
  • stop testing and report to us immediately if you encounter personal data or any other data that is not yours, and not copy, store or share it;
  • use only the minimum access and data necessary to demonstrate the vulnerability, and not exfiltrate data beyond that minimum;
  • not establish persistence, install backdoors, or pivot from a vulnerability to other systems;
  • not degrade the service for other users or send unsolicited messages to them; and
  • keep the details of the vulnerability confidential until it has been fixed or the disclosure period in section 6 has passed, and give us a reasonable time to respond before any disclosure.

When your testing is complete, or when we ask, delete any data you obtained in the course of it.

4. Safe harbour

Security research carried out in good faith and in accordance with this policy is authorised by Creative Coders sp. z o.o.. For such research:

  • we will not pursue civil legal action against you, and we will not report you to law enforcement or initiate a complaint with any authority;
  • to the extent that anti-circumvention, computer-misuse or similar laws apply to your activities, we consider them authorised access and will not bring a claim against you under those laws; and
  • if a third party brings legal action against you in connection with research that complied with this policy, we will make it known that your activities were authorised by us.

This authorisation covers only systems in scope and only activity that complies with this policy. It cannot bind third parties, including our customers and service providers, nor authorise testing of their systems. If you are unsure whether an action is consistent with this policy, ask us through the contact channel above before proceeding.

5. What you can expect from us

  • an acknowledgement of your report within 3 business days;
  • an initial assessment, including whether we can reproduce the issue and its severity, within 10 business days;
  • status updates at least every 30 days until the report is resolved; and
  • remediation of critical vulnerabilities as a priority, with the aim of fixing them within 30 days and other confirmed vulnerabilities within 90 days of the initial assessment.

These are targets, not contractual commitments, and a complex fix may take longer; if so, we will tell you why. Where a vulnerability affected personal data, we will also assess it under our own data-protection obligations, as described in the Privacy notice.

6. Coordinated disclosure

We ask that you do not disclose a vulnerability publicly until we have released a fix, or until 90 days after your report if no fix has been released, unless we agree a different timeline with you. We will coordinate the timing and content of any publication with you and, with your consent, credit you for the discovery.

7. No bug bounty

We do not currently operate a bug bounty programme and do not offer payment for reports. On request, we are glad to thank you publicly and acknowledge your contribution once the issue has been resolved.

8. Changes to this policy

We may update this policy from time to time, and the date at the top of this page shows the latest revision. Research carried out while an earlier version was published is assessed under that version.

These documents describe how Quorum actually behaves — the data it reads, where it sends it, and how long it keeps it — and are updated whenever that behavior changes.