Immutable Bug Bounty

Description

Immutable is a global leader in gaming, on a mission to bring digital ownership to every player and empower developers to build great games that scale. Immutable's full-stack product suite powers every stage of game creation and growth — from purpose-built blockchain infrastructure to player acquisition, engagement, and monetisation. Trusted by 700+ game studios and publishers, and the teams behind Gods Unchained and Guild of Guardians. Immutable provides an end-to-end platform that includes Immutable Chain (purpose-built gaming infrastructure), Passport (universal accounts and wallets for games), and an AI-powered Audience platform for player conversion, engagement, attribution, and revenue growth. No technology is perfect, and Immutable believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. We are excited for you to participate as a security researcher to help us identify vulnerabilities across our Immutable ecosystem. Good luck, and happy hunting! Focus Area Severity is anchored to the attacker objectives below, not to CVSS base score. P1 is limited to the closed list below. Everything else is triaged at Immutable's discretion under standard severity. Final severity is determined by Immutable. A report may qualify as P1 only if it demonstrates that an attacker can achieve one of the following outcomes: Control user funds or wallets — steal or move a user's funds, take over a linked wallet, or compromise an account in a way that reaches funds, wallets, or transferable assets. This includes bypassing Guardian, user approval, or equivalent authorisation controls. Cause unauthorised on-chain actions — get the platform to mint an asset, or submit a transaction through the relayer, that the user did not authorise. Break tenant isolation — read or modify another organisation's data, secrets, configuration, or OAuth clients. Severity is assessed based on impact and may result in downgrade. Compromise critical production systems — achieve remote code execution, or escalate privileges to internal/admin tooling or a privileged platform identity, on Immutable's production infrastructure. Duplicates and Report Quality When several reports share a root cause, Immutable has discretion over which one is rewarded as the original. We will generally reward the most complete, reproducible report, not necessarily the first one submitted. We consider: submission time whether the report could be reproduced from the steps or PoC as submitted the quality of the root-cause analysis the impact demonstrated A placeholder or partial report does not reserve priority for findings added later. Reports that share a root cause are duplicates, even if the entry point differs. A root cause is shared when one fix closes all of them. At our discretion, we may also award a quality bonus to a duplicate that demonstrates materially greater impact or provides an exceptional PoC. Testing Limits If you reach credentials or secrets, stop at proof of access. For example, show the caller identity or the name of a secret, and do not retrieve or print any secret value. Do not use any credential you obtain to access other systems. Report it, and we will treat the demonstrated reach as proven impact for severity purposes.

Targets

Testing is only authorized on the targets listed as in scope. Any domain/property of Immutable not listed in the targets section is out of scope. This includes any/all subdomains not listed above. If you happen to identify a security vulnerability on a target that is not in scope, but it demonstrably belongs to Immutable, you can report it. However, be aware that it is ineligible for rewards or points-based compensation.

Additional information

