ABP Framework version: v8.2.3
UI Type: React
Database System: EF Core (SQL Server)
Tiered (for MVC) or Auth Server Separated (for Angular): yes
I am currently using ABP Framework 8.2.3 and have identified the following vulnerabilities in my project dependencies:
select2@4.0.13 (Transitive) Select2 versions prior to 4.0.8 are vulnerable to Cross-Site Scripting (XSS). This occurs in scenarios where rich select lists use AJAX-based remote data loading along with HTML templates to render list items, allowing potentially unsafe HTML to be injected and executed. AutoMapper@13.0.1 (Transitive) AutoMapper is vulnerable to a Denial-of-Service (DoS) attack. In versions prior to 15.1.1 (and 16.x prior to 16.1.1), mapping deeply nested object graphs can lead to unbounded recursive calls, potentially causing a StackOverflowException and terminating the application.
At the moment, I am unable to upgrade the ABP Framework version because I want to remain on .NET 8 and avoid moving to .NET 9.
My question is: Is there a recommended way to mitigate or fix these vulnerabilities without upgrading the ABP Framework version? For example:
Can these transitive dependencies be safely overridden? Are there configuration-based mitigations (e.g., limiting mapping depth in AutoMapper)? Any best practices to address such issues in ABP without a full framework upgrade?
2 Answer(s)
-
0
- AutoMapper (NuGet / .NET side): Yes, you can safely override the transitive AutoMapper version without upgrading ABP or moving to .NET 9.
- In every project that ends up referencing AutoMapper (typically
*.Application, sometimes*.HttpApi.Hostdepending on your module graph), add an explicit package reference to a patched AutoMapper version so NuGet resolves your version instead of the transitive one:
- In every project that ends up referencing AutoMapper (typically
<ItemGroup> <PackageReference Include="AutoMapper" Version="15.1.1" /> <PackageReference Include="AutoMapper.Extensions.Microsoft.DependencyInjection" Version="15.1.1" /> </ItemGroup>- Rebuild and verify the resolved versions (e.g.,
dotnet list package --include-transitive).
Configuration-based mitigation in ABP specifically: ABP uses AutoMapper via its integration package, but I could not find (in verified ABP sources available to me) an ABP-provided setting like “limit mapping depth” that you can flip to mitigate the specific AutoMapper recursion DoS issue. The reliable mitigation here is overriding to a fixed AutoMapper version.
- Select2 (npm / React side): In ABP React apps, Select2 is not a typical built-in dependency, and I could not verify from ABP sources here where
select2@4.0.13would be coming from in an ABP React 8.2.3 solution. However, if your scanner reports it as transitive, the standard mitigation on the React/npm side (without any ABP upgrade) is to force/override the dependency version at the package manager level:- npm (
overrides):
- npm (
{ "overrides": { "select2": "4.1.0-rc.0" } }- yarn (
resolutions):
{ "resolutions": { "select2": "4.1.0-rc.0" } }Then reinstall (
rm -rf node_modules package-lock.jsonandnpm install, or the equivalent for yarn/pnpm) and re-check the lockfile.Important note about your reported Select2 advisory: your message says “versions prior to 4.0.8 are vulnerable”, but you have 4.0.13, which is not “prior to 4.0.8”. So either:
- the advisory text is mismatched, or
- the scanner is flagging Select2 for a different reason, or
- the actual installed version is not what you think (lockfile says otherwise).
The practical, framework-independent mitigation remains: ensure the lockfile resolves to a non-vulnerable version and avoid using HTML templates with untrusted remote data.
- Best practice in ABP (when you cannot upgrade the framework):
- Override patched transitive versions (NuGet via explicit
PackageReference, npm viaoverrides/resolutions). - Regenerate lockfiles and verify actual resolved versions in CI.
- Prefer DTO projections (e.g.,
Select(...)/ query projection) over deep object graph mapping when feasible to reduce risk and cost of mapping large/deep graphs.
- Override patched transitive versions (NuGet via explicit
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.
Markdown supported.Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post) - AutoMapper (NuGet / .NET side): Yes, you can safely override the transitive AutoMapper version without upgrading ABP or moving to .NET 9.
-
0
hi
Thanks for the detailed report. Let me address each issue separately.
AutoMapper 13.0.1 (GHSA-rvv3-g6hj-g44x)
The ABP team has applied a code-level mitigation for this vulnerability in PR #25138 by setting
MaxDepth = 64for all AutoMapper maps that don't have an explicitMaxDepthconfigured. However, this fix is going into the upcoming ABP release and will not be backported to 8.2.3.Since you're staying on ABP 8.2.3 / .NET 8, you can apply the same mitigation manually in your own project. Additionally, since the AutoMapper maintainer has confirmed no patch will be released for the affected version, your NuGet security audit will continue showing NU1902/NU1903 warnings regardless. To suppress the warning, add the following to your
Directory.Build.props(or individual.csprojfiles):<ItemGroup> <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-rvv3-g6hj-g44x" /> </ItemGroup>If you hold a commercial AutoMapper license (LuckyPenny Software), you can override the AutoMapper package to version 15.1.1 in your projects. The ABP team has also released a
Volo.Abp.LuckyPenny.AutoMapperintegration package (see #25153) as a drop-in replacement forVolo.Abp.AutoMapperfor users with such a license — though note this targets newer ABP versions, so you would need to adapt it manually for 8.2.3.As a long-term solution, we recommend migrating from AutoMapper to Mapperly, which ABP Framework has built-in support for. See the migration guide for details.
Select2 4.0.13
Select2 4.0.13 is actually the latest stable release in the 4.0.x series (released January 28, 2025). The only known vulnerability in Select2 (GHSA-rf66-hmqf-q3fc) was fixed in version 4.0.6 — 4.0.13 is well past that threshold and is not affected. The scanner result is a false positive, and I'd recommend raising it with your security scanning tool vendor.
Additionally, since your UI type is React, Select2 is only present in the MVC-based Auth Server pages, not your main React frontend, so the actual exposure is further limited.
Thanks
Markdown supported.Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)