Info-leak flaw in the Directus data platform (CVE-2026-61836): password-protected shares exposed to others, update to v12

Directus, software used worldwide as the foundation for managing company data and serving it behind websites and apps, has a vulnerability that can leak information. Tracked as CVE-2026-61836, it carries a severity score (CVSS) of 8.6 out of 10. Without any login, an unrelated third party can peek at the contents of a "share link" that was meant for someone else. Even a password-protected share can have its contents pulled without the password once the conditions line up.

First, let's be clear. Only environments where two conditions both hold are affected. One is that you have turned on the "cache" feature that speeds up data display (off by default). The other is that you use the "share links (Shares)" feature that exposes data externally. If either one does not apply, you are not affected by this flaw. The issue is already fixed in the latest version, 12.0.0, so if your usage matches, updating there resolves it.

This article walks through what Directus is, why someone else's shared content can be exposed without a login, and how to tell whether your environment is affected — all in plain terms that require no special background.

What Directus is, and why the leak happens

Directus is open-source backend software that, just by connecting to an existing database (a system that stores things like customer lists and product data in an organized way), automatically provides an interface (API) to read and write that data, plus an admin screen where staff can edit the contents in a browser. This category is also called a headless CMS (a content management system that has no display layer and handles only data management), and it is widely used as the foundation for managing the data of websites and mobile apps.

The project's GitHub page has around 34,500 "stars," and it is reported to be used by companies such as Tripadvisor, Adobe, and Mercedes-Benz overseas. Because it is free to start and can be self-hosted on your own server, it is well known among developers and corporate IT departments.

What went wrong this time is a Directus feature called "share links (Shares)." This lets you issue a URL that shows only specific data even to people outside the organization who are not logged into the admin screen, with per-URL settings for "who sees what" and, if needed, a password. But when combined with the "cache" (a mechanism that temporarily stores a display result once produced and reuses it next time to speed things up), that stored result can be handed out even to the wrong audience — that is the heart of this flaw.

Overview of the vulnerability

CVE-2026-61836: a share link's contents get handed to someone else

This flaw arises because Directus mixes up "which display result to remember as whose." The key points are summarized below.

The flaw was reported by tr4ce-ju. It was published as a GitHub Security Advisory (GHSA-c6w9-5g5j-jh2p) on June 24, 2026, and fixed in 12.0.0 released the same day. It was registered with the U.S. NVD as CVE-2026-61836 on July 15.

Who would target this, and why

Classification codes and numbers alone rarely convey "does this concern me?" So let's spell out who would abuse this hole, what they would do, and what leaks.

The target is not limited to highly skilled attackers. The likely party is someone who obtained a share link's URL, or an anonymous third party who reached that URL. Share links are meant to be handed out even externally, so anyone who knows the URL can reach them.

What such a party can do with this hole is snatch and read shared content meant for someone else (or supposedly protected by a password), stored display result and all. Once someone opens that share and the display result lands in the cache, a later anonymous request — or a person who merely holds a different share link — can receive the same content. Even a password-protected share, once it is in the cache, can reportedly have its contents pulled without any password exchange.

What leaks depends on the permissions you assigned to that share link. If you tightly limited permissions, only the primary keys (the numbers that serve as data headers) leak; if you allowed a wide viewing scope, everything visible under that permission goes out. For the company or organization running Directus, the biggest blow is that data meant for limited disclosure ends up with an unspecified audience; for the people using that service, the impact is that their information may be seen by an unintended party. That is exactly why the next section — telling whether you are affected — matters.

What is actually happening: breaking down the mechanism

From here it gets a bit technical. This is for readers who want the mechanism; if you only want the fix, feel free to skip ahead.

A cache is a mechanism that stores a "for this request, this answer" mapping with a label (cache key) so it doesn't have to build the answer from scratch every time. When the next request with the same label arrives, it returns the saved answer as-is. It's a trick for speed, but if you get the labeling wrong, you return someone else's answer by mistake.

