Responsible Disclosure Policy

Hostwover recognizes that security vulnerabilities may exist despite reasonable security measures.

Responsible security research can help Hostwover:

• identify weaknesses.
• understand security risks.
• remediate vulnerabilities.
• improve security controls.
• protect Customers.
• protect infrastructure; and
• improve the security of Hostwover Services.

We encourage good-faith security researchers to report qualifying vulnerabilities through the process described in this Policy.

Responsible disclosure means privately reporting a suspected security vulnerability to Hostwover and allowing Hostwover a reasonable opportunity to:

• investigate.
• reproduce.
• assess.
• mitigate.
• remediate; and
• coordinate disclosure

before detailed vulnerability information is publicly released.

For purposes of this Policy, "good-faith security research" means security testing performed:

• for the purpose of identifying and helping correct a vulnerability.
• without malicious intent.
• without unnecessarily harming Hostwover or its Customers.
• within the authorization boundaries of this Policy.
• while minimizing access to Personal Data and Customer Content; and
• in a manner reasonably designed to avoid Service disruption.

This Policy provides authorization only for research involving systems that:

1. are expressly identified as in scope under this Policy; and
2. are owned or controlled by Hostwover for the relevant testing purpose.

This Policy does not authorize security testing merely because a system:

• displays Hostwover branding.
• is accessible through Hostwover.
• is linked from hostwover.com.
• is sold by Hostwover.
• is resold by Hostwover.
• integrates with Hostwover; or
• provides infrastructure used by Hostwover.

Unless Hostwover expressly states otherwise in writing, this Policy does not authorize testing of systems controlled by third parties.

This may include infrastructure or services operated by:

• cloud providers.
• data-center providers.
• domain registrars.
• domain registries.
• Google.
• payment processors.
• email providers.
• software vendors.
• analytics providers.
• identity providers.
• communications providers; or
• other third-party suppliers.

Researchers must follow the applicable third party's own vulnerability disclosure or security-testing policy.

This Policy does not authorize testing of systems belonging to Hostwover Customers.

This includes, without limitation:

• Customer websites.
• Customer VPS instances.
• Customer VDS instances.
• Customer databases.
• Customer applications.
• Customer email accounts.
• Customer APIs.
• Customer control panels.
• Customer domains.
• Customer DNS configurations.
• Customer storage.
• Customer repositories; or
• Customer credentials.

Authorization to test Hostwover does not create authorization to test Hostwover Customers.

Even where Hostwover supplies the underlying VPS or VDS Service, a Customer-controlled server may contain:

• Customer software.
• Customer accounts.
• Customer databases.
• Customer Content.
• Personal Data; and
• third-party applications.

Researchers must not scan, access, exploit, or test Customer instances without explicit authorization from the applicable Customer.

Researchers must not use this Policy as authorization to test:

• hypervisors.
• upstream network equipment.
• provider management interfaces.
• data-center infrastructure.
• cloud-provider APIs.
• physical servers controlled by an upstream provider; or
• other infrastructure outside Hostwover's direct testing authority.

Hostwover may supply domain-registration Services through an upstream registrar or other provider.

This Policy does not authorize security testing against:

• the Sponsoring Registrar.
• domain registry.
• EPP infrastructure.
• registrar APIs not operated by Hostwover.
• WHOIS/RDAP infrastructure controlled by third parties; or
• registry systems.

Google Workspace is operated by Google.

This Policy does not authorize researchers to test Google Workspace, Google infrastructure, Gmail, Google Drive, Google Admin, or related Google systems.

Vulnerabilities in Google-controlled systems should be reported through Google's applicable security-reporting process.

Where Professional Email relies on third-party infrastructure, this Policy does not automatically authorize testing of the provider's:

• mail servers.
• webmail.
• administrative interfaces.
• APIs.
• storage infrastructure; or
• authentication systems.

Researchers must not test or interfere with payment-provider infrastructure through Hostwover checkout flows.

This includes attempting to exploit:

• card gateways.
• hosted payment pages.
• banking integrations.
• external payment APIs; or
• payment-provider accounts.

Unless Hostwover publishes a more specific scope, security research may be considered in scope only for Hostwover-controlled public-facing systems associated with:

• hostwover.com.
• Hostwover-owned web applications.
• Hostwover account-management functionality.
• Hostwover-controlled APIs.
• Hostwover-controlled authentication systems.
• Hostwover-developed frontend or backend applications; and
• other systems expressly identified by Hostwover as eligible for security research.

Hostwover may publish a more detailed vulnerability-testing scope identifying specific:

• domains.
• subdomains.
• applications.
• APIs.
• repositories.
• mobile applications.
• IP ranges; or
• services.

Where a specific scope exists, that scope takes precedence over the general description above.

If you are unsure whether a system is owned or controlled by Hostwover, do not actively exploit it.

Instead:

• stop testing.
• document what you observed; and
• contact Hostwover for clarification.

Discovering a previously unknown Hostwover-controlled asset does not automatically authorize intrusive testing against that asset.

Researchers should apply the minimum necessary testing and ask Hostwover if uncertainty exists.

