Program guidelines

Introduction

MUFG looks forward to working with the security community to find vulnerabilities in order to keep our businesses and customers safe.

Program highlights

Open ScopeAccepts reports for all owned assets based on impact, even if not listed in scope. [https://docs.hackerone.com/en/articles/8490833-security-page#h_46a5b35ded](

)

Gold Standard Safe HarborAdheres to Gold Standard Safe Harbor. [https://docs.hackerone.com/en/articles/8494525-gold-standard-safe-harbor-statement](

)

Coordinated Vulnerability DisclosureStandard [https://docs.hackerone.com/en/articles/9829406-coordinated-vulnerability-disclosure](

)

Top Response EfficiencyThis program's response efficiency is above 90%. [https://docs.hackerone.com/en/articles/8490880-response-target-indicators](

)

Managed by HackerOne

5 hours Average time to first response

1 day, 23 hours Average time to triage

N/A Average time to resolution

Scope exclusions

Core Ineligible Findings are out of scope. [https://docs.hackerone.com/en/articles/8494488-core-ineligible-findings](Learn more

)Category Exclusion details

Overview

Last updated on February 5, 2026. [/mufg-vdp/policy_versions](View changes

)

MUFG Public Vulnerability Disclosure Program (VDP) Overview The security and privacy of your data are our utmost concern. MUFG abides by rigorous security policies and implements robust systems to protect user data. MUFG looks forward to working with the security community to find vulnerabilities in order to keep our businesses and customers safe.

Response Targets MUFG will make a best effort to meet the following response targets for hackers participating in our program: • Time to first response (from report submit) - 2 business days • Time to triage (from report submit) - 2 business days • Time to resolution - depends on severity and complexity

We’ll try to keep you informed about our progress throughout the process.

Disclosure and Confidentiality Policy • As this is a private program, please do not discuss the program or any vulnerabilities (even resolved ones) outside of the program without express written consent from the organization. • Follow HackerOne’s disclosure guidelines.

MUFG is a complex global brand that includes many entities and products. The MUFG Vulnerability Disclosure Program is an unpaid program which is intended to allow for responsible disclosure of vulnerabilities discovered on MUFG assets. If valid, in-scope findings are reported, the reporter will be recognized with “reputation points” and may receive an invite to the private MUFG Bug Bounty Program. MUFG reserves the right to extend invitations to their private MUFG Bug Bounty Program on a case-by-case basis.

Program Rules • All of the tests must not violate any law or compromise any data that is not your own. • You must be the first reporter to report the issue to us. When duplicates occur, we only award the first report that was received (provided it can be fully reproduced). • When submitting a vulnerability, please provide detailed reports with reproducible steps for verification. If the report does not contain sufficient details to reproduce the issue, the issue may not be found valid. • Do not gain access to another user's account or their confidential information. Authenticated testing is OUT OF SCOPE for testing. • Multiple vulnerabilities caused by one underlying issue will be closed as duplicates. • Submit one vulnerability per-report, unless you need to chain vulnerabilities to provide impact. • Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. The following actions are not permitted: • Any intrusive tests or exploits that could crash or disable a service (i.e. Denial of Service) • Denial of service, spam, and social engineering (e.g. phishing, vishing, smishing) are prohibited. • Network layer Man-in-the-Middle (MITM) attacks • Testing that could result in damage to the systems or data, including modification or destruction of data, or degradation of services • Excessive network scanning that could saturate firewall connection tables or network resources • Brute-force attacks or testing of any accounts is strictly prohibited • Physical attacks against any physical facility owned by MUFG

Testing and Guidance • Testing should be limited only to the assets explicitly outlined in the scope. • Comply with Code of Conduct and Core Ineligible Findings https://www.hackerone.com/policies/code-of-conduct https://docs.hackerone.com/en/articles/8494488-core-ineligible-findings

Critical vulnerabilities examples: • SQL Injection impacting internal sensitive data • Remote code execution on server • Privilege escalation affecting all users • Broken authentication affecting all users • SSRF to internal service, with extremely critical impact, such as being able to access internal sensitive data • And other critical severity issues High vulnerabilities examples: • Privilege escalation affecting some users • Broken authentication affecting some users • SSRF to internal services • And other high severity issues

