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 GET requests 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 information
  • https://www.example.com/etc/truststore/truststore.p12;x='.ico/x'- May allow download of the truststore certificate file
  • https://www.example.com/.children.-1.json;x='.ico/x'- May expose internal node names, content structure, configuration-related paths, and metadata
  • https://www.example.com/libs/dam/merge/metadata.css;x='.ico/x'?path=/content/dam/example-site/example-logo-32x32.ico- May expose asset metadata through MergeMetadataServlet
  • https://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:

  1. Review Dispatcher filters configuration

    • Open the Dispatcher configuration file, such as dispatcher.any.
    • Locate the /filter or /filters section.
  2. 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.

  3. 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*" }
      
  4. 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 404 or another expected deny response based on your setup.
  5. 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.
recommendation-more-help
experience-cloud-kcs-help-kbarticles