Researchers participating under this Policy should:

• use the minimum testing necessary.
• stop when impact is demonstrated.
• avoid accessing unnecessary data.
• avoid disruption.
• avoid persistence.
• avoid altering production information.
• avoid affecting other users; and
• report the issue privately.

Researchers should demonstrate a vulnerability using the least intrusive method reasonably sufficient to establish that the vulnerability exists.

Once the security impact is proven, testing should stop unless Hostwover requests additional verification.

A report may include a limited proof of concept where reasonably necessary to demonstrate the vulnerability.

A proof of concept must not unnecessarily:

• extract Customer data.
• modify production records.
• cause downtime.
• establish persistence.
• spread malware.
• access unrelated accounts; or
• create significant operational risk.

Researchers should use their own accounts whenever authentication is required.

Researchers must not attempt to access another Customer's account.

Researchers may create ordinary Hostwover accounts for security testing where:

• creation complies with Hostwover's Terms.
• information is not materially fraudulent.
• the accounts are not used to abuse promotions.
• payment systems are not abused; and
• the number of accounts remains reasonably necessary for testing.

Creating a limited number of researcher-controlled accounts may be permitted where needed to test:

• authorization.
• account isolation.
• role boundaries.
• cross-account access; or
• similar security controls.

Researchers must not create excessive accounts that disrupt Hostwover systems.

Researchers should use synthetic or researcher-controlled data where possible.

Do not intentionally create test scenarios containing:

• real payment-card information not belonging to you.
• unrelated Personal Data.
• government identifiers.
• medical records.
• private Customer Content; or
• other unnecessary sensitive information.

Testing for authorization failures such as:

• IDOR.
• broken access control.
• privilege escalation.
• cross-account access; or
• role bypass

must be performed only between accounts controlled by the researcher unless Hostwover expressly authorizes broader testing.

If testing unexpectedly exposes information belonging to another person or Customer, you must:

1. stop accessing additional information.
2. avoid downloading unnecessary data.
3. avoid modifying the information.
4. preserve only the minimum evidence needed.
5. report the issue promptly; and
6. securely delete retained data when no longer necessary.

Researchers must not intentionally access Customer Content merely to demonstrate severity.

Examples include:

• emails.
• databases.
• website files.
• private documents.
• passwords.
• API keys.
• private messages.
• billing data; or
• personally identifiable information.

If a vulnerability exposes highly sensitive information, researchers should avoid including unnecessary copies of that information in the report.

Where possible, use:

• redaction.
• hashes.
• partial values.
• screenshots with sensitive fields concealed; or
• descriptions sufficient to demonstrate impact.

Researchers must not knowingly:

• retain.
• use.
• trade.
• disclose; or
• attempt credential stuffing with

credentials belonging to Hostwover Customers or personnel.

If you discover exposed Hostwover credentials, API keys, tokens, private keys, or secrets, report them immediately.

Do not use them beyond what is minimally necessary to determine that they appear valid or security-sensitive.

Researchers should avoid actively authenticating with exposed production credentials unless absolutely necessary to establish risk.

When possible, report the exposed secret without using it.

Researchers must minimize processing of Personal Data.

If Personal Data is encountered inadvertently, it must not be:

• copied unnecessarily.
• shared.
• published.
• sold.
• retained longer than necessary; or
• used for any unrelated purpose.

The following activities are prohibited unless Hostwover provides specific prior written authorization:

• deleting production information.
• intentionally corrupting data.
• destroying databases.
• destructive file modification.
• wiping systems.
• destructive ransomware simulation; or
• irreversible account modification.

Researchers must not conduct:

• DoS attacks.
• DDoS attacks.
• application-layer resource exhaustion.
• bandwidth exhaustion.
• connection flooding.
• request flooding; or
• similar availability attacks.

Load testing, stress testing, or capacity testing against production Hostwover Services is not authorized unless Hostwover expressly approves it in advance.

Limited automated vulnerability scanning may be permitted where it:

• remains within scope.
• uses reasonable request rates.
• does not cause disruption.
• does not target Customers; and
• stops if adverse effects are observed.

High-volume or aggressive scanning is prohibited where it may:

• degrade Service performance.
• trigger resource exhaustion.
• affect Customers.
• overload APIs.
• generate excessive logs; or
• interfere with production operations.

Researchers must respect reasonable rate limits.

Testing designed primarily to defeat rate limiting through distributed or high-volume requests is not authorized unless required to demonstrate a security vulnerability and performed at minimal scale.

Large-scale brute-force attacks are prohibited.

Limited testing of authentication controls may be permitted using researcher-controlled accounts and a small number of attempts.

Credential stuffing using real leaked credentials is prohibited.

Password spraying against Hostwover Customers, employees, administrators, or production accounts is prohibited.

Social engineering is outside the authorized scope.

Researchers must not attempt to compromise Hostwover through:

• phishing employees.
• impersonating Customers.
• telephone pretexting.
• SMS phishing.
• fake support requests.
• physical impersonation; or
• other manipulation of people.

Physical security testing is not authorized.

Do not attempt to:

• enter Hostwover facilities without permission.
• access provider data centers.
• steal equipment.
• bypass physical controls; or
• test staff physical-security procedures.

Testing Hostwover employees' personal or work devices is not authorized.

Researchers must not attempt to compromise employee:

• email accounts.
• social-media accounts.
• personal accounts.
• third-party SaaS accounts; or
• identity-provider accounts

unless Hostwover specifically identifies such testing as in scope.

Researchers must not deploy malware on Hostwover infrastructure.

This includes:

• ransomware.
• trojans.
• worms.
• spyware.
• credential stealers.
• botnet agents.
• rootkits; or
• destructive payloads.

Researchers must not establish persistent unauthorized access.

This includes installing:

• backdoors.
• additional administrator accounts.
• persistent scheduled tasks.
• unauthorized SSH keys.
• remote-access software; or
• long-lived unauthorized tokens.

Researchers must not establish unauthorized command-and-control infrastructure inside Hostwover systems.

If a vulnerability gives access to an internal environment, researchers must not move laterally into additional systems merely to explore the network.

Stop and report the initial access unless Hostwover authorizes further investigation.

Limited privilege-escalation testing may be performed where:

• the affected system is in scope.
• the testing does not access unrelated Customer data.
• the researcher stops after establishing impact; and
• additional compromise is unnecessary.

Researchers should avoid making persistent changes to production systems.

If a small reversible modification is necessary to demonstrate a vulnerability, restore the previous state where safely possible.

Large-scale data exfiltration is prohibited.

Researchers should not download databases or bulk records to prove that unauthorized data access is possible.

A small, controlled demonstration is sufficient.

Downloading or publishing a production database dump is prohibited.

Researchers must not intentionally read or send email belonging to another Customer or Hostwover employee.

Where testing email-related functionality, use email accounts and addresses controlled by you.

Do not send unsolicited messages to third parties.

Spam testing involving external recipients is prohibited.

Researchers must not use Hostwover systems to attack:

• third-party networks.
• Customers.
• upstream providers.
• external websites; or
• internet infrastructure.

This Policy does not authorize use of Hostwover infrastructure to scan external networks.

Testing an independent vendor's product because Hostwover uses that product is outside scope unless Hostwover owns the affected deployment and the vulnerability can be tested without attacking the vendor's systems.

If a vulnerability exists solely in a third-party open-source component, researchers are encouraged to follow the disclosure procedure applicable to that project.

If Hostwover's deployment creates an additional security impact, the Hostwover-specific impact may also be reported to us.

Reports identifying a vulnerable dependency should explain why Hostwover is actually exploitable.

Simply reporting that a package version has a publicly known vulnerability may not be sufficient where the vulnerable functionality is not used or exploitable.

Reports concerning vulnerabilities that Hostwover is already aware of may be treated as duplicate reports.

Reports merely repeating publicly available vulnerability information without demonstrating a Hostwover-specific security impact may not qualify as actionable security reports.

Hostwover is particularly interested in vulnerabilities such as:

• remote code execution.
• authentication bypass.
• significant authorization bypass.
• cross-account access.
• privilege escalation.
• SQL injection.
• server-side request forgery with meaningful impact.
• sensitive-data exposure.
• insecure direct object references.
• account takeover.
• significant session-management flaws.
• cryptographic implementation weaknesses.
• file upload vulnerabilities leading to code execution.
• path traversal with meaningful impact.
• command injection.
• payment or billing manipulation.
• domain-management authorization flaws.
• API authorization vulnerabilities; and
• other weaknesses that materially affect confidentiality, integrity, or availability.

Meaningful business-logic vulnerabilities are in scope where they create a genuine security impact.

Examples may include unauthorized:

• account ownership changes.
• subscription modifications.
• credit manipulation.
• billing bypass.
• Service takeover.
• privilege changes.
• domain-management actions; or
• access to another Customer's resources.

Security weaknesses in Hostwover-controlled domain-management interfaces may be reported.

However, researchers must not:

• transfer Customer domains.
• modify Customer DNS.
• change registrant information.
• request unauthorized EPP codes.
• disable domain protections; or
• otherwise interfere with a Customer's domain

to demonstrate the issue.

Use researcher-controlled domains where necessary.

Vulnerabilities affecting a Hostwover-controlled server-management interface may be in scope.

Testing must use researcher-controlled Services.

Researchers must not access or interfere with another Customer's VPS or VDS.

Security vulnerabilities involving billing may be reported where they enable unauthorized:

• transactions.
• balance manipulation.
• price manipulation.
• refunds.
• credits.
• Service activation; or
• access to another Customer's invoices.

Researchers must not intentionally create financial loss.

Do not:

• use stolen cards.
• create fraudulent payments.
• initiate chargebacks as testing.
• manipulate third-party processors; or
• intentionally cause settlement errors.

Simple promotion stacking, coupon enumeration, or discount behavior may not constitute a security vulnerability unless it creates meaningful unauthorized financial or account impact.

Reports concerning information disclosure should explain the sensitivity and security impact of the information.

Publicly intended information is not a vulnerability merely because it can be discovered.

