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
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
| 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 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 | — | — |
Note: Severity is determined based on realistic impact, exploitability, and affected scope, not solely on theoretical maximum impact.
Out of Scope
- Detection & threat intelligence:
- 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
- Attack Scenarios:
- 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
- Scanner & Low-Impact Findings (Unless real impact demonstrated)
Common findings that do NOT qualify:- Presence or contents of robots.txt
- Missing or informational HTTP security headers (e.g., CSP, HSTS, X-Frame-Options)
- 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
- Technical Exclusions:
- 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
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
High
- Privilege escalation to administrator
- SQL/command injection with data access
- Significant unauthorized data access
- Bypass of critical security controls
Medium
- Cross-site scripting (XSS) with security impact
- CSRF affecting sensitive operations
- Limited sensitive data disclosure
- Security misconfiguration requiring additional steps
Low
- Minor information leakage
- Issues requiring significant user interaction
- Security improvements without direct exploit
Duplicate Reports
What makes a quality report
- 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)
- 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
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 severit
- Transparency on remediation timeline/li>
- Resolution
- Notification when fixed and deployed
- Coordinated disclosure discussion
- Recognition coordination
Coordinated disclosure
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
- Work in good faith to remediate promptly
- Provide regular updates on progress
- Coordinate public disclosure when appropriate
- Credit researchers with permission
- Explain technical or business reasons
- Provide revised timeline
- Work collaboratively on disclosure plans
Safe harbor
- 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
- 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
- Respect customer privacy and data
- Stop immediately when vulnerability is discovered
- Keep findings confidential until coordinated disclosure
- Report vulnerabilities promptly with sufficient detail
- 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
- Violating laws or regulations
- Access beyond necessary security research
- Harm to Cynet, customers, or third parties
- Update this policy
- Determine vulnerability validity and severity
- Decide recognition and disclosure timing
- Decline engagement with researchers who violate this policy