[GHSA-5rrx-jjjq-q2r5] Microsoft Security Advisory CVE-2025-55315: .NET Security Feature Bypass Vulnerability

[udlose]

Updates

• Affected products
• Description
• References

Comments
We have a PoC that demonstrates the vulnerability in .NET 6.0.36 here: https://github.com/sirredbeard/CVE-2025-55315-repro

[github]

Hi there @victorisr! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[Copilot]

Pull Request Overview

This PR updates the security advisory for CVE-2025-55315 to include ASP.NET Core 6.0 as an affected product, corrects the discussion issue reference, and adds a reference to a proof-of-concept demonstration.

Key Changes:

• Added ASP.NET Core 6.0 to the list of affected products (6.0.36 and earlier)
• Corrected the discussion issue URL from issues/372 to issues/371
• Added affected package entries for all ASP.NET Core 6.0 runtime variants

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[rbhanda]

.NET 6.0 is out of support. This PR should not be merged

[udlose]

.NET 6.0 is out of support. This PR should not be merged

We have already had the GHSA for CVE-2025-24070 updated back when that came out so the precedent has been set.

[rbhanda]

.NET 6.0 is out of support. This PR should not be merged

We have already had the GHSA for CVE-2025-24070 updated back when that came out so the precedent has been set.

that is wrong and should be reverted

[udlose]

why should the GHSA Advisory not include EOL software? I understand that Microsoft doesn't support or report on EOL. However, that should be restricted to the MSRC notifications and the .NET Announcements. I strongly disagree that the GHSA should follow the same pattern of excluding EOL. Otherwise, the Advisory is not "complete" and there is no means for the community to effectively communicate on other versions affected.

To purposely choose to omit information on a security vulnerability is a disservice to the community at large.

[rbhanda]

why should the GHSA Advisory not include EOL software? I understand that Microsoft doesn't support or report on EOL. However, that should be restricted to the MSRC notifications and the .NET Announcements. I strongly disagree that the GHSA should follow the same pattern of excluding EOL. Otherwise, the Advisory is not "complete" and there is no means for the community to effectively communicate on other versions affected.

To purposely choose to omit information on a security vulnerability is a disservice to the community at large.

None of the EOL releases gets an update. Updating these advisories defeats the purpose of "EOL" products. Please stop requesting changes for EOL products. We will not be taking these changes.

[udlose]

Microsoft is not the only vendor that provides updates for .NET products. We have applied to become members of your security program. The community should be made aware they have options if they are stuck on EOL software. The first part of that is gaining the knowledge that you have a vulnerability.

[rbhanda]

Microsoft is not the only vendor that provides updates for .NET products. We have applied to become members of your security program. The community should be made aware they have options if they are stuck on EOL software. The first part of that is gaining the knowledge that you have a vulnerability.

If someone is on EOL it means they could be vulnerable. We do not update the advisories similarly for .NET 7.0 either.

[github]

Hi there @victorisr! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[udlose]

@rbhanda at a bare minimum, you should take the part of the PR that corrects the .NET announcement url. I removed the .NET 6 stuff but fixed the Announcement url.

[dwelch2344]

Hey all, jumping in here from the HeroDevs side since this ties directly to our work.

@rbhanda — first, thank you for all your great contributions and engagement here. We know each ecosystem handles EOL differently, and we want to collaborate in ways that add value without creating friction.

On vulnerabilities in EOL products: while support has ended, usage often hasn’t — meaning vulnerabilities can still impact real users. Many organizations are still running .NET 6, and in some cases, compliance or security tooling doesn’t even flag issues. This gap is well-known and stems from the entirely reasonable expectation that OSS and PSIRT teams can’t validate against every legacy version. We completely understand and support that.

That said, true security depends on identifying risks systemically — and frameworks like CVE and GHSA are critical first lines of defense. Our goal is simply to ensure these systems accurately reflect the real-world risks end users face.

