Vulnerability Disclosure

Where to send it

Email security@webcastle.in with a clear subject line. Prefix the subject with the word URGENT if the issue is being actively exploited or exposes data right now, so it is not queued behind routine correspondence.

Acknowledgement

WebCastle aims to acknowledge a report within 2 business days, confirming receipt and naming the person handling it. This is a good-faith target based on how WebCastle works, not a contractual commitment.

Triage

WebCastle aims to complete initial validation and give you an assessment within 5 business days. Complex or multi-environment issues take longer, and WebCastle will tell you so rather than going quiet.

Remediation timing

No fix deadline is promised. Remediation is prioritised by severity and exploitability, and some fixes depend on a client or a third-party provider. You will be told what the plan is and when it changes.

Sensitive material

Do not attach live credentials, session tokens or personal data belonging to other people. Describe the exposure instead. If evidence has to be shared, say so first and WebCastle will agree a secure channel.

Encryption and anonymity

WebCastle does not publish a PGP key for encrypted submissions; provisioning one is being considered as the security program develops. Anonymous and pseudonymous reports are accepted, though they limit follow-up and credit.

• The affected asset

  The exact URL, hostname, endpoint, application area or component where you found the issue, and the environment if you can tell (production, staging, a demo instance).

• A description of the issue

  What the weakness is, in your own words. Name the class of issue where you can — injection, broken access control, exposed secret, insecure direct object reference — but a plain description is fine.

• Reproduction steps

  The precise sequence someone else can follow to see the same behaviour, including the request, parameters, account type or role used, and any preconditions. Screenshots, request and response captures, or a short recording help.

• An impact assessment

  What an attacker could actually achieve: which data becomes readable or writable, whose account is affected, what privilege is gained. Say what you verified and what you inferred, and keep the two apart.

• Any proof of concept

  A minimal payload, script or request that demonstrates the issue. Keep it non-destructive and limited to proving the point — enough to confirm the finding, and no further.

• Your contact details

  An email address WebCastle can reply to, and the name or handle you want used if the issue is credited. Say if you would prefer no attribution.

• Prior or planned disclosure

  Whether the issue has been reported elsewhere, published, shared with a third party, or submitted to a broker or a CVE process, and whether you intend to publish. This changes how WebCastle sequences the response.

• Allow time to remediate before disclosing publicly

  Give WebCastle a reasonable opportunity to investigate and fix the issue before publishing details. WebCastle will agree a disclosure timeline with you and keep you informed, rather than asking for open-ended silence.

• Do not access, alter or exfiltrate data belonging to others

  Stop as soon as you have established that access is possible. Use accounts and data you own or are authorised to use. If you encounter personal data accidentally, stop, do not save or share it, and say so in your report.

• Do not degrade or disrupt service

  No load testing, resource exhaustion, or automated scanning at a volume that affects availability. Real users and client businesses depend on these systems. Keep testing to the minimum needed to demonstrate the issue.

• Do not use social engineering or physical intrusion

  Phishing, pretexting, vishing or any other manipulation of WebCastle staff, clients or suppliers is out of bounds, as is any attempt to enter WebCastle premises or access physical equipment.

• Comply with applicable law

  Nothing on this page authorises activity that is unlawful in your jurisdiction or in India, and nothing here overrides the terms that apply between you and any third party whose services are involved.

• Keep the report between you and WebCastle

  Report through the security mailbox rather than through social media, a client contact, a support ticket or a public issue tracker, and do not sell or trade the finding while it is being handled.

If you are unsure whether something is in scope, report it anyway and say you are unsure. WebCastle would rather assess an out-of-scope report than miss an in-scope one.

• Findings without demonstrated impact

  Theoretical weaknesses, version disclosure or configuration observations with no route to a concrete security consequence.

• Missing best-practice headers with no exploit path

  Absent security headers, cookie flags or policy directives reported on their own, without a demonstration of what an attacker gains from their absence.

• Rate limiting on non-authentication endpoints

  Absence of throttling on public or read-only endpoints. Rate limiting on authentication and credential-reset flows is treated seriously.

• Self-XSS

  Issues that require the victim to paste attacker-supplied content into their own browser or developer console.

• Issues confined to outdated or unsupported browsers

  Behaviour that only appears in end-of-life browsers or with security features disabled by the user.

• Unvalidated automated scanner output

  Raw tool exports submitted without manual verification. A single verified finding with reproduction steps is more useful than a full scan report.

• Social engineering and physical security

  Phishing or pretexting of WebCastle staff, clients or suppliers, and anything involving physical access to offices or equipment.

• Denial of service

  Volumetric, resource-exhaustion and availability attacks. Do not test these. A design flaw that makes such an attack unusually cheap can be described in writing.

1. 1

   Acknowledgement

   Target: within 2 business days

   Your report is confirmed as received, with the name of the person handling it and any immediate clarifying questions. If it describes something being actively exploited, containment starts before triage is complete and WebCastle switches to the incident response process.

2. 2

   Triage and validation

   Target: within 5 business days

   WebCastle reproduces the issue, confirms which asset and environment it affects, and checks whether the same weakness exists elsewhere. Severity is assessed on data sensitivity, exploitability and the number of affected parties. You are told the outcome — including when a report is closed as out of scope, duplicate or not a security issue — with the reasoning, not just the verdict.

3. 3

   Remediation planning

   Prioritised by severity

   A fix is scoped and owned by an engineer, and scheduled against severity. Where the affected system belongs to a client, WebCastle informs that client and coordinates with them, since the decision to deploy is theirs. Where the root cause sits with a third-party provider, WebCastle raises it with the provider and applies mitigation in the meantime.

4. 4

   Fix and verification

   Varies by issue

   The change is made, reviewed and deployed through the normal engineering process unless the severity justifies an emergency change. WebCastle verifies the fix and, where a reproduction path was given, checks that it no longer works. Reporters are welcome to re-test and to say so if they think the fix is incomplete.

5. 5

   Closure and credit

   After verification

   The report is closed with a summary of what was found, what changed and any residual risk accepted. WebCastle agrees with you what may be published and when, and credits you if you want to be named. Findings that point at a systemic weakness feed into the engineering backlog rather than ending at the single fix.