Real Value or AI Trash?

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 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

The following are NOT considered security vulnerabilities under this policy:
  1. 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
    Important: Detection improvements are valuable and welcomed as product feedback but are classified as product enhancements rather than security vulnerabilities. Please contact support@cynet.com for detection coverage feedback.
  2. 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
  3. 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
    Findings based solely on:
    • Automated vulnerability scanners
    • Static analysis tools
    • Generic security checklists
    Informational findings such as:
    • Version or banner disclosure
    • Enabled HTTP methods without exploitability
    • Cookie attributes flagged without abuse scenario
    • Rate-limiting or brute-force concerns without demonstrated impact
    Note: Reports must demonstrate a realistic attack scenario affecting confidentiality, integrity, or availability. Scanner output alone is insufficient.
  4. 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

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:
  1. Acknowledgement (24-48 hours)
    • Confirmation of receipt
    • Case/ticket number assignment
    • Primary contact identified
  2. Triage and validation (2-5 business days)
    • Technical analysis and reproduction
    • Severity classification (CVSS scoring)
    • In-scope determination
  3. Regular updates
    • Status updates every 5-7 business days minimum
    • More frequent communication for critical/high severit
    • Transparency on remediation timeline/li>
  4. 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

Search results for: