openclaw/docs/compliance/vulnerability-disclosure.md

title	summary	permalink
Vulnerability Disclosure Policy	Responsible disclosure policy for reporting security vulnerabilities in Moltbot.	/compliance/vulnerability-disclosure/

Vulnerability Disclosure Policy

This policy describes how to report security vulnerabilities in Moltbot and how we handle disclosures.

Reporting a Vulnerability

Preferred Channels

GitHub Security Advisories (Recommended)

Report vulnerabilities privately through GitHub Security Advisories:

1. Go to Moltbot Security Advisories
2. Click "Report a vulnerability"
3. Provide details following the template below

Email

For reporters who cannot use GitHub:

• Email: security@clawd.bot
• Encrypt sensitive details using our PGP key (available at the repository)

What to Include

Your report should include:

Field	Description
Summary	Brief description of the vulnerability
Severity	Your assessment: Critical, High, Medium, Low
Affected versions	Which Moltbot versions are affected
Attack vector	How the vulnerability can be exploited
Impact	What an attacker could achieve
Reproduction steps	Step-by-step instructions to reproduce
Proof of concept	Code, screenshots, or logs demonstrating the issue
Suggested fix	If you have recommendations

Example Report

## Summary
Authentication bypass in gateway pairing mechanism

## Severity
High

## Affected Versions
Moltbot 2024.1.0 through 2024.1.15

## Attack Vector
Remote, requires network access to gateway

## Impact
Attacker could pair a device without valid pairing code under specific timing conditions

## Reproduction Steps
1. Start Moltbot gateway with default configuration
2. Initiate pairing request from attacker device
3. Send rapid concurrent pairing attempts with invalid codes
4. Under race condition, one attempt may succeed

## Proof of Concept
[Attached script or detailed steps]

## Suggested Fix
Add mutex lock around pairing code validation

Response Timeline

Phase	Timeline	Description
Acknowledgment	2 business days	Confirm receipt of report
Initial assessment	5 business days	Determine validity and severity
Status update	10 business days	Provide fix timeline or request more info
Fix development	Varies by severity	Develop and test remediation
Coordinated disclosure	90 days max	Public disclosure after fix available

Severity-Based Response

Severity	Target Fix Time	Disclosure Timeline
Critical	7 days	14 days after fix
High	30 days	30 days after fix
Medium	60 days	60 days after fix
Low	90 days	90 days after fix

Safe Harbor

We want security researchers to feel comfortable reporting vulnerabilities. If you:

• Act in good faith to avoid privacy violations, data destruction, and service disruption
• Only interact with accounts you own or have explicit permission to test
• Do not exploit vulnerabilities beyond what is necessary to demonstrate the issue
• Report vulnerabilities promptly and do not disclose publicly before coordinated disclosure
• Do not demand payment for vulnerability information

Then we commit to:

• Not pursuing legal action against you for security research conducted in accordance with this policy
• Working with you to understand and resolve the issue quickly
• Recognizing your contribution (with your permission) in our security acknowledgments
• Keeping you informed of our progress toward remediation

Scope

In Scope

Component	Description
Moltbot CLI	Core command-line application
Gateway	WebSocket server and HTTP endpoints
Channel integrations	WhatsApp, Telegram, Discord, Slack, Signal, iMessage
Plugins	Official Moltbot plugins
Configuration	Security of config files and credentials
Authentication	Gateway auth, pairing, RBAC

Out of Scope

Component	Reason
Third-party services	Report to respective providers (OpenAI, Anthropic, etc.)
Messaging platform bugs	Report to WhatsApp, Telegram, Discord, etc.
User configuration errors	Covered by security audit and hardening guide
Social engineering	Not a software vulnerability
Physical attacks	Out of scope for software security
Denial of service	Unless it reveals an amplification vector

Qualifying Vulnerabilities

Category	Examples
Authentication bypass	Accessing gateway without valid credentials
Authorization bypass	Accessing resources beyond granted permissions
Injection attacks	Command injection, prompt injection with security impact
Information disclosure	Credential leakage, sensitive data exposure
Cryptographic issues	Weak encryption, improper key handling
Logic flaws	Security control bypass, race conditions

Non-Qualifying Issues

Category	Examples
Best practices	Missing headers without demonstrated impact
Self-XSS	Requires victim to inject malicious content
Rate limiting bypass	Without security impact
Version disclosure	Unless it reveals specific vulnerable version
Already reported	Duplicate of known issue

Coordinated Disclosure

We follow coordinated disclosure principles:

1. Reporter contacts us with vulnerability details
2. We acknowledge receipt within 2 business days
3. We assess severity and develop fix
4. We coordinate disclosure date with reporter
5. We release fix and publish advisory
6. Reporter may publish after coordinated disclosure date

Disclosure Content

Our security advisories include:

• Vulnerability description
• Affected versions
• Fixed versions
• Severity rating (CVSS if applicable)
• Mitigation steps
• Credit to reporter (if desired)

Early Disclosure Exceptions

We may disclose earlier if:

• Vulnerability is being actively exploited
• Public disclosure is imminent from another source
• Significant user harm can be prevented

We may request delayed disclosure if:

• Fix requires significant development time
• Coordinating with dependent projects
• Critical infrastructure implications

Recognition

We maintain a Security Hall of Fame for researchers who report valid vulnerabilities:

• Acknowledgment in security advisory
• Listed in SECURITY.md (with permission)
• Letter of appreciation (on request)

We do not currently offer monetary bounties, but we deeply appreciate responsible disclosure.

Legal

This policy is not a license to conduct security research on systems you do not own or have permission to test.

Always obtain proper authorization before testing. This policy applies only to:

• Your own Moltbot installations
• Test environments you control
• Systems where you have explicit written permission

Unauthorized access to computer systems is illegal. This policy does not authorize any activity that would violate applicable laws.

Contact

• Security reports: GitHub Security Advisories (preferred)
• Email: security@clawd.bot
• General questions: Use GitHub Issues (do not disclose vulnerabilities publicly)

Policy Updates

This policy may be updated periodically. Significant changes will be announced in the repository.

Related Documentation

• Threat Model - Security architecture and known risks
• Incident Response - How we handle security incidents
• Security Hardening - Secure configuration guide

---

Policy owner: Security Team Effective date: 2026-01-27 Last reviewed: 2026-01-27