Hi,
You're right — GHSA-24c8-4792-22hx was published on 2026-05-12, after we shipped Scriban 7.0.0 in v10.4.0 (PR https://github.com/abpframework/abp/pull/25170 was merged on 2026-03-27, when 7.0.0 was still the latest stable with no known advisories). Scriban then released 7.2.0 with the fix on 2026-05-12, and 7.2.1 followed on 2026-05-24 with some extra hardening.
I'll bump ABP's Scriban reference to 7.2.1 in the next release.
In the meantime, you can clear the audit on your side immediately by pinning the version in your own Directory.Packages.props:
<PackageVersion Include="Scriban" Version="7.2.1" />
ABP modules that consume Scriban (Volo.Abp.TextTemplating.Scriban, Volo.Docs) declare it as a PackageReference without a fixed version, so NuGet resolves whatever you set here. No further changes needed.
Thanks
Hi,
Yes, configuring AppUrlOptions is the correct and supported way to make Account email links (forgot password, email confirmation, change email, user invitation, etc.) tenant-aware. It's not a hack, and there are no hidden side effects. Your config is exactly right:
Configure<AppUrlOptions>(options =>
{
options.Applications["MVC"].RootUrl = "https://{0}.example.com";
});
A few things worth knowing so you can rely on it with confidence:
Why the "MVC" key is correct on Blazor Server. In a Blazor Server app, the Account pages that send these emails (login / forgot-password / register) are served by server-side MVC Razor Pages. They submit the request with AppName = "MVC", and the password reset / email confirmation URLs are registered under Applications["MVC"] by default. So Applications["MVC"].RootUrl is exactly the value ABP uses to build those links.
The {0} placeholder. It's replaced with the current tenant's name. This is the same placeholder semantics used by AddDomainTenantResolver("{0}.example.com"), so as long as your subdomains map to the tenant name (the common case), the outbound email links line up perfectly with your inbound resolution. If your subdomains are based on the tenant id instead, use https://{{tenantId}}.example.com (there's also {{tenantName}} if you prefer to be explicit).
No side effect for host (no tenant). When there is no current tenant, ABP removes the {0}. part entirely, so https://{0}.example.com becomes https://example.com. Host-side links keep working.
This single setting covers all Account emails (not just password reset), so you don't need to configure them one by one.
You're right that this isn't spelled out in the docs. The closest related reference is the subdomain resolver section, which confirms the {0} = tenant name placeholder:
https://abp.io/docs/latest/framework/architecture/multi-tenancy#domainsubdomain-tenant-resolver
And a runnable sample of the subdomain setup: https://github.com/abpframework/abp-samples/tree/master/DomainTenantResolver
Thanks
Hi,
No, there's no built-in "per-tenant AI Workspace" feature. AI Management is a host-level module — workspaces (and their data sources, MCP servers and indexed documents) aren't multi-tenant entities, so they're global records managed from the host and shared across tenants. This is by design, not a configuration you can switch on.
Thanks
hi
Is your problem solved? If not, you can continue sharing the logs. https://abp.io/support/questions/10659/Shared-User-Accounts---sent-email-format#answer-3a213270-a9ea-58ca-2111-9b161116c3a1
Because when I try to implement this middleware now it can bypass and the switch tenant now show as expected. But I don't know if it will cause other error
You can remove your middleware to troubleshoot the problem.
Thanks
: )
Your current ticket has been refunded.
Thanks.
Hi,
Thanks for the report — we've confirmed this is a bug in ABP Studio and will ship a fix in the next release.
Thanks
Hi,
A quick note on this topic — ABP framework itself doesn't ship a built-in module for blob/file encryption or entity field-level encryption. Both need to be implemented by the developer, combining ABP's primitives with platform or library features. Below are a few common directions people typically take, which may help you choose what fits your project best.
File encryption (S3/MinIO):
Most teams rely on the storage layer's own server-side encryption (SSE-KMS / SSE-C). MinIO and S3 both support this. Master keys live in an external KMS (AWS KMS, Azure Key Vault, HashiCorp Vault), and encryption happens transparently. This is generally simpler and performs better than wrapping IBlobContainer with custom streaming AES in the application layer.
If you really need application-level encryption, you can wrap IBlobContainer with a streaming AES-GCM layer (per-file DEK + master key wrap pattern), but rolling your own envelope encryption is non-trivial.
Field-level encryption (PostgreSQL): A few options worth considering:
ValueConverter + IStringEncryptionService — works for basic column-level encryption. The EF Core docs do include a caution about rolling your own encryption here, and ValueConverter can't access DbContext or session state, which makes per-tenant key derivation tricky.pgcrypto extension — SQL-level encryption/decryption functions.Encrypted columns aren't directly searchable by plaintext. The common pattern is a separate blind-index column (HMAC of the value) for equality lookups.
Key management:
ABP doesn't ship a dedicated KMS abstraction, but AbpStringEncryptionOptions reads from IConfiguration, so AWS Secrets Manager / Azure Key Vault / HashiCorp Vault can be plugged in via the standard .NET configuration providers. ASP.NET Core Data Protection APIs are mainly designed for short-lived secrets (cookies, tokens), so I wouldn't recommend them for long-term storage of medical data.
Related ABP article:
I wrote a piece some time ago covering the encryption mechanisms ABP uses internally — IStringEncryptionService (AES), Identity password hashing (PBKDF2 / HMAC-SHA512), and OpenIddict signing/encryption credentials. It may help as background:
https://abp.io/community/articles/encryption-and-decryption-in-abp-framework-37uqhdwz
Thanks
