KOHO

Introduction

KOHO is a Canadian fintech company rooted in the belief that a better banking alternative exists. Our bug bounty program will allow researchers to help us improve our security for our customers to enable that better banking experience. We look forward to working with you through this program!

Positive Hacker Signal required

Due to the increase in spam and N/A report submissions coming from program participants that have a negative Signal score, we are prohibiting anyone from participating in this program if they have a Signal score at or under 0. Any reports submitted by those with a negative score will be immediately closed as Spam and then locked. We reserve the right to report the author for abuse and block them from the KOHO bug bounty program.

Response Targets

We'll try to stay within our stated SLAs and keep you informed about our progress throughout the process. We will endeavour to achieve resolution for bugs within 30 days of reporting, but may need more time to fix the issues. We'll let you know if we require more time.

Disclosure Policy

Please refrain from discussing vulnerabilities in this program without express consent from a member of the KOHO program team.

Follow HackerOne's https://www.hackerone.com/disclosure-guidelines.

Communication Policy

• All communication regarding vulnerability reports must occur exclusively through the HackerOne platform.
• Do not contact KOHO employees, executives, or official KOHO accounts through any external channels (including but not limited to social media, direct email, LinkedIn, or other messaging platforms) regarding bug bounty submissions or program-related matters.
• If you experience issues with the HackerOne platform itself, you may contact [email protected] with "HackerOne" in the subject line, but only for HackerOne platform access issues—not to discuss report status, bounty amounts, or dispute resolutions.
• Attempting to escalate or expedite reports through external channels is considered a violation of this policy.

Any participant who contacts KOHO through external channels regarding their submission will forfeit their eligibility for a bounty award on that report and may be banned from the program.

Professional Conduct

All interactions with the KOHO security team must be professional and respectful.

We are committed to treating all researchers fairly and with respect, and we expect the same in return. The following behaviours are strictly prohibited:

• Abusive, threatening, or harassing language
• Personal attacks or insults directed at KOHO employees
• Threats to publicly disclose vulnerabilities as leverage for higher bounties or faster resolution
• Demands or ultimatums regarding bounty amounts or report timelines
• Any form of intimidation or coercion
• Repeated messaging after being asked to wait for a response

We understand that disagreements may arise regarding severity assessments or bounty amounts. We welcome constructive discussion and are happy to explain our reasoning. However, disagreement does not justify unprofessional behaviour.

Violations of this policy will result in immediate forfeiture of bounty eligibility for the associated report. Severe or repeated violations will result in a permanent ban from the KOHO bug bounty program and may be reported to HackerOne for further action.

Some Geographic Restrictions Apply

Performing any authenticated testing on the KOHO application requires you to be a Canadian resident eligible to open a KOHO account. Due to our status as a financial technology company, any customer or user of the KOHO application requires passing the Know Your Customer (KYC) laws, which can only be passed by Canadian citizens at this time. We are looking at ways around this geographic restriction but, at the moment, this means non-Canadian residents can only test in-scope assets other than the KOHO mobile or web application.

Program Rules

• Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
• Submit one vulnerability per-report, unless you need to chain vulnerabilities to provide impact.
• When duplicates occur, we award the first report received that contains sufficient detail to reproduce the issue. If your report is marked as duplicate, we will provide the original report ID and submission date upon request. Findings listed under "Known issues" below have already been reported to us; new reports of them are closed as Duplicate without a bounty, even when the new write-up is more complete than the original.
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• Social engineering (e.g. phishing, vishing, smishing) is prohibited.
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.
• Use the User Agent "HackerOne: username" when testing against our systems in order for us to distinguish your testing efforts against legitimate attacks (where username should be replaced with your HackerOne username).
• Our normal working hours at KOHO are between 8AM and 6PM EST. If you're going to do testing on our systems that might trigger alarms on our end, we'd truly appreciate it if you did so during business hours. Not a requirement - just helps us sleep at night :)
• No request floods (TCP, HTTP, etc) on any endpoints.
• Current and former KOHO employees and contractors are not eligible for bounty awards from this program.
• Do not sell, transfer, or disclose vulnerability details to any third party without KOHO's written consent.

Scope

Please refer to the Scope tab for the domain assets in scope. Anything not listed as In Scope is considered out of scope and not permitted for testing.

The following classes of vulnerabilities would be interesting to us and will generally have us up the criticality of a bug:

• Any vulnerability that would allow you to create a KOHO account and send transactions by bypassing our KYC protocols;
• Any vulnerability that would allow modifications to the balance of a KOHO account that are unintended (e.g. achieving a negative balance and being able to continue purchasing despite);
• Vulnerabilities that allow for user spoofing/account takeovers.

Out of scope vulnerabilities

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:

• Clickjacking on pages with no sensitive actions
• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
• Attacks requiring MITM or physical access to a user's device.
• Previously known vulnerable libraries without a working Proof of Concept.
• Comma Separated Values (CSV) injection without demonstrating a vulnerability.
• Missing best practices in SSL/TLS configuration.
• Any activity that could lead to the disruption of our service (DoS).
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
• Rate limiting or bruteforce issues on any endpoints
• Missing best practices in Content Security Policy.
• Missing HttpOnly or Secure flags on cookies
• Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc.)
• Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).
• Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis.
• Tabnabbing
• Open redirect - unless an additional security impact can be demonstrated
• Issues that require unlikely user interaction
• Credential stuffing
• Self-XSS (XSS that only affects the user performing the action)
• Logout CSRF
• Account enumeration via login/registration/password reset pages (unless demonstrably exploitable)
• Theoretical vulnerabilities without working proof of concept
• Vulnerabilities requiring root/jailbreak on mobile devices
• Automated scanner output without manual validation

Known Issues / Out-of-Scope (Not Security Vulnerabilities)

To help you spend your time on findings we can actually reward, this section documents the report patterns we receive most often that are not security vulnerabilities. Please review it before submitting. Reports that fall squarely into the categories below will generally be closed as Not Applicable or Informative without a bounty.

We group these into three distinct categories:

• Out of scope: behaviour that is intended, or a class of issue we do not reward.
• False positives: findings that can look like a vulnerability but demonstrate no security impact.
• Known issues: specific things we are already aware of and track.

