Last updated: 2026-08-16. Governing law: Israel.

Coordinated Vulnerability Disclosure Policy

EyalSec sells security tooling. It would be absurd to make it hard to report a security problem in it, so this page sets out how to do that, what we commit to in return, and the safe harbour that protects you for good-faith research.

Published by Eyal Gabay, trading as "EyalSec", sole proprietor (osek murshe) no. 211868450, Israel.

Report to: security@eyalsec.com

This policy is referenced by the Terms of Service (/legal/terms, Section 9(d)), the Acceptable Use Policy (/legal/aup, Sections 5 and 8), and the security page (/legal/security).

---

1. Scope

In scope:

• The EyalSec web application, dashboard and public site (eyalsec.com and its subdomains).
• The agent ingestion and public APIs.
• The EyalSec agents: es-python, es-chromium, es-c, es-cpp, es-rust, es-node, es-solidity, es-bash and es-php, as published by us.
• The installation and delivery mechanism for those agents.

Out of scope:

• Third-party services we use, such as our cloud provider. Report those to the provider.
• Vulnerabilities in third-party open-source components we redistribute unmodified, where the issue is already public. Tell us anyway if we are shipping an affected version, so we can update it; report the underlying flaw upstream.
• Findings that require an already-compromised machine, physical access, or a self-inflicted misconfiguration by the reporter.
• Social engineering of EyalSec, its customers or its suppliers; physical attacks; and denial-of-service or volumetric testing (see Section 3).
• Reports produced solely by an automated scanner with no demonstrated impact, missing security headers with no exploit path, and best-practice observations without a concrete attack.

A note on es-chromium. es-chromium is a security monitoring and testing instrument, not a hardened consumer browser, and we say so in Section 10(a) of the Terms. A report that it does not match the defensive posture of a mainstream consumer browser is a known and disclosed characteristic, not a vulnerability. A specific, exploitable flaw in our own functionality is in scope and we want it.

2. How to report

Email security@eyalsec.com with:

• what the issue is and where (URL, endpoint, agent and version, platform);
• clear, reproducible steps, and a proof of concept if you have one;
• the impact you believe it has;
• whether the issue is already public or known to anyone else;
• how you would like to be credited, if at all.

English or Hebrew are both fine. If you want to encrypt your report, say so and we will arrange a key.

3. Rules for testing

To stay inside the safe harbour in Section 5, you must:

• Test only against your own account, your own data and your own installations. Never against another customer's account, data, machines or browsers.
• Stop as soon as you have proof. Access the minimum data needed to demonstrate the issue. Do not download, retain, alter or destroy data that is not yours, and do not use an access you gain to reach anything further.
• Do not degrade the Service. No denial-of-service testing, no volumetric or load testing, no spam, no brute-forcing at a rate that affects availability.
• Do not social-engineer anyone, and do not attempt physical access.
• Report promptly and give us a reasonable chance to fix the issue before you tell anyone else (Section 6).
• Comply with the law, including data-protection law. If you encounter personal data, stop and tell us; do not read further, copy it, or keep it.
• If you need a test account, ask us for one at security@eyalsec.com rather than registering under a false identity.

4. What we commit to

| Stage | Our commitment | |-------|----------------| | Acknowledgement | Within 3 business days of your report reaching us. | | Initial assessment | Within 10 business days: whether we accept it, our severity assessment, and our intended course. | | Progress updates | At least every 14 days while the issue is open. | | Fix target | Critical and high severity: as fast as we can, targeting 30 days. Medium and low: with the next reasonable release. | | Notification | We tell you when it is fixed, and we tell affected customers where the issue warrants it. | | Credit | Public credit if you want it, anonymity if you prefer. Your choice, and we will ask before naming you. |

We do not currently run a paid bug bounty, and we will not pretend otherwise. There is no monetary reward. We are grateful anyway, and we credit properly.

5. Safe harbour

If you make a good-faith effort to comply with this policy, we will treat your research as authorized. Specifically, for such research:

• We will not initiate or support legal action against you, including under the Israeli Computers Law, 5755-1995, the Privacy Protection Law, 5741-1981, computer-misuse or anti-hacking laws in other jurisdictions, or any anti-circumvention provision.
• We will not treat your activity as a breach of the Terms of Service or the Acceptable Use Policy, and we will not suspend your account for it.
• If a third party brings a claim against you for research conducted in compliance with this policy, we will make clear that your activity was authorized by us.

This safe harbour covers only your dealings with EyalSec's own systems and software. It cannot and does not authorize you to test a customer's systems, or a third party's, and it does not waive any third party's rights. It also does not apply if you deliberately access or exfiltrate data that is not yours, extort us, or publish before the coordination period in Section 6.

If you are unsure whether something is in bounds, ask first at security@eyalsec.com. We would much rather answer a question than argue afterwards.

6. Coordinated disclosure

• We ask you to keep the issue confidential for 90 days from your report, or until we publish a fix, whichever is sooner.
• If we need longer, we will say why and agree a date with you rather than leaving you waiting. We will not use an extension request to bury an issue.
• If an issue is being actively exploited, we may publish sooner, and we will coordinate the wording with you.
• We support the assignment of a CVE where the issue warrants one, and we will not object to you requesting one.
• We will not ask you to sign a non-disclosure agreement as a condition of reporting.

7. Our own vulnerability handling

• We scan our dependencies for known vulnerabilities as a release gate: a failing scan blocks the deployment. See Section 6 of /legal/security.
• Where a published agent release carries known issues, we may publish them. Customers are responsible for running the current published version (Terms, Section 9).
• EU Cyber Resilience Act. From 11 September 2026, Regulation (EU) 2024/2847 requires manufacturers of products with digital elements placed on the EU market to report actively exploited vulnerabilities and severe incidents to ENISA and the relevant national CSIRT within defined deadlines (an early warning within 24 hours, a notification within 72 hours, and a final report thereafter). We are preparing to meet those obligations, and this policy is the coordinated-disclosure component of that work. Further CRA requirements apply from 11 December 2027.

8. Reporting something other than a vulnerability

• A false positive or a missed detection in an agent is a product issue, not a security vulnerability. Send it to eyal@eyalsec.com; it is still very welcome.
• Abuse of the Service, or a customer misusing an agent, goes to eyal@eyalsec.com under Section 8 of the AUP.
• A privacy concern or a data-subject request goes to eyal@eyalsec.com; see /legal/privacy.

9. Changes

We may update this policy. The version in force when you report is the one that applies to your report.