Skip to content
ShamashCyber
العربية Open workspace
Vulnerability disclosure

Reporting a security issue.

If you believe you have found a security issue in ShamashCyber, report it privately. A good report is one that lets us reproduce the issue and understand its impact without unnecessary access to anyone else's data.

Security contact

Send reports to the address below. Put the affected asset or URL near the top of the message.

[email protected]
Email a report View security.txt
  1. 01

    In scope

    Reports that show a real confidentiality, integrity or availability impact on ShamashCyber services we operate.

    • Authentication and sessions. Authentication bypass, session bypass, or access to an account that is not yours.
    • Workspace isolation. Reaching another user's files, processes or data from a workspace you do not own.
    • Web services. Server or application vulnerabilities with clear impact, such as injection, SSRF, meaningful XSS, or exposure of secrets.
    • Application previews. Isolation or routing flaws that expose a preview or session belonging to someone else.
  2. 02

    Out of scope

    These create risk without demonstrating a vulnerability, so please do not send them.

    • Denial of service, load testing, or resource exhaustion.
    • Social engineering, phishing, or anything targeting people.
    • Physical access attempts, or attempts to take devices or accounts.
    • Issues in third party services that ShamashCyber does not operate.
    • Scanner output with no demonstrated impact and no reproducible path.
    • Self XSS, or a theoretical observation that crosses no trust boundary.
  3. 03

    Research rules

    Prove the issue with the smallest amount of access and change that is sufficient.

    • Use accounts and workspaces you control wherever that is possible.
    • Do not read, copy or modify another user's data beyond the minimum needed to show impact, and stop there.
    • Do not create persistence, backdoors, or destructive changes.
    • Do not exfiltrate real data or secrets beyond what the demonstration requires.
    • Do not publish exploitation detail before coordinating with us.
  4. 04

    What to include

    A useful report saves time on both sides.

    • A short summary of the issue and its security impact.
    • The affected URL, component or workspace surface.
    • Exact reproduction steps from a clean starting point.
    • The result you observed, and the result you expected.
    • A minimal proof of concept: a request, a screenshot, or a log.
    • Browser, operating system and any environment detail that affects reproduction.

Safe harbour

For research carried out in good faith and within this policy, ShamashCyber intends to treat the activity as authorised and will not pursue legal action solely because of it. If you come across data that is not yours, stop, do not expand access, and tell us what you saw.

After you report

We will make a reasonable effort to acknowledge, review and reproduce the report, and we may ask for more detail when steps are incomplete. Where a fix is possible we prefer to coordinate the timing of disclosure rather than ask anyone to stay quiet indefinitely.

Credit

If you would like to be credited under a particular name or handle, say so in the report. Recognition is given when a report is valid and useful and when publication is appropriate.

Machine readable contact

We publish security.txt at the standard well-known path, following RFC 9116, so researchers and tools can find the contact and this policy.

https://shamashcyber.com/.well-known/security.txt