Centers for Medicare & Medicaid Services - Public Bug Bounty Program 2026

Description

Purpose: The goal of the 2026 CMS Bug Bounty is to improve the security posture of CMS information systems by proactively identifying and mitigating vulnerabilities prior to adversarial exploitation through monetary incentives for security research. This engagement invites security researchers to mimic hacker behavior to identify and report on vulnerabilities in select CMS systems. This approach provides an additional layer of scrutiny beyond CMS’ internal security tools and practices. Researchers with diverse expertise also apply new, innovative and different methods to identifying vulnerabilities. Researcher Restrictions: This is a public program. Anyone may submit vulnerabilities for consideration, but bounty payments are subject to eligibility requirements. CMS and the vendor (Bugcrowd) do not conduct background checks. Instead, eligibility is enforced through sanctions screening, platform restrictions, researcher attestation, and payout controls. By participating in this engagement, you agree to the terms contained in this Rules of Engagement (ROE) prior to engaging in authorized security research conducted under the CMS program, including but not limited to the restrictions listed below: Citizenship: While security researchers are not required to have U.S. citizenship, they may not hold citizenship from, or reside in the following countries: Afghanistan, Central African Republic, China, Cuba, Cyprus, Democratic Republic of Congo, Eritrea, Haiti, Iran, Iraq, Lebanon, Libya, North Korea, Russia, Somalia, South Sudan, Sudan, Syria, or Zimbabwe. Watch List: Researchers may not appear on the U.S. Treasury’s “Specially Designated Nationals” (SDN) list and may be vetted by the DHS National Targeting Center. Criminal Background: Researchers may not have been convicted of a misdemeanor or felony and must be cleared by the vendor per the vendor’s policies and practices. Experience: Researchers of all levels of experience are welcome. Affiliation: If a current Federal employee or contractor, researchers may need Counsel consultation and approval. Current CMS Federal employees and contractors may not participate in the 2025 CMS Bug Bounty. Equipment: Must be done on personally owned devices. Skills: Researchers must possess the knowledge, skills, and abilities most applicable and valuable for the goals of the engagement and the specific assets and areas of focus. Ratings/Rewards: To be eligible for rewards, all reports must include a POC that can be replicated by authorized Bugcrowd and CMS personnel. All information required to reproduce each vulnerability must be submitted prior to the program closing. Any reports requiring more information after the program has ended will not be considered for a reward. CMS will evaluate the plausibility, existence, and status of vulnerabilities submitted for bounties and reserves the right to make all decisions regarding vulnerability validity, status, and eligibility for bounty payment. CMS reserves the right to end the payment of bounties at any time. Bounty awards will be prioritized based on the submission timestamp for the initial instance of each unique vulnerability. Findings already documented or known to the CMS team will not be eligible for bounty payments. Duplicates: Researchers are encouraged to report all vulnerabilities that they find and to re- test after CMS has remediated the issue. Additional bounties will not be awarded for retesting the same vulnerability unless new or related issues are discovered. Vulnerabilities that share the same root cause and affect multiple sections or areas of a website will be treated as duplicates. In such cases, only the first instance of the vulnerability will be eligible for a bounty, though reporting additional instances is still encouraged to support comprehensive remediation efforts. A global fix is recommended to address the root cause across all affected sections. For the initial prioritization/rating of findings, this program will use the Bugcrowd Vulnerability Rating Taxonomy . However, it is important to note that in some cases a vulnerability priority will be modified due to its likelihood or impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher - along with the opportunity to appeal, and make a case for a higher priority. Bounty Table The bounty for each vulnerability is set on a sliding scale according to criticality. Priority │ Impact │ Vulnerability Examples │ Bounty Amount P1 │ Provide proof that a vulnerability is present on an in-scope asset │ Command Injection, SQL Injection, Remote Code Execution │ $5,000 - $7,000 P2 │ Provide proof that a vulnerability is present on an in-scope asset │ Directory Traversal, Poor Encryption Standards │ $2,500 - $3,500 P3 │ Provide proof that a vulnerability is present on an in-scope asset │ Reflective XXS with impact, Direct Object Reference, URL Redirect, CSRF with impact │ $1,000 - $2,500 P4 │ Provide proof that a vulnerability is present on an in-scope asset │ SSL Misconfigurations with little impact, SPF configuration problems, XSS with limited impact, CSRF with limited impact │ $250 - $500

Targets

