Introduction
Security researchers play a vital role in protecting cloud ecosystems. However, when a vulnerability report is rejected by a vendor like Microsoft, it can be frustrating—especially if a silent fix later appears without a CVE acknowledgement. This guide walks you through the process of reporting a potential Azure vulnerability, what to expect from Microsoft's response, and how to handle a rejection professionally, drawing lessons from a real incident involving Azure Backup for AKS.
What You Need
- Microsoft Security Response Center (MSRC) account – Register at msrc.microsoft.com.
- Detailed proof of concept (PoC) – Clear steps to reproduce the vulnerability.
- Supporting evidence – Screenshots, logs, network captures, or code snippets.
- Understanding of Microsoft’s vulnerability classification – Familiarize yourself with what constitutes a security flaw vs. expected behavior.
- Patience and persistence – Responses may take weeks or months.
- Backup communication channels – Consider public disclosure only after 90 days or per your policy.
Step-by-Step Guide
Step 1: Prepare Your Report Thoroughly
Before submitting, ensure your report is complete and objective. Include the exact steps to reproduce the issue, affected Azure services (e.g., Azure Backup for AKS), software versions, and any configuration details. Attach logs and a working PoC. Remember: vendors are more likely to act on reproducible, high-impact findings. In the case of the Azure Backup vulnerability, the researcher provided evidence of unintended privilege escalation, but Microsoft classified it as “expected behavior.”
Step 2: Submit Through MSRC Portal
Use the official MSRC vulnerability reporting portal. Fill in the mandatory fields: vulnerability type, impact, affected product (e.g., Azure Kubernetes Service), and your contact info. Upload your PoC and evidence. You can also report via secure email if preferred. Keep a copy of your submission ID for tracking.
Step 3: Await Initial Response and Triage
Microsoft typically acknowledges receipt within 24–48 hours. Their security team will triage the report, potentially asking clarifying questions. During this phase, be responsive and provide any additional details requested. In the Azure Backup incident, the researcher exchanged several messages, but Microsoft ultimately closed the case as “not a security boundary violation.”
Step 4: Receive the Vendor's Decision
After analysis, Microsoft will either:
- Accept the vulnerability and begin working on a fix, usually issuing a CVE upon release.
- Reject the report, often stating the behavior is expected or out of scope.
- Dispute your findings, claiming no product changes are needed.
In the original case, Microsoft rejected the report, saying the behavior was expected and no product changes were made—despite later evidence of a silent fix.
Step 5: Document the Exchange and Monitor for Changes
If your report is rejected, keep detailed records of all communication. Monitor the affected Azure service for any changes. The researcher in our example noticed a silent fix in a subsequent update—the vulnerability no longer worked. Take screenshots and note the dates and version numbers. This documentation becomes crucial for later public disclosure or escalation.
Step 6: Escalate Responsibly (Optional)
If you believe the rejection was erroneous, consider these escalation paths:
- Reply to the MSRC case requesting a re-evaluation with new evidence.
- Contact Microsoft’s bug bounty program, if applicable (note: Azure Backup for AKS may not be in scope).
- Reach out to a trusted third-party coordinator like CERT/CC.
- Wait the recommended disclosure timeline (usually 90 days) and then publish a detailed blog post.
Be professional and avoid public shaming—maintain your credibility.
Step 7: Decide on Public Disclosure
After a reasonable period (e.g., 90 days) with no fix or acknowledgement, you may disclose the vulnerability publicly. Present the facts, including the vendor’s rejection and the silent fix if observed. In the Azure Backup case, the researcher went public with the evidence, leading to community discussion. Use platforms like your personal blog, GitHub, or security mailing lists. Ensure you do not violate any laws or agreements.
Step 8: Learn and Update Your Process
Each interaction with a vendor teaches you something. Review what went well and what could be improved. Did you provide enough detail? Was your vulnerability classification accurate? Update your reporting templates accordingly. The fact that Microsoft denied any product changes despite a silent fix suggests that your report may have been valid—but they classified it differently. Adjust future reports to better align with vendor expectations while still advocating for security.
Tips
- Read the program rules carefully – Microsoft Azure has specific terms for bug bounties and vulnerability disclosure. Know what is in scope.
- Use clear, non-confrontational language – Avoid accusatory phrasing. Instead of “You failed to fix this,” say “The following behavior appears to violate security boundaries.”
- Track CVEs yourself – If the vendor does not issue one, you can request a CVE ID from MITRE (as a researcher) after public disclosure, but note that vendor concurrence is often required.
- Build relationships – Engage with vendors at conferences or through responsible disclosure. A good reputation can lead to faster triage.
- Don’t assume malice – Vendors may reject a report due to resource constraints, differing risk assessments, or internal miscommunication. A silent fix could be a sign they eventually agreed but didn’t want to admit it.
- Always maintain professionalism – Even if you feel ignored, your integrity as a researcher is your most valuable asset. Public shaming rarely leads to positive outcomes.