The top-level package is Volo.Abp.Http.Client.IdentityModel 10.1.1, which pulls in Volo.Abp.IdentityModel, which in turn depends on Microsoft.IdentityModel.* 6.26.1 and System.IdentityModel.Tokens.Jwt 6.26.1.
Can ABP package upgrade to System.IdentityModel.Tokens.Jwt version 8?
3 Answer(s)
-
0
- ABP 10.1.1 cannot simply “upgrade to Jwt v8” as a drop-in change, because ABP versions are tied to a tested dependency set and Microsoft.IdentityModel/System.IdentityModel.Tokens.Jwt 8.x is a major-version jump that can introduce breaking changes across the IdentityModel stack.
- What ABP has already done (officially) is upgrade away from the old 6.x line: starting with ABP 8.2, ABP upgraded:
System.IdentityModel.Tokens.Jwtto 7.5.1Microsoft.IdentityModel.*packages to 7.5.1
- So the actionable, ABP-supported path to address the reported vulnerability in
System.IdentityModel.Tokens.Jwt 6.26.1is to upgrade your ABP solution to a version that includes these upgraded dependencies (at least ABP 8.2+, and in practice you should move to the latest ABP version in your major line).
If you’re staying on ABP 10.1.1 specifically, there is no verified ABP source stating that ABP 10.1.x supports
System.IdentityModel.Tokens.Jwt8.x via its own packages. The verified ABP guidance available shows the framework moving to 7.5.1 (not 8.x) as part of its dependency upgrades.Links (verified):
- https://abp.io/docs/latest/release-info/migration-guides/abp-8-2#upgraded-nuget-dependencies
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
-
0
My bad, it is introduce by Microsoft.Graph 4.54.0 that the application use. There is another vulnerable package Volo.Abp.TextTemplating.Scriban 10.1.1 it depends on Scriban 6.3.0 which has high-severity vulnerabilities.
-
0
Hello ABP Team,
We are currently working on an ABP-based solution (ABP v10.x) and during package restore/build we are receiving NuGet security warnings related to a transitive dependency on Scriban 6.3.0, which reports multiple vulnerabilities (including high severity GHSA advisories).
From our analysis, Scriban is being brought transitively through ABP packages related to Text Templating (used for email templates and notifications), not from a direct package reference in our solution.
The issue is that NuGet audit warnings (NU1901–NU1904) are being treated as errors in our environment, which blocks restore, build, and EF Core migrations unless we explicitly suppress these warnings or lower the audit level.
Our questions are:
Is ABP planning to update the Scriban dependency to a non-vulnerable version in an upcoming release? Is it safe to override the Scriban version at the solution level, or could this break ABP Text Templating functionality? What is the recommended approach from the ABP team for handling NU190x vulnerability warnings caused by transitive dependencies used internally by ABP? Is there an official mitigation strategy recommended by ABP for production environments where email templating is used?
At the moment, as a temporary workaround, we are considering configuring:
WarningsNotAsErrors for NU1901–NU1904 NuGetAuditLevel=critical
But we would like to confirm the officially recommended approach from the ABP team before proceeding.
