Our recent penetration test flagged a high-severity vulnerability (CWE-94, CVE-2023-32571 class) regarding how the ABP framework natively handles the sorting parameter in its built-in paged list endpoints.
Affected Endpoints:
?sorting= (Verified specifically against GET /api/identity/users and GET /api/audit-logging/audit-logs, affecting ~80 built-in endpoints).Issue Details:
The ?sorting= query string is natively passed to System.Linq.Dynamic.Core by the framework without a strict allow-list mechanism. Consequently, arbitrary entity properties—including critical server-only columns like PasswordHash, SecurityStamp, and ConcurrencyStamp—along with string method invocations (e.g., .Substring, .Length) and ternary boolean predicates, are evaluated server-side.
This creates a data-exfiltration blind oracle out-of-the-box. Server-only columns are accepted as sort keys, and rows are ordered by their actual values, allowing attackers to extract sensitive data character by character.
Requested Framework-Level Remediation: Since this vulnerability stems from the core framework's default implementation, we are requesting a structural patch/fix in the ABP framework itself rather than implementing manual overrides for every endpoint. Specifically, we request that the ABP team:
IGetListInput.Sorting by default, rejecting any unmapped or sensitive columns (like PasswordHash) with an HTTP 400 before they reach .OrderBy().System.Linq.Dynamic.Core ParsingConfig to strictly disable method-invocation, ternary-conditional, and substring-style accessors.Could you please confirm if this issue is already being tracked, and in which upcoming release we can expect a framework-level patch for this vulnerability?
A penetration test revealed a high-severity email enumeration vulnerability (CWE-204, OWASP ASVS 4.0.3 §V2.6.7) on the account module's password reset endpoint.
Affected Endpoint:
Issue Details: The endpoint returns differential responses based on whether the supplied email exists in the selected user store.
Additionally, passing a __tenant: header allows the lookup to pivot against any named tenant's user store without rate limits. We observed that the preventEmailEnumeration setting under /api/account-admin/settings appears to be false.
Requested Assistance & Remediation Guidance: We need to configure the password-reset action to always return an HTTP 200 with a uniform response body, regardless of whether the email exists in the system. How can we properly enforce preventEmailEnumeration: true globally and secure this endpoint against enumeration attacks in our current version?
We have identified a high-severity security finding (CWE-204: Observable Response Discrepancy) during a recent penetration test regarding the default tenant lookup endpoints in the ABP framework.
Affected Endpoints:
Issue Details: Both lookups return existence-oracle responses anonymously. There is no rate limiting in place. The tenant UUIDs feed several other tenant-aware unauthenticated endpoints, allowing an attacker to enumerate valid tenants on the system.
Requested Assistance & Remediation Guidance: The SPA does not require anonymous tenant lookup once the login URL accepts a tenant query parameter. Can you provide the recommended approach to either:
Hello,
We still have some migration code related to IdentityServer in the project, as we currently support customers using a product version that relies on it.
This will be addressed during release management, and the IdentityServer-related migration code will be removed accordingly.
Thank you for your effort and support
I have enabled the Dynamic Claims feature in my application to prevent concurrent logins by adding the following configurations in HttpApiHostModule and AuthServerModule:
context.Services.Configure(options => { options.IsDynamicClaimsEnabled = true; });
app.UseDynamicClaims();
I placed app.UseDynamicClaims(); before app.UseAuthorization(); as recommended in the documentation.
However, I am facing the following issue:
When logging in as a host admin, the granted permissions are empty in the application configuration. This prevents the admin from seeing menus and accessing certain pages.
Yes that's the problem, thank you
Hi, i recorded the issue
https://streamable.com/103ycv
In our application Identity is not the first tab, I assumed the same for yours. You can reproduce this issue by clicking a tab other than the first one, closing the modal, then reopening it.
Hello, There was a mistake so I updated the question, sorry for the confusion. You can reproduce the bug without adding any custom features.
Entering the host tenant. Navigate to the feature settings of any tenant. Click on Identity and then click Cancel. Access the feature settings of that tenant again. Observed Result: The previously closed pop-up, which is the Identity section, initially appears, followed by the first tab, which is Setting Management. Expected Result: The Setting Management tab, located in the first tab, should be displayed directly.
Thank you
