The Phantom Menace: Dissecting the 'Fake' ConcreteCMS XPath Injection

In the high-stakes world of bug bounty hunting and CVE chasing, there is a dangerous trap that ensnares even seasoned researchers: confirmation bias. You see a URL, you throw a single quote (') at it, the server screams in agony with a 500 Internal Server Error, and you immediately draft a report titled 'Critical Injection'. This is precisely what happened with CVE-2022-50807.

ConcreteCMS (formerly Concrete5) is a popular open-source CMS. In late 2022, a researcher claimed to have found an XPath Injection (CWE-643) in version 9.1.3. The claim was bold: by injecting boolean logic into the URL path, one could allegedly manipulate XML queries. The exploit made its way into Exploit-DB, a CVE ID was assigned, and scanners started flagging it.

But there was a catch. The 'exploit' didn't actually retrieve data. It didn't bypass authentication. It just made the server vomit a stack trace. This deep dive isn't about how to hack ConcreteCMS; it's a masterclass in reading stack traces and distinguishing between a security vulnerability and a code quality issue.

The original researcher, nu11secur1ty, provided a Proof of Concept (PoC) that looked suspiciously like a standard SQL injection fuzzer payload pasted into a URL path. The logic was that if the application processed the URL as an XPath query, injecting a TRUE condition would change the behavior.

The payload looked like this:

GET /concrete-cms-9.1.3/index.php/ccm50539478' or 4591=4591-- /assets/localization/moment/js HTTP/1.1
Host: target-host

To the untrained eye, this looks dangerous. You have the single quote to break syntax, the OR operator, a tautology (4591=4591), and the comment characters (--). When sent to a ConcreteCMS instance running in a development environment (like XAMPP), the server responded with a massive, detailed error page. The researcher saw the chaos and assumed valid injection. However, correlation does not imply causation.

So, what actually happened? Was the application blindly concatenating this URL into an XPath query? No. The stack trace, which was ironically included in the researcher's own report, tells the real story. The error wasn't an XML parsing failure; it was a file system inclusion error generated by the caching layer.

ConcreteCMS uses a library called Stash for caching. When a request comes in, the CMS often tries to map the URL path to a cache key or a localized resource. The relevant part of the stack trace looked something like this:

Whoops\Exception\ErrorException: include(): 
Failed opening 'C:/xampp/.../expensive...php' for inclusion
In Stash\Driver\FileSystem\NativeEncoder

The NativeEncoder in Stash was trying to handle the incoming path. The malformed URL—containing spaces, quotes, and dashes—likely confused the file system driver or resulted in a generated filename that was invalid or missing. The application didn't know how to handle the garbage input, so it threw an exception.

Because the target system was running with Debug Mode (Whoops handler) enabled, it displayed the exception. This is Information Disclosure, sure, but it is effectively "Debug Mode is on," not "XPath Injection."

A true injection vulnerability allows an attacker to alter the control flow of an application to execute unintended commands or retrieve unauthorized data. In this case, the attacker provided garbage, and the application threw an error saying, "I can't read this garbage."

There was no evidence that the boolean logic (4591=4591) was ever evaluated. You could likely have replaced that payload with GET /index.php/banana_pancake_recipe and received a similar 404 or 500 error depending on the routing configuration. The boolean operators were red herrings.

Consequently, the CVE was REJECTED and withdrawn. The CNA (VulnCheck) and the vendor correctly identified that this was a functional bug in how the router/cache handled invalid characters, magnified by a misconfigured server (Debug Mode). It serves as a reminder: Just because it breaks, doesn't mean it's pwned.

While this specific CVE is a dud, it highlights a critical configuration weakness that plagues many organizations: leaving Debug Mode on in production. The only reason the researcher knew the file paths (C:/xampp/htdocs/...) and the library versions was because the server told them.

To mitigate the risk of Information Disclosure (and to stop researchers from filing false positives against you):

1. Disable Display Errors: In your php.ini, ensure display_errors = Off.
2. Disable ConcreteCMS Debug: Go to the Dashboard -> System & Settings -> Environment -> Debug Settings and ensure "Hide errors from the visitor" is selected.
3. Sanitize Inputs: While not an injection, it's bad practice for an application to crash on special characters. Ensure your routing layer handles 404s gracefully rather than bubbling up 500 exceptions for bad paths.