T-Mobile

Description

Program Purpose T-Mobile USA, Inc. ("T-Mobile") is committed to protecting our customers, our employees, our partners, and our brand. As part of this commitment, T-Mobile works with the security community to keep our customers and business safe. If you have identified a high-impact, reproducible security vulnerability in a T-Mobile property, application, or system, we encourage you to report it. We are especially interested in vulnerabilities that could materially affect: T-Mobile customers, employees, and owned brands or acquired businesses; customer accounts, billing, identity, authentication, and line-management systems; cellular, MSISDN, SIM/eSIM, DIGITS, messaging, location, and carrier-trust workflows; T-Mobile internal, cloud, administrative, and business operations. We evaluate reported vulnerabilities and promptly take appropriate action. Scope Boundary In this policy, T-Mobile means T-Mobile USA, Inc. and its affiliates. This program is limited to T-Mobile-owned or T-Mobile-controlled assets explicitly listed as in scope. T-Mobile does not own — and cannot remediate findings on — non-T-Mobile assets, including Deutsche Telekom assets and third-party vendors. Deutsche Telekom domains, applications, systems, networks, services, subsidiaries, infrastructure, employee accounts, customer data, and corporate environments are out of scope and not eligible for bounty — even where the asset references T-Mobile, shares branding, links to T-Mobile properties, or appears related to T-Mobile business operations. Any domain, property, product, protocol, or service not explicitly listed in scope is out of scope. Submissions against unlisted assets are welcome but not guaranteed a bounty. Eligibility The following are not eligible to participate. T-Mobile determines eligibility in its sole discretion, evaluated at submission and at payment. residents of countries or regions under applicable U.S. sanctions or export restrictions; persons on the U.S. Treasury SDN List or another applicable restricted-party list; current or former employees, contractors, consultants, interns, or vendor staff of T-Mobile or any T-Mobile affiliate, regardless of when the relationship ended; current or former employees of SoftBank Group Corp. or any of its affiliates; immediate family or household members of any person in the preceding two bullets; any person bound by a current or former NDA, confidentiality, or similar agreement with T-Mobile or any T-Mobile affiliate covering T-Mobile systems, security, source code, operations, or customer/employee data; any person who has had, at any time, non-public access to T-Mobile systems, source code, vulnerabilities, security testing, internal tools, credentials, or customer/employee data; any Bugcrowd staff member with access to the T-Mobile program, and their immediate family or household members; any person who learned of, identified, or developed the finding while in any role, agreement, or access above, regardless of current status; any other person prohibited by applicable law, regulation, contract, or program rule. T-Mobile affiliate means any parent, subsidiary, predecessor, successor, acquired entity, branded MVNO, joint venture, or otherwise controlled entity of T-Mobile USA, Inc. Immediate family means spouse, domestic partner, parent, child, sibling, and step/half/in-law equivalents. Household member means anyone sharing the researcher’s residence. Submitting on behalf of an ineligible person through a proxy, agent, alt account, or third party voids the submission. Researchers must promptly disclose any fact that could affect eligibility, and T-Mobile may require identity, employment, or tax documentation as a condition of triage or payment. Ineligible submissions are void. T-Mobile may withhold unpaid rewards and, where permitted, recover amounts already paid, close associated submissions, ban the researcher, and refer the matter to Bugcrowd, law enforcement, or regulators. Program Terms Participation in T-Mobile’s Bug Bounty Program is voluntary and subject to the terms and conditions of this policy. By submitting a vulnerability report to T-Mobile, researchers acknowledge that they have read and agree to comply with this policy. T-Mobile may modify this policy at any time. Continued participation in the program after a modification constitutes acceptance of the modified policy. Submission of a security report does not create a consumer, employment, contractor, partnership, or agency relationship between the researcher and T-Mobile. All communications regarding vulnerability findings, submissions, appeals, questions, or T-Mobile Bug Bounty Program policies must be conducted through the Bugcrowd platform. Researchers must not use any alternative channel unless expressly authorized in writing by T-Mobile or Bugcrowd. Prohibited channels include but are not limited to: direct contact with T-Mobile employees or executives by any means; social-media messages or posts directed at T-Mobile personnel; T-Mobile customer, enterprise, support, sales, PR, HR, or legal channels; physical visits to T-Mobile locations; any T-Mobile contact, regardless of how it was obtained. Intent (e.g., “just a heads-up”) does not create an exception. Failure to comply may result in removal from the program, reduced or forfeited bounty payments, ineligibility for future participation, and/or other punitive actions. T-Mobile may use the contents of submitted reports for any purpose related to validation, remediation, legal obligations, regulatory obligations, contractual obligations, security operations, or protection of T-Mobile, its customers, employees, partners, products, services, or systems. Information provided to T-Mobile will be handled according to T-Mobile’s Privacy Policy. Researchers must adhere to the Bugcrowd Community Code of Conduct and Bugcrowd Terms and Conditions. If this policy conflicts with Bugcrowd disclosure guidance or platform rules, this policy controls for the T-Mobile program. Failure to comply with this policy may result in reduced reward, reward ineligibility, report closure, removal from the program, or loss of eligibility for future participation. Non-Disclosure Researchers must not publicly disclose or discuss any vulnerability, submission, or program-related information — including resolved vulnerabilities — outside the T-Mobile Bug Bounty Program without T-Mobile’s prior written approval. Disclosure requests are evaluated case by case. T-Mobile reserves the ultimate right to approve or deny any disclosure request in its sole discretion. Absent written approval, no disclosure is permitted. This restriction includes, but is not limited to, public disclosures, social media posts, blog posts, presentations, interviews, conference talks, or discussions in other public or private forums. Failure to comply with this requirement may result in removal from the program, reduced or forfeited bounty payments, ineligibility for future participation, and/or other punitive actions. Third-Party Systems and Disclosure T-Mobile does not authorize testing against third-party systems, networks, applications, products, services, or data that T-Mobile does not own or control. If a reported vulnerability appears to affect third-party software, systems, devices, or processes, T-Mobile may report the issue to the relevant third party on a best-efforts basis. When a reported vulnerability turns out to affect a third party’s software, device, or process, T-Mobile will not publicly disclose the issue for 90 days after notifying the third party, unless disclosure is required by law, legal process, or lawful government request, or T-Mobile determines earlier disclosure is necessary to protect customers, employees, partners, or the public. After 90 days, if the third party has not responded or the issue remains unresolved, T-Mobile may, in its sole discretion, publicly disclose the vulnerability and any related information it deems appropriate. T-Mobile does not pay bounties for vulnerabilities reported through a third party’s own disclosure or bug bounty process unless T-Mobile separately determines the report is eligible under this program. T-Mobile cannot guarantee that a third party will respond, remediate, communicate status, or provide safe harbor. T-Mobile cannot bind third parties and cannot defend, indemnify, or otherwise protect researchers from third-party action based on testing or disclosure involving third-party systems. T-Mobile may disclose vulnerability information when required by law, legal process, lawful government request, regulatory obligation, contractual obligation, or when T-Mobile determines disclosure is necessary to protect customers, employees, partners, systems, services, or the public. Safe Harbor T-Mobile supports good-faith security research conducted in accordance with this policy. For security research and vulnerability disclosure activities conducted consistent with this policy, T-Mobile considers that activity authorized under the Computer Fraud and Abuse Act, the DMCA, and other applicable computer-use laws. T-Mobile will not pursue civil or criminal action, or send notice to law enforcement, for accidental or good-faith violations of this policy when the researcher acts promptly to stop testing, avoid harm, avoid data misuse, and report the issue through the program. This safe harbor does not apply to activity that is unlawful, destructive, extortive, deceptive, harmful, outside program scope, or inconsistent with this policy. This safe harbor does not apply to third-party systems, networks, applications, products, services, or data that T-Mobile does not own or control. This safe harbor does not waive any rights of third parties affected by your activity. Researchers are responsible for complying with all laws applicable to them and must not disrupt services, compromise data, or access data beyond what this policy permits. Researchers should contact T-Mobile through the Bugcrowd platform before engaging in conduct that may be inconsistent with or unaddressed by this policy. Asking before testing is a significant factor in determining whether conduct was accidental and in good faith.

