unopost

Responsible disclosure policy

Last updated: 15 October 2026

1. Introduction

We welcome reports from anyone who believes they have found a security vulnerability in Unopost. This Responsible Disclosure Policy explains how to report one, the rules we ask you to follow while looking, and what we will do in return. It is published by AWS, CYY & Co. Pty Ltd (ACN 686 116 245) as Trustee for Mumu, Lulu & Co. (ABN 54 837 123 965), which operates Unopost.

We do not run a paid bug bounty and do not pay rewards for reports. With your permission, we will thank you by name on this page once the issue is fixed.

2. Scope

This Policy covers:

It does not cover services run by others that we use, such as Square, Australia Post or Amazon Web Services. Report issues in those to the provider concerned.

3. How to report

Email support@unopost.com.au with "Security" in the subject line. Please include:

  • A description of the issue and the impact you believe it has
  • The URL, endpoint or feature affected
  • Step-by-step instructions to reproduce it, with any proof-of-concept code, screenshots or requests
  • How we can contact you, and whether you would like to be thanked by name

If you have found an exposed key, password or other secret, tell us straight away and do not use it. Please write in English if you can.

4. What we ask of you

When looking for and reporting a vulnerability, you must:

  • Test only against accounts, documents and Letters that are your own, or that you have the owner's permission to use
  • Stop as soon as you reach personal information, documents or data that are not yours, and tell us what you accessed. Do not copy, keep, change or delete it, or share it with anyone
  • Not degrade or interrupt the Service, including by denial-of-service attacks, load testing or high-volume automated scanning
  • Not post Letters to anyone without their consent, or send messages to our customers, their recipients or our staff
  • Not use social engineering, phishing or physical attacks against our staff, premises or service providers
  • Not use another person's payment card, Business Credit or credentials
  • Do only what is necessary to show that the vulnerability exists
  • Keep the details confidential until we have fixed the issue, or until 90 days after your report, whichever is sooner, unless we agree otherwise with you
  • Comply with the law

5. What we will do

When you report a vulnerability in accordance with this Policy, we will:

  • Acknowledge your report within 2 business days
  • Tell you whether we can reproduce the issue, and keep you informed of our progress
  • Aim to fix a confirmed vulnerability within 90 days, sooner where it puts personal information at risk
  • Tell you when the issue has been fixed, and thank you by name if you have asked us to

If the issue involved personal information, we will assess it and notify affected individuals and the Office of the Australian Information Commissioner as Section 11 of our Privacy Policy (https://unopost.com.au/privacy) describes.

6. Safe harbour

If you act in good faith and in accordance with this Policy, we will treat your research as authorised, will not take legal action against you in connection with it and will not report you to law enforcement. If a third party takes legal action against you for research that complied with this Policy, we will make it known that your research was authorised by us.

This does not apply if you have breached this Policy, accessed more than you needed to, or asked for payment in exchange for not disclosing an issue. If you are unsure whether something you intend to do is allowed, ask us first at support@unopost.com.au.

7. What we do not treat as a vulnerability

The following are generally outside this Policy unless you can show a real impact on the security of the Service or our users:

  • Reports from automated scanners without a working proof of concept
  • Missing security headers, cookie flags or email authentication records (SPF, DKIM, DMARC) on their own
  • Clickjacking on pages with no action that could be harmful
  • Self-XSS, or issues that need physical access to a user's unlocked device
  • Software version disclosure, or the absence of rate limits on actions with no security consequence
  • Denial of service, and vulnerabilities in third-party services described in Section 2

8. Changes to this Policy

We may change this Policy at any time by publishing a new version on this page. The version published when you make a report applies to that report.