A directory listing is reportable where it exposes information not intended for public access and creates meaningful security impact.

Server-version banners or ordinary software-version disclosure generally do not constitute a qualifying vulnerability without demonstrated security impact.

Reports solely concerning missing security headers may be treated as informational unless an exploitable security impact is demonstrated.

Reports concerning TLS configuration should demonstrate a practical, material security risk.

Merely identifying support for a configuration without meaningful exploitability may be considered informational.

Clickjacking reports should demonstrate a realistic sensitive action that can be performed through the vulnerability.

Reports affecting pages without security-sensitive functionality may be treated as low impact.

Cross-site scripting may be reportable where it affects Hostwover-controlled systems.

Reports should identify:

• context.
• payload.
• affected URL.
• required user interaction; and
• realistic security impact.

Self-XSS requiring the victim to manually execute attacker-supplied code in their own developer console may generally be treated as non-security-impacting unless a realistic exploitation chain exists.

Cross-Site Request Forgery reports should demonstrate an unauthorized security-sensitive action.

Open redirects may be accepted where they create a meaningful security impact.

An isolated redirect without a realistic security consequence may be treated as informational.

Server-Side Request Forgery reports should avoid accessing sensitive third-party or Customer infrastructure.

Researchers should prove impact using the minimum necessary request.

File-upload testing must avoid:

• malware distribution.
• hosting malicious public payloads.
• persistent shells; and
• impact to other users.

If you achieve remote code execution, immediately stop escalating the compromise once execution is proven.

Do not use the access to:

• explore unrelated files.
• access Customer data.
• pivot internally.
• create persistence; or
• alter production systems.

Report the vulnerability immediately.

When testing SQL injection:

• avoid dumping tables.
• avoid modifying data.
• retrieve only minimal proof where necessary; and
• stop once exploitability is established.

When testing command injection, use harmless commands that demonstrate execution without altering the system.

Authentication bypass should be demonstrated using researcher-controlled accounts wherever possible.

Do not use the vulnerability to access unrelated Customer accounts.

For account-takeover vulnerabilities, demonstrate the issue using accounts you own.

Do not take over accounts belonging to real Customers.

MFA bypass vulnerabilities may be reported using researcher-controlled accounts.

Rate-limit weaknesses should be tested conservatively.

Do not send large volumes of production traffic merely to establish that a limit is absent.

User, email, domain, or account enumeration may be reportable where it creates a meaningful privacy or security risk.

High-volume enumeration is not permitted.

Security issues in Hostwover-controlled DNS-management functionality may be reportable.

Researchers must use domains they are authorized to control.

Cache poisoning, cache deception, or similar vulnerabilities may be reported where the researcher can demonstrate impact without harming other users.

CORS misconfiguration should demonstrate unauthorized exposure of meaningful protected information or actions.

A permissive header alone may not constitute a vulnerability.

Security misconfiguration may be reportable where it creates a realistic exploitable risk.

Potential subdomain takeover may be reported where:

• the affected subdomain belongs to Hostwover.
• takeover can be demonstrated safely; and
• the researcher does not publish harmful content.

Do not permanently claim third-party resources or leave takeover content active longer than necessary.

Where a third-party platform requires claiming a resource to demonstrate takeover, researchers should use the minimum action necessary and immediately notify Hostwover.

The following findings are generally out of scope unless they create a demonstrated material security impact:

• missing security headers alone.
• software version disclosure alone.
• banner disclosure.
• clickjacking on non-sensitive pages.
• self-XSS without an exploitation chain.
• harmless verbose errors.
• SPF/DKIM/DMARC recommendations without exploitable impact.
• email spoofing claims that do not involve Hostwover-controlled configuration.
• lack of a particular cookie attribute without meaningful exploitation.
• best-practice-only TLS observations.
• public information exposure.
• username enumeration with negligible impact.
• lack of rate limiting on low-risk functionality.
• theoretical vulnerabilities without a working or credible attack path.
• issues requiring obsolete unsupported browsers only.
• scanner-only reports without manual validation; and
• purely cosmetic issues.

Vulnerabilities located entirely within third-party systems are out of scope for Hostwover's Responsible Disclosure Program.

Researchers should report them to the relevant provider.

Vulnerabilities in Customer websites, applications, servers, or configurations are not Hostwover vulnerability reports unless the root cause is a Hostwover-controlled platform vulnerability.

Security abuse and vulnerability disclosure are different processes.

Examples of abuse include:

• phishing websites.
• malware hosted by a Customer.
• spam.
• compromised Customer servers.
• fraudulent domains; or
• network attacks.

These matters should be submitted under the Hostwover Abuse Handling Policy, rather than this Responsible Disclosure Policy.

Researchers should report suspected vulnerabilities privately to Hostwover.

Until a dedicated security reporting channel is published, reports may be sent to:

Hostwover Support

Email: [email protected]

Website: hostwover.com

Use a clear subject such as:

Security Vulnerability Report – [Short Description]

Hostwover may establish a dedicated address such as:

[email protected]

or another vulnerability reporting channel.

