> TL;DR:
A recently disclosed security flaw, CVE-2024-29041, affects Express.js (versions prior to 4.19. and all pre-release alpha/beta 5. versions). It enables open redirect attacks—even when you carefully use allow lists—due to unexpected handling of malformed URLs. Here’s what happened, why it matters, the exploit in plain code, and how to patch your apps immediately.

What is CVE-2024-29041?

CVE-2024-29041 is an open redirect vulnerability in Express.js, the minimalist web framework for Node.js. If your app redirects users based on user input using res.redirect() or res.location(), attackers might trick it into redirecting users to malicious websites—even if you check against an allow list of safe URLs.

This happens because Express‘s internal URL encoding (via encodeurl) does not sanitize malformed URLs the way browsers or server-side logic may expect. As a result, some malformed URLs might slip past your allow list and still get sent as legitimate redirects.

The Problem

When developers implement redirects, it’s a common best practice to allow redirects only to a list of permitted domains or URI patterns (“allow list”). Express, however, encodes the URL passed to res.location() using encodeurl, before writing it to the Location header.

Here’s the catch: Malformed URLs (like those with a double slash, colon, or other quirks) can sometimes pass through allow lists and, after encoding, result in open redirects you didn’t intend.

`

/login?returnTo=https://evil.com

(internally: res.location(returnTo))

4. Due to the encoding + malformed input, an attacker can bypass allow list checks and get your app to redirect to a malicious site.

Here’s how a typical Express route might handle a user-provided return URL

const express = require('express');
const app = express();

// Suppose your allow-list of trusted domains:
const allowedDomains = ['example.com', 'my-app.com'];

app.get('/login', (req, res) => {
    const returnTo = req.query.returnTo;

    // ALLOW LIST CHECK:
    if (allowedDomains.some(domain => returnTo && returnTo.includes(domain))) {
        // Redirect to the trusted domain.
        res.redirect(returnTo);
    } else {
        // Default redirect.
        res.redirect('/');
    }
});

At first glance, this looks secure. But with CVE-2024-29041, a cleverly-mangled URL can bypass your allow list.

Suppose the attacker submits this as their returnTo

//\evil.com

Or this

http:/\evil.com

Here’s what happens

- Your allowedDomains check is tricked (since the domain string may appear in a longer or altered form, or due to how encodeurl normalizes it).
- Express’s encodeurl encodes these funky URLs, which when placed into the Location header, are interpreted by the browser as a redirect to evil.com (over HTTP).

Some allow-list implementations are bypassed because they don’t expect this encoding outcome.

As a result: The user gets sent to a malicious site containing fake login forms, phishing pages, malware, etc.

`

https://yourapp.com/login?returnTo=//evil.com

`js

res.redirect('//evil.com');

`

HTTP/1.1 302 Found
Location: //evil.com

`

4. Browser interprets //evil.com as https://evil.com (https is inferred from current protocol).

References

- NPM Security Advisory (CVE-2024-29041)
- encodeurl GitHub (encoding details)
- Express.js GitHub issue #xxxx (original report)
- Express.js Official Changelog - 4.19.2 release notes

5.x: 5..-beta.3

npm install express@4.19.2
# or
npm install express@5..-beta.3

Do not rely on just allow lists. Always sanitize, parse, and validate redirect URLs more strictly, e.g.:

const { URL } = require('url');

function isAllowed(returnTo) {
    try {
        const url = new URL(returnTo, 'https://my-app.com';);
        return url.hostname.endsWith('my-app.com');
    } catch (e) {
        return false;
    }
}

Conclusion

CVE-2024-29041 proves that even well-meaning, “safe” coding patterns—like allow lists—can break down due to subtle library internals.

Stay informed on dependencies and their security advisories

Visit the official advisory for more:
- Express.js Security Advisory


*Securing your redirects means securing your users—from phishing, session theft, and beyond. Update now.*

Timeline

Published on: 03/25/2024 21:15:46 UTC
Last modified on: 03/26/2024 12:55:05 UTC