Vulnerability Disclosure Policy

This Vulnerability Disclosure Policy ("VDP") sets out the procedures and rules adopted by ZynReach for receiving, verifying, addressing, and communicating about reports of potential security vulnerabilities.

The Policy aims to:

• Encourage responsible reporting of vulnerabilities.
• Protect customers and users.
• Reduce security risks.
• Prevent unauthorized exploitation.
• Provide a clear channel for security researchers.
• Improve the security of the ZynReach platform.
• Support responsible disclosure of vulnerabilities.

This Policy applies to the assets and services owned or operated by ZynReach that are explicitly listed within the scope of this Policy.

The scope includes, as determined from time to time:

The appearance of any domain, IP address, or service associated with ZynReach does not, by itself, mean that testing it is automatically authorized.

• The official ZynReach website.
• Official ZynReach applications.
• Official APIs.
• Services and infrastructure that are announced as being within the testing scope.

Unless stated otherwise, the following are considered out of scope of this Policy:

• Customer systems.
• Customer accounts.
• Employee systems.
• Third-party services.
• Cloud infrastructure not directly managed by ZynReach.
• Domains not owned or managed by ZynReach.
• Vendor systems.
• Users' personal services.
• Any system that has been designated in writing as out of scope.

Any security testing must be directed exclusively at discovering and demonstrating the existence of a security vulnerability without causing unnecessary harm.

Testing may not be used to obtain personal or commercial benefit, or to access data that does not belong to the researcher.

A security vulnerability means any flaw or weakness in design, implementation, or configuration that could reasonably lead to:

• Unauthorized access.
• Privilege escalation.
• Data disclosure.
• Data modification.
• Service disruption.
• Execution of unauthorized commands.
• Account compromise.
• Impact on the confidentiality, integrity, or availability of the system.

ZynReach is committed to encouraging Responsible Disclosure.

This means reporting a vulnerability to ZynReach in a manner that allows the Company to verify and address it before details are published that could enable other parties to exploit it.

A security researcher may report vulnerabilities through the official security channel designated by ZynReach on its website, or the approved Security Contact.

The official channel must be used rather than publicly disclosing details of the vulnerability.

A report should include, as far as possible:

• A clear title.
• A description of the vulnerability.
• The affected asset.
• Steps to reproduce.
• A safe Proof of Concept.
• The expected security impact.
• A suggested severity level.
• Screenshots where needed.
• Any other useful technical information.

The minimum evidence necessary to demonstrate the vulnerability must be provided.

No more personal or confidential data than is necessary may be collected or retained.

If testing unintentionally results in the exposure of:

the researcher must stop accessing the data, must not copy or download it, must not use it, must not share it, and must notify ZynReach immediately.

• Personal data.
• Customer data.
• Credentials.
• API keys.
• Technical secrets.
• Confidential information.

The researcher is prohibited from attempting to access Customer Data or Personal Data that does not belong to them.

Unnecessary access to customer data is considered to exceed the scope of testing.

The researcher may not:

except to the extent strictly necessary to demonstrate the vulnerability and consistent with this Policy.

• Delete data.
• Modify it.
• Encrypt it.
• Transfer it.
• Destroy it.
• Change its permissions.

Conducting any test that could reasonably lead to the following is prohibited:

• DDoS.
• DoS.
• Service disruption.
• Resource exhaustion.
• System instability.

The following may not be performed:

on Production Systems without prior written authorization.

• Load testing.
• Stress testing.
• Flooding.
• Resource exhaustion.

The following are prohibited:

or any tools whose intended use is to cause harm or to maintain unauthorized access.

• Installing Malware.
• Ransomware.
• Backdoors.
• Persistence mechanisms.
• Cryptominers.

After demonstrating the existence of a vulnerability, the researcher must stop exploiting it.

Continuing for the purpose of the following is not permitted:

• Escalating privileges.
• Accessing other systems.
• Extracting additional data.
• Demonstrating a broader scope than necessary.

Using a vulnerability in ZynReach to access the following is prohibited:

• Customer systems.
• Vendor systems.
• Third-party services.
• Other users' systems.

If a vulnerability could lead to the ability to take over an account:

• A test account owned by the researcher must be used whenever possible.
• Taking over another user's account is prohibited.
• Accessing real account data is prohibited.

Authentication mechanisms may be tested in a limited and responsible manner.

The following must be avoided:

• Credential stuffing.
• Large-scale password spraying.
• Brute force against real accounts.
• Attempting to bypass authentication in a way that could affect users.

Authorization errors may be tested using appropriate test accounts.

Real users' accounts may not be used without authorization.