Targets

Business Impact Standard T-Mobile prioritizes vulnerabilities that create meaningful business, customer, operational, financial, regulatory, brand, or security impact. A report should demonstrate what an attacker can do that matters to T-Mobile, its customers, employees, partners, systems, services, or data. Technical behavior alone is not always enough. The report must connect the technical issue to a practical consequence, such as unauthorized access to sensitive data, account or line compromise, fraud, service abuse, internal system access, credential misuse, customer harm, employee impact, regulatory exposure, material financial loss, or trusted-brand abuse. Findings are less likely to be accepted or rewarded when the demonstrated impact is limited to: behavior affecting only the researcher’s own account, device, installation, or local environment; control of an inactive, unused, non-sensitive, or non-production host with no trusted traffic or meaningful abuse path; exposed credentials, API keys, tokens, or secrets that do not provide meaningful access, meaningful spend risk, sensitive data access, privileged capability, or operational impact; client-side or local application behavior that does not affect other users, backend systems, T-Mobile data, authentication, authorization, account security, or service integrity; theoretical impact without evidence of a practical attack path; low-dollar, non-repeatable, or operationally insignificant abuse with no broader customer, business, or security consequence. The same vulnerability class may receive different treatment depending on business impact. Reward Eligibility This program rewards P1 and P2 findings. P4 and P5 are never rewarded. P3 is rewarded only in two specific cases: A P3 finding that escalates to P2 under a Business Impact Modifier (Severity Rating Chart §9.1). The reward is paid at the applicable P2 amount for the asset tier. Subdomain Takeover of an active trusted-traffic host. The reward is $1,500 flat. P3 reports that do not meet either condition are closed as Informational or N/A. T-Mobile determines final priority, qualification for reward, and the applicable reward amount in its sole discretion based on demonstrated impact, evidence quality, and exploit reliability. Rating Disputes All rating and reward disputes are handled by Bugcrowd. Researchers must raise disputes through the Bugcrowd submission using Bugcrowd’s standard challenge process. Bugcrowd’s triage team is the first point of review and will escalate to T-Mobile only when a dispute cannot be resolved on the platform. Researchers must not contact T-Mobile directly to challenge a rating, reward, or submission outcome. Bypassing Bugcrowd may result in the dispute being declined. Report Relationships Duplicates Reports will be treated as duplicates when they: share the same root cause, even if they affect multiple endpoints, brands, or apps; or will be resolved by the same remediation, even if the underlying vulnerabilities are otherwise unrelated (for example, multiple findings blocked by a single WAF rule, configuration change, or other consolidated remediation). Regressions and Bypasses A regression or bypass is rewardable at 25% of the original reward when: the original issue was confirmed remediated; the new report demonstrates renewed exploitation; the behavior is not merely the same unresolved issue; the bypass appears after remediation deployment or after T-Mobile confirms the original issue resolved. Undisclosed Access Artifacts Report all secrets, credentials and similar artifacts you discover during your research for a submission, whether or not they were part of your attack chain. A later report that relies on something you found as part of your previous submission but did not disclose is not separately rewardable and is treated as part of the original submission.

