On March 6th, Searchlight Cyber published a blog revealing details about a new deserialization vulnerability in Sitecore [1]. Sitecore calls itself a "Digital Experience Platform (CXP)," which is a fancy content management system (CMS). Sitecore itself is written in .Net and is often sold as part of a solution offered by Sitecore partners. Like other CMSs, it makes it easy to manage a website's content. It offers several attractive features to marketing professionals seeking more insight into user patterns.

Searchlight Cyber has reviewed Sitecore in the past, and this is not the first vulnerability Searchlight Cyber has discovered in Sitecore.

This most recent vulnerability is interesting in that it does not require authentication. Like other deserialization vulnerabilities, this vulnerability may lead to remote code execution. Another somewhat unusual property of this vulnerability is using a custom header. A few deserialization vulnerabilities are exploitable via cookies, but I do not remember seeing one exploiting a custom header. Let me know if there are others.

For Sitecore, the "thumbnailsaccesstoken" header is used to authenticate requests. The header value is Base64 encoded to transport it safely using a header. The Searchlight Cyber blog explains how Sitecore deserializes this header using the BinaryFormatter class. Last August, Microsoft published an article warning of the use of this class. Microsoft specifically stated: "The BinaryFormatter.Deserialize method is never safe when used with untrusted input." Of course, there is very likely a lot of code out there using BinaryFromatter, with Sitecore being one example. Searchlight Cyber used the standard deserialization exploit tool ysoserial.exe to create a working code execution exploit targeting the Sitecore vulnerability.

After the recent Next.js vulnerability, I started paying more attention to the HTTP request headers collected by our honeypots. On March 14th and March 19th, about a week after Searchlight Cyber published its blog, I found requests that included the "thumbnailsaccesstoken" header. Sadly, we only save the first 250 bytes of any header value. But the snippet we have matches the PoC exploit used by Searchlight Cyber:

thumbnailsaccesstoken: AAEAAAD/////AQAAAAAAAAAEAQAAAClTeXN0ZW0uU2VjdXJpdHkuUHJpbmNpcGFsLldpbmRvd3NJZGVudGl0eQEAAAAkU3lzdGVtLlNlY3VyaXR5LkNsYWltc0lkZW50aXR5LmFjdG9yAQYCAAAAkApBQUVBQUFELy8vLy9BUUFBQUFBQUFBQU1BZ0FBQUY1TmFXTnliM052Wm5RdVVHOTNaWEpUYUdWc2JDNUZaR2wwYjNJc0lGWmxjbk

Sitecore patched the vulnerability in January. 

To help with identifying other odd headers more easily, I created some new summary reports for headers collected by our honeypots. Two starting points:

https://isc.sans.edu/weblogs/allheaders.html

This page lists all headers we saw, including the first and last time they were seen. Sorting by "First seen" can help identify "new" headers. I am still refining the list and improving it. For example, "accept" shows up as a new header, but this is " accept" with a space as the first character.

[1] https://slcyber.io/blog/sitecore-unsafe-deserialization-again-cve-2025-27218/
[2] https://learn.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide
[3] https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003535

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|