Automated scanning tools may be used if they are:

• Rate-limited.
• Non-destructive.
• Not causing undue load.
• Directed at assets authorized for testing.

Usage limits and request rates must be respected.

ZynReach may block or restrict testing sources that pose a risk to the Service.

This Policy does not typically include:

unless prior explicit written authorization has been obtained.

• Phishing.
• Vishing.
• Smishing.
• Impersonation.
• Social engineering targeting employees.

Testing physical security, entering facilities, or attempting to bypass physical protection measures is not permitted without written authorization.

ZynReach employees may not be targeted or deceived to obtain:

without prior explicit consent.

• Passwords.
• MFA codes.
• Credentials.
• Confidential information.

If a vulnerability is discovered in a third-party service used by ZynReach, it must be reported to ZynReach if it has a clear impact on ZynReach.

It may also be reported to the third party in accordance with its own disclosure policy.

If a vulnerability results from an external component, library, or service, ZynReach may need to coordinate with the vendor or responsible party before public disclosure.

When a researcher acts in good faith in compliance with this Policy and does not exceed its scope, ZynReach regards compliant security research activity as responsible and authorized within the limits of this Policy.

This does not mean:

• Granting open authorization to all systems.
• Permitting access to other people's data.
• Permitting destructive testing.
• Granting any rights beyond the scope of the declared assets.

Testing must be:

• Conducted in good faith.
• Non-harmful.
• Limited.
• Proportionate to the purpose of demonstrating the vulnerability.

The researcher must take all reasonable measures to prevent:

• Data loss.
• Service disruption.
• Privacy violations.
• Disclosure of confidential information.
• Impact on customers.

The researcher must stop testing immediately if:

• The system becomes unstable.
• Customer data appears.
• A risk to the Service arises.
• The asset is discovered to be out of scope.
• ZynReach requests that testing be stopped.

After testing is complete, the following must be removed:

to the extent within the researcher's control.

• Files created by the researcher.
• Test accounts created by the researcher.
• Test tokens.
• Any testing tools or data.

No sensitive data obtained unintentionally may be retained.

It must be deleted immediately after reporting, unless retaining it is reasonably necessary to provide proof of the vulnerability and is coordinated with ZynReach.

A PoC must be:

and may not include unnecessary confidential data.

• Minimal.
• Non-destructive.
• Reproducible.
• Relevant.

ZynReach may classify vulnerabilities according to levels such as:

• Critical — may lead to broad control over systems or disclosure of sensitive data on a large scale.
• High — may lead to significant access or impact.
• Medium — may have a limited security impact or require additional conditions to exploit.
• Low — vulnerabilities with low impact or a high degree of exploitation difficulty.

The final severity level is determined at ZynReach's sole discretion, based on:

ZynReach is not bound by the classification suggested by the researcher.

• Impact.
• Exploitability.
• Scope of impact.
• Prerequisites.
• Nature of the data.
• Availability of mitigations.

After receiving a report, ZynReach may:

• Review it.
• Reproduce it.
• Assess its impact.
• Classify it.
• Prioritize it.
• Refer the report to the responsible team.

ZynReach may contact the researcher to request:

• Additional information.
• Reproduction steps.
• An additional PoC.
• Clarification of impact.
• Information about the testing environment.

ZynReach seeks to review security reports within a reasonable time based on:

No discretionary response time constitutes a contractual guarantee.

• The severity of the report.
• The number of reports.
• Available resources.
• The complexity of the issue.

ZynReach may confirm:

• The existence of the vulnerability.
• Its reproducibility.
• The affected systems.
• The scope of impact.

If ZynReach is unable to reproduce the issue, the report may be classified as:

with the possibility of re-evaluation if new information is provided.

• Not Reproducible.
• Informational.
• False Positive.

If the same vulnerability has been reported previously, the report may be classified as Duplicate, with ZynReach retaining the right to communicate with the researcher at its discretion.

Security observations that do not constitute direct vulnerabilities may be submitted.

ZynReach evaluates them according to their security value.

ZynReach may accept reports relating to security improvements even if they do not represent an exploitable vulnerability.

ZynReach may not consider certain types of issues to be disclosable vulnerabilities, including, depending on the case:

This is not an exhaustive list.

• Missing security headers with no actual security impact.
• Publicly available general information.
• Self-XSS without a genuine impact path.
• Clickjacking on non-sensitive pages.
• Configuration issues that are not exploitable.
• Unsupported software versions without demonstrated impact.
• Reports based solely on theoretical scenarios.

Social engineering attempts against ZynReach employees are not considered within the scope of this Policy unless agreed upon in advance.

