Vulnerability Disclosure Policy

Heidi Health Pty Ltd

Vulnerability Disclosure Policy

Version: 1.0 Date: March 2026 Owner: Legal & Compliance

Heidi Health Pty Ltd (ACN 649 783 871) ("Heidi Health", "we", "us") welcomes the responsible disclosure of security vulnerabilities in our products and services. This policy sets out how to report a vulnerability, what you can expect from us, and the basis on which any discretionary bounty payment may be made.

This policy does not constitute an offer of employment, an engagement agreement, or any ongoing commercial arrangement.

1. Scope

The following are in scope for responsible disclosure:

• Authentication and authorisation vulnerabilities affecting Heidi Health web and mobile applications
• Data exposure or unauthorised access to patient or user records
• Insecure Direct Object Reference (IDOR) allowing unauthorised access, modification, or deletion of user or patient data.
• Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) vulnerabilities with demonstrable impact.
• Server-side injection vulnerabilities (SQL, command, SSRF, etc.)
• Prompt injection or AI model manipulation vulnerabilities in Heidi Health AI features
• AI persistence such as inputs, or retrieval that allows unauthorized modification or corruption of contextual dataleading to persistent misgeneration.
• Cryptographic weaknesses or insecure data transmission
• Insecure server or cloud storage configurations that lead to the exposure of sensitive data.
• Any vulnerability that could reasonably result in significant harm to users, patients, or Heidi Health systems

The following are out of scope:

• Denial of service (DoS/DDoS) attacks
• Social engineering or phishing of Heidi Health employees
• Physical security vulnerabilities
• Vulnerabilities in third-party services not under our control
• Issues in software versions that are explicitly end-of-life
• Automated scanning without prior written approval
• Missing security headers, unless an exploitable impact can be demonstrated.
• Self-XSS (Cross-Site Scripting that cannot affect other users), or vulnerabilities requiring unlikely user interaction.
• General enumeration of user IDs or resource identifiers where no data is accessed or compromised.
• Any testing conducted on live patient data or production systems without explicit written permission

2. How to Report

To report a vulnerability, please email security@heidihealth.com with the subject line "Responsible Disclosure" and include:

1. A clear description of the vulnerability, including the type of issue
2. The affected product, service, or endpoint
3. Step-by-step instructions to reproduce the issue
4. Your assessment of the potential impact
5. Any supporting materials such as screenshots, proof-of-concept code, or HTTP request/response captures

Please do not include actual patient data, credentials, or any other sensitive personal information in your report. Submit only the minimum information necessary to demonstrate the vulnerability.

3. Safe Harbour

Heidi Health will not pursue civil or criminal action, and will not refer matters to law enforcement, against any individual who:

• Reports a vulnerability in good faith and in compliance with this policy
• Does not access, modify, destroy, or exfiltrate data beyond what is strictly necessary to demonstrate the vulnerability
• Does not disrupt our services, degrade system performance, or affect other users
• Does not publicly disclose the vulnerability before we have had a reasonable opportunity to investigate and remediate (see Section 4 below)
• Acts in accordance with all applicable laws

This safe harbour does not extend to conduct that falls outside these parameters, or to any criminal offences under applicable law.

4. Coordinated Disclosure

We ask that you observe a coordinated disclosure period and not publicly disclose details of any reported vulnerability until:

• Heidi Health has confirmed receipt of your report and completed an initial triage (we aim to do this within 5 business days); and
• A reasonable remediation timeline has been agreed between you and Heidi Health, which will not exceed 90 days from the date of confirmed receipt, unless we jointly agree to an extension.

If we fail to respond within 5 business days of receiving your report, you may proceed with public disclosure after giving us a further 5 business days’ written notice.

5. Discretionary Bounty Payments

5.1 Discretionary Nature

Heidi Health operates a pay-at-our-discretion model rather than a formal bug bounty program. Any payment made in recognition of a vulnerability report is entirely at Heidi Health’s sole discretion. We are under no obligation to make any payment, and no payment obligation arises from the submission of a report or from this policy.

5.2 Eligibility Criteria

To be eligible for consideration of a discretionary payment, you must:

