Secure research starts with responsible testing.
Requirements for Complete Vulnerability Reports
Partner with Microsoft to strengthen our products and services by identifying and reporting security vulnerabilities that could impact our customers.
Note: Any vulnerability report submitted before October 20, 2026 at 8am Pacific Time will continue to be assessed under the report-quality requirements: bounty-example-report-submission. If a vulnerability report is submitted on or after October 20, 2026 at 8am Pacific Time, the report will be assessed under the new report completeness requirements on this page.
Microsoft strives to address reported vulnerabilities as quickly as possible to protect customers. The amount of time it takes Microsoft to assess a vulnerability is heavily influenced by the completeness and accuracy of the information provided with a vulnerability report. For faster triage and response, we request that security researchers submit Complete reports. Information provided after the initial submission, including in response to a request from MSRC, will not change the Complete assessment. Complete reports may also qualify for higher bounty awards, as described on each individual bounty program page.
While we prefer Complete reports, we always want to learn about vulnerabilities that affect Microsoft, so we encourage researchers to report vulnerabilities even if they are not able to provide all of the information required for a Complete report.
As a general guiding principle, narrative sections of a report (such as the analysis, exploitability, and impact descriptions) should aim to remain within approximately 5,000 characters. This is guidance, not a strict limit, and a report will not be considered Not Complete solely because it exceeds this length. This guidance is intended to encourage focused, clear submissions that still include all of the information needed for a report to be considered Complete.
The requirements on this page describe what makes a report Complete. They do not determine whether a vulnerability or bug class is in scope or eligible for a bounty award, which is governed by the Microsoft Bounty Terms and Conditions and the applicable bounty program page.
All researchers must strictly adhere to the Microsoft Security Testing Rules of Engagement. If a researcher accidentally accesses unauthorized data, the researcher should stop immediately, notify MSRC with the details, delete the data, and acknowledge this in the report. Researchers should not share the accessed information.
Requirements for Complete reports
To be considered Complete, a report must include:
- All requirements in the “Additional requirements for Complete reports” section below that apply to the product area of the reported vulnerability;
- Steps to reproduce the issue, starting from a well-known state;
- Reliable, minimized proof-of-concept;
- Type of vulnerability;
- Detailed and correct analysis, including the root cause of the vulnerability;
- Affected target environment and platform (type and version);
- Exploitability and attack conditions;
- Impact; and
- Affected component (if applicable).
Any report that does not include one or more of the above requirements will be considered Not Complete. Reports that direct MSRC to an attached report or write-up instead of completing the portal fields may be assessed as Not Complete.
Additional requirements for Complete reports
The following sections list additional requirements by product-area that a report must include for the stated vulnerability. Complete reports for each of these sections must also include the general requirements listed above.
Vulnerabilities in Endpoint & On-Prem Products
Scope includes all the Endpoint & On-Prem Products bounty programs.
| Bug Class | Additional Bug Class-Specific Requirements |
|---|---|
| Denial of Service (e.g., OOB-R, Null Deref) and Memory Corruption (e.g., OOB-W, UAF, Double Free) |
|
| File Redirection |
|
| Info Disclosure (e.g., OOB-R, Uninitialized memory use) |
|
| NTLM Coercion |
|
| NTLM Relay |
|
| Other vulnerabilities in on-prem products |
|
Vulnerabilities in Web Applications
Scope includes all Cloud bounty programs unless otherwise stated.
- At least one of the following forms of supporting evidence demonstrating the stated Impact; this evidence should clearly distinguish between impact confirmed by the PoC and hypothetical impact that has not been demonstrated:
- Video PoC (recommended);
- Diagnostic artifacts such as Burp Suite request/response logs, HTTP responses or requests, HAR file, PCAP/Network/fiddler traces
- Identifiers required to build the PoC requests such as Azure tenant, resource ids;
- Correlation ID;
- Screenshots;
- Scripts used in PoC.
Vulnerabilities in AI systems
Scope includes the Copilot Bounty Program.
- For Copilot (including Chat, Cowork, Code, and Autopilot):
- First obtain the Conversation ID by typing /id in the chat session you want to report.
- Then report the conversation to Microsoft by clicking the “I don't like something” (thumbs down) button below Copilot’s response. For the question “What went wrong”, select “Something else”. In the text box, enter “MSRC report” followed by the conversation ID obtained above.
- Your report must include the conversation ID and the exact prompt you input to Copilot, attached as a text file named prompt.txt.
Vulnerabilities involving Microsoft owned open-source software
Scope includes the Open Source Bounty Program.
- URL to the open-source repository
- PoC against a running instance of the open-source project
Explanation of information required
The following table describes each element referenced above, including what information should be provided for a report to be considered Complete. Not every element applies to every report; refer to the information above to determine which elements are required based on the product-area.
| Element | Description |
|---|---|
| Type of vulnerability | A classification of the type of vulnerability being reported, such as Use After Free, Cross-Site Scripting, and so on. For examples of vulnerability types, it may be helpful to refer to https://nvd.nist.gov/vuln/categories. |
| Affected component | The component or service that is affected by the vulnerability. This should include the component's name and any relevant version information. |
| Affected target environment | The target environment that is affected by the vulnerability, such as the operating system or application that is affected. This should include a description of the target environment, including all associated versions, builds, releases, editions, or configurations that are known or believed to be vulnerable. Where versioning does not apply, the researcher should clearly identify the affected service, endpoint, API, component, or deployment context. For Windows targets, this should include the BuildLabEx string, which is located in the Windows registry at: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BuildLabEx |
| Proof-of-concept | A description of the vulnerability in the form of text, code, or other form depending on the nature of the vulnerability. This description should include all steps required to trigger the vulnerability. Any information about how the target needs to be configured to trigger the vulnerability should also be included. |
| Reliable and minimized proof-of-concept | A proof-of-concept that reproduces the vulnerability automatically (e.g. with code) when applicable. This proof-of-concept should:
|
| Detailed and correct analysis | This analysis should correctly describe how each part of the proof-of-concept affects the target in terms of triggering the vulnerability. It should also explain how timing, environment, or other constraints affect whether the vulnerability can be successfully triggered. To the extent possible, this analysis should describe the root cause of the vulnerability. |
| Exploitability and attack conditions | Identifies who the attacker is, their starting privileges/role, the prerequisites required for the vulnerability to be exploitable, and the specific action or interaction that triggers the vulnerability. Where applicable, identifies the relevant account type, role, permission level, tenant/resource relationship, or authentication state. Include reference to any claims supported by public documentation. |
| Impact | A description of what the attacker gains or can accomplish. This description should identify the affected data, system, user, tenant, service, or security boundary and clearly outline whether the vulnerability affects the confidentiality, integrity, and/or availability of the affected system. The stated impact should follow logically from the exploitability and attack conditions. |
| Steps to reproduce the issue | An ordered and executable sequence of steps, commands, inputs, and expected results sufficient to reproduce the vulnerability. Provides all necessary details about environment setup and configuration, including any non-default settings or configurations required for the vulnerability to be reproduced. |
| Crash dump | A .dmp file captured during the fault in the vulnerable process. This should match the fault triggered when running the provided proof-of-concept. Example commands:
|
| TTD Trace | For user-mode crashes where time travel debugging (TTD) is possible, this should be a TTD capture of the faulting process. Details on how to use TTD.exe can be found here: TTD.exe Command Line Utility for Time Travel Debugging - Windows drivers | Microsoft Learn. |
| Call stack | This should be a function call stack at the point of the vulnerability. |
| PoC source code | Any proof-of-concept should include all of the source code needed to build and run the proof-of-concept. |
| Procmon log file | This should be a Process Monitor (Procmon) log showing the relevant behavior. More details on Procmon can be found here: Process Monitor - Sysinternals | Microsoft Learn. |
| PCAP | This is a packet capture showing the vulnerable network behavior described in the report. |
COMPLETE REPORT EXAMPLE #1
Title: Out-of-bounds write in Sample Image Preview Extension
Product: Windows Sample Image Preview Extension
Vulnerability type: Memory corruption, out-of-bounds write
Affected component: SamplePreview.dll, image metadata parser
Affected environment: Windows 11 Insider Preview, x64, fictional build 27xxx.1000, default configuration
Security context: A local standard user previews a specially crafted .cimg file
Summary
The fictional Sample Image Preview Extension does not validate a metadata entry count before using it to write fixed-size records into a heap allocation. A specially crafted file causes the parser to write beyond the end of the allocated buffer when File Explorer generates a preview.
The supplied proof -of-concept reliably triggers the memory corruption on the stated build. Reproduction does not require changes to memory, code, registers, execution flow, or thread state in a debugger.
Technical analysis
The parser reads a metadata entry count from the input file. It calculates the destination allocation using a validated metadata length, but the copy loop uses the original untrusted entry count. As a result, the parser can copy more fixed-size records than the destination allocation can contain.
- The proof-of-concept file declares more metadata entries than the destination can contain.
- The parser allocates a buffer using the smaller validated metadata length.
- The parser loops using the original declared entry count.
- Each iteration copies one fixed-size record into the destination.
- The copy proceeds beyond the allocation and the preview host terminates on the invalid write.
The crash evidence points to the fictional SamplePreview!CopyMetadataRecord function. The report claims memory corruption and process termination only; it does not claim code execution.
Illustrative affected source
This simplified pseudocode illustrates the fictional validation mismatch. It is intentionally non-operational and is not sourced from a Microsoft product.
CPP
// Fictional, simplified, and non-operational example.
ParseResult ParseMetadata(const FileHeader& header, ByteView metadata)
{
const size_t validatedBytes = ValidateMetadataLength(metadata.size());
const size_t recordSize = FictionalRecordSize;
Buffer destination = AllocateForExample(validatedBytes);
// The loop uses the untrusted count rather than the number of records
// that fit inside validatedBytes.
for (uint32_t index = 0; index < header.declaredEntryCount; ++index)
{
const ExampleRecord record = ReadExampleRecord(metadata, index);
CopyMetadataRecord(destination.data() + (index * recordSize),
record,
recordSize);
}
return ParseResult::Success;
}
Illustrative proof-of-concept excerpt
The full source would be attached to the report. This deliberately incomplete excerpt shows how a fictional trigger file might be generated without providing an operational file format.
PYTHON
# Fictional, incomplete, and non-operational example.
def build_test_file(output_path):
header = make_fictional_header(
magic=b"CIMG",
declared_entry_count=4096,
metadata_length=SMALL_VALIDATED_LENGTH,
)
metadata = make_minimal_example_metadata()
with open(output_path, "wb") as test_file:
test_file.write(header)
test_file.write(metadata)
if __name__ == "__main__":
build_test_file("trigger.cimg")
Steps to reproduce
- Use a clean virtual machine running the affected fictional Windows build.
- Confirm that the Sample Image Preview Extension and the File Explorer Preview pane are enabled.
- Extract the proof-of-concept package to a folder writable by the current user.
- Build the generator using the included project file, or use the supplied trigger.cimg sample.
- Open File Explorer, browse to trigger.cimg, and select the file so that a preview is generated.
- Observe that the preview host terminates and Windows Error Reporting records a crash in SamplePreview.dll.
- Restart File Explorer and repeat the test. Observe the same faulting function and call stack.
Expected result
The parser rejects the malformed metadata because the declared entry count exceeds the number of records supported by the available metadata and destination allocation. The preview host remains running and returns an invalid-file error.
Observed result
The parser accepts the declared count and writes beyond the destination allocation, causing a repeatable crash in the preview host process.
Evidence attached
- Minimized proof-of-concept source code and build files.
- Pre-generated trigger.cimg sample.
- Crash dump captured from an unmodified reproduction.
- TTD trace covering file open through the faulting write.
- Plain-text, symbol-resolved call stack.
- Debugger output showing the destination allocation and invalid write.
- README with build and execution instructions and file hashes.
- Screenshot of the target build information, including BuildLabEx.
- Short recording of the complete reproduction.
Example resolved call stack
TEXT
SamplePreview!CopyMetadataRecord+0x4a SamplePreview!ParseMetadataEntries+0x137 SamplePreview!DecodeImageMetadata+0x82 SamplePreview!GeneratePreview+0x119 PreviewHost!RenderSelectedFile+0x6d PreviewHost!PreviewWorker+0x51 kernel32!BaseThreadInitThunk+0x14 ntdll!RtlUserThreadStart+0x21
Why this report is Complete: The report identifies the affected environment and vulnerability class, provides a reliable and self-contained reproduction, includes the required memory-corruption evidence, connects attacker-controlled input to the fault, and limits the impact statement to demonstrated behavior.
COMPLETE REPORT EXAMPLE #2
Title: Cross-tenant information disclosure in deployment export API
Affected Product/Service
Product/Service: Azure Insights
Affected endpoint: https://example.azure.com/v1/exportJobs/{jobId}
Affected API version: 2026-06-01
The issue was reproduced against API version 2026-06-01. Other API versions were not tested and should not be assumed to be affected.
Description of the vulnerability
IDOR / Broken Object-Level Authorization resulting in cross-tenant information disclosure
The API authenticates the requesting user but does not enforce authorization to verify that the requested export job belongs to the caller's tenant.
Exploitability and Attack Conditions
The attacker can be an authenticated user in an Azure tenant they control. No elevated privileges in the victim tenant and no victim interaction are required.
The attacker requires:
- A valid user token issued for their own tenant.
- Access to the Deployment Insights API available to that user.
- A valid export job ID belonging to another tenant.
When the attacker submits another tenant's export job ID to the job-status endpoint using their own valid token, the API returns the export-job metadata and a SAS URL for the export despite the caller not belonging to the tenant that owns the job.
The issue was demonstrated using two researcher-owned test tenants.
Impact
The vulnerability causes a cross-tenant confidentiality boundary violation.
In the demonstrated scenario, a user authenticated to Tenant A can retrieve an export belonging to Tenant B. The returned export contains deployment information including resource names, network topology, and tags.
Confirmed impact: Unauthorized disclosure of another tenant's deployment export was demonstrated between two researcher-owned test tenants.
Potential/hypothetical impact: If export job identifiers belonging to other tenants can be identified or predicted more broadly, additional tenant deployment exports may potentially be accessible. This broader impact was not tested or confirmed. No integrity or availability impact was demonstrated.
Reproduction Steps
Test environment
- Two researcher-owned Azure test tenants were used.
- Tenant A represents the attacker.
- Tenant B represents the victim.
- No customer or third-party data was accessed.
- API version: 2026-06-01.
- In Tenant B, create an export through Azure Deployment Insights and record the resulting export job ID.
- In Tenant A, authenticate as a standard user and obtain a valid access token for the Deployment Insights service.
- From Tenant A, request the export job created by Tenant B using Tenant A's access token and Tenant B's export job ID.
- Observe that the request succeeds even though the export job belongs to Tenant B.
- The response contains Tenant B's tenant identifier and a SAS URL associated with Tenant B's export.
- Using the returned SAS URL, retrieve the export associated with the researcher-owned Tenant B.
Supporting Evidence
The following evidence accompanies the report:
- poc-video.mp4: demonstrates the complete cross-tenant flow between the two researcher-owned test tenants.
- request-response.txt: contains the relevant sanitized HTTP request and response demonstrating that a Tenant A token can retrieve Tenant B's export metadata and SAS URL.
- enumerate_jobs.py: demonstrates the reported job-ID behavior.
The PoC confirms cross-tenant disclosure of an export between the two researcher-owned test tenants.
The report does not claim that arbitrary customer exports were accessed or that broad enumeration of customer exports was performed. Any broader cross-tenant exposure beyond the controlled test scenario should therefore be considered potential/hypothetical impact rather than confirmed impact.
Why this report is Complete: It contains a working PoC, exact reproducible steps, video, scripts, and a triage summary answering impact / cross-tenant / auth / interaction up front.
COMPLETE REPORT EXAMPLE #3
Title: Cross user prompt injection vulnerability in M365 Copilot desktop app
Product: Copilot, AI + ML, and LLMs
Affected Target Environment: M365 Copilot desktop app
Type of vulnerability: Prompt Injection
Conversation ID: 6c6cdba2-10f0-418e-b876-131b43230eff
Vulnerability description
Description: An indirect prompt injection vulnerability exists in the M365 Copilot desktop app on Windows. An attacker can embed malicious instructions in an untrusted Word document, which is shared with the victim user. When the victim adds the document to a Copilot conversation and asks Copilot to summarize the document, Copilot follows the attacker-controlled instructions.
Observed behavior: The instructions cause Copilot to summarize the victim's preceding conversation, encode this in base64, and append it as a parameter to an attacker-controlled URL. Copilot outputs this URL as a clickable link, which, if clicked, would exfiltrate the victim's conversation data to the attacker.
Security impact: Information disclosure - if the victim clicks the link, their conversation data will be sent to the attacker.
Expected behavior: Copilot should not generate a clickable link that could be used to exfiltrate the victim's data to the attacker.
Steps to reproduce
- Open the M365 Copilot desktop app on Windows. For this test, I used:
- Version number: 2.20260916.24.0
- Model: GPT 5.6 Quick response
- Interact with Copilot for one or more turns. For example, I asked Copilot: "What is the weather forecast for Redmond?"
- Attach the Word document (included as an attachment to this report) and ask Copilot to "Summarize this document".
- In its output, Copilot will generate a clickable link to https://attacker.com?q=SG93IHNob3VsZCBJIGNvcnJlY3RseSByZXBvcnQgQUkgdnVsbmVyYWJpbGl0aWVzIHRvIE1TUkM/
Attachments
attacker_document.docx: The Word document containing the prompt injection.
prompt.txt: The exact prompts input to Copilot stored as a text file.
demonstration_video.mov: A video or screenshots showing all relevant aspects of the interaction with Copilot.
Why this report is Complete: The above example is Complete because it clearly identifies the affected product and includes the conversation ID. For details of how to obtain the conversation ID, please refer to the Reporting AI Vulnerabilities page.
It also includes (1) a concise list of steps to reproduce the issue, starting from the very first step of opening the application or web page, (2) any files mentioned in the report, (3) a text file with the exact prompts sent to Copilot, and (4) a video showing the full interaction.