Once a dedicated security channel is published, researchers are encouraged to use it instead of general Customer Support.

A useful vulnerability report should include:

• researcher name or pseudonym.
• contact information.
• affected Hostwover asset.
• vulnerability type.
• affected URL or API endpoint.
• reproduction steps.
• required account type.
• proof of concept.
• screenshots where useful.
• request and response examples.
• security impact.
• suggested remediation, if available; and
• disclosure expectations, if any.

Reports should contain clear and concise steps enabling Hostwover to reproduce the vulnerability.

Where appropriate, evidence may include:

• HTTP requests.
• HTTP responses.
• API calls.
• redacted screenshots.
• logs.
• proof-of-concept code.
• video demonstration; or
• other technical information.

Reports must redact unrelated:

• passwords.
• Personal Data.
• authentication tokens.
• payment information.
• Customer Content; and
• third-party confidential information.

Proof-of-concept code may be provided where necessary.

Researchers should avoid sending:

• destructive malware.
• weaponized payloads designed for mass exploitation.
• unnecessary credential-stealing code; or
• data obtained unlawfully.

Researchers may report using their real name or a pseudonym unless additional information is reasonably required for a specific legal, payment, or recognition process.

Anonymous reports may be investigated if sufficient technical information is provided.

Hostwover may publish a PGP key or another secure method for transmitting highly sensitive security reports.

Until such a method exists, researchers should minimize sensitive information transmitted through ordinary email.

Do not include unnecessary:

• passwords.
• private keys.
• complete access tokens.
• Customer databases.
• payment-card data; or
• large quantities of Personal Data

in vulnerability reports.

Hostwover may acknowledge receipt of a vulnerability report.

Acknowledgment means only that the report was received.

It does not mean that:

• the issue is confirmed.
• the report is eligible for recognition.
• a bounty is owed.
• severity has been determined; or
• Hostwover agrees with the researcher's analysis.

Hostwover may review a report to determine:

• whether the asset is in scope.
• whether the vulnerability is reproducible.
• security severity.
• potential Customer impact.
• likelihood of exploitation.
• whether the issue is already known.
• whether an upstream provider is involved; and
• appropriate remediation priority.

Hostwover may evaluate severity using factors including:

• confidentiality impact.
• integrity impact.
• availability impact.
• privilege required.
• user interaction.
• exploit complexity.
• affected Customers.
• exploitability.
• data sensitivity; and
• business impact.

Hostwover may use an industry-recognized vulnerability scoring framework or internal risk methodology as an input when assessing severity.

The final remediation priority may differ from an automated numerical score.

A vulnerability with a technically high score may present lower practical risk depending on deployment conditions.

Likewise, a technically simple vulnerability may receive higher priority where it threatens critical:

• authentication.
• billing.
• domain control.
• Customer isolation; or
• administrative functionality.

Where multiple researchers report the same vulnerability, Hostwover may classify later reports as duplicates.

Hostwover may consider factors such as:

• earliest complete report.
• reproducibility.
• independent discovery.
• quality of information; and
• remediation value.

A vulnerability already known to Hostwover before receipt of the report may be marked as previously known.

Reports that cannot be reproduced or do not present a security vulnerability may be closed as:

• invalid.
• informational.
• not applicable; or
• insufficient evidence.

Hostwover may request:

• additional reproduction steps.
• clarification.
• testing information.
• affected versions.
• browser or environment details; or
• limited follow-up validation.

Researchers should not perform materially more intrusive testing merely because a report has been submitted.

Additional testing should remain within this Policy or be specifically authorized by Hostwover.

Hostwover may address a vulnerability through measures including:

• code changes.
• configuration changes.
• access-control changes.
• credential rotation.
• provider updates.
• infrastructure changes.
• feature restrictions.
• monitoring.
• temporary mitigation; or
• permanent remediation.

Hostwover may implement temporary mitigation before a complete fix is available.

Examples may include:

• disabling a feature.
• restricting an endpoint.
• blocking an attack vector.
• adding monitoring.
• increasing authentication requirements; or
• applying a temporary configuration.

Hostwover does not guarantee that every vulnerability can be fully remediated within the same period.

Timing may depend on:

• severity.
• complexity.
• affected architecture.
• Customer impact.
• provider dependencies.
• regression risk.
• testing requirements.
• deployment constraints; and
• availability of a safe fix.

Hostwover may prioritize vulnerabilities that create an immediate or substantial risk of:

• account takeover.
• widespread Customer compromise.
• remote code execution.
• unauthorized domain control.
• significant Personal Data exposure.
• privilege escalation.
• large-scale financial abuse; or
• similar severe consequences.

Where practical, Hostwover may provide the researcher with updates concerning:

• report acceptance.
• reproduction.
• status.
• remediation.
• requested retesting; and
• coordinated disclosure.

Hostwover may not disclose sensitive internal security information.

Hostwover may decline to provide detailed information about:

• internal architecture.
• security controls.
• provider infrastructure.
• Customer information.
• detection systems; or
• other confidential matters

where disclosure would create additional security risk.

Hostwover may ask the original reporter to verify that a remediation is effective.