• Have reported the vulnerability in accordance with this policy
• Be the first person to have reported the specific vulnerability to us
• Not be a current or former employee, contractor, or director of Heidi Health or any of its subsidiaries or related entities
• Not be located in, or a resident or national of, a country or territory that is subject to applicable sanctions, including those administered by the Australian Department of Foreign Affairs and Trade (DFAT), the United States Office of Foreign Assets Control (OFAC), the United Nations Security Council, or the European Union
• Not be a person or entity designated on any applicable sanctions list or on any financial intelligence watchlist
• Be able to lawfully receive a payment from Heidi Health under applicable laws in your jurisdiction
• Have successfully completed Heidi Health’s identity verification and compliance process

Heidi Health reserves the right to withhold or withdraw any discretionary payment at any time if it is unable to verify that a recipient meets the eligibility criteria, including if identity verification or compliance screening cannot be completed to Heidi Health's satisfaction.

5.3 Payment Amount

Any discretionary payment will be determined by Heidi Health at its sole discretion, taking into account factors including the severity and impact of the vulnerability, the quality and completeness of the report, and the accuracy of any proof of concept. Payment amounts are not published and Heidi Health makes no representation as to the value of any potential payment.

5.4 Payment Process

If Heidi Health determines that a discretionary payment is appropriate, we will contact you to initiate the payment process. This will require you to:

• Complete and sign a Discretionary Payment and Release Agreement
• Provide government-issued photo identification
• Pass applicable sanctions screening and AML/KYC checks
• Provide valid payment details for an account in your own name

Payments will be processed via Airwallex or such other payment method as Heidi Health nominates.

6. No Ongoing Relationship

This policy and any payment made under it do not create, and must not be construed as creating, any employment relationship, contractor relationship, agency, partnership, or other ongoing commercial or legal relationship between you and Heidi Health. You acknowledge that you have no entitlement to any further payments, work, or engagement with Heidi Health.

7. Governing Law

This policy is governed by the laws of Victoria, Australia. Any disputes arising in connection with this policy will be subject to the exclusive jurisdiction of the courts of Victoria.

8. Policy Updates

Heidi Health may update this policy from time to time. The version published on our website at the time of your report is the version that applies to that report.

Security Testing Guidelines

Heidi Health Pty LtdFor Security ResearchersLast updated: 25 March 2026Contact: security@heidihealth.com

These guidelines supplement our Vulnerability Disclosure Policy. They explain what you can and cannot do when testing Heidi Health systems, and clarify the specific conditions under which our safe harbour applies. Reading both documents before you begin is strongly encouraged.

If anything is unclear, email us before testing. We'd rather answer a question than investigate an incident.

Testing Environments

Always test against your own account in the production environment, or request access to a dedicated test environment.

To request a test environment or explicit permission for a specific test, email security@heidihealth.com with a brief description of what you intend to test.

What You May Do

The following activities are permitted within your own account and within the in-scope system boundaries described in the VDP:

• Manual testing of authentication flows, session management, and access control
• Inspecting API requests and responses using a proxy (Burp Suite, OWASP ZAP, etc.) to identify misconfigurations or data leakage
• Testing input validation on your own account's data, including attempting injection payloads in fields you control (text inputs, file uploads, API parameters)
• Testing for IDOR vulnerabilities by manipulating resource identifiers (IDs, GUIDs, etc.), but only confirming the issue exists; do not access or download data belonging to other users’ account(s)
• Testing authorisation controls by attempting to access resources your account should not be able to reach. Stop as soon as you confirm the issue without reading the underlying data
• Testing AI/LLM features for prompt injection, jailbreaking, or model manipulation within your own session (see AI-Specific Testing below)
• Reviewing client-side code (JavaScript, mobile app binaries) for hardcoded credentials, insecure storage, or logic flaws
• Testing for cryptographic issues (e.g. weak TLS configuration, insecure cookie attributes) using passive observation of your own traffic
• Creating test accounts using a clearly identified email address (e.g. security-researcher+test@yourdomain.com) to avoid ambiguity

What You May Not Do

The following activities are not permitted under any circumstances and fall outside the safe harbour:

• Automated or scripted scanning of any Heidi Health system without prior written approval. This includes vulnerability scanners (Nessus, Nuclei, nikto, sqlmap in automated mode, etc.)
• Accessing, downloading, or retaining data belonging to any other user, patient, or organisation, even if access is technically possible
• Modifying, deleting, or corrupting any data or system state, including your own account data if doing so could affect system integrity
• Disrupting service availability including any test that degrades performance, exhausts resources, or affects other users (no DoS/DDoS, no resource exhaustion loops, no large-scale enumeration)
• Testing on accounts you do not own without the account holder's explicit written consent
• Social engineering Heidi Health employees or contractors
• Exploiting a vulnerability beyond what is necessary to confirm it exists. If you can demonstrate the issue with a single low-impact request, stop there, and clearly explain mechanisms of exploitation thereafter.
• Exfiltrating or storing sensitive data encountered during testing. If you access data you should not have access to, whether inadvertently or as a result of testing, stop immediately, do not save or copy it, and report it to us
• Testing third-party integrations (e.g. identity providers, payment processors, partner APIs). Vulnerabilities in third-party systems should be reported directly to that vendor
• Using automated tools to brute-force credentials, API keys, tokens, or resource identifiers

Limitations on Evidence Collection

When documenting a vulnerability, collect only what is necessary to demonstrate that the issue exists.

Acceptable evidence:

• A single API request/response showing the vulnerability
• A screenshot showing that an unexpected resource is accessible (blur or truncate any personal data visible)
• Proof-of-concept code that demonstrates the vulnerability class without extracting real data
• A short video demonstrating the steps to reproduce, where other users' data is redacted

Not acceptable:

• Bulk exports or enumerated lists of user or patient records
• Copies of database contents, session tokens, or credentials belonging to others
• Logs or data retained beyond what is needed to write the report
• Any evidence involving real patient clinical data

If in doubt: the minimum is enough. You do not need to prove scale. Telling us "I can access any user's record via this IDOR" is sufficient. You do not need to prove it by downloading a thousand records.

AI-Specific Testing

Heidi Health's products incorporate large language model (LLM) features. We treat AI vulnerabilities as first-class security issues. The following guidance applies:

Permitted:

• Testing for prompt injection by attempting to override system instructions or alter model behaviour through user-controlled inputs within your own session
• Testing whether the model can be manipulated into disclosing system prompts, configuration, or internal instructions
• Testing for Retrieval-Augmented Generation (RAG) poisoning or input injection that affects the integrity or relevance of data retrieved from the knowledge base.
• Testing for data leakage including whether the model can be induced to reveal information about other users that has been included in its context, but only in cases where you can guarantee that you adhere to safety mechanisms for handling sensitive data
• Testing insecure output handling, such as whether model outputs are rendered in a way that enables XSS or other downstream attacks
• Reporting model jailbreaks that could allow policy-violating outputs in a clinical context

Not permitted:

• Using AI feature access to attempt to extract data about real patients or real clinical notes
• Attempting to use model outputs to pivot into backend infrastructure
• Automated or high-volume prompting intended to enumerate system behaviour or exhaust model quotas

When reporting AI vulnerabilities, include the exact prompt sequence used and the model's response. Describe the potential harm in a clinical context (e.g. "a clinician could be misled into prescribing based on fabricated output").

Safe Harbour: Specific Conditions

Our safe harbour in the Vulnerability Disclosure Policy applies when all of the following conditions are met:

The safe harbour does not apply if you:

• Continue testing after being asked to stop
• Access systems or data beyond what is in scope
• Test without a genuine intent to report the vulnerability
• Demand payment before disclosing, or threaten disclosure to extract a payment
• Share vulnerability details with third parties before coordinated disclosure is complete

Severity Reference

We assess vulnerability severity using a combination of CVSS scoring and clinical impact. When writing your report, consider the following:

Including your own severity assessment in your report helps us prioritise and is always appreciated, even if our assessment differs.

Frequently Asked Questions

Can I test while logged in as myself on the production app? Yes, but only within your own account(s) and within the permitted activities listed above. We ask that you use a test account (not your primary account) where possible.

Do I need permission before I start testing? Not for manual testing within your own account. You do need written approval before running automated scanners or testing against any environment other than production/your own account.

What if I accidentally access data I shouldn't have? Stop immediately. Do not save, copy, or share it. Tell us in your report. We will not hold this against you if you acted in good faith and report it promptly.

What if I find a vulnerability in a third-party service Heidi uses? Report it to that vendor directly. You're welcome to mention it to us so we're aware, but we cannot offer safe harbour or payments for third-party issues.

Can I publish a write-up after disclosure? Yes, once the vulnerability has been remediated and we have notified you, you are welcome to publish a write-up. We ask that you give us a chance to review it before publication to ensure no sensitive information remains and the representations are accurate.

Questions? Email security@heidihealth.com. We aim to respond within 2 business days.