⚠️ Identity HTTP header for researchers Always include X-Bugcrowd-Username: [email protected] HTTP header with every request, including any automated tools. Example: X-Bugcrowd-Username: [email protected] . Failing that you may be refused a payout even for valid findings. This helps us with triage a lot, and it is also beneficial to researchers when dealing with duplicates, as we would be able to ascertain which request came in first. Signing up for Immutable services When interacting with Immutable resources, if you ever need to create an account, please use your @bugcrowdninja.com email address only. Failing that, you may be refused a payout even for valid findings. E.g., if you need to test for CWE-284 and have multiple accounts in your name, you can always append [email protected] in the email address. You do not need any fiat money or credit cards to conduct testing. Immutable has a faucet in the Developer Hub to disperse Test-IMX coins for testing on the zkEVM chain. No double-dipping Multiple reports stemming from the same core issue will be merged and paid out as one issue, likely with a higher impact. We would love to know about the presence of such pervasive issues. We’re keen to upgrade the severity in a single report and award such reports according to the blast radius. Example: the same library used on all Immutable sites has an XSS. We expect researchers to note that in the report instead of reporting an XSS on every domain affected. If we ourselves identify an issue reported has a greater impact, we will let the reporter know. Excluded Submission Type The following are closed as out of scope or informational. Please do not submit: Public on-chain data (all blockchain state is public; e.g. no IDOR on explorer.immutable.com) Cache poisoning HTTP request smuggling Client-side-only issues with no realistic remote path (e.g. self-XSS) Missing rate limiting without a concrete abuse scenario (incl. brute-forcing 6-digit codes on auth.immutable.com) SPF / DKIM / DMARC on non-transactional / non-auth domains Missing security headers, cookie flags, TLS/cipher config, or version fingerprinting without demonstrated exploitability Automated scanner output without a working, manually-verified exploit Clickjacking on non-sensitive pages; CSRF on non-sensitive or protected actions; open redirects without escalation Subdomain takeover without a working PoC; broken-link or social-handle hijacking Third-party tracker / pixel behaviour we embed but do not control OpenAPI / Swagger UI exposure on non-sensitive endpoints Known CVEs in third-party libraries or dependencies with no demonstrated exploit path Newly disclosed CVEs are also out of scope for 30 days after public disclosure (our patch window) Third-party services we integrate with but do not control; previously reported or known issues Submission requirements Working PoC with evidence (required) — step-by-step reproduction with screenshots or video. No-repro submissions move to needs-info and close after 14 days. Attacker scenario — who the attacker is, what they control, and the end impact, framed against the objectives above. Identity header — include X-Bugcrowd-Username: [email protected] on every request, and use @bugcrowdninja.com for any test accounts. Safe harbor, CVSS v3.1 severity mapping, vulnerability-chaining bonuses, and the no-double-dipping rule carry over unchanged.

Passport (in scope)

Passport Games on Immutable use Passport . Immutable Passport is a non-custodial wallet and authentication solution that streamlines user onboarding through passwordless sign-on and automated wallet creation. Watch our talk about Passport and the Immutable ecosystem as it will greatly help you grasp the overall architecture and threat models that are important to us. As a Web3 wallet, it lets one view NFT collections, trade, track assets, etc., but also lets one sign in to games and marketplaces. The Passport wallet is an SPA written in Typescript and uses Magic underneath for key generation and key management, while Passport’s on-chain contracts are deployed by https://github.com/immutable/wallet-contracts . The wallet traditionally allows buying/selling assets, signing/approving transactions, displaying assets at passport.immutable.com (and soon, transaction history). When shipped as an SDK, Immutable Passport is an Open ID provider and uses the Open ID Connect protocol for authentication and authorization. Games and marketplaces can integrate Passport into their platforms to authenticate users and access their wallets via approved oAuth scopes. All authentication on auth.immutable.com is handled by Auth0 . The most potent issues that can be discovered in Passport relate to key generation and use. XSS can also be potent if it lets attackers transact on behalf of the wallet user. The following properties must always hold true for a secure Passport, otherwise there is a vulnerability present: When email is used to sign in to Passport, only that email is associated with a single account, and only that account is associated with a Passport wallet. During social SSO (e.g. Google), if there is an email already registered with Passport, the two accounts will be merged. The email match must be exact. E.g. a [email protected] is not the same as [email protected] , including capitalization. A single account with Auth0 is a single account with Passport, which in turn, maps into a single Smart Contract Wallet (SCW) contract on the zkEVM chain. The Magic private key created during Passport account creation can only operate on that SCW contract and only that Magic key. Only the owner of the wallet can send/sign transactions from that wallet, before giving approval to any other third party to transact on their behalf. Only the transaction contained on the confirmation screen will ever be sent to the chain. For pre-authorized transactions, it is not possible to breach the pre-agreed maximum transfer (“approved”) limit or any other limits contractually. 1.No transactions can be sent without Immutable’s smart contract wallet signer co-signing (by Relayer). Guardian modal is always used when confirming transactions in Passport. A user is always able to link any EIP-1193 compatible Web3 wallet (e.g. Metamask) they have access to, to their Passport. One user can not deny service to another user or render their Passport unusable, including denial of service when acquiring assets. The asset that a user is buying in Passport is exactly that asset on the chain. Additionally, Passport employs the help of neighboring services that play critical role in its threat model: Guardian A modal pop-up that is shown to a user for transaction confirmation. It is meant to protect users by showing an additional confirmation popup that they have to click on. Relayer Co-signs Passport activities on-chain with Immutable’s signing key. This double signature from a user and Immutable can be checked on the chain . Developer Hub OpenID clients are created in the Developer Hub. Create your own to start testing today!

