Directus to Anywhere: Riding the SAML RelayState Express (CVE-2026-22032)

Directus is the darling of the modern stack—a sleek, real-time API and dashboard that turns any SQL database into a headless CMS. It’s the kind of tool developers love because it 'just works.' But when you start integrating enterprise protocols like SAML (Security Assertion Markup Language), 'just working' isn't enough; it needs to just work securely.

SAML is a beast of a protocol. It involves a three-way dance between the User, the Service Provider (Directus), and the Identity Provider (IdP, like Okta or Auth0). One critical component of this dance is maintaining state. If I try to access a specific dashboard page but haven't logged in, the application sends me to the IdP. Once I authenticate, the application needs to remember where I wanted to go. Enter the RelayState parameter.

RelayState is essentially a bookmark. It travels from the Service Provider to the IdP and comes back unchanged. It’s the digital equivalent of a coat check ticket. The problem with CVE-2026-22032 is that Directus trusted this ticket implicitly. If the ticket said 'give this person the coat belonging to the bank robber,' Directus happily obliged.

The vulnerability lies within the logic gap between initiation and callback. When a user starts a SAML login flow, Directus constructs a SAML Request and sends the user to the IdP. It allows a redirect URL to be embedded in the RelayState so the user lands on the right page after login.

The developers implemented validation logic during the initiation phase (when generating the request). However, they forgot the golden rule of web security: never trust input, even if you think you generated it. The vulnerability existed in the Assertion Consumer Service (ACS)—the callback endpoint where the IdP returns the user.

When the IdP POSTs the SAML Response back to Directus, it includes the RelayState. The Directus SAML driver (api/src/auth/drivers/saml.ts) would parse this response, log the user in, and then—without a second glance—issue an HTTP 302 Redirect to whatever URL was inside that RelayState. It didn't check if the URL was relative (e.g., /admin/content) or absolute (e.g., https://evil-phishing-site.com). This meant the validation at the start of the flow was irrelevant; if an attacker could inject a malicious URL into the RelayState passed to the callback, the game was over.

Let’s look at the code. This is a textbook example of a missing safeguard. In the vulnerable versions (pre-11.14.0), the SAML driver handled the success path like this:

// The Vulnerable Logic (Pseudo-code representation)
async callback(req, res) {
    const { relayState } = req.body;
    // ... perform authentication ...
    
    // The Fatal Flaw: Blindly redirecting
    if (relayState) {
        return res.redirect(relayState);
    }
    return res.redirect('/');
}

The fix, introduced in commit dad9576ea9362905cc4de8028d3877caff36dc23, forces the application to verify the destination against a strict allowlist (usually the application's own public URL). It introduces a utility function isLoginRedirectAllowed.

// The Fix in api/src/auth/drivers/saml.ts
 
// ... inside the callback handler ...
 
if (relayState && isLoginRedirectAllowed(relayState, providerName) === false) {
    // 🛑 STOP RIGHT THERE, CRIMINAL SCUM
    throw new InvalidPayloadError({
        reason: `URL "${relayState}" can't be used to redirect after login` 
    });
}
 
// proceed to redirect only if valid

This simple check ensures that the relayState is either a relative path or matches the configured PUBLIC_URL of the Directus instance. If it points to an external domain not explicitly allowed, it throws an error.

Exploiting this is trivially easy and highly effective for social engineering. The goal is to create a link that looks legitimate (it points to the company's Directus instance) but lands the user on a phishing page.

The Attack Chain:

1. Reconnaissance: The attacker identifies a target organization using Directus with SAML enabled (e.g., https://cms.target-corp.com).
2. Crafting the Link: The attacker creates a URL that initiates the SAML login but specifies a malicious redirect. Depending on how Directus parses the initial request to build the RelayState, this might look like: https://cms.target-corp.com/auth/login/saml?redirect=https://evil-phishing.com/login
3. The Hook: The attacker sends this link to an employee via email: "Urgent: Please review the Q1 content updates on the CMS."
4. The Bait: The victim clicks. They see the legitimate Directus URL. They are redirected to their corporate IdP (Okta/Azure AD). They sign in with valid credentials.
5. The Switch: The IdP sends them back to Directus. Directus authenticates them, reads the RelayState (https://evil-phishing.com/login), and issues a 302 Found.
6. The Catch: The victim lands on evil-phishing.com, which is styled exactly like the Directus dashboard but asks for a "session re-verification." The victim enters their creds again. Game over.

Because the redirect happens after a valid login, the user's suspicion is at an absolute minimum. It feels like a standard SSO quirk.

CVSS scores often mislead. A score of 4.3 (Medium) suggests this is a "fix it next month" problem. It isn't. Open Redirects are force multipliers for other attacks.

In a corporate environment, trust is the perimeter. Users are trained to check the URL bar. This exploit allows an attacker to start the interaction on a trusted, green-lock domain. It bypasses the first line of human defense.

Furthermore, this wasn't just on successful logins. The vulnerability existed in error handling paths too. Even if the user cancelled the login at the IdP, Directus might still process the RelayState and redirect them, meaning the attack doesn't even strictly require valid credentials to work as a redirector.

The remediation is straightforward: Update Directus to version 11.14.0 or higher immediately.

If you are stuck on an older version and cannot upgrade (why?), you might be able to mitigate this at the network level, but it's messy. You would need WAF rules that inspect the RelayState parameter in POST requests to /auth/login/saml/callback and block anything looking like an external absolute URL.

Post-patch, ensure your PUBLIC_URL environment variable is set correctly. This variable is the source of truth for the new validation logic. If you do need to redirect to external domains (e.g., multiple micro-frontends), you must now explicitly list them in AUTH_SAFE_REDIRECT_URLS. Directus has moved from a "permissive by default" to a "secure by default" stance here, which is exactly what we want to see.