Report security concerns without creating more risk.

KOMERRA welcomes good-faith security research that helps protect businesses, customers, Authorized Users, providers, and the wider platform.

This Policy explains which systems may be tested, the conduct KOMERRA authorizes, the safeguards researchers must follow, how reports should be submitted, what researchers can expect from KOMERRA, and how coordinated disclosure should be handled.

The objective is to make it easy to report a genuine security weakness without creating additional privacy, financial, operational, or safety risk.

This Policy does not create permission to access another person’s Account, copy private information, disrupt production, test third-party systems, or perform conduct prohibited by applicable law.

This Policy should be read together with the KOMERRA Security & Trust page, Acceptable Use Policy, Privacy Policy, Responsible AI framework, Terms of Service, and any written testing authorization issued by KOMERRA.

KOMERRA is operated by KOMERRA Technologies Limited, a company registered in the Federal Republic of Nigeria with registration number 9681120.

Security reports should be sent to security@komerra.app.

Use “Security Report” in the subject and avoid sending sensitive evidence through ordinary email unless the information is already appropriately minimized and protected.

Questions about whether intended research is permitted should be sent before testing goes further.

“Researcher” means a person who investigates and reports a suspected security vulnerability in good faith.

“Vulnerability” means a weakness that may compromise the confidentiality, integrity, availability, authorization, privacy, financial integrity, or intended security behaviour of an in-scope KOMERRA system.

“Good-faith research” means testing performed primarily to identify, understand, report, and support correction of a security weakness while taking reasonable steps to avoid harm.

“In-scope asset” means a KOMERRA-owned or KOMERRA-controlled production service expressly covered by this Policy.

“Sensitive data” includes credentials, authentication tokens, private keys, financial information, identity information, customer records, private files, messages, security configuration, and tenant-scoped Business Content.

“Coordinated disclosure” means confidential collaboration between the researcher and KOMERRA before technical details are publicly disclosed.

“Minimal proof of concept” means the least intrusive evidence reasonably necessary to demonstrate that the suspected vulnerability exists.

Send vulnerability reports to security@komerra.app.

The report should be submitted from an email address through which the researcher can receive questions and status updates.

Do not send reports to individual employees, public social-media accounts, customer-support comments, Mini Stores, Trust Passports, or public issue trackers where sensitive details could be exposed.

Where the evidence is too sensitive for ordinary email, request a secure transfer method before sending the evidence.

A report is considered received for response-target purposes when it reaches the designated security channel with enough information to begin a meaningful review.

This Policy is intended for reporting security vulnerabilities and accidental exposure of protected information.

An active Account takeover, ongoing fraud event, lost device, suspicious payment, abusive user, inaccessible Account, or ordinary service outage may require immediate operational support rather than vulnerability research.

Where the matter concerns an active security incident affecting your own Account, state clearly that immediate protective action may be required.

Where the issue concerns a payment or Credit purchase rather than a platform vulnerability, use the payment-review process described in the Refund and Cancellation Policy.

General product defects, feature requests, accessibility problems, and customer-service questions should use their appropriate support channels.

Research is considered good faith where it is conducted primarily to improve security, uses proportionate methods, remains within the authorized scope, and is designed to avoid harm to people and services.

Good-faith researchers stop when testing would require access to another person’s information, destruction or alteration of data, persistence, disruption, financial impact, or a material expansion beyond the confirmed vulnerability.

Researchers must use information obtained during testing only to understand, report, and support remediation of the vulnerability.

Research performed for extortion, intimidation, commercial leverage, harassment, data collection, competitive advantage, resale, or exploitation is not good-faith research.

To the extent KOMERRA has authority to grant permission, KOMERRA authorizes good-faith research against the in-scope assets when the researcher follows this Policy.

The authorization is limited to the minimum testing reasonably necessary to identify and demonstrate a suspected vulnerability.