Developer Hub (in scope)

Developer Hub The Immutable DevHub empowers you to launch and manage your projects in one easy place. One can launch collections, analyze performance, tune access management and set up Passport. The Hub is another crucial part of our infrastructure as game studios use it to set up Passport. While a vulnerability in the Passport will likely affect only a single user at a time, one in the Hub may impact e.g. all gamers of a single game studio. Developer Hub features many tools: Passport OpenID, chain monitoring with webhooks, contract deployment, etc. and is thus full of attack surface. The webhooks functionality uses Amazon’s SNS underneath. The most impactful vulnerabilities in the Hub are: Broken access control through the Organizations feature. E.g. getting oneself added to any organization gets them access to the organization’s settings. There are only two roles: Owner and Member . The only difference right now is that an Owner can remove organization members. IDOR among accounts, organizations, etc. and horizontal privilege escalation SSRF in the Hub can impact our Kubernetes cluster. XSS - can change settings for a lot of Passport clients in one go.

Immutable Play (in scope)

Immutable Play serves as a central hub for gamers to explore, engage, and earn within the Web3 gaming ecosystem. Players can discover new games, join wishlists for upcoming titles, and earn rewards by completing game quests and daily engagements. The platform offers a variety of play-to-earn games, such as “RavenQuest” and other Immutable published games where players can immerse themselves in dynamic virtual worlds and communities. Additionally, Immutable Play features a rewards system where players can earn gems daily, complete quests, and unlock exclusive rewards, including IMX tokens and NFTs. Given its comprehensive features and integration with various games and reward systems, Immutable Play presents a broad attack surface. Potential vulnerabilities could impact multiple games and users simultaneously. Notable areas of concern include: • Broken access control : Unauthorized access to user accounts or game data could lead to data breaches or unfair advantages. • Insecure reward mechanisms : Flaws in the rewards system could allow exploitation, leading to unauthorized distribution of tokens or NFTs. • Cross-Site Scripting (XSS) : XSS vulnerabilities could enable attackers to inject malicious scripts, compromising user accounts or altering game content. • Server-Side Request Forgery (SSRF) : SSRF vulnerabilities could allow attackers to make unauthorized requests from the server, potentially accessing internal systems or sensitive information. Addressing these potential vulnerabilities is crucial to maintaining the integrity and security of the Immutable Play platform and its users.

Immutable (in scope)

Data Classification In the following table, the types of sensitive information are classified into four categories: Restricted, Confidential, Internal Only, and Public. For any Security Reports, we will likely evaluate the impact based on the data classification. Any Public Data should have little Security Impact hence will likely be Out of Scope. Classification │ Types │ Description │ Examples Restricted │ Personal Identifiable Information (PII) │ Information that can be used to identify an individual │ Name, address, phone number, email, Social Security Number (SSN) Restricted │ Authentication Credentials │ Information used to authenticate a user's identity │ Game Credentials, Crypto Private keys Confidential │ Financial Information │ Information related to financial transactions │ Credit card number, bank account number Confidential │ Chat/Conversation Data │ Messages exchanged between players during gameplay │ Chat logs, private messages Public │ Cryptocurrency Wallet Address │ Publicly available address used for transactions │ Ethereum wallet address, Bitcoin wallet address Public │ In-Game Purchases │ Transactional data related to in-game purchases │ NFT purchases, virtual currency purchases