Retesting remains subject to this Policy.

A report may be closed when:

• remediation is completed.
• mitigation sufficiently addresses the risk.
• the vulnerability is invalid.
• the report is duplicate.
• the asset is out of scope.
• the issue belongs to another provider.
• the risk is accepted; or
• another appropriate resolution is reached.

Researchers should coordinate public disclosure with Hostwover.

Do not publicly disclose detailed information that could reasonably facilitate exploitation while:

• Hostwover is actively investigating.
• remediation is being developed.
• Customers remain materially exposed; or
• a mutually agreed disclosure date has not been reached.

Hostwover encourages researchers to allow a reasonable remediation period before public disclosure.

The appropriate period may depend on:

• severity.
• exploitability.
• affected Customers.
• remediation complexity.
• active exploitation.
• provider dependencies; and
• whether a safe fix exists.

This Policy does not establish a universal automatic disclosure deadline for every vulnerability.

Hostwover and the researcher are encouraged to agree on a reasonable disclosure timeline based on the actual risk.

If there is credible evidence that a vulnerability is already being actively exploited, Hostwover and the researcher may need to coordinate an accelerated security response.

Publicly disclosing exploitable technical details without giving Hostwover a reasonable opportunity to address the vulnerability may fall outside the good-faith expectations of this Policy.

Researchers may discuss a vulnerability at a high level before remediation only where doing so does not materially increase risk and does not disclose exploit-enabling details.

Prior coordination with Hostwover is strongly encouraged.

Information obtained solely because of vulnerability research must not be publicly disclosed where it contains:

• Customer information.
• Personal Data.
• authentication credentials.
• internal secrets.
• proprietary source code.
• private infrastructure information; or
• other confidential data.

Hostwover determines whether and when affected Customers should be notified of a vulnerability or security incident, subject to applicable law and contractual obligations.

Researchers must not independently contact Customers using data obtained through the vulnerability.

Hostwover will handle any legally required:

• Personal Data Breach notifications.
• regulatory reports.
• law-enforcement notifications; or
• Customer notifications

through the appropriate Hostwover processes.

Hostwover does not guarantee that every vulnerability will receive a CVE identifier.

Where appropriate, Hostwover may coordinate with an applicable CVE Numbering Authority or relevant provider.

Where appropriate and with the researcher's permission, Hostwover may publicly acknowledge a researcher for a valid vulnerability report.

Potential recognition may include:

• name.
• pseudonym.
• organization.
• website.
• social profile; or
• another mutually agreed attribution.

Recognition is discretionary unless Hostwover expressly promises otherwise.

Researchers may request:

• anonymous recognition.
• pseudonymous recognition; or
• no public recognition.

This Responsible Disclosure Policy is not, by itself, a bug bounty program.

Submission of a vulnerability does not create an entitlement to:

• money.
• account credit.
• free Services.
• merchandise.
• employment.
• contractual compensation; or
• another reward.

Hostwover may introduce a separate Bug Bounty Program.

If such a program is introduced, eligibility, scope, rewards, and rules will be governed by the specific Bug Bounty Program terms.

Hostwover may choose to provide discretionary recognition or rewards for particularly valuable reports.

A discretionary reward:

• is not guaranteed.
• does not establish precedent.
• does not create entitlement for another report; and
• may be subject to verification and legal requirements.

If Hostwover offers a discretionary reward, factors may include:

• severity.
• originality.
• report quality.
• exploitability.
• Customer impact.
• remediation value.
• compliance with this Policy; and
• whether the issue was previously known.

Hostwover may refuse discretionary rewards where the researcher:

• violated this Policy.
• accessed unnecessary Customer data.
• caused Service disruption.
• publicly disclosed prematurely.
• used stolen credentials.
• threatened Hostwover.
• demanded payment as a condition of non-disclosure.
• exploited the issue for personal gain; or
• engaged in unlawful activity.

Threatening to:

• publish a vulnerability.
• sell Customer data.
• attack Hostwover.
• disclose stolen information; or
• cause operational harm

unless Hostwover pays money is not responsible disclosure and is not protected by this Policy.

Researchers must not sell, transfer, or provide unauthorized access to an unremediated Hostwover vulnerability to persons likely to misuse it.

This Policy does not authorize disclosure of unremediated vulnerabilities to third-party vulnerability brokers without Hostwover's consent where doing so may materially increase exploitation risk.

Hostwover supports good-faith security research performed in accordance with this Policy.

To the extent within Hostwover's control and permitted by applicable law, Hostwover will not initiate legal action against a researcher solely because of security research that Hostwover reasonably determines was conducted in good faith and in substantial compliance with this Policy.

Safe-harbor consideration requires that the researcher:

• acts in good faith.
• tests only authorized Hostwover-controlled assets.
• minimizes harm.
• avoids privacy violations.
• stops after demonstrating impact.
• does not exploit Customers.
• does not retain unnecessary data.
• reports the vulnerability promptly.
• coordinates disclosure.
• does not demand payment through threats; and
• complies with applicable law.

Hostwover may consider the totality of circumstances where a good-faith researcher unintentionally exceeds a minor technical boundary while reasonably attempting to comply with this Policy.