Authorization does not extend to third-party infrastructure, another customer’s Account, another Workspace, unrelated systems, employee devices, physical premises, or provider services outside KOMERRA’s control.

Authorization ends when KOMERRA gives the researcher an unambiguous instruction to stop or materially limit the testing.

Researchers who are uncertain whether an activity is authorized should ask security@komerra.app before continuing.

The following categories are generally in scope where they are owned or controlled by KOMERRA and form part of the production service.

The fact that a hostname, IP address, provider resource, repository, mobile package, or service appears related to KOMERRA does not automatically make it in scope.

Researchers should confirm ownership and authorization before testing an asset that is not clearly operated through the principal KOMERRA production environment.

A security.txt file applies according to the domain and scope defined by that file and this Policy.

Written authorization issued by KOMERRA for a particular assessment may expand or narrow this public scope.

Where this Policy and a written testing agreement conflict, the written agreement governs the specific authorized engagement.

Testing must be limited to Accounts, Workspaces, records, files, integrations, payment test resources, and data that the researcher owns or has explicit written permission to test.

Create clearly identifiable research Accounts where registration and the applicable terms permit it.

Do not use stolen, purchased, leaked, guessed, shared, or unrelated credentials.

Do not invite an unsuspecting person into a test Workspace or use a customer’s genuine information as test data.

Synthetic or harmless test data should be used wherever possible.

If testing unexpectedly reveals another person’s private information, stop accessing the affected function immediately.

Do not browse, search, enumerate, download, export, screenshot, copy, retain, or disclose more information than is strictly necessary to show that unauthorized exposure occurred.

Record the minimum safe evidence, such as the affected route, time, request identifier, response category, and a redacted example.

Do not contact the affected customer, business, staff member, or provider directly unless KOMERRA asks you to do so or immediate action is required by law.

Notify KOMERRA promptly so the exposure can be contained and investigated.

Tenant-isolation weaknesses are in scope, but researchers must test them only between separate Workspaces that they own or have explicit permission to use.

Do not attempt to identify or access a real third-party Workspace merely to prove that cross-tenant access may be possible.

A safe demonstration can ordinarily use two researcher-controlled Workspaces and harmless records created specifically for the test.

Where an identifier appears to reference another business, stop before requesting or modifying the underlying record.

The report should explain the suspected authorization failure without including another business’s private content.

Authentication, session-management, passkey, multi-factor, password-reset, email-verification, invitation, and Account-recovery vulnerabilities are in scope when tested against researcher-controlled Accounts.

Do not attempt to take over another person’s Account, intercept their recovery process, or test credentials obtained from a breach or unrelated source.

Do not perform password spraying, credential stuffing, broad password guessing, or high-volume authentication attempts.

Where a weakness can be demonstrated through one or two controlled Accounts, do not expand the test to additional users.

Do not retain an unauthorized session or use it to access business records after the vulnerability has been confirmed.

Payment verification, provider references, webhook authenticity, Credit allocation, duplicate processing, idempotency, refund controls, and wallet authorization may be in scope where they are operated by KOMERRA.

Testing must not use stolen payment methods, real chargebacks, unauthorized transfers, fabricated bank activity, or deceptive provider evidence.

Use provider test modes, sandbox resources, or written authorization where financial processing could otherwise occur.

Do not intentionally obtain or consume unpaid Credits, refunds, services, or financial benefit.

If testing accidentally creates a Credit, charge, refund, or ledger effect, stop and report the exact reference so it can be corrected.

AI security reports may include unauthorized tool use, tenant-boundary failures, sensitive data exposure, high-impact actions without required approval, unsafe retrieval, prompt-injection control failures, or improper trust in unverified model Output.

Use only researcher-controlled Workspaces, content, integrations, and recipients.

Do not attempt to make the AI contact an uninvolved person, access another business, expose production secrets, perform financial activity, publish harmful content, or execute destructive actions.

A model producing undesirable text is not necessarily a security vulnerability unless the Output bypasses a relevant boundary, exposes protected information, or creates a material unauthorized effect.

