Epic Games

Program Rules

###Program Eligibility

• You are not a resident of, and will not make your submission from, a country against which the United State has issued export sanctions or other trade restrictions (eg: Cuba, Iran, North Korea, Sudan, and Syria)
• Employees, former employees that separated from the company within the prior 18 months, interns, contingent workers, contractors and their personnel, or consultants of Epic Games or its subsidiaries, as well as persons living in the same household and their immediate family members, are not eligible to receive bounties or rewards of any kind under the Epic Games program

###What's allowed/permitted

• You will comply with all applicable laws and regulations
• You will let us know as soon as possible following the discovery of a vulnerability
• You will follow the disclosure guidelines defined below

###What's not allowed/not permitted

• You will not maliciously exploit any vulnerabilities
• You will not in any way access any private or confidential information pertaining to Epic, our users, and/or any third parties
• You will not conduct Denial of Service testing nor any other actions that disrupt services
• You may not do any testing that could: result in a system that is more vulnerable than it was when discovered, degrade performance, or destroy information.
• You will not conduct social engineering of any Epic employees and/or contractors
• You will not conduct physical attempts against Epic Games property or data centers

###Legal

• We reserve the right to exclude vulnerabilities for reasons that may not be included in the above list.
• The Epic Games HackerOne program will not remove or modify any bans placed on an account.
• Failure to comply with any or all of these rules may, at our sole discretion, result in ineligibility for bounties and/or removal from the program.

Report Submissions

What's required

• You will only use an account you own that has been created for security testing when demonstrating a vulnerability. ==Your test account must include the phrase “sectest” in the username.==
• Where applicable, you should use the following custom HTTP header during testing: X-Bug-Bounty: Hackerone- to differentiate your requests from those from normal users. Example: X-Bug-Bounty: Hackerone-FlyingToasters. Additional custom headers may be added to differentiate between tests or reports.
• Whenever possible, your reports should include as much information as possible regarding your tests and environment. For example: AccountID, IP, SessionID, Client Version, Client Log File, Date and Time, etc.
• When reporting vulnerabilities, you will consider (1) attack scenario/exploitability, and (2) security impact of the bug. These are crucial when determining the severity of your finding.
• You will provide detailed reports with reproducible steps. Reports which are not detailed enough to reproduce will be closed as NA.
• You may only submit one vulnerability per report unless multiple vulnerabilities are required to provide an impact.
• Testing of vulnerabilities like cheats or exploits must be done using minimal proofs of concept and without disrupting gameplay for other users.
• When testing vulnerabilities in community-driven material, like forums or profiles, you may only test on content you've created. Do not attempt to discover findings on any community content other than your own. Where possible delete any comments/posts after confirmation of findings as to not pollute pages.
• You may not use any Epic created content (such as Megascans) when performing testing on any of our digital marketplace products (Such as Fab).
• ==When testing for findings, you will not flood email forms, public forums, publish insensitive or illegal content, or any other publicly consumable content in a way that may have an adverse affect on user experience.==
• Payment bypass and/or price bypass findings will only be accepted if you are able to successfully purchase the corresponding item(s). Where applicable, the price may only be changed by 5% and changes must be limited to a single purchase. The purchase price will be reimbursed as part of your bounty if a bounty is granted.
• Any content obtained during the POC of a finding must be deleted from systems within your control upon notice of your finding being rejected or validated by Epic.
• ==In case any potentially harmful action is required to test or validate a vulnerability or bug, submit your potential finding and ask for permission prior to taking the potentially harmful action. Do not take any potentially harmful actions without the explicit permission of the Epic Games team.==

Disclosure Guidelines

You understand that you may not disclose, or permit disclosure of, your findings or contents of your submission to anyone other than Epic or the HackerOne team without prior written approval from Epic Games.

You understand that any media used to support your report should only be shared through HackerOne, and that the use of any public hosting service will be considered as unpermitted disclosure and could cause the report to be considered ineligible for bounties. If there is a need for use of a separate hosting service, please reach out to the program team for further instructions.

If you violate this agreement you will be ineligible for bounty payments, swag or any other rewards.

Bounty Examples

Please review the table below for examples of severity categories. These examples don't guarantee any bounties or severity ratings for any reports, and should only be considered as a guideline:

###General

###Fortnite

###Easy Anti Cheat

Denial of Service

Most DoS findings will be assessed at ==Medium or lower== unless there is a significant, direct impact from simple requests. We are most interested in simple requests that cause significant service disruption to players or customers.

To be eligible, a DoS submission must:

• Affect users beyond the attacker's own session, party, private server, or island
• Be triggered via public-facing endpoints
• Do not rely on volumetric traffic or sustained requests