Researchers should:

• stop the activity.
• report what happened; and
• cooperate with Hostwover.

Safe-harbor expectations do not apply to conduct involving intentional:

• data theft.
• extortion.
• ransomware.
• malware deployment.
• Customer compromise.
• Service destruction.
• fraud.
• DDoS attacks.
• persistence.
• sale of stolen information; or
• other malicious activity.

Hostwover's safe-harbor statement applies only to actions within Hostwover's authority.

Hostwover cannot:

• authorize testing of systems it does not control.
• waive another party's legal rights.
• promise that a third party will not take legal action.
• bind law-enforcement authorities.
• override applicable law; or
• grant immunity from criminal or civil law.

An upstream infrastructure or service provider may maintain independent security-testing rules.

Researchers are responsible for ensuring that testing does not violate those rules.

Hostwover cannot waive a Customer's rights concerning unauthorized access to the Customer's systems or data.

This is one reason Customer-controlled assets are excluded from authorization under this Policy.

Researchers remain responsible for complying with applicable law.

Nothing in this Policy authorizes conduct that Hostwover lacks legal authority to permit.

Hostwover may process Personal Data provided by security researchers for purposes such as:

• responding to reports.
• communicating about vulnerabilities.
• assessing security issues.
• maintaining security records.
• recognizing researchers.
• preventing abuse.
• processing a discretionary reward; or
• satisfying legal obligations.

Researcher Personal Data will be handled according to applicable privacy requirements and the Hostwover Privacy Policy.

Hostwover may retain records relating to vulnerability reports, including:

• report content.
• reporter information.
• affected assets.
• severity.
• technical evidence.
• communications.
• remediation.
• testing.
• disclosure decisions; and
• case outcome.

Vulnerability records may be retained where reasonably necessary for:

• security.
• audit.
• recurrence detection.
• legal compliance.
• incident investigation.
• risk management; and
• documentation of remediation.

A researcher may request that their identity remain confidential.

Hostwover will consider reasonable confidentiality requests.

Hostwover cannot guarantee confidentiality where disclosure is legally required or reasonably necessary to investigate serious wrongdoing.

Hostwover may respond to valid legal requests in accordance with applicable law and the Hostwover Privacy & Data Protection Policy.

A vulnerability is not necessarily evidence that a security breach occurred.

If evidence indicates that unauthorized exploitation has occurred, Hostwover may open a separate security-incident investigation.

If a researcher observes evidence that another party is actively exploiting the vulnerability:

• stop further unnecessary testing.
• report the evidence immediately.
• do not engage the attacker.
• do not attempt vigilante remediation; and
• preserve only appropriate evidence.

Researchers must not independently modify Hostwover production systems in an attempt to "fix" a vulnerability unless Hostwover expressly requests and authorizes the action.

Discovery of a vulnerability does not provide continuing authorization to access the affected system after Hostwover asks the researcher to stop.

Hostwover may ask a researcher to temporarily stop specific testing where necessary because of:

• Service stability.
• Customer risk.
• incident response.
• legal concerns.
• provider restrictions; or
• ongoing remediation.

Good-faith researchers are expected to cooperate.

Testing a remediation should use the least intrusive method necessary.

Hostwover supports legitimate educational discussion of security concepts.

Researchers should distinguish general educational research from publication of actionable details concerning an unremediated Hostwover vulnerability.

Public screenshots or demonstrations must not reveal:

• Personal Data.
• Customer Content.
• access tokens.
• internal secrets.
• sensitive infrastructure details; or
• exploit-enabling information for an unresolved vulnerability.

After remediation and appropriate coordination, Hostwover may agree to publication of technical details.

The parties may coordinate:

• publication date.
• technical scope.
• attribution.
• advisory wording.
• CVE information; and
• remediation details.

Hostwover does not require every vulnerability reporter to sign a nondisclosure agreement merely to submit a report.

A separate confidentiality agreement may be requested in exceptional circumstances involving highly sensitive investigation or remediation work.

Submitting a vulnerability report does not create:

• employment.
• agency.
• partnership.
• contractor status.
• fiduciary relationship; or
• authority to act for Hostwover.

Researchers must not represent themselves as:

• Hostwover employees.
• Hostwover security staff.
• authorized penetration testers.
• Hostwover contractors; or
• Hostwover representatives

unless expressly authorized in writing.

Participation in this disclosure process does not authorize use of Hostwover trademarks or branding in a manner suggesting:

• sponsorship.
• employment.
• endorsement; or
• official partnership.

Researchers should accurately describe their relationship with Hostwover.

For example, receiving acknowledgment for a vulnerability does not mean that Hostwover has certified the researcher or their company.

Unless Hostwover expressly agrees otherwise in writing, researchers are responsible for their own:

• testing costs.
• Service purchases.
• internet costs.
• equipment.
• software.
• travel; and
• other research expenses.

Purchasing a Service solely for vulnerability research does not automatically make the Service refundable.

The Hostwover Refund Policy continues to apply.