Reports should distinguish model-quality concerns from exploitable authorization, privacy, security, or financial-integrity failures.

Researchers may test supported API and webhook behaviour using authorized credentials, researcher-controlled provider resources, and proportionate request volumes.

Do not replay live financial or communication events where the replay may create duplicate Credits, messages, orders, documents, notifications, or other external effects.

Do not use leaked provider secrets, internal service credentials, or another customer’s tokens.

Third-party provider endpoints are not in scope merely because KOMERRA integrates with them.

Where the issue appears to originate in a provider, report it through the provider’s own authorized disclosure process and inform KOMERRA where its customers may be affected.

File-upload, private-object access, signed links, document generation, file-type validation, tenant ownership, metadata exposure, and deletion controls may be tested with harmless files owned by the researcher.

Do not upload malware, harmful macros, destructive scripts, illegal material, or files designed to attack an employee or another user.

Do not attempt to enumerate another customer’s storage objects or access a private file whose ownership is unknown.

Use minimal files that demonstrate the issue without introducing unnecessary content or processing load.

Do not publish private signed links, internal object identifiers, or evidence containing customer information.

Client-side vulnerabilities may be reported where they create a meaningful security impact in a supported KOMERRA experience.

The report should explain the realistic impact, required user interaction, affected origin, browser conditions, and whether the issue crosses a trust or authorization boundary.

Self-only behaviour with no plausible effect beyond the researcher’s own Account may be treated as informational.

Do not use social engineering or send a harmful link or payload to another person to demonstrate impact.

Banks, payment gateways, messaging services, social networks, email providers, identity-verification providers, AI providers, hosting services, analytics tools, browser vendors, operating systems, and other independent services are governed by their own policies.

Do not test a third-party service unless that provider expressly authorizes the activity.

A vulnerability in a third-party component may still be reported to KOMERRA where the component creates a material risk to KOMERRA users.

KOMERRA cannot grant safe harbour or testing authorization on behalf of an independent provider.

Researchers are responsible for understanding and complying with the third party’s requirements.

The following reports may be closed as informational or out of scope unless they demonstrate a material and realistic security impact.

The following activities are prohibited under this Policy even where the researcher believes they may reveal a vulnerability.

Research must be designed to avoid degrading the availability or performance of KOMERRA or an integrated provider.

Use the smallest reasonable number of requests and stop if error rates, latency, queue activity, notification volume, or provider effects increase unexpectedly.

Do not perform load testing, sustained concurrency testing, deliberate resource exhaustion, or broad automated enumeration without written authorization.

Where a suspected issue requires volume to demonstrate, report the hypothesis and request permission for a controlled test rather than creating the production impact.

Do not deceive, pressure, impersonate, manipulate, or test employees, contractors, customers, providers, or other users.

Do not request credentials, one-time passwords, recovery codes, internal files, secrets, or unauthorized support actions.

Do not submit fabricated support evidence or persuade personnel to bypass an established identity, payment, security, or authorization process.

A vulnerability report concerning a social-engineering risk should describe the design weakness without conducting the attack against a real person.

Do not create hidden Accounts, persistent sessions, backdoors, scheduled tasks, privileged tokens, unauthorized integrations, or other mechanisms intended to preserve access.

Do not move from the initially affected component into unrelated systems, Workspaces, infrastructure, provider Accounts, or administrative functions.

Once the vulnerability is demonstrated, stop testing and report it.

Any accidentally created credential, session, file, webhook, integration, or administrative change should be identified in the report so KOMERRA can remove it.

Do not test a credential or secret whose ownership or authorization is uncertain.

If a secret is accidentally discovered, do not use it to authenticate, enumerate access, or determine what it controls.

Record only enough information to identify the exposure, such as the location, secret type, and a heavily redacted fragment.

Report the exposure immediately and securely delete any unnecessary copy.

