Security disclosure policy

Vorel takes security seriously. If you have found a vulnerability in our service, this page tells you how to report it, what to expect from us, and how we work with security researchers. The structured machine-readable version of this policy is published at /.well-known/security.txt per RFC 9116.

How to report

Email [email protected]. Please include:

• A clear description of the vulnerability and the affected surface.
• Steps to reproduce, including any required preconditions.
• Proof of impact — what an attacker could do if this were exploited.
• Your preferred name and contact handle if you want credit; we are happy to attribute or keep the report anonymous, your choice.

For sensitive details (working exploits, customer data examples) please ask us first before sending anything that contains real PII; we will reply with guidance.

Scope

In scope. The Vorel platform and any service we operate, including:

• app.vorel.ai — the operator and tenant dashboard.
• api.vorel.ai and /api/v1/* on the app domain — the public API.
• docs.vorel.ai — the documentation site (cross-site scripting, click-jacking, dependency CVEs).
• The voice (Vapi/Telnyx) and chat (WhatsApp) ingest paths, including signature verification and webhook authentication.
• Server-side application code and infrastructure operated by Vorel.

Out of scope. Issues we have already published as known limitations or which fall outside our control, including:

• Findings against third-party vendors we use as sub-processors. Please report directly to them; their security disclosure pages are linked on each vendor's site.
• Social engineering, physical security, or denial of service generated by traffic alone.
• Vulnerabilities requiring physical access to a victim's device, MITM with a compromised CA, or attackers with privileged network position.
• Reports generated entirely by automated scanners with no demonstrated impact.

What you can expect from us

• Acknowledgement within one business day of receipt. We read every report.
• Initial triage within five business days, including a severity assessment and an indicative remediation window.
• A coordinated disclosure timeline shared with you in writing once we have confirmed the issue. We default to fixing first, disclosing after; we work with you on the exact dates.
• Public credit in our changelog if you want it. We do not run a paid bug-bounty program today.

What we ask of you

• Report privately first. Public disclosure before we have had a chance to remediate puts other Vorel customers at risk and is contrary to coordinated disclosure norms.
• Stop at proof of impact. Do not access more data than necessary to demonstrate the issue, and do not modify, delete, or exfiltrate data belonging to anyone else.
• Respect availability. Do not run automated scans that materially degrade performance for other users; if your finding requires that, ask us first.
• Give us reasonable time to fix. We aim for industry-standard timelines (typically 30-90 days depending on severity) before any public disclosure.

Safe harbour

Vorel will not pursue legal action against security researchers who report findings in good faith and follow this policy. If you are uncertain whether your planned research falls within scope, contact [email protected] before you start — we would rather discuss boundaries up front than receive a report we can't act on.

Languages

We accept reports in English (preferred) and Arabic.

Updates to this policy

We refresh this policy at least annually, and immediately when our scope or contact information changes. The current version always lives at this URL, and the structured form at /.well-known/security.txt includes a machine-readable expiry.