Security
Vulnerability Disclosure Policy
If you have found a security flaw in EL7.AI, we want to hear about it. This page tells you exactly how to report it, what we consider in scope, and what you can expect from us.
Last updated: 2026-07-27
We do not pay bounties — but reports are welcome
EL7.AI does not operate a paid bug bounty programme and we do not offer monetary rewards for vulnerability reports. We do operate this Vulnerability Disclosure Programme: report a genuine flaw in good faith and we will investigate it, fix it, keep you informed, and credit you publicly if you want to be credited. Please do not send an invoice or ask for payment in exchange for the details of a vulnerability — a report conditioned on payment will be treated as extortion rather than as security research.
How to report
Send us an email. Write in Arabic or English, and include enough detail that an engineer can reproduce the issue without guessing.
We read Arabic and English and will reply in whichever language you write in. Encrypted reports are not supported yet — do not send sensitive proof-of-concept data in the clear. Describe it instead and we will arrange a secure channel.
What to include
- What the issue is — the vulnerability class in one sentence — for example authentication bypass, stored XSS, or IDOR.
- Where it is — the exact URL, endpoint, or parameter. Include the locale prefix, for example /ar/dashboard.
- How to reproduce it — numbered steps from a clean session. Say which account tier you used.
- Why it matters — what an attacker actually gains — which data, whose data, and how much of it.
- Evidence — a short screen recording or screenshots. Redact any real member data you happened to see.
- How to reach you — and whether you want to be credited by name or by handle.
What you can expect from us
These are targets, measured from the moment your report reaches security@el7.ai. We are a small team — we would rather publish honest targets than impressive ones.
| Stage | Target |
|---|---|
| We acknowledge your report | 3 business days |
| We confirm or reject it, with reasoning | 10 business days |
| We send an update if the fix runs long | 14 days (recurring) |
| We fix confirmed critical issues | 30 days |
Scope
In scope
- el7.ai and www.el7.ai, including all /ar/ and /en/ pages
- Our public API endpoints under el7.ai/api
- Authentication, session handling, and account-tier access control
- Checkout, subscription, and billing flows
- storage.el7.ai and ws.el7.ai
Out of scope
- Raw automated scanner output submitted without a working proof of concept
- Missing security headers with no demonstrated exploit (HSTS, CSP, X-Frame-Options)
- Denial of service, volumetric testing, brute force, or any load testing
- Social engineering, phishing, or physical attacks against our staff
- Attacks requiring physical access to a victim's unlocked device
- Vulnerabilities in third-party services we consume — report those to the vendor
- Self-XSS, or issues requiring the victim to paste code into their own console
- Missing rate limits with no demonstrated impact
- Email configuration findings (SPF, DKIM, DMARC) on domains that send no mail
- Outdated software versions with no demonstrated exploit path
If you are unsure whether something is in scope, report it and say you are unsure — we would rather read one extra email than miss a real issue. A bulk submission of scanner findings with no analysis will be closed without a detailed reply.
Rules of engagement
Testing that stays inside these rules is authorised. Testing that breaks them is not, and loses the safe-harbour protection below.
- 1Use the minimum access needed to prove the issue, then stop. Do not keep digging once you have a proof of concept.
- 2Never download, copy, retain, or share member data. If you access personal data by accident, stop immediately, tell us, and delete it.
- 3Test only against accounts you own or have explicit permission to use. Do not touch other members' accounts.
- 4Do not pivot into our internal network, our servers, or our third-party providers, and do not attempt to escalate a web flaw into infrastructure access.
- 5Give us 90 days to fix a confirmed issue before disclosing it publicly. We will not pursue you for publishing after that window, and we are happy to agree an earlier date if the fix ships sooner.
- 6Do not degrade our service, and do not use a finding to extract payment. Follow applicable law — nothing on this page authorises anything illegal.
Safe harbour
If you make a good-faith effort to follow this policy during your research, we will treat your activity as authorised, we will not pursue or support legal action against you, and we will help make it known that your actions were conducted in compliance with this policy if a third party raises a complaint.
This protection covers your research only. It does not waive the rights of third parties, it does not apply if you break the rules of engagement above, and it does not cover data destruction, service disruption, or any demand for payment. If you are unsure whether an action is authorised, ask us before you take it.
Credit
We do not pay for reports, but we do publish credit. If you report a valid issue and want to be acknowledged, tell us the name or handle you would like us to use and we will list you once the fix has shipped. If you would rather stay anonymous, that is fine too — just say so.
Anything else
For questions that are not security reports — billing, account access, or general support — please use the contact page.