Skip to content

$ man security — Legal · Security & Responsible Disclosure

security.md
readonly

Security & Responsible Disclosure

Last updated: May 1, 2026

ClaudeSkill takes the security of our users, their data, and the broader ecosystem seriously. We welcome reports from the security community and offer good-faith researchers a safe channel to disclose vulnerabilities.

1. How to report

  • Email: info@claudeskil.com
  • PGP: a key fingerprint is published at /.well-known/security.txt for encrypted reports. (If the file is not yet present, send unencrypted and we will follow up over an encrypted channel.)
  • Subject line: “Security report — <short summary>”.

Please do not file a public GitHub issue, blog about the vulnerability, or share it on social media before we have had a reasonable opportunity to investigate and remediate.

2. What to include in a report

  • A description of the vulnerability and its potential impact.
  • Step-by-step reproduction instructions, including any test accounts you used and the exact URL(s) involved.
  • Proof-of-concept code, request/response logs, or screenshots — only what is needed to demonstrate the issue.
  • The CVSS v3.1 vector (if you have one) and your assessment of severity.
  • Whether you are willing to be credited and how you wish to be attributed.

3. In scope

Vulnerabilities in the following systems are in scope:

  • The web application at claudeskil.com and its subdomains.
  • The public API endpoints at /api/*.
  • Authentication, authorisation, session management, and account recovery flows.
  • Server-side issues such as injection, SSRF, RCE, deserialisation, and broken access control.
  • Significant client-side issues such as stored XSS, CSRF on state-changing endpoints, and prototype pollution leading to privilege escalation.
  • Supply-chain risk — leaked credentials, exposed admin endpoints, misconfigured cloud resources we control.

4. Out of scope

  • Reports based solely on missing security headers without a demonstrable exploit.
  • Social-engineering attacks against ClaudeSkill staff or users.
  • Physical attacks on offices or infrastructure.
  • Denial-of-service or volumetric testing — please do not run load, stress, or DDoS scenarios against the Service.
  • Self-XSS, clickjacking on pages without sensitive actions, and tab-nabbing without an exploit chain.
  • SPF/DKIM/DMARC configuration nits without a demonstrated phishing path.
  • Vulnerabilities that require an already-compromised device or rooted browser.
  • Issues in third-party Skills hosted on external repositories (report those to the upstream maintainers; you may also CC us at info@claudeskil.com if the Skill is being distributed via ClaudeSkill).
  • Automated scanner output without manual validation.

5. Safe harbour

We will not pursue or support legal action against researchers who:

  • Make a good-faith effort to comply with this policy.
  • Avoid privacy violations, destruction of data, and interruption or degradation of the Service.
  • Only interact with accounts you own or have explicit permission to access.
  • Stop testing as soon as a vulnerability is identified and report it promptly.
  • Do not exploit the vulnerability beyond what is needed to confirm its presence.
  • Do not access, modify, or exfiltrate data belonging to others.

Activity conducted in compliance with this policy is considered authorised conduct under the Computer Fraud and Abuse Act and similar laws, and we will defend the position that your testing was authorised. If a third party initiates legal action against you for activities that complied with this policy, we will take reasonable steps to make it known that those activities were authorised.

6. Our response targets

  • Acknowledgement: within 3 business days of receipt.
  • Initial triage: within 7 business days, including a severity assessment and an estimated remediation timeline.
  • Resolution: critical issues within 14 days; high within 30; medium within 60; low at our discretion.
  • Public disclosure: by mutual agreement, typically after a fix has shipped and affected users have been notified where required.

7. Recognition

We are a small project and currently do not run a paid bug-bounty programme. We will publicly acknowledge researchers who report valid, in-scope vulnerabilities (with their permission) on a recognition page. We may also offer swag where available.

8. security.txt

A machine-readable security contact, in line with RFC 9116, is published at /.well-known/security.txt.

9. Contact

Security: info@claudeskil.com