CWILL Main Logo
menu icon

Security Disclosure Program

Updated: Jun 24, 2026

CWILL (hereinafter "we," "us," or "the Company") is committed to protecting the security of our users, their data, and our systems. We value the work of the security research community and welcome good-faith reports of potential vulnerabilities in our products and services.
Please read this policy in full before participating. By submitting a report or conducting testing against our assets, you agree to the terms below. This program is intended to be a two-way relationship, not a one-sided set of obligations.
If you believe you have found a security vulnerability, bug, or other security concern affecting any CWILL product or service, please submit a report through:

1. Eligibility

This program is open to external security researchers, subject to the following:
  • Current employees and contractors of CWILL and its affiliates are not eligible.
  • Former employees and contractors are not eligible for 12 months after their engagement ends.
  • Immediate family members of current employees or contractors are not eligible.
  • You must not be a resident of, or located in, any country or region subject to comprehensive sanctions or trade restrictions that would prohibit us from making a payment to you (see Section 6).
  • You must be at least the age of majority in your jurisdiction, or have verifiable consent from a parent or legal guardian.

2. In-Scope Assets

Good-faith testing is authorized against the following production assets:
Product Domain(s)
CWILL*.cwill.com
TrackingMore*.trackingmore.com
CWILL Post-Purchase*.parcelpanel.com, *.parcelwill.com
CWILL Product Reviews*.trustoo.io
CWILL Loyalty & Referrals*.loloyal.com
CWILL Pop-Up & Email Marketing*.ecomsend.com
CWILL SEO & Speed*.seoant.com, *.seowill.com
CWILL AI Chat*.chatwill.ai
Newly discovered CWILL assets. If you discover a security issue on a CWILL-owned asset that is not listed above, we still want to hear about it. Report it to [email protected].

3. Out of Scope

Out-of-scope assets. Any asset not listed in Section 2 (including third-party services, vendor platforms, and infrastructure we do not own or operate) is out of scope. Do not test it.
Out-of-scope activities. The following are never authorized:
  • Denial-of-service (DoS/DDoS) or any test that degrades availability or performance.
  • Social engineering, phishing, or physical attacks against CWILL, its staff, or its users.
  • Automated scanning that generates high-volume traffic (see Section 4 rate limits).
  • Accessing, modifying, deleting, or exfiltrating data belonging to other users.
Out-of-scope / typically non-qualifying findings. These are generally accepted only with a demonstrated, realistic security impact:
  • Missing security headers (CSP, HSTS, X-Frame-Options, etc.) with no demonstrated exploit.
  • Missing cookie flags on non-sensitive cookies.
  • Self-XSS that cannot be used against another user.
  • Clickjacking on pages with no sensitive state-changing action.
  • CSRF on non-sensitive or unauthenticated actions, or with no security impact.
  • Rate-limiting / brute-force concerns without a working proof of concept.
  • Login/logout/email-confirmation CSRF.
  • Reports based solely on automated scanner output with no manual validation.
  • Vulnerabilities affecting only unsupported or end-of-life browsers/software.
  • Publicly disclosed 0-days in third-party software within 30 days of disclosure.
  • Theoretical vulnerabilities without evidence of exploitability.
  • Best-practice or "informational" findings with no security impact.

4. Rules of Engagement

To protect system stability and user data, you must:
  • Use self-registered test accounts wherever possible. If you need dedicated test accounts, request them at [email protected].
  • Respect rate limits. Keep automated testing gentle — as a guideline, no more than 5 requests/second per target, and clearly identify your traffic with a custom header (e.g., X-Security: <your-handle>) or a dedicated user-agent so we can distinguish research from attacks.
  • Never access, download, store, or exfiltrate real user data. Interact only with accounts and data that belong to you.
  • Stay within the minimum necessary. Do only what is needed to demonstrate a vulnerability, and stop as soon as impact is confirmed.
  • Do not delete, modify, or tamper with data; do not disrupt availability; do not use social engineering or phishing.
  • Do not publicly disclose a vulnerability before it is resolved and we have agreed on disclosure (see Section 9).
  • If something goes wrong — you unexpectedly access sensitive data, cause an error, or disrupt a service — immediately stop, delete any data collected locally, take reasonable steps to restore normal operation, and report the incident to us.
If you obtain a foothold (e.g., a webshell or RCE), do not proceed to download source code, browse databases, read configuration files, collect logs, or pull user information. Stop at proof of access and coordinate with us for any further validation.

5. Proof of Concept — How to Demonstrate Impact Safely

We need enough evidence to validate a finding, without you touching real user data. Please demonstrate impact using non-invasive proof:
  • For SQL injection: demonstrate control of the query using non-sensitive signals — e.g., current_user(), database version, @@hostname, a COUNT(*), or the names of tables/columns. Do not extract, dump, or exfiltrate actual data rows. A single benign proof value (not user data) is sufficient.
  • For access-control / IDOR issues: show the change in access (e.g., that a different object ID becomes reachable) using your own test objects, or redact/anonymize any incidental data in your report.
  • For information disclosure: provide masked or truncated evidence — enough to prove the exposure, not the exposed data itself.
  • In general: structural information, screenshots with sensitive fields redacted, and reproducible steps are always preferred over raw data.