Do not place live credentials, private keys, tokens, recovery codes, or payment secrets in ordinary email.

A report should use the least intrusive proof reasonably necessary to establish the vulnerability.

Do not increase the number of affected records, Accounts, requests, files, transactions, messages, or systems merely to make the report appear more serious.

Screenshots, logs, recordings, and request examples should be redacted to remove unrelated personal data, credentials, tokens, internal identifiers, and customer content.

Where a vulnerability can be demonstrated using a harmless marker or researcher-owned record, use that approach.

KOMERRA may ask for additional controlled evidence where the initial report cannot be reproduced safely.

A useful report should contain enough detail for an authorized engineer or security reviewer to understand, reproduce, assess, and remediate the issue.

A vulnerability report should not include another person’s complete customer record, identity document, payment information, private message, file, credential, or secret.

Use synthetic data or a researcher-owned example wherever possible.

Where sensitive evidence is genuinely necessary, describe what exists and request a secure transfer method.

KOMERRA may delete or restrict unnecessarily sensitive attachments while preserving the minimum information needed for the investigation.

Researchers should securely delete unnecessary local copies after KOMERRA confirms that the required evidence has been received.

Ordinary email may be appropriate for a concise, redacted initial report.

Where the report includes sensitive logs, recordings, files, exploit material, customer information, or secrets, ask KOMERRA for an approved secure transfer method.

Do not upload sensitive evidence to a public file-sharing service, public repository, social network, video platform, or public issue tracker.

A temporary transfer link should be access restricted and should expire after a reasonable period.

The researcher should state whether the evidence is encrypted and how the decryption information will be communicated separately.

Stop active testing of the reported vulnerability unless KOMERRA requests a limited follow-up test or confirms that additional testing is authorized.

Preserve the minimum notes and evidence required to support coordination, but do not continue collecting data.

Do not discuss the unresolved vulnerability publicly or with unrelated third parties.

Respond to reasonable clarification requests where possible.

Notify KOMERRA before retesting a production fix where the retest could create risk or external effects.

KOMERRA targets acknowledgment of an actionable security report within two business days.

KOMERRA targets an initial triage response within five business days after receiving enough information to begin a meaningful review.

These are operational targets rather than guaranteed service-level commitments.

Weekends, public holidays, incomplete reports, identity questions, provider dependencies, complex reproduction conditions, and major active incidents may affect response time.

Where a report presents an immediate and material risk, KOMERRA may prioritize containment before providing a detailed response.

After initial review, a report may be classified as accepted for investigation, duplicate, informational, out of scope, unable to reproduce, intended behaviour, or requiring additional information.

An initial classification is not necessarily the final severity or remediation decision.

Where a report is closed, KOMERRA will seek to provide a general explanation without revealing confidential security design, another person’s information, provider secrets, or investigation details.

A researcher may provide new evidence where they believe the initial assessment was based on incomplete information.

KOMERRA assesses severity according to the actual risk created in the KOMERRA environment rather than the vulnerability name alone.

Relevant factors may include exploitability, required access, affected users, tenant-boundary impact, sensitive information exposed, financial effects, persistence, detectability, reversibility, availability, provider impact, and the possibility of widespread exploitation.

A finding affecting one researcher-controlled record may still be severe where the same weakness could reliably affect many businesses.

A technically interesting issue may be lower severity where meaningful exploitation requires unrealistic conditions or creates no protected impact.

Severity may change as the investigation produces additional evidence.

KOMERRA may respond through a code change, configuration change, credential rotation, access restriction, provider update, monitoring rule, temporary feature disablement, additional confirmation, user communication, or another proportionate control.

An urgent mitigation may be deployed before a complete long-term repair.

Complex issues involving architecture, migrations, providers, clients, compatibility, or historical records may require staged remediation.

KOMERRA will not represent an issue as fixed until the relevant production behaviour has been verified.

The researcher may be asked to perform a limited retest using agreed conditions.

