---
title: Vulnerability Disclosure Policy | Vibecodr
description: How to privately report security vulnerabilities in Vibecodr, what is in scope, what is out of scope, and how we handle good-faith research.
canonical: https://vibecodr.space/vulnerability-disclosure-policy
---

# Security reports

## Vulnerability disclosure

If you find a real security issue in Vibecodr, we want a direct, private path for it to reach us quickly. This policy explains what to send, what research is allowed, and how reports are handled.

Use the HTTPS bug-report form for private intake or email founder@vibecodr.space. Do not post vulnerability details publicly until we have investigated and coordinated a fix.

## Start here

### Contact: Use the private HTTPS intake route or email the founder.

Preferred contact is https://vibecodr.space/support/bug-report?type=security; email founder@vibecodr.space also reaches the disclosure owner.

### Safe harbor: Good-faith research is welcome when it avoids harm.

If you act in good faith, avoid harm, avoid privacy invasion, and follow this policy, Vibecodr will not pursue legal action against you for the security research described here.

### Scope: Focus on privacy, platform safety, and trust-boundary bugs.

Cross-user access, sandbox escape, XSS, SSRF, secret exposure, permission bypass, data corruption, and policy bypass are high-signal reports.

### Handling: Reports are private and routed to admin-only review.

Bug-report submissions are transmitted over HTTPS to Vibecodr's API and held in a private admin intake queue; email reports go directly to the founder mailbox.


## How it works in practice

### Report privately: Send enough detail for us to reproduce the issue.

The fastest report includes the affected URL, account or post context when relevant, exact reproduction steps, expected versus actual behavior, screenshots or short clips when useful, and whether you believe data or trust boundaries were exposed. Preferred: submit through https://vibecodr.space/support/bug-report?type=security. Alternative: email founder@vibecodr.space. Include a safe proof of concept when it helps verification. Do not include secrets, credentials, private user data, or exploit payloads beyond what is necessary to explain the issue.

### In scope: Focus on platform safety, privacy, and trust-boundary bugs.

Reports are most useful when they show a way to cross a Vibecodr trust boundary or expose something private. Runnable code, public publishing, Pulse execution, storage, auth, moderation, and runtime isolation are all important surfaces. Vibecodr web app routes on vibecodr.space. Published player, embed, vanity, and VXBE runtime surfaces that are operated by Vibecodr. API behavior that affects auth, storage, publishing, runtime execution, private metadata, or admin-only access. Cross-user access, sandbox escape, XSS, SSRF, secret exposure, permission bypass, data corruption, or policy bypass.

### Out of scope: Avoid noisy findings and attacks that do not prove a real Vibecodr risk.

We still appreciate good-faith notes, but not every scanner result is a vulnerability. Please prioritize issues with a concrete impact and a Vibecodr-specific reproduction path. Automated scanner output without a validated exploit path. Social engineering, phishing, spam, or physical attacks. Denial-of-service testing, stress testing, or rate-limit exhaustion. Issues requiring malware, credential theft, or access to another person's account. Reports about third-party software with no demonstrated Vibecodr impact.

### Research rules: Test carefully and stop when you find evidence.

The goal is to prove the weakness without expanding the blast radius. Once you can demonstrate impact, stop and report it so we can investigate safely. Use your own account, your own content, or explicit test content. Do not access, change, delete, or exfiltrate another user's data. Do not degrade service, bypass rate limits at scale, or run destructive tests. Do not publish details before we have had a reasonable chance to investigate and fix the issue.

### Handling: Reports are private and routed to admin-only review.

Bug-report submissions are transmitted over HTTPS to Vibecodr's API and stored in a private admin intake queue. Email reports go directly to the founder mailbox. We do not intentionally publish reporter contact information or vulnerability details. We aim to acknowledge high-signal security reports quickly. We may ask for clarifying details if the issue cannot be reproduced safely. We prioritize issues by user impact, exploitability, affected surface, and containment risk. We do not currently run a paid bug bounty program.


## Disclosure boundaries

Use this table to decide whether a finding belongs in the vulnerability disclosure lane, the ordinary bug lane, or a product/support note.

| Plan | Good fit | Not a good fit |
| --- | --- | --- |
| Security reports | A reproducible platform, privacy, sandbox, auth, storage, or policy boundary issue. | A scanner-only warning with no Vibecodr-specific exploit path. |
| Testing behavior | Minimal proof against your own account, project, or test content. | DoS, destructive testing, data exfiltration, spam, phishing, or social engineering. |
| Publication | Private report first, coordinated disclosure after investigation. | Public exploit details before Vibecodr has a reasonable chance to respond. |

## Keep exploring

- [Private form: Submit a private vulnerability or bug report](https://vibecodr.space/support/bug-report?type=security)
- [Email: founder@vibecodr.space](https://vibecodr.spacemailto:founder@vibecodr.space)
- [security.txt: Machine-readable disclosure contacts](https://vibecodr.space/.well-known/security.txt)
- [Security model: Runtime and trust boundaries](https://vibecodr.space/security/index.md)
- [Privacy: Data handling policy](https://vibecodr.space/privacy)
- [Content policy: Publishing and moderation rules](https://vibecodr.space/content-policy/index.md)

## FAQ

### Do you need a PGP or encryption key before I can report?

No. Vibecodr does not currently publish a PGP key in security.txt. Use the HTTPS bug-report form for encrypted transport, or email founder@vibecodr.space if the report is better handled by email.

### Can I test with another user's content?

No. Use your own account, your own content, or explicit test content. Stop once you have enough evidence to explain the issue.

### Is there a paid bug bounty?

Not currently. Reports are appreciated, but this policy is a vulnerability disclosure policy rather than a bounty program.

### When should I use /security instead?

/security explains Vibecodr's general security model. Use this disclosure policy when you have found a concrete vulnerability or trust-boundary issue.

## Closing note

Security reports should be boring to send and serious to receive: private path, clear evidence, careful handling, and a real human on the other side.