Additional information

Testing Rules Required Header Researchers must include: X-Bug-Bounty: BugCrowd- Failure to include the header may reduce bounty eligibility when it materially affects attribution, traffic correlation, safety review, or reproduction. Source IP Address Researchers must include the source IP address or source IP range used for testing in each submission. If testing was performed from multiple IP addresses, VPNs, cloud hosts, proxies, mobile networks, or automated tooling infrastructure, the submission must identify all relevant source IPs or ranges used during testing. Failure to provide accurate source IP information may delay triage, prevent validation, or reduce bounty eligibility when T-Mobile cannot reliably identify, correlate, or distinguish the researcher’s traffic. Researchers must not use source IP information to hide, misattribute, or evade testing activity. Submission Template Researchers must use the current submission template. Required documentation fields include the testing timeframe (start and end of the testing activity that produced the finding), source IP information, artifacts created, and any other fields marked required in the template. "Artifacts created" includes anything left behind on a T-Mobile system from testing, listed with its location and whether it was removed. Submissions that do not use the current template, or that omit required documentation fields, will be closed by Bugcrowd, who will ask the researcher to resubmit using the correct template. Penalty Stacking A bounty may be reduced for good-faith noncompliance with any program requirement — including documentation gaps, incomplete testing detail, or any other shortfall that impedes T-Mobile’s ability to attribute, correlate, validate, or reproduce a finding. No single shortfall carries a fixed penalty; reductions are proportionate to impact and, for good-faith submissions, will not combine to exceed 50% of the bounty. Separately, T-Mobile reserves the right to withhold, reduce, or deny a bounty where a report involves bad-faith testing, unsafe testing, evasion, deliberate prevention of attribution or reproduction, or prohibited conduct. This is reserved for bad-faith conduct — good-faith researchers who make an honest mistake are not the target of this provision. T-Mobile may waive penalties when the researcher provides sufficient alternative evidence or when the testing context made compliance impractical. Automated Tooling Maximum automated tooling rate: 5 requests per second. Higher rates, fuzzing, or testing likely to affect service require prior written approval. Data Handling Researchers must test only accounts, lines, devices, data, and systems they own or are authorized to use. Intentional access to T-Mobile Customer or Personal Information other than the researcher’s own information is prohibited. T-Mobile Customer or Personal Information means any data obtained from T-Mobile, on T-Mobile’s behalf, or generated by a T-Mobile customer, consumer, employee, account, household, device, or line that is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, to an identified or identifiable individual, household, device, line, or T-Mobile account. If T-Mobile Customer or Personal Information is inadvertently discovered, uncovered, or accessed, researchers must: stop testing immediately; cease any activity involving the T-Mobile Customer or Personal Information or the vulnerability; immediately report the discovery, access, or acquisition in the submission; provide enough detail for T-Mobile to identify and remediate the issue; not retain, copy, use, disclose, download, exfiltrate, or further access the information. Researchers must not modify customer accounts, production data, account settings, line settings, billing settings, or service state except within accounts, lines, devices, or data they own or are authorized to use. Intentional modification of customer accounts or unauthorized access to customer data may result in reduced reward, ineligibility, removal from the program, or other action. Prohibited Conduct Researchers must not: violate any law or regulation; violate T-Mobile’s Terms of Service or Privacy Policy; disrupt, degrade, or interrupt T-Mobile services; destroy, corrupt, alter, or exfiltrate data; contact, spam, or attempt to deceive T-Mobile customers or potential customers; engage in phishing or social engineering of T-Mobile customers, employees, contractors, vendors, or partners; perform physical attacks against T-Mobile infrastructure, stores, offices, property, or data centers; perform aggressive vulnerability scans or automated scans outside the published rate limits; perform automated credential guessing, credential stuffing, password spraying, or high-volume brute-force attacks; use a finding to compromise the security of T-Mobile, T-Mobile customers, or T-Mobile systems beyond the minimum proof necessary for the report. Prohibited conduct is a basis for immediate suspension, ban, forfeiture of unpaid rewards, and referral to Bugcrowd, law enforcement, or regulators. In cases of fraud or ineligibility, T-Mobile may also seek recovery of amounts already paid, where permitted. Report and Communication Standards This applies to submissions and to all follow-up communication (comments, replies, dispute responses). Content in a submission or any follow-up communication must reflect the researcher’s own testing and analysis. AI-assisted drafting is permitted; researchers remain responsible for every claim, endpoint, PoC step, request, response, and impact assertion. Bugcrowd may close a report, and T-Mobile may deny or revoke a bounty, when the report or a subsequent communication: contains fabricated, hallucinated, or unverifiable endpoints, parameters, requests, or responses; presents unverified AI-generated content as testing results or as engagement with the triager’s reasoning; repeats an argument after it has been addressed by the triager; restates the finding in longer form rather than engaging with the specific reasoning given; is excessively verbose, off-topic, or buries the actual point; is hostile, personal, or abusive; copies content from scanner output, public disclosures, or other researchers’ reports without attribution and independent validation. Repeated abuse of the report or communication process may result in report closure, forfeiture of pending rewards, and program removal. Non-Production Environments Findings against non-production systems are evaluated under the Severity Rating Chart §7 Environment Rules — synthetic or test-only data is closed as P4/N/A, while production data found in a non-production environment is treated as production impact. Access and Test Accounts Researchers may self-register a T-Mobile account using an @bugcrowdninja.com email address. T-Mobile accounts are not provisioned by Bugcrowd or T-Mobile. Postpaid lines, prepaid lines, SIM cards, phones, hotspots, hardware, and IoT devices must be purchased by the researcher.