Physical security testing is not considered within the scope of the VDP unless authorized in writing.

DoS or DDoS testing is not accepted as part of this Policy without prior authorization.

ZynReach services may not be used to send the following during testing:

• Spam.
• Unauthorized bulk messages.
• Malicious content.

The researcher must respect the Privacy Rights of all users.

Collecting or disclosing Personal Data not necessary to demonstrate the vulnerability is prohibited.

Confidentiality must be maintained for:

• Customer data.
• User data.
• Security details.
• Vulnerability details.
• Credentials.
• Internal information.

Details of the vulnerability, the PoC, or customer data may not be published before coordinating with ZynReach.

ZynReach prefers the use of Coordinated Vulnerability Disclosure.

Agreement may be reached with the researcher on:

• The disclosure date.
• The level of detail.
• A CVE where applicable.
• Attribution to the researcher.

There is no fixed timeline for the public disclosure of every vulnerability.

Timing is determined based on:

• The nature of the vulnerability.
• The severity level.
• The extent of its prevalence.
• The availability of a fix.
• The risks to users.

If a researcher is legally required to disclose a vulnerability, they must, to the extent possible, notify ZynReach before disclosure and coordinate on the information to be published.

Publishing any of the following is prohibited:

even if obtained during a security test.

• Customer data.
• Personal data.
• Credentials.
• API keys.
• Tokens.

With the researcher's consent, ZynReach may credit their name or alias in a Hall of Fame or security report.

Unless a separate Bug Bounty Program has been explicitly announced, this Policy does not constitute a promise to pay:

ZynReach may establish a separate Bug Bounty Program with independent terms.

• Monetary rewards.
• Gifts.
• Compensation.

If ZynReach launches a Bug Bounty Program, that program's terms will be independent of this Policy and will define:

• Eligibility.
• Asset scope.
• Rewards.
• Exclusions.
• Payment terms.

Participation in the vulnerability disclosure program does not create:

between the researcher and ZynReach.

• An employment relationship.
• An agency relationship.
• A partnership.
• Legal representation.

This Policy does not grant the researcher any ownership right in:

• ZynReach.
• Source code.
• Customer data.
• Intellectual property.

The ZynReach or Zyntra Digital name or logos may not be used in commercial or marketing activities without authorization, except for factual reference to the security report as permitted by law.

ZynReach may take appropriate action if a person uses the VDP:

• To gain unauthorized access.
• To extort the Company.
• To obtain unlawful benefit.
• To disrupt services.
• To publish stolen data.

Financial demands or threats of disclosure in exchange for non-disclosure are not considered part of Responsible Disclosure.

ZynReach may address them in accordance with applicable law and its security policies.

Threatening to publish customer data or trade secrets does not grant the researcher any additional rights under this Policy.

ZynReach may take appropriate technical and legal action to protect:

• The platform.
• Users.
• Customers.
• Data.

Where required by law, ZynReach may cooperate with the competent authorities regarding activities that exceed this Policy.

When a researcher complies with this Policy in good faith, ZynReach seeks to treat them as a responsible security researcher within the limits of the law and this Policy.

This Policy does not grant immunity from liability for acts falling outside its scope.

The protection described in this Policy does not apply to:

• Destructive testing.
• Intentional access to other people's data.
• Extortion.
• Data theft.
• Service disruption.
• Disclosure of confidential information.
• Exploiting the vulnerability for unlawful benefit.

ZynReach may add or remove assets from the scope of the Policy.

The version of the Policy currently published applies to new testing.

ZynReach may take immediate security actions, such as:

if it determines that testing poses a risk to the Service or to users.

• Blocking an IP.
• Disabling a token.
• Closing an endpoint.
• Suspending a test account.

ZynReach may require the researcher to stop testing immediately when:

The request to stop must be respected.

• The asset is out of scope.
• Testing is affecting Production.
• There are risks to customers.
• Sensitive data appears.
• The researcher exceeds the limits of this Policy.

ZynReach's architecture or services may change over time.

This may result in:

• Removal of a vulnerability.
• A change in the reproduction method.
• A change in asset scope.
• A change in impact.

The researcher is responsible for:

• Complying with this Policy.
• Using secure tools.
• Protecting credentials.
• Not exceeding the scope.
• Not harming systems.

Within its resources and procedures, ZynReach commits to:

• Receiving reports.
• Evaluating them.
• Investigating them.
• Taking appropriate action.
• Communicating when necessary.
• Improving security controls.

ZynReach does not guarantee that every report will be fixed, or fixed within a specific period.

Priority is determined according to the level of risk and impact.

