Responsible Disclosure Program

InstiKit Bug Bounty &
Responsible Disclosure Policy

At InstiKit, security is not a checklist. It is critical. We welcome responsible security researchers who can demonstrate real, high-impact vulnerabilities in our systems.

This is not a general bug reporting page.
We only accept serious security issues with proof.

Authorized Testing Domain

ONLY test on

play.instikit.com

This is our official testing environment for security research.

Strictly Prohibited

  • DO NOT test on customer production domains or any other InstiKit infrastructure
  • DO NOT test on subdomains not explicitly listed above
  • Testing unauthorized domains will result in immediate disqualification and potential legal action

What We Are Looking For (In Scope)

We reward and respond to critical and high-severity vulnerabilities that demonstrate real exploitation, not theory. Your report must clearly demonstrate at least one of the following:

Account Takeover (ATO)

  • Login bypass
  • OTP or authentication bypass
  • Privilege escalation from student/teacher to admin
  • Session hijacking with proof

Unauthorized Data Access

  • Accessing another school's data
  • Accessing data without authentication
  • Ability to dump sensitive records

Remote Code Execution (RCE)

  • Command execution on server
  • Arbitrary file upload leading to execution

Server Access

  • Shell access
  • Database access
  • Cloud credential leakage
If it does not lead to real access, control, or data exposure, it is out of scope.

What We Are NOT Looking For (Out of Scope)

Please do not submit reports for the following:

  • Clickjacking
  • Missing security headers
  • CORS misconfigurations without exploit
  • Rate limiting suggestions
  • Self-XSS
  • Open redirects
  • CSRF without real impact
  • Brute-force warnings without proof
  • Theoretical attack scenarios
  • Automated scanner output
  • Dependency vulnerability reports without exploitation
If your report can be found by running an automated tool, it will be ignored.

Proof Requirements (Mandatory)

Every valid report must include:

  • Clear step-by-step reproduction
  • Screenshots or screen recording
  • Proof of impact — e.g., successful admin access, data exposure, server response, shell output
  • Test credentials (if applicable)
No proof → No response.

How to Submit a Report

Use a clear subject line like: [Critical ATO - InstiKit]

Include the following in your report:

  • Vulnerability title
  • Affected URL or module
  • Detailed reproduction steps
  • Proof (screenshots or video)
  • Your name or handle
  • Optional: payload address
Reports sent via contact forms, WhatsApp, LinkedIn, or support tickets will be ignored.

Rewards

We offer cash rewards for valid, high-impact findings. The reward amount depends on:

  • Severity
  • Clarity of report
  • Real-world impact
  • Duplicate reports receive no reward
  • Reports submitted without valid proof will not be rewarded
  • Final reward decision is at InstiKit's discretion

Rules of Engagement

DoS/DDoS Attacks Are Strictly Prohibited

Any form of denial-of-service attack — including network flooding, resource exhaustion, or application-layer attacks — will result in immediate termination from the program and potential legal consequences.

  • Only test on play.instikit.com — no other domains or subdomains
  • Do not test on customer schools or production systems
  • Do not perform denial-of-service (DDoS/DoS) attacks
  • Do not perform network scanning or port scanning without explicit permission
  • Do not use automated exploiting frameworks without manual verification
  • Do not publicly disclose vulnerabilities without our written permission
  • Test only on your own test accounts — do not target other users' data
  • Stop testing immediately once impact is proven
  • Do not delete, modify, or corrupt any data
  • Do not attempt to access or modify data belonging to other researchers or real users
  • Do not exploit discovered vulnerabilities beyond the necessary proof of concept
  • Notify us immediately if you accidentally access sensitive data
  • Use only non-destructive testing methods
  • Respect rate limits and do not overload the system
Responsible disclosure is mandatory.

Critical Safety Notice

Security testing must be strictly non-destructive. Any activity that causes or risks data loss, corruption, service disruption, or harm to schools or users is not permitted and may result in immediate termination of testing and legal action. This includes, but is not limited to:

  • Deleting, altering, or corrupting database records
  • Encrypting, overwriting, or destroying any data
  • Modifying student, staff, or school data beyond the minimum required for proof
  • Interfering with backups, logs, or recovery systems
Researchers must stop testing as soon as impact is proven.

Demonstration of access is sufficient. Data destruction or service disruption is never required to validate a vulnerability.

Response Timeline

  • Initial response

    Within 24–72 working hours

  • All reports acknowledged

    Every valid submission receives a response

  • Out-of-scope reports

    Invalid or out-of-scope reports may not receive a reply

🔐

Final Note

If your report shows real compromise, we want to hear from you.
If it's noise, theory, or tool output — save your time.

We respect skilled researchers and expect the same professionalism in return.

Submit a Report