Special Target (in scope)

Special Target objectives are predefined, business-critical outcomes eligible for T-Mobile’s highest rewards. These are not ordinary assets. They require exact evidence and strict qualification. Special Target rewards supersede Core and Supplemental asset-tier bands when both could apply. Reports that do not meet Special Target qualifying evidence are evaluated under the applicable asset tier. Special Target Reward Priority │ Reward P1 │ $133,700+ A Special Target report qualifies under one of three scenarios, each with its own evidence requirements: T&P Flag Servers (Temporarily Out of Scope) Cellular Network Authentication Bypass Self-Register Account on T-Mobile Microsoft Entra ID T&P Flag Servers (Temporarily Out of Scope) A report qualifies only when the researcher retrieves the contents of flag.txt from a listed T&P flag server. Current targets: http://10.72.218.66/flag.txt http://10.62.252.214/flag.txt Required evidence: full attack path; proof of flag retrieval; timestamp; source asset or vector used to reach the flag; reproducible steps or requests. Private IP reachability alone is not sufficient unless the required flag contents are retrieved. Cellular Network Authentication Bypass This scenario applies to authentication bypasses involving cellular-network identity, SIM/eSIM trust, MSISDN trust, device identity, or carrier-authenticated context. Current authorized MSISDN for safe testing: 404-200-7239 The authorized MSISDN is a production testing target for this objective. It is not a lower-severity test environment or reduced-impact account. Required evidence — one video demonstrating: the affected mobile or web workflow; the authentication bypass path; the account profile, settings, and line visibility. Self-Register Account on T-Mobile Microsoft Entra ID A report qualifies when the researcher self-registers or creates an account in T-Mobile’s Microsoft Entra ID (corporate identity) tenant without authorization. Required evidence: proof of the self-registered or created account in the T-Mobile Entra ID tenant; the account identifier (UPN / email) created; the registration path or flow used; any tenant access, group membership, application, or resource the account can reach; timestamp and reproducible steps or requests. Existence of a public sign-up or guest-invite page alone is not sufficient — the researcher must demonstrate a usable account provisioned in the T-Mobile tenant.