ZynReach may address a vulnerability through:

depending on the nature of the issue.

• A code fix.
• A configuration change.
• Access control.
• Monitoring.
• A compensating control.
• An architecture change.

ZynReach may use compensating controls when a direct fix is not appropriate or requires additional time.

After a vulnerability is addressed, testing may be conducted to verify:

• The effectiveness of the fix.
• That the issue does not recur.
• That no material side effects have arisen.

ZynReach may publish a Security Advisory when it deems it useful.

It may include:

• A general description.
• The severity level.
• Affected systems.
• The fix.
• Mitigation measures.

Where appropriate, ZynReach or a competent authority may coordinate to obtain a CVE or an appropriate security identifier.

ZynReach may update this Policy as needed due to:

• Technical changes.
• Legal changes.
• Security changes.
• Changes in service scope.

The version published on ZynReach's official channels is deemed the authoritative reference for the current disclosure policy, unless a different written agreement exists.

This Policy is governed by the law applicable to ZynReach and related agreements.

This Policy does not grant any rights that conflict with mandatory law.

ZynReach's failure to enforce any provision of this Policy in a particular case does not constitute a waiver of its right to enforce it in the future.

If any provision of this Policy becomes invalid or unenforceable, the remaining provisions remain in effect to the extent permitted by law.

This Policy operates in conjunction with:

• The Security & Trust Policy.
• The Incident Response & Security Breach Notification Policy.
• The Enterprise Security Addendum.
• The Privacy Policy.
• The Data Processing Agreement.
• The Acceptable Use Policy.
• The Terms of Service.

This Policy is not deemed an amendment to, or waiver of:

unless expressly stated otherwise.

• The Terms of Service.
• The MSA.
• The DPA.
• The SLA.
• The Enterprise Agreement.

Security reports must be directed to the official Security Contact channel published by ZynReach.

Security Contact: the official email address and reporting channel are specified on the Security / Vulnerability Disclosure page at zynreach.com.

In the event of a vulnerability that could lead to:

the report should note URGENT / CRITICAL SECURITY in the subject line.

• A large-scale breach.
• Disclosure of customer data.
• A complete authentication bypass.
• Widespread service disruption.

It is recommended that a report follow this format:

• Title — [Severity] — [Short Vulnerability Description].
• Affected Asset — [Domain / Application / API].
• Description — [Description].
• Steps to Reproduce — [Steps].
• Proof of Concept — [Safe PoC].
• Impact — [Security Impact].
• Suggested Remediation — [Optional].
• Researcher Contact — [Contact Information].

The researcher must not submit unnecessary personal information.

ZynReach uses the contact information provided by the researcher for the purpose of handling the report, in accordance with the Privacy Policy and applicable law.

ZynReach treats details of unpublished vulnerabilities as sensitive security information.

A full exploit against the Production Environment should not be developed or published when a safe proof of concept is sufficient to demonstrate the vulnerability.

It must be assumed that the Production Environment contains real data and systems.

The utmost caution must therefore be exercised during testing.

The following are preferred for use:

instead of real customer or user accounts.

• Test accounts.
• Test data.
• Researcher-owned accounts.

The least impactful method of demonstrating a vulnerability must always be chosen.

Where completing testing conflicts with protecting users, data, or the Service, protection must be given priority.

ZynReach reserves the right to:

without prejudice to the legal rights of the researcher or any other party.

• Determine the scope of the Policy.
• Assess risks.
• Determine severity.
• Determine the remediation method.
• Determine the timing of disclosure.

The following table sets out this document's record data:

• Document Name — Vulnerability Disclosure Policy.
• Abbreviation — VDP.
• Company — Zyntra Digital.
• Platform — ZynReach.
• Website — zynreach.com.
• Version — 1.0.
• Effective Date — August 31, 2026.
• Classification — Public / Security.
• Owner — Security / Engineering.
• Review — Periodic or upon a material change.
• Related Documents — Security & Trust Policy / Incident Response Policy / Enterprise Security Addendum / Privacy Policy / AUP / Terms of Service.

Zyntra Digital / ZynReach

• Name of Responsible Officer
• Job Title
• Signature
• Date

This Policy is intended to govern the responsible disclosure of security vulnerabilities at ZynReach and does not grant any person general authorization to test all ZynReach systems, customer systems, or third-party systems.

Security research activities must be limited to the declared scope and must be conducted responsibly and non-destructively.

This Policy does not grant absolute immunity from legal liability, and does not waive any rights or obligations established by applicable law or governing contracts.

© 2026 Zyntra Digital. All Rights Reserved.