Out of scope (won't reward)

Business logic presented as a security vulnerability. The following are intentional product and compliance decisions, not vulnerabilities:

• Geographic / residency restrictions. KOHO serves Canadian residents only (see "Some Geographic Restrictions Apply"). Validation that rejects non-Canadian addresses, phone numbers, or identity documents — or that otherwise enforces our Know Your Customer (KYC) requirements — is intentional and is not a vulnerability.
• Disposable / temporary email addresses. Whether we accept or reject disposable or temporary email addresses is a product decision. It is not a vulnerability unless you can demonstrate that it enables a specific attack (e.g., authentication bypass or account takeover).
• Account-management issues. Profile settings, password resets, closing an account, and account-access or transaction-dispute requests are handled by Customer Support, not through this program. Please direct these to [email protected]; they will not be rewarded as security reports.
• Phone-number verification ordering during registration. We ask for a phone number during sign-up, but completing SMS verification is intentionally not a prerequisite for creating an identity, receiving a session token, or reaching the pre-KYC dashboard. Every action that actually depends on a verified phone number is enforced server-side on that action. Reports that an unverified account can "still log in", "still reach the dashboard", or "still call the API" describe this design and will be closed as Informative, unless you demonstrate reaching a verification-gated action (for example, moving money) without the verification credential.
• Second-factor (2SV / MFA) requirements that differ between surfaces. Our web, mobile, and pre-registration ("identity-only") login flows apply different second-factor rules. This difference is a known, accepted business position that we are narrowing over time. Reporting that one surface prompts for 2SV and another does not is not a vulnerability. A genuine bypass must show a second factor being skipped on a surface that requires it, for an account that has one enrolled.
• Public money-request pages. A KOHO money-request link is designed to be shared. The request page, and the unauthenticated API it calls, deliberately show the requester's name, the amount, the e-Transfer address, and the e-Transfer security question and answer to anyone holding the request code. The "answer" is an inbound load code: knowing it only lets someone send funds to the requester, never claim or redirect them. Reports that this data is reachable with a request code will be closed as Informative.

Vague open redirects. Open redirects are already out of scope unless you can demonstrate additional security impact (see "Out of scope vulnerabilities" above). When you can demonstrate that impact, your report must include the specific URL, the vulnerable parameter, the payload used, and proof of the redirect to an external domain. Generic claims — e.g., "I found an open redirect on your site" — will be closed as Not Applicable.

Spam, low-quality, and unvalidated scanner output. Raw output from automated scanners or AI-assisted tools, pasted without manual validation, reproduction steps, or a demonstrated security impact, is not eligible. Test submissions, template or placeholder text, and reports lacking technical substance will be closed, and may result in account restrictions. See also "Positive Hacker Signal required" and "Program Rules."

False positives (looks like a vuln but isn't)

Client-side response manipulation. Modifying a server response, hidden field, JavaScript variable, or the DOM in your own browser using Burp Suite, your browser's developer tools, or a proxy — and then observing a "changed" price, balance, role, flag, or restriction — is not a vulnerability. A common example is changing an HTTP 403 to a 200 in a proxy to "bypass" a restriction: this alters only what your own browser displays and is never trusted or persisted by our backend. To qualify, you must demonstrate that the server itself accepts and acts on the manipulated request (for example, a change that persists to your account or affects another user). Screenshots of edited responses, without corresponding server-side impact, will be closed as Informative.

Client-side third-party SDK keys. Our web and mobile apps embed keys for third-party SDKs, as their vendors require — for example LaunchDarkly client-side IDs and secure-mode hashes, Kustomer org.tracking keys, and Firebase, Braze, Segment or similar publishable keys. Finding one of these in a JavaScript bundle or APK, or showing that the vendor's API accepts it, is not a vulnerability on its own: the key is designed to be public and is scoped by the vendor for client-side use. A report qualifies only when you demonstrate concrete impact the key should not permit — reading customer or KOHO-internal records, or writing to data the client-side role should not reach. We have paid for exactly that kind of report before; "the key exists and the API returns 200" will be closed as Informative.

Custom-scheme deep links on mobile. The koho:// scheme is used for in-app navigation and carries no tokens or personal data; another app registering the same scheme can at most send the user to an unintended screen. Reports that this scheme is hijackable are not vulnerabilities. For authentication callback schemes, a report must demonstrate the full chain — interception of a victim's authorization code and a successful exchange for a working KOHO session — not merely that a scheme can be registered or that a request is accepted.

Local-app-only display issues on mobile. Issues that require a malicious application already installed on the victim's device, and whose only outcome is something that device's user sees — a spoofed notification under our branding, an unintended screen, an intent that leads nowhere new — are hardening observations, not vulnerabilities. Exported components that let another app read data from KOHO's private storage, or trigger a server-side action, are in scope: show the data or the action.

Known issues (specific findings we already track)

Vendor-hosted / third-party subdomains. Some KOHO subdomains (for example, roadmap.koho.ca ) are CNAME'd to and hosted by third-party service providers rather than KOHO-controlled infrastructure. These DNS records and the vendor-hosted content they point to are intentional and configured as expected. Simply discovering such a subdomain, reporting that it points to a third party, or filing a generic "possible subdomain takeover" with no demonstrated takeover, describes a known, accepted configuration and is not a vulnerability. If you can demonstrate an actual takeover — serving content you control from one of these hostnames — we absolutely want to hear about it; please include a full proof of concept.

Sanity CMS token in www.koho.ca JavaScript. The marketing site's JavaScript bundles include a hard-coded Sanity content-management token. This was first reported to us in May 2024, was paid, and is tracked internally with remediation in progress. It is by far our most re-reported finding. New reports of this token — or of the datasets, documents, or project members it can read — will be closed as Duplicate without a bounty, regardless of write-up quality.

LaunchDarkly secure-mode hash endpoint. GET /1.0/users/users/{ref}/flags/hash on api.koho.ca is intentionally unauthenticated so that feature flags can be evaluated before a user logs in, and it returns a LaunchDarkly secure-mode hash for whatever key is supplied. That hash is not a credential: it cannot read account data, impersonate a user to our support channel, or change anything server-side. We are aware that it also accepts registered users' references and plan to tighten that path; until then, reports of this endpoint will be closed as Duplicate or Informative.

Exported CropImageActivity in the Android app (ca.koho). Reported and paid in September 2026, tracked internally, and being fixed. Further reports of this activity — including variations on which image or file can be reached through it — are duplicates.

Non-production identifiers in app-association files. Our assetlinks.json and apple-app-site-association files list QA and staging application identifiers alongside production ones. This is known and being tidied. Without possession of the matching signing certificate, reports about these entries are theoretical (see "Theoretical vulnerabilities without working proof of concept").

Report Quality Requirements

To keep triage efficient and fair to everyone, all reports must meet these minimum standards. Reports that do not will be closed as Not Applicable or Informative.

Every report must include:

• The specific affected asset — an exact URL, endpoint, or component.
• Clear, reliable reproduction steps our security team can follow.
• A proof of concept demonstrating the issue on our production environment.
• An explanation of the realistic security impact.

We will not accept:

• Generic automated scanner or AI-tool output without manual validation.
• Template or placeholder text with no actual vulnerability details (e.g. "testtttt", default template language).
• Reports under 100 characters, or otherwise lacking technical substance.
• Off-topic submissions unrelated to security.
• Test submissions — please use HackerOne's "Submit Test Report" feature instead.

Spam or low-quality submissions may result in account restrictions or a ban (see also "Positive Hacker Signal required").

Pre-Submission Checklist

Before you submit, please confirm:

• I tested this on the live production environment (not staging or dev; unless given explicit permission).
• This affects the backend/server, not just what I see in my own browser.
• I have specific URLs, endpoints, or parameters — not a generic description.
• I can reproduce this reliably, with clear step-by-step instructions.
• This is a security vulnerability — not a customer-support request, feature request, usability concern, or a business-logic decision I disagree with.
• I have reviewed the "Out of scope vulnerabilities" and "Known Issues / Out-of-Scope" sections, and this is not listed there.
• I have checked for existing duplicates of this issue, including the "Known issues" list above — those findings are already reported and new reports of them are closed as Duplicate.

Vulnerability-Specific Submission Guidance

Some vulnerability classes are frequently reported without enough detail for us to act on. For these, please include the following.

Open redirect (CWE-601). Open redirects are out of scope unless an additional security impact can be demonstrated (see "Out of scope vulnerabilities"). When you report one, include:

• The exact vulnerable URL.
• The specific parameter being exploited.
• The complete payload used.
• A screenshot or video showing the redirect to an external domain.
• The HTTP request and response showing the Location header.

Illustrative format:

URL:       https://<in-scope-host>/login
Parameter: next
Payload:   https://<in-scope-host>/login?next=//evil.example
Result:    Redirects to https://evil.example

Not acceptable: "I found an open redirect on your site. It's on the login page."

Client-side vs. server-side. Modifying responses in Burp Suite, browser DevTools, or another proxy is not a vulnerability unless you can prove the backend is affected (see "Known Issues / Out-of-Scope"). Your report must show the server's actual response to the manipulated request, proving server-side enforcement was bypassed.

• Not valid: changing an HTTP 403 to 200 in a proxy to bypass a front-end restriction.
• Not valid: editing JavaScript in DevTools to display different content.
• Valid: demonstrating that the server accepts invalid data — or grants access it should not — when the manipulated request is actually sent.

Authentication / authorization bypass. If you report a bypass, demonstrate:

• The specific protection mechanism being bypassed.
• A server-side enforcement failure (not just a client-side change).
• The unauthorized access actually granted by the backend.
• The specific data or functionality reached without proper authorization.

Valid vs. Invalid Report Examples

Example of a valid report

Title: IDOR on /api/v1/transactions allows viewing other users' transactions Description: The endpoint accepts a user_id parameter that is not properly validated, allowing any authenticated user to view another user's transaction history. Steps to reproduce:

1. Log in as User A (user_id: 12345).
2. Capture the request GET /api/v1/transactions?user_id=12345.
3. Change user_id to 67890 (User B).
4. Observe that User B's transactions are returned.

Impact: Any authenticated user can view another KOHO user's full transaction history — amounts, merchants, and dates. Proof: HTTP request/response showing User A accessing User B's data.

Examples of invalid reports

Communication & Timeline Expectations

Responding to our requests. If we request additional information (a "Needs More Info" reply), please respond within 7 calendar days. If we do not hear back within that window, we may close the report as Not Applicable. You're welcome to submit a new report if you obtain the missing detail later.

When you respond, please:

• Provide specific technical details, not general descriptions.
• Include any new evidence — screenshots, video, or the relevant HTTP requests and responses.
• Answer each question we asked.
• Let us know if you can no longer reproduce the issue.

Researcher Acknowledgement

With your permission, we may acknowledge your contribution on our security acknowledgements page.

Thank you for helping keep KOHO and our users safe!