Responsible Disclosure

Found a security issue? Help us fix it responsibly.

ShabuShabu Security values responsible vulnerability research. If you believe you have identified a security issue affecting a ShabuShabu-operated system, report it privately so the finding can be reviewed, validated and addressed without unnecessarily increasing risk.

Private reporting Responsible research Controlled validation Coordinated remediation
Disclosure workflow Report → Validate → Remediate
Private
01
Submit privately Send enough technical context for the issue to be reviewed.
02
Triage the finding Determine whether the reported behavior represents a security issue.
03
Validate impact Reproduce the issue and understand the affected security boundary.
04
Remediate Address the weakness and coordinate further communication where appropriate.
Our disclosure philosophy

Security research is most useful when it creates a path to remediation.

Vulnerability disclosure works best when researchers and system owners can exchange technical information without creating additional exposure around an unresolved issue.

ShabuShabu therefore encourages clear, private reporting of suspected security weaknesses together with enough context to understand and reproduce the reported behavior.

01

Report privately

Avoid unnecessary public disclosure while a potential vulnerability remains unresolved.

02

Minimize impact

Use the minimum interaction necessary to identify and explain the suspected weakness.

03

Preserve evidence

Provide technical information that helps reproduce the issue without collecting unnecessary data.

How to report a vulnerability

Give us enough information to understand the security boundary that failed.

A useful vulnerability report does not need to be long, but it should explain where the issue occurs, how it can be reproduced and what security impact you believe it creates.

Please use our contact channel and clearly identify the message as a security or vulnerability report.

Recommended report content Include where possible
✓ The affected URL, feature, endpoint or application component.
✓ A concise description of the suspected vulnerability.
✓ Steps required to reproduce the observed behavior.
✓ The user role or authentication state required to reproduce it.
✓ Your understanding of the potential security impact.
✓ Relevant screenshots, requests or other technical evidence if appropriate.
Good-faith security research

Use the minimum level of access necessary to demonstrate the issue.

If you encounter a possible vulnerability, focus on confirming the existence of the security issue without unnecessarily expanding access, collecting unrelated information or affecting users.

01 / LIMIT

Limit testing

Stop once you have enough evidence to explain the security issue and allow technical reproduction.

02 / DATA

Protect data

Do not intentionally access, download, alter or retain information belonging to other users beyond what is necessary to identify the issue.

03 / REPORT

Report promptly

Share meaningful findings privately so the affected security control can be investigated and remediated.

Researcher expectations

Responsible disclosure depends on how the vulnerability is handled.

Please do

✓ Use your own accounts and information wherever possible.
✓ Keep testing proportional to the vulnerability being investigated.
✓ Stop if testing begins to affect real users or service availability.
✓ Protect any sensitive information encountered accidentally.
✓ Provide clear reproduction information in the report.

Please do not

× Use destructive techniques or intentionally damage data.
× Attempt denial-of-service or resource-exhaustion attacks.
× Use social engineering, phishing or impersonation against people.
× Access unrelated third-party systems or accounts.
× Publicly expose sensitive technical details while the issue remains unresolved.
Disclosure scope

Reporting a vulnerability is different from receiving a penetration-testing authorization.

This page provides a channel for responsible reporting. It should not be interpreted as blanket authorization to actively test arbitrary systems, infrastructure, third-party services or accounts.

01

ShabuShabu-operated systems

Reports should relate to systems or services you reasonably believe are operated by ShabuShabu.

02

Third-party platforms

Separate providers and unrelated infrastructure should be reported through their own security channels.

03

Client environments

ShabuShabu client systems are not automatically authorized for independent testing through this policy.

04

Uncertain ownership

If you are unsure whether a system belongs to us, contact ShabuShabu before performing additional testing.

What happens after reporting

From vulnerability report to remediation.

Reports are assessed based on technical reproducibility, affected security boundaries and realistic impact.

01

Receive

The report is reviewed to understand the affected system and the behavior being described.

02

Triage

We determine whether the report contains enough information for meaningful technical investigation.

03

Validate

The suspected issue is reproduced where possible and evaluated for practical security impact.

04

Remediate

If the issue is confirmed, the affected control can be corrected and further validation performed.

Coordinated disclosure

Resolve the vulnerability before increasing exposure around it.

When a valid security issue is reported, we encourage continued private coordination while the technical impact is understood and remediation is being prepared.

If future public disclosure is appropriate, timing and technical detail should be considered in a way that does not unnecessarily place users or systems at risk.

01
Confirm the issue Establish whether the reported behavior is reproducible.
02
Understand impact Identify the affected security boundary and practical risk.
03
Prepare remediation Correct the underlying security weakness where appropriate.
04
Verify the fix Check that the original attack path is no longer reproducible.
Important policy notes

Responsible disclosure is a reporting process, not an open-ended authorization.

Nothing on this page grants unrestricted permission to access systems, user information or infrastructure that you are not otherwise authorized to access.

If you need formal authorization to perform a security assessment, that activity should be covered by a defined testing engagement and agreed rules of engagement.

01 Do not assume systems are in scope simply because they reference ShabuShabu.
02 A vulnerability submission does not automatically create a commercial testing engagement.
03 No vulnerability reward or payment should be assumed unless separately agreed.
04 Stop testing if continued activity could create unnecessary operational or user impact.
Report a vulnerability

If you found something that could weaken our security, tell us privately.

Describe the affected system, the behavior you observed, how it can be reproduced and the impact you believe it creates. We will use that information to investigate the security issue and determine the appropriate next step.