Core Assets (in scope)

Core Assets are high-value T-Mobile systems supporting customer accounts, billing, authentication, APIs, business workflows, carrier services, or major customer-facing products. Core Web/API Assets t-mobile.com account.t-mobile.com *.api.t-mobile.com metrobyt-mobile.com sprint.com tfb.t-mobile.com devedge.t-mobile.com tess.service-now.com digits.t-mobile.com account.business.t-mobile.com Core Mobile/Desktop Assets T-Life iOS T-Life Android DIGITS Mobile/Desktop DIGITS auth bypass routing. DIGITS authentication bypasses are evaluated under Core Mobile/Desktop Assets unless the submission demonstrates bypass of the cellular-network, SIM/eSIM, MSISDN, or carrier-authenticated trust layer — in which case the report routes to Special Target Cellular Network Authentication Bypass. Core Reward Band Priority │ Reward P1 │ $55,000 P2 │ $35,000

Supplemental Assets (in scope)

Supplemental Assets are T-Mobile-owned, T-Mobile-operated, acquired, transitional, lower-priority, or limited-support assets where T-Mobile has remediation ownership but where expected business impact is lower than Core. Supplemental Asset Intake Criteria An asset may enter Supplemental scope when: T-Mobile or a T-Mobile-controlled entity owns or operates it; T-Mobile has a remediation owner; the asset is internet-accessible or otherwise researcher-testable; exploitable vulnerabilities could plausibly affect T-Mobile customers, employees, partners, corporate data, brand, service integrity, or business operations. Newly acquired or M&A-related assets enter Supplemental by default unless T-Mobile designates them Core. Current Supplemental Assets *.t-mobile.com , except listed Core assets *.metrobyt-mobile.com , except listed Core assets *.sprint.com , except listed Core assets assurancewireless.com *.assurancewireless.com *.uscc.net *.uscc.com *.uscellular.com dashboard-101.moengage.com api.vistarmedia.com api.vistarmedia.eu production-dynam-creative.vistarmedia.com storybook.vistarmedia.com creatives.vistarmedia.com production-delivery-metrics-svc.vistarmedia.com maps.vistarmedia.com transcodes-cdn.vistarmedia.com assets-cdn.vistarmedia.com staging-trafficking.vistarmedia.com job-svc-b.vistarmedia.com docsite.vistarmedia.com audience-builder.vistarmedia.com staging-login.vistarmedia.com packages.cortexpowered.com sflower.cortexpowered.com sfleet.cortexpowered.com docker-staging.adstruc.com clients.adstruc.com demo.adstruc.com blis.com platform.blis.com platform.development.blis.com platform.development2.blis.com platform.rc.blis.com internal.platform.blis.com assets.platform.blis.com assets.platform.development.blis.com assets.platform.rc.blis.com audiencelogos.blis.com imply.blis.com imply-pivot.blis.com imply-pivot.test.blis.com imply.internal.platform.blis.com imply.platform.blis.com imply.platform.development.blis.com imply.platform.rc.blis.com imply.test.blis.com jenkins-github.gcp.blis.com signature.blis.com sitepixel.blis.com sitepixel.dev.blis.com platform.blismedia.com privacy.blismedia.com creative.infinity.blismedia.com wmaudience.com rc.wmaudience.com development.wmaudience.com imply.wmaudience.com wiki.atom-lens.com assets.development.amazon-tacticalplanner.com Supplemental Reward Band Priority │ Reward P1 │ $20,000 P2 │ $12,000

