Vulnerability Disclosure Policy

Last updated: 14 October 2026

CYVIATION Ltd. (“CYVIATION”, “we”, “us”) is an aviation cybersecurity company. Our researchers find security defects in aircraft systems, avionics, cabin and ground systems, and the protocols that connect them, and we operate our own products and services. This policy explains how we disclose vulnerabilities we discover in other organisations’ products, how we handle vulnerability reports sent to us, and when and how we assign CVE identifiers and publish advisories.

It follows the principles of ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling) and the coordinated disclosure practice of the CERT Coordination Center (CERT/CC).

What we count as a vulnerability

A vulnerability is a weakness in software, firmware, hardware, configuration, or in a protocol or standard, that can be used to compromise the confidentiality, integrity or availability of a system, or the safety of the aircraft, crew and passengers that depend on it.

We treat a weakness as in scope even when exploiting it requires physical access to a unit, access to an on-board or maintenance network, or a specific aircraft configuration. We describe those preconditions in the advisory rather than excluding the finding.

We do not treat the following as vulnerabilities: issues with no security or safety impact, the presence of an outdated component without a demonstrated path to exploitation, or a missing best practice that does not create an exploitable condition.

Reporting a vulnerability to us

Report vulnerabilities in our own products and services (SkyRay and cyviation.aero), or vulnerabilities in aviation products that you would like CYVIATION to coordinate, to security@cyviation.aero. A machine-readable version of this contact is published at /.well-known/security.txt.

You can also ask us to assign a CVE ID for a vulnerability in our scope by writing to security@cyviation.aero. Requesting a CVE ID does not require agreeing to any terms or conditions.

Please include the affected product or system and its version, the steps needed to reproduce the issue, the impact you observed, and any proof-of-concept material. You may report anonymously. Identification is only needed if you want to receive updates or be credited.

What to expect from us:

• We acknowledge your report within 3 business days.
• Within 10 business days we tell you whether we have confirmed the issue and whether we will fix it, coordinate it with the responsible vendor, or refer you to a better-placed coordinator.
• We keep you informed of significant changes in status and update you at least every 30 days until the issue is resolved or published.
• We credit you in the advisory and the CVE record unless you ask us not to. We pass your name and contact details to a vendor only with your consent.
• Reports about third-party products enter the coordinated disclosure timeline below from the day we notify the responsible organisation.

Good-faith research. We will not pursue legal action against researchers who test our own systems in good faith, avoid privacy violations, data destruction and service disruption, do not access or retain more data than is needed to demonstrate the issue, and give us a reasonable time to respond before disclosing. Do not test on aircraft or equipment in operational service.

How we disclose vulnerabilities we discover

Most vulnerabilities we publish are in other organisations’ products. We coordinate with the organisation best placed to fix the issue (the “responsible organisation”: usually the manufacturer or software vendor, sometimes the operator or the standards body). The default timeline is:

• Day 0. We notify the responsible organisation privately, through its published security contact or the best channel available, with enough technical detail to reproduce the issue. We reserve a CVE ID at this point.
• Day 15. If we have received no acknowledgement, we treat the organisation as non-responsive and share the report with a coordinator: CISA, CERT/CC, the relevant national CSIRT, or the relevant aviation authority. We may involve a coordinator earlier when safety warrants it.
• Day 45. We publish the advisory and the CVE record, whether or not a fix is available. This is the same 45-day clock used by CERT/CC.

Extensions. If the responsible organisation has acknowledged the report and is working on a fix in good faith, and more time is needed for reasons specific to aviation, such as airworthiness certification, service bulletin issue or fleet deployment, we may agree an extension. Extensions are agreed in writing with a fixed date, and we do not normally publish later than 90 days from the organisation’s acknowledgement.

Earlier publication. We may publish before day 45 when the vulnerability is being exploited, when it has been disclosed publicly by someone else, when a fix has been released (including a silent fix), or when the risk to flight safety makes waiting unreasonable. In the case of active exploitation we aim to publish within 72 hours of notifying the responsible organisation and a coordinator.

No surprises. We tell the responsible organisation our planned publication date in advance, invite a written statement, and include that statement in the advisory. We do not withhold vendor-supplied information because it disagrees with our assessment. Where we know which operators are affected, we may notify them privately before publication.

What we publish. An advisory contains a description of the vulnerability, the affected products and versions (manufacturer, part number, software or firmware version where known), the impact and preconditions, available mitigations, the CVE ID, the disclosure timeline and credit. We may withhold exploit code or step-by-step exploitation detail where publishing it would create a disproportionate risk to flight safety and it is not needed to understand or mitigate the issue.

CVE assignment

Scope: CYVIATION will issue CVE IDs for vulnerabilities in aviation and avionics products, components and systems that CYVIATION is researching or coordinating, unless they are otherwise covered by another CNA’s scope.

• We reserve a CVE ID when we begin coordination and publish the CVE record at the same time as the advisory.
• If the responsible organisation is itself a CVE Numbering Authority (CNA), we give it the opportunity to assign the CVE ID for its own product. If it declines or does not respond, we ask MITRE, our Root, to decide who assigns the ID.
• Where a vulnerability falls outside our CNA scope, we request the CVE ID from the responsible CNA or from the CNA of last resort.
• Where the weakness lies in a protocol or standard rather than in one product, we describe the affected standard and version and the implementations we know to be affected, and we request a CVE ID for each affected implementation where appropriate.
• Every CVE record we publish carries the affected product and versions, the problem type (CWE), the impact, and a reference to the advisory.

Where we publish

Advisories are published at cyviation.aero/security/advisories, which is public and requires no login, and in the CVE List. Some findings are also covered in our reports and articles. When an advisory is amended, the change is recorded in its revision history.

Contact

Security reports: security@cyviation.aero

CYVIATION Ltd., 114 Yigal Alon Street, 11th Floor, ToHa Tower, Tel Aviv-Yafo 6744320, Israel

Please report privately. Do not post vulnerability details in public forums or on social media before the advisory is published.

We review this policy at least once a year and whenever the CVE Program rules change.