Unauthenticated access exposes truststore and internal metadata via Publish instance URLs
If Dispatcher filters on Adobe Experience Manager (AEM) publish instances are too permissive, unauthenticated requests can expose truststore-related resources, internal metadata, and other non-public paths. To resolve this issue, review and tighten Dispatcher filter rules, explicitly deny access to sensitive endpoints, and validate that crafted requests are blocked before they reach the publish tier.
Description description
Environment
Adobe Experience Manager (AEM) deployments that use Dispatcher in front of publish instances
Issue/Symptoms
The following symptoms are observed on AEM publish instances when Dispatcher filter rules are too permissive or sensitive paths are not explicitly restricted:
- Certain publish-instance URLs are accessible through unauthenticated
GETrequests without requiring authentication, cookies, or special headers. - Successful requests can expose truststore-related resources, internal node names, content structure, configuration-related paths, and asset metadata.
- Some crafted requests also allow access to internal login-related paths that are normally expected to be restricted.
Example URLs:
https://www.example.com/etc/truststore.-1.json;x='.ico/x'- May expose truststore-related informationhttps://www.example.com/etc/truststore/truststore.p12;x='.ico/x'- May allow download of the truststore certificate filehttps://www.example.com/.children.-1.json;x='.ico/x'- May expose internal node names, content structure, configuration-related paths, and metadatahttps://www.example.com/libs/dam/merge/metadata.css;x='.ico/x'?path=/content/dam/example-site/example-logo-32x32.ico- May expose asset metadata throughMergeMetadataServlethttps://www.example.com/libs/granite/core/content/login.html;x='.ico/x'- May allow access to an internal login-related path that is normally expected to be restricted
Error/Log Output
No explicit error messages; the issue is the unintended exposure of internal resources.
Cause
The issue is typically caused by Dispatcher filter rules that are not restrictive enough to block crafted requests or to prevent access to sensitive internal paths on publish instances.
Resolution resolution
Note: Dispatcher filtering is important, but it is not a reliable security boundary by itself. AEM repository ACLs and endpoint restrictions on publish must remain the primary control, with Dispatcher/Apache/CDN rules as defense in depth.
Follow these steps to resolve the issue:
-
Review Dispatcher filters configuration
- Open the Dispatcher configuration file, such as
dispatcher.any. - Locate the
/filteror/filterssection.
- Open the Dispatcher configuration file, such as
-
Add a rule to deny requests containing semicolons or other suspicious URL patterns when those patterns are not required by the application.
code language-none /0xxx { /type "deny" /url "*;*" }This rule blocks any request containing a semicolon in the URL, which is commonly used in crafted requests intended to bypass filtering.
-
Restrict access to sensitive paths
-
Add explicit deny rules for sensitive paths such as
/etc/truststore,/libs/dam/merge, and/libs/granite/core/content/login.html. -
Example:
code language-none /0xxx { /type "deny" /url "/etc/truststore*" } /0xxx { /type "deny" /url "/libs/dam/merge*" } /0xxx { /type "deny" /url "/libs/granite/core/content/login.html*" }
-
-
Validate the updated configuration
- Deploy the updated Dispatcher configuration to all publish instances.
- Re-test the previously exposed URLs and confirm that they now return a blocked response, such as
404or another expected deny response based on your setup.
-
Review publish-tier hardening
- Verify that sensitive resources are not accessible anonymously on publish.
- Review AEM permissions and servlet exposure for internal endpoints.
- Prefer an allowlist-based Dispatcher model wherever possible so that only known, required paths are exposed publicly.