Responsible Disclosure Policy

Last updated: 2026-08-03

The security of our customers' data — and of their employees' data — is a priority at Trilha CuboPlus. We value the work of the security research community and believe responsible collaboration helps us protect the platform better. This page describes how to report a vulnerability and what you can expect from us.

This policy is not a bounty program: we do not pay for reports. See section 6.

1. Safe harbor

Good-faith research is authorized activity. If you conduct security research in accordance with this policy, we will consider your conduct authorized, we will not recommend or initiate legal or administrative action against you, and we will not ask third parties to do so on account of your research.

We will work with you to understand and resolve the issue quickly. Should a third party initiate legal action against you for activities conducted in accordance with this policy, we will make this authorization public.

This safe harbor applies only while you act in good faith and comply with the guidelines in this policy. It does not extend to activities that break the law, harm third parties, or compromise data that does not belong to your own test accounts — nor to activities outside the limits of sections 2.1 and 3, however well-intentioned.

2. Scope

This policy covers exclusively the Trilha CuboPlus services reachable at the following addresses:

• The public website: trilha.cubo.plus;
• The administration, account and partner portals: admin-trilha, conta-trilha, partner-trilha and auth-trilha, under the cubo.plus domain;
• Customer LMS environments and their APIs, when you already have legitimate access to one of them — subject to the restrictions in section 2.1.

2.1 Customer environments — what is allowed

Each customer company has its own environment, holding real data belonging to that company and its employees.

We do not publish the addresses of those environments, and you must not look for them. Discovering, guessing or enumerating customer addresses is not research covered by this policy — it is precisely one of the risks this policy exists to prevent, because the mere list of who uses the platform is our customers' information, not ours.

If you already have legitimate access to one of those environments — for example, because you work at a customer company and have an account there — flaws you find there are covered, including (and especially) isolation flaws between distinct customers. What you may do is limited:

• Allowed: manual analysis, browsing, inspection of requests and responses, and a minimal, non-destructive proof of concept, always from your own account.
• Never allowed: automated traffic at volume (scanning, fuzzing, brute force, mass enumeration, load testing), writing to or altering data that is not yours, creating or modifying users, and any action that changes the environment's configuration.
• No access and want to test? Write to the contact in section 7 and, where appropriate, we will provide a test environment or account. A flaw demonstrated in a test environment counts exactly the same as one demonstrated in production — and puts nobody's data at risk.
• Dedicated test environment: once we make a public test environment available, it becomes the default target of this policy, and customer environments are restricted to the manual analysis described above. We will announce it on this page.

The reason, stated plainly: customer environments share a server. A load spike on one can take down its neighbours — companies that never asked to take part in any test. This is not paperwork: it is the operational risk that worries us most.

3. Out of scope

• Other Cubotimize products, even when hosted on a similar or shared domain — including the root address cubo.plus, which serves a different product on separate infrastructure. They are not covered by this policy nor by the safe harbor above;
• Discovering, guessing or enumerating customer environment addresses (see section 2.1);
• Third-party services we use (for example cloud providers, CDN, transactional email and payment gateways) — report those issues directly to the responsible vendor;
• Social engineering, phishing, or any approach to employees, customers or end users;
• Physical attacks against facilities or equipment;
• Volumetric or denial-of-service attacks (DoS/DDoS) and load/stress testing;
• Automated traffic at volume — scanning, fuzzing, brute force, credential stuffing and mass enumeration — against any address covered by this policy. Need such a test to demonstrate the flaw? Arrange it beforehand via the contact in section 7;
• Persisting access (backdoor, scheduled task, hidden user), pivoting from one environment to another, and extracting data at volume. A proof of concept is one record, one screenshot, and stop;
• Volume against email-triggering flows (sign-up, password reset, invitation) — our provider quota is shared with real customers' email;
• Any test that degrades the service, corrupts data, or accesses information belonging to other customers or users;
• Automated scanner output without demonstrated security impact, and "best practice" findings with no exploitable risk.

4. What to report

We are primarily interested in technical vulnerabilities with real security impact, such as:

• Authentication or authorization flaws, including improper access across distinct customers/tenants;
• Exposure of sensitive or personal data;
• Injections (SQL, command, template), remote code execution, SSRF, impactful XSS, among others;
• Flaws allowing privilege escalation or bypass of security controls.

To speed up triage, please include: a clear description of the flaw and its impact, steps to reproduce, a minimal proof of concept (where applicable), and the affected addresses/parameters.

5. Research guidelines

• Act in good faith and avoid any activity that violates privacy, degrades other users' experience, disrupts services, or destroys data;
• Use only test accounts that belong to you; do not access, alter or retain data belonging to other users or customers;
• Identify yourself while researching. Email the contact in section 7 before you start, giving the time window and your source addresses, and include an identifiable header in your requests (for example `X-Security-Research: <your email>`). This is what lets us tell research from an attack — and talk to you instead of blocking blindly;
• Noticed impact? Stop. If you see slowness, widespread errors, or any sign that the service has degraded, stop immediately and let us know through the same channel, even if you are not sure you caused it. One warning too many costs nothing; one too few costs a customer's day;
• Limit yourself to the minimum necessary to demonstrate the flaw — do not exploit beyond what is required as proof of concept;
• If you encounter personal data or credentials during research, stop immediately and notify us; do not copy, store or disclose them;
• Give us a reasonable opportunity to fix the issue before disclosing it publicly (coordinated disclosure);
• Comply with applicable law, including the Brazilian General Data Protection Law (LGPD).

6. What to expect from us

• We do not offer a financial reward. This policy is not a bug bounty program: there is no payment, prize, credit or gift for a report — neither for severity nor for novelty. What we offer is the safe harbor in section 1, a response to your report and, if you wish, public recognition of your contribution;
• We will acknowledge receipt of your report;
• We will assess the issue, keep you informed of progress, and may request further details;
• We will work to fix legitimate vulnerabilities with priority proportional to their severity and impact;
• If you wish, we will publicly credit your contribution once the fix has been applied.

7. Contact

Send your report to [email protected]. We accept reports in Portuguese or English. See also our security.txt (RFC 9116) at trilha.cubo.plus/.well-known/security.txt.

Thank you in advance for helping keep Trilha CuboPlus safer.