Found something? Tell us and we will fix it
Elevate ERP holds the records of children, so a security report is the most useful message we get. This page is the whole policy: what is in scope, the ground rules, what you can hold us to, and the plain fact that there is no bounty. It is read by the 2 people who build the product — there is no security desk.
Where to send it
Email [email protected] with a description of the vulnerability, the steps to reproduce it, what an attacker could do with it, and any proof-of-concept code or screenshots. Plain text is fine; there is no form and no portal to register with.
If you have had no acknowledgement after 48 hours, message +91 88098 11850 (WhatsApp only — it is not a voice line) and say that a security report is waiting. That is the same channel the grievance process uses, and it reaches Omniflux Team directly.
What is in scope
Anything in this list, on infrastructure we control. If you are unsure whether something counts, send it anyway — a wrongly-scoped report costs us a reply, and a report you decided not to send costs a school.
The web application
Everything behind sign-in at https://elevateerp.in — the administrative dashboard, the staff modules and the student portal — plus the public pages of this website.
The API routes
https://elevateerp.in/api/* — including anything that returns data without asking who is calling, or that accepts a write it should have refused.
What happens after sign-in
Session and token handling, and the account record a token resolves to. Sign-in itself runs through Firebase Authentication, which is Google’s service and not ours to authorise testing on — but everything this application does with the result of it is in scope.
Tenant isolation
Any path by which one school can read, write or infer another school’s records. The database rule set ends in a catch-all that denies every read and write, and each rule above it is scoped by a school identifier — a way past either of those is the highest-severity finding on this list.
Roles and permissions
Privilege escalation between roles, and any tool the AI assistant can be made to call outside the permissions of the account that asked it. Both the application layer and the database rules are meant to enforce this, so a gap in one of them is worth reporting even if the other holds.
Data exposure
Anything that discloses a student, guardian, staff or payment record — or a fragment of one — to somebody who should not be able to see it. These are children’s records, so this is the category we most want to hear about.
What we cannot authorise you to test
Elevate ERP runs on other people's infrastructure and calls other people's APIs — Google Cloud and Firebase, Vercel, Cloudinary, the AI providers and the gateway in front of them, the payment gateway, the identity-verification API and both email relays. Every one of the 11 entries on the subprocessors page is a system we do not own, so none of them is ours to grant permission over and nothing on this page authorises testing against any of them; take a finding in one of their platforms to that provider's own disclosure programme. Also out of scope: denial-of-service and load testing, physical or telephone attacks on anyone, and a version-number report against a dependency with no demonstrated impact here.
Ground rules
These are the conditions the undertakings below depend on. Stay inside them and you are researching in good faith as far as we are concerned.
- Do not access, modify, or delete data belonging to other users.
- Do not perform denial-of-service (DoS) or load testing.
- Do not use social engineering against Ayushman or Shivamanand, or against staff at any school using Elevate ERP.
- Provide sufficient detail for us to reproduce the vulnerability.
- Allow us reasonable time to fix the issue before public disclosure.
- Do not exploit the vulnerability beyond what is necessary to demonstrate it.
What you can hold us to
Five undertakings, each one something a single person can actually honour. There is no severity matrix and no support tier behind them, because neither exists.
Who reads it
The 2 people who build Elevate ERP, directly. There is no triage rota, no overnight cover and no security desk — the address below is an alias that resolves to one mailbox. Reports are read in the order they arrive, with anything touching student data or tenant isolation taken first.
Acknowledgement within 48 hours
You will get a human reply confirming we have it. This is the same window as the only response time Omniflux is bound to anywhere — the statutory grievance channel — so it is not a tier invented for this page. If 48 hours pass in silence, treat the acknowledgement as failed and use the fallback channel below.
A fix timeline within five business days
An estimate of when a fix will land, and a severity assessment we will explain. It is an estimate, deliberately: it is not a promise to have shipped the fix by that date, and we would rather give you a date we can move than one we cannot.
No legal action against good-faith research
Stay inside the scope and the ground rules on this page and we will not pursue you, and will not report you, for the testing itself. That undertaking is ours to give and it stops at our own systems — see the note below on the providers underneath us, whose systems we cannot authorise anybody to test.
Credit, if you want it
We will credit you by name when we confirm the fix, unless you would rather remain anonymous. We do not yet publish a security advisory feed; if we start one, past reporters will be asked before anything is listed retrospectively.
There is no bounty
We do not pay for vulnerability reports and there is no budget from which we could. No reward programme exists, none is planned, and nothing on this page should be read as promising one later. What you get is a named human reply, credit if you want it, and the fix. If that is not worth your evening, we would rather you knew before you started than after.