Sitecore Container Prerequisites Script Updates

Heads up!  I’ve made some recent updates to the open source Sitecore Container Prerequisites script to keep things aligned with the latest Sitecore versions and development environments.

What’s new:

• ✅ Added support for Sitecore 10.3.2 and 10.4.0

• 🖥️ Improved OS compatibility checks for Windows 10 and 11

• 📄 Refined the README with clearer instructions for installation, usage, and contributing

• 🔗 Updated package download links and references to current installation guides

Sitecore Container Prerequisites script remains a helpful utility for preparing your Windows machine to run Sitecore containerized environments smoothly. 

Feedback and contributions are always welcome!

📍 View the GitHub repo

Read the full post →

Using Sitecore Indexes in PowerShell-Driven Multilist Datasources

If you didn't know, you can point a Sitecore field's datasource to a PowerShell script. It's a super clean way to make dynamic picklists, filtering based on the current item, tags, templates, relationships, you name it.

But if you're pulling a large set of items, you really want to use the search index.

That's where things get weird.

The Find-Item command gives you fast results… but they aren't real Sitecore items. They're search result objects; great for speed, not so great for populating a multilist. Sitecore expects actual items, and when it doesn't get them, your field ends up looking empty.

Luckly, you don't have to abandon the approach completely. The fix is actually a pretty straightforward.

Some Context

For context, you can set the datasource for a multilist to be driven via a script in SPE like this:

In the script definition itself, you can write PowerShell to obtain some set of items from the tree. The resulting list is what shows as applicable for selection on the field.

In theory, you should be able to also utilize the Find-Item commandlet to obtain a list of items from the index. In my case was necessary due the performance implications of running a Get-ChildItem against a massive subtree.

First attempt looked something like this:

So far, so good. You get back a list of items. Or do you?

The Catch

The objects in the $list variable returned by Find-Item are not Sitecore items. They're dynamic search result objects that look like items, walk like items, but won't work in your multilist unless they quack like items.

If you try to return them as-is from your script, you'll find that, even if items were found in the index, the multilist fails to render the items for selection.

The fix? Pretty simple actuallu: Transform the search results back into legit Sitecore items.

Put it all together and you're golden

Now your multilist knows what to do. The search is lightning fast thanks to the index, and authors can pick from relevant matches without sifting through the entire tree.

Why This Matters

This pattern shines when you're working with large content trees or complex tagging structures where traditional item traversal would be painfully slow. By using the index, you're offloading the heavy lifting to Solr, gaining serious performance without sacrificing editor experience.

But more importantly, it calls out a subtle, easy-to-miss SPE gotcha: not all objects returned from PowerShell helpers are Sitecore items. If you're using Find-Item, you'll almost always need a second pass to resolve those results into actual items before they'll work in a field context.

Fail to do that, and you might spend hours wondering why your multilist is coming up empty, despite the index finding exactly what you wanted.

Happy datasourcing! 🚀

Read the full post →

Sitecore Security: Are These 2023 CVEs Still a Risk?

Security in Sitecore is always evolving, and if you're not keeping an eye on the latest CVEs, you might find yourself on the wrong end of a security bulletin scramble.

Recently, a set of CVEs related to Sitecore PageDesigner have resurfaced with an increased severity rating from NIST (National Institute of Standards and Technology, the U.S. agency responsible for maintaining the National Vulnerability Database and setting cybersecurity standards), prompting the question:

Are these vulnerabilities already covered in Sitecore's official security bulletin SC2024-001-619349?

The short answer: not entirely. But let's break it down.

The CVEs in Question

Back in March 2023, security researchers uncovered a set of zero-day vulnerabilities in Sitecore PageDesigner that could allow attackers to exploit weaknesses in how Sitecore handles file paths and serialized data.

These vulnerabilities were later classified under three CVE (Common Vulnerabilities and Exposures) IDs:

• CVE-2023-27066 - Directory Traversal: Allows authenticated attackers to download arbitrary files via UrlHandle.
  
  
• CVE-2023-27067 - Directory Traversal: Allows remote attackers to download arbitrary files via a crafted request to download.aspx.
  
  
• CVE-2023-27068 - Deserialization of Untrusted Data: Enables remote attackers to execute arbitrary code through ValidationResult.aspx

How These Vulnerabilities Work

The original Sitecore PageDesigner flaws were discovered in how Sitecore handled URL parameters and session values within specific backend pages. Here’s a breakdown of the two primary attack vectors:

First: Directory Traversal (CVE-2023-27066 & CVE-2023-27067)

The download.aspx page in Sitecore allowed attackers to manipulate file paths using ../ sequences, potentially granting access to sensitive files like web.config.

Normally, Sitecore prevents direct user input in these cases.

However, a flaw in Sitecore’s internal UrlHandle mechanism made it possible for an attacker to forge requests that bypassed these protections.

Second: Insecure Deserialization (CVE-2023-27068)

Sitecore PageDesigner’s session handling stored data in an unprotected format, allowing an attacker to inject malicious serialized objects.

This vulnerability could lead to remote code execution (RCE) if exploited correctly, making it the most severe issue among the three.

Why These CVEs Matter Now

At the time of discovery, the recommended fix was to upgrade to Sitecore 10.3.0 rev. 008463 or later. However, as of January 28, 2025, the severity rankings for these three CVEs has been increased.

Sitecore’s Response

After reaching out to Sitecore Support, I got clarification specifically regarding CVE-2023-27067:

CVE-2023-27067 is related to bug #390129, which was fixed in Sitecore 10.3.

Sitecore classifies this issue as low priority because it requires an authenticated user to exploit, meaning there is no risk of an anonymous attack.

This CVE is NOT included in Security Bulletin SC2024-001-619349 (KB1003408).

So, while CVE-2023-27067 is real, Sitecore does not consider it critical enough to be included in an official security bulletin.

Workarounds & Mitigation

If upgrading to Sitecore 10.3 isn't an immediate option, Sitecore provides a simple workaround:

🔧 Delete the following file:

• /sitecore/shell/Applications/Layouts/PageDesigner/PageDesigner.xaml.xml

This file is tied to a deprecated layout editor (used for editing ASPX markup), and removing it does not impact any core Sitecore functionality.

For those running older Sitecore versions <10.3, this is a quick and effective way to mitigate risk until an upgrade is possible.

Final Thoughts

It’s easy to assume that a security bulletin will cover every vulnerability, but in this case, SC2024-001-619349 (KB1003408) does NOT include CVE-2023-27067. However, the issue was addressed in Sitecore 10.3, and for those who haven’t upgraded yet, removing a single deprecated file provides an immediate workaround.

If you haven't yet, check your environment, apply the necessary mitigation, and as always, stay on top of those Sitecore security bulletin updates!

Happy securing! 🔐

Read the full post →