Cynet Responsible Disclosure Policy
At Cynet, we believe security research makes the entire ecosystem stronger. We actively welcome collaboration with the security research community and value responsible disclosures that help protect our customers and partners.
Our Commitment to You
If you believe you’ve discovered a security vulnerability in Cynet’s systems, products, or services, we want to hear from you.
Report security issues to: responsible-disclosure@cynet.com
Impact-first note:
To help us prioritize effectively, reports should demonstrate a realistic security impact. Informational findings that don’t show clear exploitability or real-world risk may not qualify under this program.
Scope
In Scope
In Scope: Assets
Category | Assets |
Web & Platform | Cynet platform and web applications (*cynet.com) |
Endpoint | Cynet endpoint agent (Windows, Linux, MacOS) |
Infrastructure | Cynet-managed internet-facing systems |
APIs | Cynet APIs and web services |
In Scope: Product Vulnerabilities
Qualifying vulnerability types:
Category | Vulnerability Class | Examples |
Web / APIs / Infrastructure | Injection | Command Injection, SSTI, SQL Injection, XXE Injection, Insecure Deserialization. |
Web / APIs | XSS | Stored XSS or Reflected XSS with demonstrated impact. |
Web / APIs / Infrastructure / Endpoint | Access Control | Authentication bypass, SSRF, IDOR, or any improper access control vulnerability that enables either lateral movement (allowing one user to authenticate as another user) or privilege escalation (elevating a standard user to administrative privileges). Note: Lateral movement from administrative accounts to standard user accounts, or between administrative accounts, does not constitute a security boundary violation. |
Web / APIs / Infrastructure / Endpoint | Misconfiguration | Sensitive data exposure, and misconfiguration with demonstrated impact. |
Infrastructure / Endpoint | Memory Corruption | Memory corruption vulnerabilities including buffer overflows, use-after-free (UAF), double free, or similar memory-based flaws. These vulnerabilities must be exploitable from a standard privilege level (not requiring kernel or SYSTEM-level execution context) and must demonstrate concrete security impact |
Out of Scope
- The following are NOT considered security vulnerabilities under this policy:
- Agent detection failures or behavioral analysis misses (EDR/XDR detection logic)
- False negatives where malicious behavior is not detected by existing methods
- Evasion techniques that do not exploit an in-scope product vulnerability
- Threat intelligence gaps or detection coverage issues
- Denial of service (DoS/DDoS) testing or attacks
- Social engineering (phishing, pretexting, physical security)
- Brute force or credential stuffing attacks
- Physical attacks requiring physical access
- Presence or contents of robots.txt
- Missing or informational HTTP security headers (e.g., CSP, HSTS, X-Frame-Options) without a demonstrated exploit
- Clickjacking on non-sensitive or non-authenticated pages
- Open redirects without clear security impact (e.g., phishing, token leakage)
- Self-XSS or issues requiring users to manually execute JavaScript
- Browser warnings or “best practice” recommendations
- Automated vulnerability scanners
- Static analysis tools
- Generic security checklists
- Version or banner disclosure
- Enabled HTTP methods without exploitability
- Cookie attributes flagged without abuse scenario
- Rate-limiting or brute-force concerns without demonstrated impact
- Theoretical vulnerabilities without proof of exploitability
- Vulnerabilities in unsupported or end-of-life product versions
- Third-party dependencies without proof of Cynet-specific impact
- Issues requiring extensive or unlikely user interaction
Security severity classification
Cynet evaluates reports using industry-standard CVSS v3.1/v4.0 scoring with the following severity framework:
Critical
- Remote code execution on production systems
- Authentication bypass leading to complete system compromise
- Mass data breach exposing customer data
- Complete compromise of confidentiality, integrity, or availability
Response timeline: 24-48 hour triage, resolution within 30 days
High
- Privilege escalation to administrator
- SQL/command injection with data access
- Significant unauthorized data access
- Bypass of critical security controls
Response timeline: 2-3 business days triage, resolution within 60 days
Medium
- Cross-site scripting (XSS) with security impact
- CSRF affecting sensitive operations
- Limited sensitive data disclosure
- Security misconfiguration requiring additional steps
Response timeline: 5 business days triage, resolution within 90 days
Low
- Minor information leakage
- Issues requiring significant user interaction
- Security improvements without direct exploit
Response timeline: 7 business days triage, resolution timeline varies
Duplicate Reports
If multiple researchers report the same vulnerability, recognition is awarded to the first valid report received, based on the submission timestamp. Reports demonstrating materially different exploitation techniques or impact may be considered independently at Cynet’s discretion.
What makes a quality report
High-quality vulnerability reports include:
- Clear description of the vulnerability and its potential impact
- Step-by-step reproduction instruction
- Proof of concept (code, screenshots, or video)
- Affected versions/components
- Your severity assessment
- Suggested remediation (optional)
Please do NOT:
- Include actual customer data or PII
- Share credentials or access tokens
- Use exploits that cause data destruction or service degradation
- Stop immediately if you encounter customer data and notify us
Researcher recognition
Cynet may recognize researchers based on the severity of validated findings. Recognition may include:
- Critical/High: Public acknowledgement in Cynet security advisories/disclosure page
- Medium/Low: Private acknowledgement
Researcher names and affiliations will only be published with explicit consent.
Bug bounty program status (important)
Cynet does not currently operate a paid bug bounty program.
We recognize and acknowledge responsible security researchers through public recognition, coordinated disclosure, and case-by-case non-monetary recognition. We continuously evaluate our security research programs and may introduce a paid bounty program in the future. Please check this page for updates.
Communication & response timelines
Submission process:
Email: responsible-disclosure@cynet.com
Subject: “security vulnerability report – [brief description]”
PGP: available upon request for sensitive reports
Response process:
- Acknowledgement (24-48 hours)
- Confirmation of receipt
- Case/ticket number assignment
- Primary contact identified
- Triage and validation (2-5 business days)
- Technical analysis and reproduction
- Severity classification (CVSS scoring)
- In-scope determination
- Regular updates
- Status updates every 5-7 business days minimum
- More frequent communication for critical/high severity
- Transparency on remediation timeline
- Resolution
- Notification when fixed and deployed
- Coordinated disclosure discussion
- Recognition coordination
Coordinated disclosure
We believe in coordinated disclosure that protects customers while recognizing researchers.
Our request:
- Allow 90 days from validated report for remediation before public disclosure
- Coordinate disclosure timing with Cynet
- Notify us 7 days before any planned disclosure
Our commitment:
- Work in good faith to remediate promptly
- Provide regular updates on progress
- Coordinate public disclosure when appropriate
- Credit researchers with permission
If additional time is needed beyond 90 days, we will:
- Explain technical or business reasons
- Provide revised timeline
- Work collaboratively on disclosure plans
Safe harbor
Cynet will not pursue legal action against security researchers who:
- Act in good faith accordance with this policy
- Avoid privacy violations, data destruction, or service degradation
- Do not access, modify, or delete data beyond proof of concept
- Report findings confidentially to responsible-disclosure@cynet.com
- Provide reasonable time for remediation
- Do not exploit vulnerabilities for personal gain or to harm Cynet/customers
- Stop testing immediately upon vulnerability discovery
We consider research conducted under this policy to be authorized conduct. This safe harbor applies only to good faith security research on in-scope systems.
This safe harbor does NOT apply to:
- Intentional harm to systems, customers, or data
- Testing on out-of-scope systems
- Violations of applicable laws
- Social engineering of Cynet employees
- Physical attacks or unauthorized physical access
Rules of engagement
Do:
- Respect customer privacy and data
- Stop immediately when vulnerability is discovered
- Keep findings confidential until coordinated disclosure
- Report vulnerabilities promptly with sufficient detail
Do not:
- Access, modify, or delete customer data
- Degrade service availability or performance
- Exploit beyond proof of concept
- Pivot to other systems or networks
- Conduct social engineering on Cynet employees
- Perform physical security testing
- Test third-party systems
- Conduct DoS/DDoS testing
- Use automated scanning without authorization
Legal
This policy does not permit:
- Violating laws or regulations
- Access beyond necessary security research
- Harm to Cynet, customers, or third parties
Cynet reserves the right to:
- Update this policy
- Determine vulnerability validity and severity
- Decide recognition and disclosure timing
- Decline engagement with researchers who violate this policy