Static Bug-Class Rewards (in scope)

These rules apply across in-scope assets and override the asset-tier reward when the bug class matches. Where a rule delegates back to the asset tier, the matching Core or Supplemental band is used. Subdomain Takeover Reward eligibility requires demonstrated control of content or service behavior for an in-scope T-Mobile subdomain. Scenario │ Priority │ Reward Dangling DNS only; no takeover possible │ N/A │ $0 Takeover of inactive, parked, non-sensitive, or zero-traffic host │ N/A │ $0 Takeover of active host serving customer, employee, partner, auth, download, or brand-sensitive traffic, with traffic evidence │ P3 │ $1,500 Takeover enabling credential theft, customer-data access, malware distribution, trusted service abuse, or auth flow compromise │ P1/P2 │ per applicable asset tier (Core or Supplemental band) Active trusted traffic means the researcher provides observable evidence that the takeover would be reached by real users, customers, employees, partners, or in-product flows — for example referrers, in-app links, current marketing or email campaigns, OAuth callbacks, download endpoints, or measured DNS/HTTP request volume. Hostnames that look active but cannot be shown to receive trusted traffic do not qualify. What counts as active trusted traffic evidence (observational — no data collection required): referer or origin data captured from your own browser session while navigating T-Mobile’s own products (in-app clicks, email link clicks, download flows); documented in-product links, marketing emails, push notifications, or CDN configuration pointing at the takeoverable host; OAuth/OIDC redirect targets or download endpoints configured in T-Mobile source or first-party JavaScript; your own DNS query counts against the host over a reasonable window; passive DNS from established datasets (PassiveTotal, DomainTools, Censys DNS) showing active resolver history. Not required, and not permitted: capturing traffic that contains other users’ credentials, session tokens, cookies, PII, or business data; serving content that would deceive real users, capture their input, or interfere with their session; collecting credentials, customer data, or third-party data of any kind to prove impact. If the takeover is real and the host is real, both bars can be satisfied without ever intercepting a third-party request body. This is the only P3-eligible bug class in the program. All other subdomain takeover reports are either N/A or escalate to P2/P1 under the Severity Rating Chart.

Mobile Targets (in scope)

