Reporting a security issue

Decide whether this is a personal account issue or a product flaw

A personal account concern involves access or activity on your own identity. A product-security report describes behavior in the website or game that might expose information or allow an action outside its intended permissions. These can overlap, but identifying the observed behavior helps support route the case. Begin with what happened rather than a dramatic label for its severity.

If you are currently losing control of your Roblox account, secure it through Roblox first and use the compromised-account guide. If you discovered unexpected website or game behavior, preserve the smallest safe description and report it privately. You do not need to prove the maximum possible harm before the team can assess a concern.

Stop when you have enough to describe the issue

Do not access another person's account, collect their private data or alter their records to strengthen a report. A permission error involving your own account and a clear description may already be enough to begin investigation. If the behavior exposes information unexpectedly, stop browsing through it and avoid saving more than necessary.

Do not disrupt live matches, send large volumes of requests or try the behavior against many users. The purpose of a report is to help the team reproduce and correct a problem under appropriate conditions. Further testing that affects others can create a separate harm without adding useful evidence.

Write the ordinary action and unexpected result

Describe the page or feature, the account state and the action you performed. Then explain what you expected and what appeared instead. For example, a normal signed-out page view producing information you believed should require sign-in is a more useful starting description than “all accounts can be hacked.” Keep the claim limited to what you actually observed.

Include whether the behavior happened once or repeated on your own account. If you have not verified a broader impact, say so. Support can assess the potential scope without you collecting other users' records. A careful boundary between observation and inference makes the report easier to trust and investigate.

Preserve only the evidence needed

A focused screenshot or short sequence can illustrate the affected control and result. Hide passwords, verification codes, cookies, authorization values and unrelated private data. If a URL contains private query values, describe the route and action without copying those values into the ticket. Do not attach an unreviewed browser export or entire account archive.

If the evidence necessarily contains sensitive material, begin with a text description and ask within the private ticket how to provide an appropriate redacted example. Do not post it publicly to get attention. The team can request the minimum additional detail needed through the support conversation.

Use the private support route

Open a support ticket under Account security or the closest relevant category and make the subject specific. Explain that the report concerns a possible product-security issue. Keep reproduction notes in that private case rather than publishing a working method in chat, a video description or a public forum.

Do not send the report to random players claiming staff access or to an unrelated third-party form. If someone asks for credentials to “confirm” the issue, do not provide them. A legitimate investigation can begin with the affected feature, account state and observed sequence.

Explain impact without exaggeration

State which permission, data boundary or action appears affected and what you observed on your own account. Distinguish a visual glitch from a confirmed unauthorized action. A control being visible does not prove its operation succeeds; likewise, a server accepting an action is more significant than an interface merely displaying an old value.

You do not need to perform consequential actions to make that distinction yourself. Say where testing stopped. For example, explain that an unexpected control appeared but you did not submit it because it might affect somebody else. That is useful evidence and a responsible boundary for the report.

Example: an unexpected private view

Suppose you navigate normally and a page appears to show information outside the account you intended to use. Stop interacting with those records. Confirm your own signed-in username without exploring the exposed content. Note the route, approximate time, navigation action and why the visible result seemed inconsistent with your account.

Create a redacted description or image that hides the other person's details. Report it privately and state that you did not continue testing. This gives the team a place to begin while limiting further exposure. Do not contact the apparent account owner with copied private information or publish the content as proof.

Frequently asked security-report questions

Must I provide a working exploit? A clear unexpected sequence can be reported without developing a more powerful method. Let the team decide what controlled reproduction is needed.

Can I test against a friend's account? Do not expand testing into other accounts as part of this support process. Keep the report to your observations and stop before actions that could affect others.

Will I receive a reward? Do not assume a payment, recognition or program exists unless the team has explicitly published those terms. Submit the report for investigation without inventing an agreement.

Should I publish if there is no immediate answer? Keep sensitive details in the private case and follow up there. A lack of instant response does not make public exposure necessary for a useful report.

Label attachments clearly

Give each redacted attachment a short description of the screen and action it illustrates. This keeps the evidence connected to the reproduction sequence without requiring the team to infer its meaning from a filename.

Provide a report the team can act on

Use a short subject naming the feature and unexpected behavior. Include account state, device or browser, approximate time, steps, expected result, observed result and the point where you stopped testing. Add focused redacted evidence if available. Identify any claim about broader impact as an inference rather than a confirmed fact.

Keep follow-up in the same ticket and answer the team's specific questions. If a later release changes the behavior, record what you observed without repeating risky tests. The best report gives the team enough context to investigate while keeping accounts, private data and live play protected.