Directus built this label from four things: version, the requested path, the query, and the user (account). The problem is that the authorization context — under what permission and as which share link the person is viewing (share, role, admin, policies, and so on) — was not part of the key. In particular, access via a share link is treated as user "none (anonymous)," so all share links and anonymous access end up with the same label, and one share's answer was handed straight to a person with a different share, or an anonymous person. Technically, it combines caching a result that contains sensitive information (CWE-524) with an authorization bypass keyed on a user-controllable value (CWE-639).

The nasty part is that this error persists over time. A cache has a retention window (CACHE_TTL, typically around 5–30 minutes), during which the wrong delivery continues. If you use an external store such as Redis for storage, a poisoned cache can survive even a server restart. As for password protection, once a legitimate person who knows the password opens it and populates the cache, the bypass works in that order: afterward the content can be pulled without going through the password check.

Am I affected? A quick reference for the conditions

The single most important question with this flaw is whether your Directus meets the conditions. If you use the cache at its default setting (off), you are not affected by this issue. Check with the table below.

You can tell whether the cache is in use by whether the setting CACHE_ENABLED is true. It is false (off) by default, so if you don't recall turning it on to improve display speed, you are most likely out of scope. However, if in production you actually use share links to expose data externally and also have the cache on, the conditions line up, so update as a priority.

The timeline from discovery to disclosure

About three weeks passed between the fix and the formal number assignment for this flaw. Knowing the timeline helps you judge the situation.

← Swipe to move

What to do right now

The response is simple. Update Directus to 12.0.0 or later. This makes the cache label correctly include permission and share information, resolving the issue. Update steps and changes are covered in the official Directus release notes.

If you can't update right away, as a stopgap you can temporarily turn off the cache (set CACHE_ENABLED back to false) to stop leaks via this path. Because incorrect content may already remain in the cache, it's safest to purge the retained cache after updating or disabling it. If you use an external store such as Redis, clear that data too.

Open-source software you run on your own server, like Directus, is easy to adopt, but it requires you to keep up with fix information yourself. When you want to review which open-source components have which vulnerabilities, see our companion piece on how to check the safety of open-source software.

Not every environment is affected — so why know now

To recap: CVE-2026-61836 scores 8.6, but it affects only environments that have "turned the cache on themselves and also use the share links feature," and there are no reports of actual exploitation so far. For most Directus users, this is news you don't need to panic about.

We still cover it because production environments where these two conditions line up are far from rare. Turning the cache on to speed up display, and using share links to expose data externally, is a common combination. And this time, the fact that even shares you protected with a password could be peeked at is hard to overlook. The structure — a trick meant to make things faster handing answers even to audiences that shouldn't see them — is also a lesson that applies to any system that uses a cache.

This blog continues to track vulnerabilities found in data-management and CMS software. Reading alongside the case of the enterprise CMS Sitefinity, flagged for information exposure without a login, and the blogging tool Ghost, reveals the recurring pattern of problems in this space.

Frequently asked questions

Q. We use Directus but haven't turned the cache on. Do we need to do anything?

A. For CVE-2026-61836, if the cache is off (at its default), you are not affected. Do keep applying your routine security updates, though. If you're concerned, updating to 12.0.0 is the sure move.

Q. Aren't password-protected share links safe?

A. Not when the conditions line up. Once a person who knows the password opens that share and the display result lands in the cache, the content may be pulled afterward without any password exchange. If this applies, update to 12.0.0.

Q. Can data be tampered with, or the service taken down?

A. This flaw is limited to information disclosure (confidentiality); it does not cause data tampering or downtime. Still, data meant for limited disclosure reaching outsiders is itself a serious problem.

References

• ▸ NVD - CVE-2026-61836 (published July 15, 2026)
• ▸ GitHub Security Advisory - GHSA-c6w9-5g5j-jh2p (June 24, 2026)
• ▸ Directus - Release notes (12.0.0)
• ▸ Directus official site
• ▸ Directus - GitHub repository