If you believe validating a finding genuinely requires going further, ask us first and we will authorize a controlled next step.

6. Rewards

Rewards under this program are discretionary and are offered as a way to recognize high-quality, high-impact reports. Submitting a valid vulnerability does not by itself guarantee a monetary reward. We consider factors such as severity, impact, report quality, and novelty when deciding whether — and how much — to reward.
Where we do issue a reward, we aim to fall within the following guideline ranges. These are indicative only, are subject to available budget, and may be adjusted or paused at any time; the version of this policy in effect at the time of your report applies.
Severity Critical High Medium Low
Guideline Reward (USD) $300 – $2000 $100 – $300 $50 – $100 $10 – $50
Even where a monetary reward is not offered, we will always acknowledge your contribution and, with your consent, credit you publicly (see Section 10).
Reward evaluation. Within each range, the final amount is based on:
  • Realistic impact scope (single user / multiple users / entire platform).
  • Exploitation complexity and preconditions.
  • Whether sensitive data or core business functions are affected.
  • Potential damage if exploited.
  • Quality, clarity, and reproducibility of the report.
Payment, taxes, and sanctions.
  • Rewards are paid in USD, exclusive of any taxes; you are responsible for taxes applicable in your jurisdiction.
  • We may require identity verification (KYC) and tax documentation before payment.
  • We cannot make payments to individuals or entities in countries or regions subject to applicable sanctions or export-control restrictions. Determinations of eligibility on this basis are final.

7. Severity Classification

Severity is our reference framework, informed by CVSS v3.1 and adjusted for real-world impact on our environment. We will explain our reasoning when a rating differs from your submission, and you may request one review.
Critical
  • Vulnerabilities granting system-level access — e.g., command injection, remote code execution, webshell upload.
  • Severe sensitive-data exposure at scale (large-scale or multi-dimensional).
  • Massive leakage of core sensitive data — e.g., SQL injection against core databases, large-scale unauthorized access to sensitive user interfaces.
  • Remote arbitrary code execution or file read/write with no or minimal user interaction.
  • Direct access to critical infrastructure (clusters, bastion hosts).
High
  • Exploitable SQL injection leading to unauthorized access to user data.
  • High-impact logic flaws — e.g., arbitrary password reset, account takeover.
  • Client-side vulnerabilities enabling remote command/code execution.
  • Authentication bypass reaching admin systems or sensitive data.
  • Local arbitrary code execution (excluding DLL hijacking from OS-level defects).
Medium
  • General information disclosure with limited impact — e.g., limited unauthorized access, source-code leaks, SSRF without data return.
  • Vulnerabilities requiring user interaction or preconditions — e.g., stored XSS, JSON hijacking, CSRF affecting payment or account settings.
  • General logic and authorization flaws.
  • Design weaknesses — e.g., brute-forceable login (PoC required), weak-password policies.
Low
  • Minor information disclosure — e.g., unauthenticated access to a low-value backend, PHPInfo exposure, minor log or config leaks.
  • Vulnerabilities exploitable only under narrow conditions — e.g., reflected or DOM-based XSS.
  • Limited-impact issues — e.g., SMS bombing, open redirect, credential-stuffing-exposed interfaces.

8. Assessment Principles

  • Duplicates: the first valid, reproducible report of an issue is eligible; later reports of the same issue are duplicates. This applies to weak-password and similar bulk findings.
  • Same source: multiple issues stemming from a single root cause (same domain/IP/component) are treated as one report, rewarded at the highest applicable severity.
  • Chained vulnerabilities: related issues combined into one attack chain are treated as a single report at the highest resulting severity.
  • Deprecated systems: findings on deprecated systems may receive a lower rating based on actual impact.
  • Complexity: findings requiring highly complex or improbable exploitation may be adjusted.
Highly sensitive personal information is defined as data containing at least three of: name / ID number; bank-card information; phone / email; password; address. Findings involving less than this threshold are rated according to actual sensitivity and impact.

9. Coordinated Disclosure

  • Please keep findings confidential until they are resolved.
  • After a fix is deployed, we are happy to coordinate public disclosure. Our default coordinated-disclosure window is 90 days from your report, or upon fix deployment, whichever comes first. If we need more time, we will tell you why and agree on an extension with you.
  • We will not restrict you from disclosing the existence of your research relationship with us, and we welcome you writing up your work once the issue is fixed and we have coordinated timing.

10. Recognition

With your consent, we will acknowledge your contribution in our public Hall of Fame. You may also choose to remain anonymous. Recognition is offered in addition to — not instead of — any monetary reward.