Mobile findings are rewarded based on the affected backend, account, data, or business function — not solely the app binary. Mobile Reward Mapping Mobile App │ Default Asset Category T-Life iOS / Android │ Core DIGITS Mobile / Desktop │ Core If a mobile vulnerability terminates against a backend API, reward is based on the backend asset category and demonstrated impact. Client-side-only findings are not normally rewarded unless they affect other users, T-Mobile systems, sensitive customer data, authentication controls, or backend trust. Mobile Issues Not Rewarded lack of certificate pinning; lack of obfuscation; lack of jailbreak/root detection; local storage issues requiring a compromised device; mobile OS vulnerabilities; attacks requiring rooted/jailbroken devices; memory dumps requiring an already-compromised device; client-side secrets that are invalid, public, expired, or not sensitive.

Restricted Targets (out of scope)

Restricted Targets are not eligible for bounty. Some targets are restricted temporarily and may return to scope; others are restricted permanently. Suspended Targets Suspended Targets are temporarily ineligible while undergoing remediation, migration, review, noise reduction, ownership validation, or third-party boundary review. After review, T-Mobile may return the target to scope, keep it suspended, move it to another asset category, or move it to Removed. Asset / Pattern │ Reason /self-service-* API paths (any host) │ remediation/review flag servers │ improvements/review Removed Targets Removed Targets are permanently ineligible. T-Mobile is not seeking reports against these targets and will not reconsider scope absent significant business change. Asset / Pattern │ Reason *.sprint.net │ legacy *.mobile.uscc.net │ customer leased *.mobile.uscc.com │ customer leased appointments.uscellular.com │ excluded from *.uscellular.com *.moengage.com , except listed Supplemental asset │ third-party/SaaS boundary

Categorical Exclusions (out of scope)

This section lists two categories of submissions: Never rewarded — categorically not eligible for bounty regardless of impact, asset, or evidence. Conditionally rewarded — eligible only when the researcher demonstrates the specific impact called out for that category. Web/API Issue Types — Never Rewarded Web and API assets are in scope. The following specific issue types are categorically not eligible for bounty, regardless of asset, impact, evidence, or whether they appear as part of an attack chain: automated scanner output without working proof of exploitability; missing security headers; missing cookie flags on non-sensitive cookies; OPTIONS or TRACE enabled without demonstrated exploit; weak TLS configuration without demonstrated exploit; expired TLS certificates; outdated software/library version without working exploit; clickjacking on pages with no sensitive data or state-changing action; unauthenticated/login/logout CSRF; autocomplete on forms; lack of email verification during registration; self-XSS; XSS whose payload reaches the victim through an attacker-operated delivery channel, or where exploitation requires the victim to load or interact with an attacker-controlled page; credentials from public breaches or known credential lists. Availability / Disruption Activities — Never Rewarded DoS/DDoS; high-volume scanning; service degradation testing; destructive testing; spam; bulk scraping; customer/employee contact. Social / Physical / Third-Party Activities — Never Rewarded attacks whose exploitation requires phishing, pretexting, or otherwise persuading a T-Mobile employee, contractor, vendor, partner, or customer to take an action outside the normal use of the product; physical attacks; attacks requiring physical access to a victim device; attacks requiring MITM unless explicitly authorized; vulnerabilities only in third-party systems T-Mobile cannot remediate; Deutsche Telekom assets. Conditionally Rewarded Issue Types The following are rewarded only when the researcher demonstrates concrete exploitability resulting in P1 or P2 impact under the Severity Rating Chart: open redirects — require token theft, credential theft, or trusted-domain abuse; content spoofing / text injection — require HTML/CSS/script control or meaningful abuse; tabnabbing — require demonstrated victim impact; CSV injection — require demonstrated exploitability against a real downstream consumer; cache poisoning — require demonstrated impact on real users; XSS — in scope only when all three hold: the payload executes in another user's authenticated session or chains to account takeover; the payload can be triggered by a T-Mobile-controlled URL alone; and the payload is delivered to the victim through a T-Mobile-operated channel (i.e., T-Mobile's own stored content, messaging, or infrastructure serves it). OAuth/OIDC flow misconfigurations (open redirects in auth flows, PKCE bypass, state parameter manipulation, token leakage via referrer) — require demonstrated credential or token theft, authentication bypass, or account takeover; leaked credentials — require credentials that are valid, non-public and not from breach lists, tied to T-Mobile or an in-scope asset, and usable to access an in-scope system, sensitive data, privileged capability, or meaningful business function.