We’re happy to collaborate however makes sense. If EOL issues fall outside your team’s scope, we’re glad to respond under our CNA role — we just aim to keep records aligned and as clear as possible with the original CVE.

[rbhanda]

Hey all, jumping in here from the HeroDevs side since this ties directly to our work.

@rbhanda — first, thank you for all your great contributions and engagement here. We know each ecosystem handles EOL differently, and we want to collaborate in ways that add value without creating friction.

On vulnerabilities in EOL products: while support has ended, usage often hasn’t — meaning vulnerabilities can still impact real users. Many organizations are still running .NET 6, and in some cases, compliance or security tooling doesn’t even flag issues. This gap is well-known and stems from the entirely reasonable expectation that OSS and PSIRT teams can’t validate against every legacy version. We completely understand and support that.

That said, true security depends on identifying risks systemically — and frameworks like CVE and GHSA are critical first lines of defense. Our goal is simply to ensure these systems accurately reflect the real-world risks end users face.

We’re happy to collaborate however makes sense. If EOL issues fall outside your team’s scope, we’re glad to respond under our CNA role — we just aim to keep records aligned and as clear as possible with the original CVE.

Thanks a lot for your response. If a product is EOL, Microsoft policy is that they will not be getting any security or non-security updates. It is not just .NET 6.0, .NET 7.0, .NET Core 3.1, might also be vulnerable. Please do not make any EOL changes to .NET advisories going forward.

[udlose]

@rbhanda let me know if any further changes are required. The only change that should be present is to correct the Announcement url.

[victorisr]

@rbhanda let me know if any further changes are required. The only change that should be present is to correct the Announcement url.

@udlose thanks for your contributions. You may close this PR as the Announcement url change is already tracked elsewhere : PR #6335

[blowdart]

I believe a discussion has already happened with Herodevs around how to manage their CVE process and adding onto the Microsoft authored CVE was ruled out.

Github please talk with @jamshedd

[udlose]

Closing as duplicate of #6335

[sirredbeard]

Thank you @blowdart and @rbhanda.

I believe a discussion has already happened with Herodevs around how to manage their CVE process

Yes, it has. We appreciate our partnership with Microsoft and ongoing collaboration. We understand and respect Microsoft's position on including EOL versions in CVEs.

The confusion here lies in that previously we have updated CVE-related GHSAs to include .NET 6 in affected version ranges and that hasn't encountered any pushback, to date. We saw GHSAs as separate from the CVE.

Now that we are aware Microsoft would prefer their EOL CVE policy to apply to the related GHSAs as well, we will work with that.

Again, thank you everyone. I apologize for the confusion. We are all trying to figure out how to be better partners in this new space.

cc @jamshedd

[jamshedd]

Lisa Olson from the MSRC had taken point on the communicating this so we had stepped back, but the short version is we cannot have HeroDevs or anyone else updating the list of Microsoft products with EOS versions. As a policy we cannot list products we do not support as vulnerable, because we do not do the work to verify the vulnerability in EOS versions. This is long standing practice across all Microsoft products, not limited to .NET.

We understand that HeroDevs and others want to document the availability of their update for their product versions. For reference there's a correct way to do that, as seen in this CVE on cve.org.

In this CVE the Microsoft container includes a list of Microsoft (supported) products and their corresponding patches. The CVE container has a pointer to the HeroDevs CVE page which can include details about their patched product. It is important to recognize that the HeroDevs patch does not apply to Microsoft's .NET 6.0 product, it applies to the HeroDevs .NET 6.0 product which HeroDevs built using .NET's public sources. So at no point should anyone other than Microsoft list "Microsoft .NET 6.0".

I am open to the GitHub advisory following a similar path to the CVE - we can have a pointer to the HeroDevs page documenting the CVE in their product as long as our distribution i.e. Microsoft .NET 6.0 is not called out here on the advisory.

cc @sirredbeard @udlose @blowdart @rbhanda @victorisr