Out of Scope

• Distributed denial of service (DDoS) using multiple source IPs or botnets
• Volumetric attacks
• Self-inflicted DoS (crashing your own session, party, private server, or island)
• DoS requiring privileged access
• Theoretical DoS without demonstrated customer impact

Severity Guidelines

All severity determinations are at Epic's discretion based on actual customer impact; CVSS scores may not be used to evaluate DoS submissions.

Scope

We generally follow the OWASP Top 10 Application Security Risks, however, we would still love to hear from you in the event that you discover a vulnerability that is out of scope. Eligibility and bounties for any finding that is not explicitly in scope will be defined by the Epic Games team. This includes any acquisition, affiliate, or subsidiary that is not under the in-scope list.

Out of Scope

• Vulnerabilities from automated scanners without additional analysis
• Vulnerabilities relying on out of date browsers/software
• Clickjacking/UI-redressing
• XSS only affecting old browser versions
• Missing or misconfigured security-related HTTP headers that do not directly lead to a vulnerability
• Mixed content warnings
• Missing cookie flags that do not directly lead to a vulnerability
• All types of brute-force and/or credential stuffing attacks (with the exception of faulty or missed rate-limiting)
• Credentials to individual end-user accounts (Eg: Epic Games Store accounts)
• Distributed Denial of Service attacks
• Fortnite UEFN Live Edit Session Crashes are considered out of scope
• Social engineering (e.g. phishing, vishing, smishing) attacks
• Physical security attacks
• SPF, DKIM, and DMARC records and flags
• Text-only injection
• Password stuffing attacks
• Bugs/Attacks requiring extremely unlikely actions by a victim (eg: Self-XSS)
• Adobe Flash related submissions
• Assets not owned by Epic Games (third party assets)

Unreal Revision Control (URC), Unreal Engine Projects, and other User Generated Projects

• Issues which rely on the victim to join a project/organization are not considered valid unless:
  • You are able to publish code to an organization you are not a member of
  • You are able to add users to an organization without their consent
• Issues relying on maintainers of projects sabotaging their own projects are not considered in scope
  • Similarly, issues relying on hijacking a high privilege account and subsequently sabotaging a project are also out of scope. The method by which ATO is achieved may be considered in scope.
• Findings due to modifications of the underlying URC framework via URC projects are considered in scope
  • Eg: Replacing executables explicitly used by URC via a project, or a project which causes it to behave in unintended ways
• Timing attacks which may briefly allow access to new organizations are out of scope
• Security issues specific to underlying IDEs are out of scope, unless the issue is unique to how URC integrates with the IDE
• Vulnerabilities caused by end of life IDEs are out of scope

HackerOne Platform Standards Deviations:

• Vulnerable Network Connection in Client Applications: Vulnerabilities that require being on the same network as a victim (“Man-In-The-Middle” -MITM- attack) will be considered on a case by case basis.

• Insecure Direct Object Reference (IDOR) vulnerability reports will be accepted only if the researcher is able to demonstrate a way to reliably obtain/guess/craft target IDs, or when demonstrating a High severity Impact.

Additional Notes

• For different attack vectors that result in the same mitigation, we reserve the right to reward the first report that is validated for that fix. All subsequent reports addressed by that mitigation will be considered duplicates, regardless of the attack vector.

• Missing or faulty Rate-limit issues will only be considered valid when affecting login or critical account related requests, and these do not include any form of 2FA. In case the 2FA control in place is also vulnerable, the issue will be assessed on a case by case basis. A valid PoC will also be required to contain: * Proof of at least 1000 accepted requests by the server in a very short time-frame. * Proof of successful login or completion of operation after said 1000+ requests.

• Web Cache Poisoning/Deception issues will only be considered valid when:

  • You’ll be able to prove that exploitation of the issue impacts other users (different IP, browser, etc.)
  • It's possible to make this attack persistent for multiple targets

• Any exploitable Zero Day vulnerabilities will only be valid if also reported to the corresponding maintainer or owner of said software/service. Zero day findings are not eligible for awards unless discovered on an in-scope asset more than 30 days after the zero day has been disclosed to the public.

• ==Cache poisoning-based denial of service attacks will be classified as low severity.== If the resulting impact causes a significant service disruption for our players and/or creators then the severity will be re-evaluated.

• Services which directly correlate to game services and game functionality generally have a higher impact than other services that would have little impact on player experience. Backend services which do not immediately impact the operation of game sessions will be considered a lower impact than those which have a direct impact on player/game experience.

• Dependency confusion submissions are only valid for first party dependencies. These submissions will receive a maximum severity rating of "Informative" unless evidence is provided which shows download attempts on Epic owned infrastructure.