How to Report Security Vulnerabilities: From Discovery to CVE-2026-21535
Finding a security vulnerability can be quite a story. In my case, it started with confusion when testing a feature or noticing something unexpected. After wider testing, you might confirm that something is broken or there could be an underlying issue. Then the real question kicks in: where do you report it, and how do you do it responsibly?
What do I need, and where do I report it?
If you don't work in this space daily, you mostly hear about CVE's. But do you actually need one for every vulnerability, and how do you get it?
Do I need a CVE?
Not always. A CVE is usually needed when:
- The vulnerability affects a publicly available product or service
- Multiple organisations are affected (decentralized product or service)
- A coordinated public advisory is needed
Do I find someone experienced around me?
Contacting Internal IT can be a mixed choice if they don't own the security process. A SOC or dedicated security team is usually a good start to handle reporting and vendor coordination. If you don't have a SOC, look for external, specialized channels such as the vendor’s security response center or a national CERT/NCSC. They are used to it and can guide you to the right place. During my interaction very responsive!
NCSC vs MSRC: which one should I choose?
Rule of thumb:
- Report to the vendor first if it is a product or cloud service issue (Microsoft 365). For Microsoft products and services, use MSRC.
- Report to the national CERT/NCSS when the issue affects multiple organisations, critical infrastructure, or has a national impact.
Many national CERTs will also help route reports to vendors if needed (GovCERT, SWITCH-CERT, CSIRT).
Responsible disclosure (CVD)
What should you include in the report? A short, clear summary helps the recipient validate and triage quickly.
- Vulnerability description (clear description of the issue and impact)
- Steps to reproduce (minimal, reliable, safe)
- Products (affected versions or configurations)
- Impact (single-tenant vs cross-tenant; user or admin scope, exposed content)
You can categorize the issue using CVSS for technical severity (CVSS Calculator). It helps understand and communicate the impact.
Bug bounties vs grey zones
If a vendor offers a bug bounty, use it. It has clear rules and a defined scope, and you may receive a reward for a valid report. For Microsoft, see:
- Microsoft 365 (Link): up to $19,500 USD (program scope may vary)
- Microsoft Identity (Link): up to $100,000 USD
Response time & Handling
Typical timeline: Many programs aim for around 90 days for coordinated disclosure, but this can be shorter or longer depending on severity and complexity.
How long does it take? It depends. Simple issues can be acknowledged within days, while complex fixes can take weeks or months. Clear, reproducible reports reduce delay. Also keep in mind that rolling out a fix across multiple tenants can add extra time.
Should I tell other teams? If the issue is reported through a bug bounty program, use the official contact path. Sharing too widely can break the program rules and you could lose a reward. Otherwise, route it through your internal security process. Keep the circle small and reasonable.
Vendors often share minimal details while they investigate. You may not learn what they found in the backend. A second round of testing can make sense once they applied a fix, but information sharing will stay limited until a possible advisory is published.
Real-world examples: Two Microsoft Teams vulnerabilities
I reported two separate security issues in Microsoft Teams through MSRC. Here's how they compared:
| Report | Teams Tags | Teams Channel Posts |
|---|---|---|
| Number | VULN-166566 | VULN-171533 |
| Impact | Security Feature Bypass | Security Feature Bypass |
| Cross tenant | Yes | Yes |
| CVSS reported | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N |
| CVSS score | N/A | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N/E:U/RL:O/RC:C |
| Base score | N/A | CVSS:3.1 8.2 / 7.1 |
| CWE reported | CWE-284 (Access Control) | CWE-284 (Access Control), CWE-488, CWE-200 (Information Disclosure) |
| CWE assigned | N/A | CWE-284 (Access Control) |
| CVE | N/A (No CVE assigned) | CVE-2026-21535 |
| Fix applied | Fast | Very Fast |
| From | 17 Nov 2025 | 24 Jan 2026 |
| Until | 23 Jan 2026 (67 days) | 20 Feb 2026 (27 days) |
Key differences: The first issue was fixed earlier but didn't receive a CVE, likely because the impact has not revealed any content or only affected specific configurations. The second vulnerability (CVE-2026-21535) received both a CVE assignment and a public advisory.
Summary
Reporting a vulnerability is mostly about choosing the right channel and sharing the right details. Keep it focused and expect limited visibility while a fix is prepared. The process worked well and the communication was clearer than a normal Microsoft 365 support ticket. I hope this helps you report issues in the right place, and wish you all a great time reporting bugs where they belong.
Reference:
- Bounty Program Guidelines
- Microsoft Bug Bounty Program
- CVE Program Mission
- CVE Program Mission - Teams
- CVE-2026-21535 - msrc - Microsoft Teams Information Disclosure Vulnerability
- CVE-2026-21535 - cvedetails
- CVE-2026-21535 - cve.org
- CVE-2026-21535 - nvd.nist.gov