Skip to main content
Security & Service

Report a security issue

Effective 12 September 2026 · Last updated 12 September 2026 · Version 1.0 · ACADEMYSHIP PTY LTD · ACN 698 283 448 · ABN 89 698 283 448

#01Purpose and legal status

ACADEMYSHIP PTY LTD (ACN 698 283 448, ABN 89 698 283 448) ("Academyship") welcomes reports of genuine security vulnerabilities in our production systems. This page describes how to report a vulnerability to us and how we practise coordinated vulnerability disclosure.

This policy is not authorisation to perform unrestricted security testing against Academyship or its customers, and it is not a bug-bounty offer. It sets out the narrow conditions under which we will treat good-faith, in-scope research as welcome. Testing outside these conditions is not authorised.

#02What to report

Please report vulnerabilities you find in an in-scope Academyship-owned public system. Examples of issues we want to hear about include:

  • authentication or session-management bypass;
  • failures of tenant isolation (access to another Institution's data);
  • broken access control or privilege escalation;
  • injection vulnerabilities (for example, SQL or command injection);
  • exposed secrets, credentials or keys;
  • unauthorised file access or path traversal; and
  • serious security misconfiguration or unintended exposure of personal data.

#03In-scope systems

In-scope systems are Academyship-owned public systems expressly covered by this policy or prior written testing approval. Do not treat a domain name, IP address, API endpoint or asset as in scope merely because it appears connected to Academyship. If Academyship has not expressly covered a system, request scope confirmation from security@academyship.com.au before testing.

Public, unauthenticated pages at academyship.com.au may be assessed only within the rules in this policy. Any authenticated service, production tenant, test environment or other system requires the approval described in section 5 before testing.

#04Out-of-scope findings

The following are generally not treated as reportable vulnerabilities unless you can demonstrate a real, exploitable security impact:

  • missing low-risk HTTP headers or best-practice suggestions without a demonstrated exploit;
  • self-XSS that cannot affect another user;
  • rate-limiting observations without demonstrated impact;
  • clickjacking on pages with no sensitive action;
  • automated scanner output without a validated finding;
  • social engineering, phishing or physical attacks;
  • denial-of-service or resource-exhaustion testing;
  • spam or content-injection without security impact; and
  • issues in third-party services or already-public information.

The following are expressly out of scope unless Academyship gives prior written permission: real Institution tenants; real student or staff accounts; Customer Data; authenticated production testing; leaked credentials; Customer-selected integrations; third-party provider systems; high-volume account creation; and denial-of-service testing.

#05Rules for good-faith research

To keep research safe for users and lawful, you must:

  • stop as soon as you can demonstrate a vulnerability and before you access, download or view Customer Data or personal information beyond the minimum needed to prove the issue;
  • not exfiltrate, alter, delete, encrypt or destroy any data;
  • not disrupt or degrade the Services, and not perform denial-of-service or high-volume automated scanning;
  • not attempt credential attacks, phishing, or social engineering of staff, customers or users;
  • not attempt to access another tenant's data, and not pivot between tenants;
  • not bypass a clear warning, paywall or authorisation boundary beyond what is necessary to demonstrate the issue; and
  • use only test accounts and data you are entitled to use, and use the minimum proof necessary.

You must request approval from security@academyship.com.au before authenticated testing. Use an Academyship-provided test account or environment where one is available; do not substitute a real customer tenant, real student or staff account, or leaked credential.

#06Safe-harbour position

Academyship does not intend to initiate legal action solely for research that strictly complies with this policy. Academyship cannot authorise activity against third parties or waive the rights of Customers, providers, regulators, law-enforcement bodies or other parties.

You remain responsible for complying with applicable law. This policy does not promise that Academyship will defend, indemnify or represent a researcher in any action by a third party.

#07How to report

Send your report to security@academyship.com.au. This is Academyship's monitored reporting channel. To help us assess it quickly, please include:

  • a clear description of the vulnerability and its potential impact;
  • the affected URL, endpoint or component;
  • step-by-step, reproducible instructions or a minimal proof of concept;
  • any prerequisites (for example, a required role);
  • your contact details and preferred language for correspondence; and
  • whether you intend to disclose publicly, and any timeline you have in mind.

Please report one issue per message where practical. We accept reports in English.

#08Handling sensitive evidence

When you send evidence, minimise the personal information it contains, redact credentials and secrets, and never email suspected illegal material. If a proof of concept would require sharing sensitive data, describe it and email security@academyship.com.au first so we can agree a secure method. Please delete any Academyship or customer data you retained during research once the issue is resolved, to the extent the law allows.

#09What Academyship does next

When we receive a report, we triage it, work to validate and reproduce it, assess its severity, and progress remediation, communicating with you as appropriate. We aim to keep you reasonably informed. We do not publish a fixed acknowledgement or fix deadline in this policy, because those timeframes depend on severity, complexity and resourcing; we will act reasonably and treat genuine security issues seriously.

#10Coordinated disclosure

We ask that you keep the details of a reported vulnerability confidential while we remediate it, and that you coordinate the timing of any public disclosure with us so that users are not put at risk. We will work with you in good faith on reasonable disclosure timing. We do not commit to a fixed disclosure window (such as a guaranteed 90 days) in this policy; we will agree a reasonable approach with you for each report.

#11Recognition and rewards

Academyship does not currently operate a paid bug-bounty program, and this policy does not offer or promise any monetary reward. Where you wish, and once an issue is resolved, we may — with your consent — acknowledge your contribution. There is no entitlement to recognition or payment under this policy.

#12Privacy and record keeping

We use the contact details and information in your report to assess and resolve the issue, to communicate with you, and to keep records of the report and our response. We handle this information in accordance with our Privacy Policy, and we may disclose it where required by law.

#13Other reports

This page is for security vulnerabilities in Academyship systems. For other matters, please use the right channel:

#14Changes, contact and related documents

We review this policy at least annually (each September) and after a material change to our security process or domain scope. Contact security@academyship.com.au with any questions.

#15Machine-readable security.txt

Academyship publishes an RFC 9116 security.txt file at /.well-known/security.txt. Deployment verification must confirm: an HTTP 200 response; HTTPS; Content-Type: text/plain; the exact Canonical URL https://academyship.com.au/.well-known/security.txt; and publication of a refreshed file before the Expires date.