Researchers who register domains for testing remain responsible for applicable domain-registration fees unless Hostwover expressly provides otherwise.

Researchers who provision VPS, VDS, hosting, or other Services for testing remain responsible for applicable charges unless Hostwover expressly authorizes a different arrangement.

Hostwover may add or remove assets from the authorized security-research scope.

Researchers should review the current version of this Policy before beginning a new testing session.

Hostwover may temporarily restrict security testing against a system where necessary because of:

• maintenance.
• security incidents.
• provider requirements.
• instability.
• Customer risk; or
• legal requirements.

Hostwover may update this Policy to reflect:

• new Services.
• new infrastructure.
• security developments.
• vulnerability-management practices.
• provider requirements.
• legal requirements; or
• operational improvements.

The Last Updated date identifies the current published version of this Policy.

Researchers should follow the current Policy when continuing testing after a material policy update unless Hostwover expressly agrees otherwise.

The Hostwover Acceptable Use Policy continues to apply to Hostwover Services.

Good-faith research within this Responsible Disclosure Policy may be treated differently from otherwise prohibited security activity only to the extent that the research is expressly authorized by this Policy.

Reports concerning active abuse should use the Abuse Handling process.

Examples include:

• phishing.
• malware.
• fraudulent Customer websites.
• spam.
• compromised servers; and
• DDoS activity.

Reports concerning vulnerabilities in Hostwover-controlled systems should use this Responsible Disclosure Policy.

Personal Data encountered during security research must be handled according to this Policy and applicable privacy requirements.

Hostwover's handling of researcher information is governed by its Privacy & Data Protection framework.

General technical or account-support requests should be submitted through ordinary Customer Support rather than the vulnerability disclosure process.

Hostwover may publish a standardized `security.txt` file providing current security-contact information and vulnerability-reporting instructions.

Where published, researchers should use the current security contact identified there.

Hostwover may later establish:

• a security portal.
• vulnerability disclosure platform.
• bug bounty platform.
• dedicated encrypted email channel; or
• another formal security-reporting system.

The specific program terms will govern where they differ from this general Policy.

Hostwover will make reasonable efforts to review credible security reports.

Hostwover does not guarantee that every report will result in:

• code changes.
• public disclosure.
• CVE assignment.
• financial reward.
• recognition; or
• a finding that the issue is a vulnerability.

Hostwover may assign a severity different from the researcher's suggested rating.

In some cases, Hostwover may determine that a reported issue presents an acceptable residual risk.

That decision does not mean the researcher acted improperly by reporting the issue.

Researchers may provide additional evidence if they disagree with Hostwover's evaluation.

Hostwover retains final responsibility for security decisions concerning Hostwover-controlled systems.

Researchers and Hostwover personnel should communicate professionally.

Threats, harassment, abusive flooding, or extortion may result in termination of communication and removal from discretionary recognition or reward consideration.

A statement such as "pay me or I publish/exploit the vulnerability" is inconsistent with responsible disclosure.

Researchers may ask whether a reward is available, but payment must not be demanded as a condition for avoiding harm.

Researchers participating under this Policy should follow these principles:

1. Test only systems you are authorized to test.
2. Use your own accounts and data.
3. Minimize impact.
4. Stop when vulnerability impact is demonstrated.
5. Do not access Customer data intentionally.
6. Do not cause Service disruption.
7. Do not establish persistence.
8. Do not deploy malware.
9. Do not socially engineer personnel.
10. Do not attack third parties.
11. Report vulnerabilities privately and promptly.
12. Protect information obtained during research.
13. Coordinate public disclosure.
14. Delete unnecessary vulnerability-related data after it is no longer required.
15. Comply with applicable law.

When a researcher submits a credible report in good faith, Hostwover seeks to:

1. provide a reasonable vulnerability-reporting channel.
2. review the report.
3. assess the potential security impact.
4. communicate where practical.
5. protect the researcher's information appropriately.
6. prioritize serious vulnerabilities.
7. implement reasonable mitigation or remediation where appropriate.
8. coordinate disclosure where necessary.
9. consider recognition for useful reports; and
10. treat compliant good-faith research according to the safe-harbor principles in this Policy.

To report a suspected security vulnerability:

Hostwover Security / Support

Email: [email protected]

Website: hostwover.com

Use the subject:

Security Vulnerability Report – [Short Description]

Include:

• affected Hostwover system.
• vulnerability type.
• clear reproduction steps.
• proof of concept where appropriate.
• security impact.
• your contact information; and
• any disclosure considerations.

Do not include unnecessary:

• Customer Personal Data.
• database dumps.
• passwords.
• private keys.
• full payment-card information; or
• unrelated confidential information.

If you encounter evidence of an actively exploited critical vulnerability, clearly identify the report as:

URGENT SECURITY VULNERABILITY

Hostwover may establish a dedicated security address such as:

[email protected]

Once published as an official Hostwover security contact, that address should be used for vulnerability disclosure instead of the general support address.

This Responsible Disclosure Policy becomes effective on the date shown above and applies to security research performed against Hostwover systems covered by this Policy.

END OF RESPONSIBLE DISCLOSURE POLICY