KOMERRA will seek to share material changes in status where doing so does not compromise security, privacy, legal obligations, or an active investigation.

Updates may identify whether the report was reproduced, mitigated, scheduled, provider dependent, ready for retesting, or closed.

KOMERRA may be unable to disclose internal source code, infrastructure details, customer impact, provider communications, legal advice, or investigative evidence.

A lack of detailed disclosure does not necessarily mean the report was ignored.

Researchers must keep vulnerability details confidential while the issue is being investigated and remediated.

The researcher and KOMERRA should agree on a reasonable disclosure timeline based on severity, exploitation risk, customer impact, remediation complexity, provider involvement, and the availability of mitigations.

KOMERRA ordinarily requests that public disclosure not occur before remediation or an agreed coordinated-disclosure date.

Where a fixed date becomes unsuitable because of active exploitation, user safety, provider dependency, or substantial remediation work, both parties should communicate promptly and agree on a proportionate adjustment.

Public disclosure should not include personal data, credentials, exploit-ready secrets, private infrastructure information, or details that unnecessarily expose users to continuing harm.

After remediation, KOMERRA and the researcher may agree on a public advisory, technical summary, acknowledgement, or researcher-authored disclosure.

The disclosure should describe the affected scope accurately and should distinguish demonstrated impact from hypothetical impact.

A fix should be given reasonable time to reach supported production environments and affected providers before detailed exploitation information is released.

KOMERRA may communicate directly with affected customers or providers before public disclosure where that is necessary to protect them.

Neither party should imply endorsement, partnership, employment, certification, or a bug-bounty award that was not granted.

A report may be classified as duplicate where KOMERRA already received or independently identified the same underlying vulnerability.

The earliest actionable report will ordinarily be treated as the original report for acknowledgement purposes.

A later report may still provide valuable new impact, reproduction, affected scope, or remediation information.

KOMERRA may be unable to reveal the identity or report details of another researcher.

Duplicate status does not imply that the later report was submitted in bad faith.

KOMERRA may publicly acknowledge a researcher who submits a useful report and follows this Policy.

Acknowledgement is optional and depends on the researcher’s preference, the report’s value, coordinated disclosure, legal restrictions, and any affected third party.

Researchers should state the name, handle, organization, and link they want used—or request anonymity.

KOMERRA may decline acknowledgement where the report was abusive, misleading, substantially violated this Policy, or creates unresolved legal or privacy concerns.

This is a vulnerability disclosure programme, not a standing promise to pay a financial reward.

Submitting a report does not create a right to payment, Credits, employment, services, reimbursement, or another benefit.

A reward applies only where KOMERRA has published a separate written bug-bounty programme or expressly agrees to a reward in writing.

Researchers must not threaten disclosure, service disruption, data release, or customer contact in order to demand payment.

Good-faith reports remain welcome whether or not a bounty is available.

For research conducted in good faith and in compliance with this Policy, KOMERRA will not initiate legal action solely because the researcher identified, tested, and reported the vulnerability within the authorized scope.

To the extent KOMERRA controls the relevant contractual restriction, KOMERRA will not treat compliant research as a violation of its Terms of Service or Acceptable Use Policy merely because the limited testing was necessary to identify the vulnerability.

KOMERRA will not intentionally refer compliant good-faith research for prosecution solely because it revealed a security weakness.

This safe harbour applies only to claims, systems, data, and restrictions under KOMERRA’s control.

It does not authorize unlawful activity and cannot bind governments, courts, regulators, independent providers, customers, employers, or other third parties.

A researcher who accidentally exceeds a boundary should stop immediately, avoid further access or impact, preserve only minimal evidence, and explain the mistake promptly in the report.

KOMERRA will consider the researcher’s intent, speed of reporting, cooperation, scope, harm avoided, data handling, and corrective steps.

An accidental and promptly reported deviation is treated differently from deliberate expansion, concealment, continued access, exploitation, or refusal to stop.