Medium vulnerabilities examples: • Privilege escalation affecting single user • Broken authentication affecting single user • XSS which could attack other users • Logical vulnerabilities affecting sensitive operations • Information disclosure of service(with customer data) • And other medium severity issues Low vulnerabilities examples: • Information leakage(without customer data) • Server misconfiguration or errors • Local denial of service or app crash • Local information disclosure on client app, like program memory, log, etc. • And other low severity issues We reserve the right to accept and review any security report including for out-of-scope issues, but we will not award a bounty for out-of-scope issues in fairness to other researchers who are adhering to program scope. This will be true regardless of the severity of the vulnerability.

Out of Scope Vulnerabilities When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope: • Validating credentials is explicitly prohibited. Please submit credentials for review and do not attempt to personally validate. • Any submission determined to be low risk, based on unlikely or theoretical attack vectors, requiring significant user interaction, or resulting in minimal impact • Reports from automated tools or scans • Best practice reports without a valid exploit (e.g. use of "weak" TLS ciphers) • Social Engineering/Phishing • Physical security • Attacks requiring MITM or physical access to a user's device • Denial of Service attacks • Missing best practices in SSL/TLS configuration • Software version disclosure / banner identification issues / descriptive error messages / missing security headers • Missing email best practices (invalid, incomplete or missing SPF/DKIM/DMARC records, etc.) • Missing Cookie Flags (Secure/HTTPOnly) • Cookie scoped to parent domain or anything related to the path misconfiguration and improperly scoped • CSRF with minimal impact i.e. login CSRF, logout CSRF, etc. • The submission of form data via HTTP sites • Clickjacking on pages with no sensitive actions • Vulnerabilities only affecting users of outdated or unpatched browsers • Any XSS that requires Flash. Flash is disabled by default in most modern browsers, thus greatly reducing the attack surface and associated risk. • Self-XSS, which includes any payload entered by the victim • Any vulnerabilities requiring significant and unlikely interaction by the victim, such as disabling browser controls • Publicly accessible login panels • Full Path Disclosure • Lack of autocomplete attribute on web forms • IP address disclosure • Private IP/Hostname disclosures or real IP disclosures for services using CDN • Cross-Origin Resource Sharing (CORS) without a valid attack scenario or Proof-of-Concept • OPTIONS/TRACE/DELETE/PUT/WEBDAV or any other HTTP Methods accepted by the server which do not specifically show a valid attack scenario • Vulnerabilities involving stolen credentials or physical access to a device • Exposed credentials that are either no longer valid, or do not pose a risk to an in-scope asset • Vulnerabilities on third party libraries without showing specific impact to the target application (e.g. a CVE with no exploit) • Security Practices where other mitigating controls exist i.e. missing security headers, etc. • Missing best practices in Content Security Policy • Content Spoofing • Stack Traces, Path Disclosure, Directory Listings • CSV Injection • Reflected File Download • Host header Injection • HTTP Trace Method • Comma Separated Values (CSV) injection without demonstrating a vulnerability • Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS • Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions • Disclosure of server or software version numbers • Hypothetical subdomain takeovers without supporting evidence • Issues that require unlikely user interaction • Missing best practices in Content Security Policy • Perceived security weaknesses without concrete evidence of the ability to compromise a user (e.g., missing rate limits, missing headers, etc.) • Previously known vulnerable libraries without a working Proof-of-Concept • Brute force issues on non-authentication endpoints • Tabnabbing • Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis. • Open redirect - unless an additional security impact can be demonstrated

Notes about IDOR Vulnerabilities Researchers must be able to prove a feasible way to gain an ID as an attacker and we will not accept reports where IDs are being brute forced. • Example: An ID is 19 characters long. To guess this ID, an attacker will have to calculate 10^19 combinations which are not in the range of an online brute force attack.

Out of Scope bugs for Android apps • Any URIs leaked because a malicious app has permission to view URIs opened • Sensitive data in URLs/request bodies when protected by TLS • Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment & root permission) • Shared links leaked through the system clipboard. • Intent or URL Redirection leading to phishing • Third party library 0day Out of Scope bugs for iOS apps • Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries • Absence of certificate pinning • Path disclosure in the binary • User data stored unencrypted in the app private directory • Lack of obfuscation is out of scope • Lack of jailbreak detection is out of scope • OAuth & app secret hard-coded/recoverable in IPA • Crashes due to malformed URL Schemes • Lack of binary protection (anti-debugging) controls • Snapshot/Pasteboard leakage • Runtime hacking exploits using tools like but not limited to Frida/ Appmon (exploits only possible in a jailbroken environment) • Third party library 0day is out of scope • URL Redirection leading to phishing • Mail headers lacking proofed impact will be accepted at our discretion. • Rate Limiting

Safe Harbor Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. Thank you for helping keep MUFG and our users safe!