Testing is authorized only on the targets explicitly listed as in scope. All systems and services associated with those domains, including their subdomains, are in scope unless explicitly excluded. Websites that are CMS-owned or CMS-managed and link to this policy are also considered in scope. Additional Clarifications and Examples: Vendor-operated or third-party systems are excluded from this program, even if: They are linked from CMS.gov or other CMS websites Any vulnerabilities discovered in these systems should be reported directly to the vendor through their disclosure policy (if available). No bounty will be awarded for such findings. Third-Party Platforms: Systems hosted or operated by vendors such as Salesforce, ServiceNow, or Atlassian (e.g., *.my.site.com, *.service-now.com, *.atlassian.net). Linked Vendor Sites: Contractor-managed resources linked from CMS.gov, including FAQs, training materials, or help centers, remain out of scope. Vendor Systems Using CMS Credentials: External vendor platforms that allow login with credentials are excluded unless explicitly listed as in scope. Redirects and Third-Party Infrastructure Any testing activity that targets, follows, or results in interaction with third-party or vendor-managed systems is out of scope. This includes, but is not limited to: Redirects from in-scope CMS domains to external systems Proxying, API calls, or backend interactions that traverse into vendor-managed infrastructure Direct access to vendor systems through URLs, endpoints, or infrastructure not explicitly listed as in scope Researchers must not test, interact with, or attempt to access these systems, even if they are reachable from or initiated through an in-scope CMS domain. Findings involving such systems are not eligible for bounty. These reports should be directed to the vendor in accordance with their disclosure policy (if any). Any CMS domain or asset not listed bove is out of scope. If a security researcher identifies a vulnerability in a system outside the scope, they are encouraged to report the issue through the vendor’s reporting mechanism. However, no bounty will be paid for such reports. The vendor may be able to assist with the reporting of these vulnerabilities. Targets may be added or removed while the program is active, though changes are typically made during designated pause windows. These windows allow CMS and Bugcrowd to reassess scope, adjust priorities, and refine test focus areas. Bounty Eligibility The following are not eligible for bounties: Any findings discovered outside of the Scope. These may be reported through the CMS Vulnerability Disclosure Program here . Duplicates: Vulnerabilities that share the same root cause and affect multiple sections or areas of a website will be treated as duplicates. In such cases, only the first instance of the vulnerability will be eligible for a bounty, though reporting additional instances is still encouraged to support comprehensive remediation efforts. Access/Credentials User accounts will not be provided for testing Wherever possible, researchers should include text 'Bugcrowd Bug Bounty' or 'BugcrowdCMS' in plaintext in order to deconflict logging data where true source IP may not be present Credential Use & Authentication Restrictions: Researchers are prohibited from using leaked, breached, or exposed credentials to access CMS systems, even if discovered via open sources. Any attempt to log into systems using such credentials will be considered out of scope and a potential violation of federal policy. Submissions based on login or account takeover from third-party leaks (e.g., Telegram, data dumps) will be rejected. Third-Party & Leaked Data Restrictions Vulnerabilities supported by data from private, invite-only, or unauthorized sources (e.g., Telegram groups, breach forums) are not accepted. Only information gathered from publicly accessible and legally obtained sources is permitted. Scope of Findings Scope of Findings: Sensitive vs. Non-Sensitive Data Non-Sensitive Public Documents: Documents that are publicly accessible and do not contain sensitive data, such as Personally Identifiable Information (PII), Protected Health Information (PHI), or confidential information, will not be considered valid findings. Any content labeled as “INFORMATION NOT RELEASABLE TO THE PUBLIC UNLESS AUTHORIZED BY LAW” that does not pose a security or privacy risk, such as general trends, findings, or procedural information, is also not valid for reporting under this engagement. Duplicate findings on public documents will not be accepted unless new sensitive data is identified. Sensitive Data Considerations: Findings involving sensitive data, such as the following, are considered valid: Personally Identifiable Information (PII): PII is any data that could individually or, when combined with other elements, identify a consumer. Examples include a consumer’s name, address, telephone number, Social Security Number, Marketplace application ID, or other identifiers. Consumers have the right to access, inspect, and/or correct their PII upon request. Assisters, such as Navigators or certified application counselors, are only permitted to create, collect, disclose, access, maintain, store, and use consumer PII for authorized purposes or with the consumer’s informed consent. Below is a list of examples of PII that security researchers may encounter (this is not exhaustive): Name Birth date Social Security number Alien Registration Number Home address Email address Phone number Electronic or paper federal tax returns (e.g., 1040, 941, 1099, 1120, and W2) Medicaid/CHIP eligibility status Citizenship or immigration status Applicant ID Household income Qualified health plan (QHP) eligibility status Advanced payments of the premium tax credit/cost-sharing reduction (APTC/CSR) eligibility status Spoken and written language preference Tobacco usage Protected Health Information (PHI): The Privacy Rule protects PHI that is held or transmitted in any form, including electronic, paper, or verbal. PHI includes: Common identifiers, such as name, address, birth date, and Social Security Number Information about the patient’s past, present, or future physical or mental health condition Details on healthcare services provided to the patient Information regarding past, present, or future payment for the healthcare provided to the patient Financial Information: Bank account numbers, credit card details, tax information, and financial transaction records. Authentication Data: Passwords, PINs, and security questions/answers used for system access. Government Data: Classified information and national security-related data. Researcher Guidelines To be provided safe harbor as described below, researchers must read and agree to abide by the guidelines in this ROE. Researchers Must: Immediately cease all actions if and/or when a system is removed from scope Respect the periods of availability and blackout dates. Any vulnerabilities discovered or reported during blackout dates or after a system has been removed from scope will not be eligible for bounties Avoid destructive or disruptive actions to CMS information systems and operations Refrain from exploiting any vulnerability beyond the minimal amount of testing required to prove its existence or to identify a related indicator. This means that researchers must: STOP from exploiting any vulnerability if successfully able to move laterally or vertically. 1.Provide details of exploit and await approval to proceed with escalation Avoid intentionally accessing the data, information transiting or stored on CMS information systems, or content of any communications, except that which is directly related to a vulnerability and access is necessary to prove that the vulnerability exists. If a researcher encounters sensitive information, they must immediately stop and report within the confines of the program Refrain from exfiltration of data under any circumstances. This includes screenshots that may include sensitive data. Avoid intentionally compromising anyone’s privacy or safety Avoid intentionally compromising the intellectual property or other commercial or financial interests of any CMS personnel or entities or any legitimate third parties Refrain from disclosing any details or information outside the terms agreed upon by CMS per the ‘Coordinated Disclosure’ provision below. Researchers must obtain explicit permission from CMS prior to disclosure of any results of a submission Understand that any original submissions may be subject to separate disclosure by CMS under the Freedom of Information Act (FOIA) Researchers May: Test in-scope CMS information systems in order to detect the vulnerability or identify an indicator related to the vulnerability for the sole purpose of providing [CMS] information about such vulnerability. Report a product vulnerability to the affected vendor or a third-party vulnerability coordination service if a vulnerability is discovered in a CMS information system consequent to the product vulnerability or in a generally available product in order to enable the product to be fixed. Researchers May Not: Use leaked credentials to test or login to any accounts that do not belong to them Employ Distributed Denial of Service (DDOS) Employ social engineering attacks, such as phishing, attempts to compromise passwords, or any distribution of malware Attempt lateral movements to other systems Attempt to bypass or disable rate limiting controls, or conduct stress testing. These protections are in place to ensure system stability and prevent unintentional Denial of Service (DoS). Attempt to physically access a CMS or hosting provider facility Test any systems or vulnerabilities not in scope Typical Out of Scope Vulnerabilities Theoretical vulnerabilities Informational disclosure of non-sensitive data Low-impact session management issues Self-XSS (user-defined payload) Coordinated Disclosure In conjunction with this ROE, the Information Security and Privacy Group commits to allowing researchers to publish mutually agreed information regarding a vulnerability after it has been remediated. CMS requires all researchers to obtain explicit permission from CMS prior to disclosing any knowledge gathered from this engagement, including vulnerabilities, indicators of vulnerabilities, data, architecture, or other system-related information. This applies to all the submissions for the program, regardless of validity or acceptance. For any vulnerability discovered through this engagement to be disclosed, all parties (CMS, the Information Security and Privacy Group, and security researcher) must agree upon the date of disclosure and the disclosure level (i.e., limited or full) and the method of disclosure. Once the vulnerability or exploit is made public by CMS, the researcher may disclose the vulnerability or exploit publicly if it adheres to the agreed level of disclosure—limited or full—and any other parameters agreed upon for the disclosure. Safe Harbor: If a researcher makes a good faith effort to comply with these ROE, CMS considers their actions to be: Authorized under the Computer Fraud and Abuse Act (CFAA) (and/or similar state laws related to authorized access on information systems), and CMS will not recommend or pursue legal action against security researchers for accidental and good faith violations of this policy; Authorized and therefore CMS will not bring a claim against the researcher under the Digital Millennium Copyright Act (DMCA) for circumvention of technology controls; and Exempt from restrictions in relevant Terms & Conditions that would interfere with security research conducted in accordance with this policy, and CMS will waive those restrictions on a limited basis for work done under this policy. Lawful, helpful to the overall security of the Internet, and conducted in good faith as stated in the CMS Vulnerability Disclosure Policy (VDP) If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please inquire via [email protected] before going any further.