This section does not excuse serious reckless conduct or bind an independent third party.

KOMERRA cannot grant authorization for a system, Account, data set, provider, or legal right that KOMERRA does not control.

If a third party initiates action concerning research that fully complied with this Policy, KOMERRA may clarify that the researcher reported the matter through KOMERRA’s authorized process.

KOMERRA cannot guarantee the decision of a third party, provider, government authority, regulator, prosecutor, court, or employer.

Researchers remain responsible for complying with applicable law and third-party terms.

Where a vulnerability appears to be actively exploited or creates an immediate material threat, state that clearly in the subject and opening paragraph of the report.

Do not attempt to investigate affected customers or threat actors beyond the authorized scope.

Preserve only safe evidence and allow KOMERRA to coordinate containment, provider engagement, customer communication, and any lawful reporting.

KOMERRA may prioritize emergency mitigation, credential revocation, feature restrictions, or service protection before normal triage communication.

KOMERRA processes researcher contact information, report content, evidence, technical identifiers, correspondence, and remediation records for security, investigation, communication, legal, and accountability purposes.

Access is limited to personnel, advisers, and providers with a legitimate need to investigate or resolve the matter.

Reports may be retained for security history, duplicate detection, incident evidence, legal claims, compliance, and remediation accountability.

Unnecessary personal data, secrets, and customer information should be removed or minimized when they are no longer required.

Information may be shared with an affected provider, customer, regulator, adviser, insurer, or lawful authority where necessary and appropriate.

Do not submit fabricated vulnerabilities, forged evidence, malicious files, threats, harassment, extortion demands, intentionally misleading impact claims, or automated scanner output presented as verified fact.

Do not create multiple identities or reports to pressure different outcomes for the same issue.

Do not use the security channel for sales outreach, product promotion, unrelated support requests, or mass vulnerability notifications with no validated relevance.

KOMERRA may restrict communications, preserve evidence, notify affected providers, or take lawful action where a report is abusive or intentionally harmful.

Good-faith disagreement about severity or remediation does not by itself constitute abuse.

Ordinary product defects, user-interface issues, missing features, accessibility barriers, billing questions, Account recovery, misuse complaints, and policy questions should use the appropriate support process.

A software bug becomes a security report where it creates a realistic impact on confidentiality, integrity, availability, authorization, privacy, financial integrity, or another security boundary.

Reports submitted to the security channel may be transferred to another support function where no security impact is identified.

KOMERRA publishes a security.txt file through the well-known security-contact location on its principal website.

The file identifies security@komerra.app as the reporting address and links to this Policy.

The security.txt file does not independently authorize unrestricted testing. Researchers must still follow the scope and safeguards in this Policy.

KOMERRA should keep the contact, Policy location, canonical location, preferred language, and expiry value current.

An expired, malformed, redirected, or unexpectedly changed security.txt file should be verified through another trusted KOMERRA channel before sensitive information is submitted.

KOMERRA may update this Policy as its systems, providers, mobile applications, APIs, AI capabilities, infrastructure, risk profile, disclosure programme, or legal obligations change.

Material changes may alter scope, reporting channels, safe-harbour terms, response targets, disclosure expectations, or prohibited testing.

Researchers should review the current Policy and security.txt file before beginning new research.

An update does not retroactively withdraw safe-harbour treatment from research that complied with the Policy in effect when it was performed, subject to applicable law and the researcher’s continuing confidentiality obligations.

Send security reports to security@komerra.app.

Use “Security Report” in the subject.

Include the affected asset, reproduction steps, expected behaviour, observed behaviour, realistic impact, approximate time, safe evidence, and researcher-controlled Accounts used during testing.

Request a secure transfer method before sending sensitive evidence.

Do not send passwords, private keys, live tokens, recovery codes, bank PINs, card security codes, another customer’s private information, or unnecessary exploit material through ordinary email.

Stop testing after the issue is demonstrated unless KOMERRA expressly authorizes additional work.