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.
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.
Vulnerability Disclosure Policy
How to privately report security vulnerabilities in Vibecodr, what is in scope, what is out of scope, and how we handle good-faith research.
Send it privately
Vulnerability reports should move through a private channel first, with enough detail for us to reproduce the issue without expanding the blast radius.
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.
What good-faith research means
The policy is written for careful testing: prove the issue, avoid user harm, stop at evidence, and give Vibecodr a chance to fix before public detail.
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. |
Disclosure entry points
These are the routes and contact points researchers, bots, and humans should be able to find without needing a signed-in account.
FAQ
Short answers for the places where marketing copy should stop hand-waving and say the plain thing.
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.