Activities of "maliming"

hi

Can you refer to: https://abp.io/support/questions/10541/SystemIdentityModelTokensJwt-6261-has-a-known-high-severity-vulnerability#answer-3a202f9f-4c50-529b-26b8-b28a076a4f77

Thanks

hi

We have added a code-level fix in Volo.Abp.AutoMapper module by setting MaxDepth = 64 for all maps that don't have an explicit MaxDepth configured. This mitigates the actual DoS vulnerability (GHSA-rvv3-g6hj-g44x) at the framework level. See #25138.

However, since the NuGet security audit checks package versions rather than code, you will still see the NU1902/NU1903 warning as long as AutoMapper 14.0.0 is referenced. Unfortunately, the AutoMapper maintainer has confirmed that no patch will be released for version 14.x (see AutoMapper#4618). Only the commercial versions (15.x/16.x) have been patched.

Workaround: To suppress the NuGet audit warning, add the following to your project file (.csproj) or Directory.Build.props:

<ItemGroup>
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-rvv3-g6hj-g44x" />
</ItemGroup>

Recommended long-term solution: We recommend migrating from AutoMapper to Mapperly. ABP Framework has built-in support for Mapperly, and we have been progressively migrating all modules to use it. See the migration guide for details.

See https://github.com/abpframework/abp/issues/25137 https://github.com/abpframework/abp/pull/25138

Thanks.

hi

I have cloned your solution. Can you share the steps to reproduce the error?

Thanks

Hi,

Can you share your project structure screenshot?

You can try the steps below:

Step 1: Download the Inter font files from https://github.com/rsms/inter/releases and place them in your project:

wwwroot/fonts/InterVariable.woff2
wwwroot/fonts/InterVariable-Italic.woff2

Step 2: Create a local font CSS file at wwwroot/fonts/local-fonts.css in the Host/Server project:

@font-face {
    font-family: "Inter";
    font-style: normal;
    font-weight: 100 900;
    font-display: swap;
    src: url("/fonts/InterVariable.woff2") format("woff2");
}

@font-face {
    font-family: "Inter";
    font-style: italic;
    font-weight: 100 900;
    font-display: swap;
    src: url("/fonts/InterVariable-Italic.woff2") format("woff2");
}

Step 3: Add URL rewriting middleware in your Blazor module to redirect font-bundle.css requests to your local file. This must run before UseStaticFiles:

public override void OnApplicationInitialization(ApplicationInitializationContext context)
{
    var app = context.GetApplicationBuilder();

    app.Use(async (httpContext, next) =>
    {
        var path = httpContext.Request.Path.Value;
        if (path != null && path.EndsWith("/font-bundle.css", StringComparison.OrdinalIgnoreCase))
        {
            httpContext.Request.Path = "/fonts/local-fonts.css";
        }
        await next();
    });

    // ... rest of your middleware configuration
}

Thanks

Can you try to override OpenIddictImpersonateTenantModel . This class is registered via DI with [ExposeServices], so it can be properly replaced:

[ExposeServices(typeof(ImpersonateTenantModel))]
[Dependency(ReplaceServices = true)]
public class MyImpersonateTenantModel : OpenIddictImpersonateTenantModel
{
    public MyImpersonateTenantModel(
        IPermissionChecker permissionChecker,
        ICurrentPrincipalAccessor currentPrincipalAccessor,
        IOptions<AbpAccountOpenIddictOptions> options)
        : base(permissionChecker, currentPrincipalAccessor, options)
    {
    }

    public override async Task<IActionResult> OnPostAsync()
    {
        // Add your custom validation logic here.
        // For example:
        // if (!CurrentUser.IsInRole("admin") && TenantUserName == "admin")
        // {
        //     throw new BusinessException("...");
        // }

        return await base.OnPostAsync();
    }
}

Place this class in your AuthServer project (or whichever project references Volo.Abp.Account.Pro.Public.Web.OpenIddict). You can remove the previous ImpersonationExtensionGrant override, as it is not needed for Blazor.

At the moment, Postgres seems like a good choice.

Hi,

We have upgraded Scriban to 6.6.0 to fix the NU1902 security warning. See https://github.com/abpframework/abp/pull/25122. This fix will be available in the next 10.2 patch release.

Here are the relevant package versions across ABP releases:

| Version | System.IdentityModel.Tokens.Jwt | Scriban | |---|---|---| | 10.0.x | 8.14.0 | 6.3.0 | | 10.1.x | 8.14.0 | 6.3.0 | | 10.2.x (next patch) | 8.14.0 | 6.6.0 |

In the meantime, you can add the following to your project file to override the transitive dependency version:

<ItemGroup>
  <PackageReference Include="Scriban" Version="6.6.0" />
</ItemGroup>

Regarding the System.IdentityModel.Tokens.Jwt 6.26.1 vulnerability, as DominaTang mentioned, it comes from Microsoft.Graph 4.54.0, not from ABP packages. ABP already uses System.IdentityModel.Tokens.Jwt 8.14.0. You may want to check for a newer version of Microsoft.Graph that addresses this.

Thanks

Hi,

Thank you for your understanding. If you have any further questions or need assistance in the future, feel free to open a new support ticket.

Thanks

Hi,

Thanks for the detailed proposal. We've discussed this internally, and we don't have plans to implement a pre-authentication tenant selection flow for the Shared strategy at this time.

The Shared strategy is fundamentally designed around the "authenticate first, select tenant after" model. In this mode, since user identity is shared across tenants, all security-related settings are managed at the Host level. This means tenants cannot independently configure:

• Password policies (required length, complexity, periodic change, reuse prevention, etc.)
• Lockout policies (lockout duration, max failed attempts, etc.)
• Sign-in settings (require confirmed email/phone, etc.)
• External identity providers (Azure AD, Okta, etc.)

This is by design — when a user's identity is shared across multiple tenants, it wouldn't make sense to allow individual tenants to enforce conflicting security policies on the same user account.

Introducing tenant resolution before authentication (as you proposed) would fundamentally change this model and add significant complexity and potential security concerns (such as email enumeration).

For scenarios that require per-tenant external identity provider configuration or per-tenant security policies, please use the Isolated strategy, which resolves the tenant before authentication and fully supports tenant-level settings.

We understand this means you can't use unified user accounts and per-tenant IdP configuration at the same time. We'll keep this feedback in mind for future improvements.

Thanks

: )