CVE-2026-34236 is a high severity (CVSS 8.2) flaw in the Auth0 PHP SDK, versions 8.0.0 through 8.18.0. Cookies are encrypted with too little entropy, which could let an attacker brute-force the key and forge session cookies. Upgrade to 8.19.0 or later.
What's affected
The project's advisory (GHSA-w3wc-44p4-m4j7) lists auth0/auth0-php from 8.0.0 up to and including 8.18.0 as affected, and 8.19.0 as patched.
The advisory says you are also affected if you use SDKs that rely on Auth0-PHP: the Symfony, Laravel and WordPress SDKs. They pull in the core library, so the version that matters is the one in your lockfile.
How to check if you're exposed
composer show auth0/auth0-php
composer why auth0/auth0-php
The second command shows which of your packages require it. A match from 8.0.0 to 8.18.0 needs the upgrade. Paste a lockfile or manifest into the free in-browser dependency scan to see whether the package is in your tree, including as a transitive dependency. Reachability analysis then helps you judge whether your code calls the affected path, so you can order the work sensibly.
Check the cookie settings in your configuration too. Confirm the cookie secret is long and random, comes from a secret store, and is different in each environment.
What to do now
- Find every PHP project that uses Auth0-PHP or an SDK built on it.
- Upgrade
auth0/auth0-phpto 8.19.0 or later. - Rotate the cookie encryption secret your app configures, so any key an attacker may have recovered stops working.
- End existing sessions if you can, so older cookies are invalid.
- Redeploy and test sign-in.
Why it matters
The weakness is CWE-331, insufficient entropy. Encryption is only as strong as the unpredictability of its key. If the key space is small, an attacker who holds a cookie can try keys until one works, and then create cookies of their own.
A forged session cookie means signing in as someone else without a password. The CVSS vector shows high attack complexity and low privileges, which is why the score is high but not critical. The record does not mark the CVE as exploited, and it is not on the CISA KEV list.
After you upgrade, treat the old secret as possibly known. Changing it signs out every user, which is a small cost compared with the chance of forged sessions.
If you operate several PHP applications that share the same Auth0 tenant, update them together. A forged cookie only works against an app that uses the weak key, but one lagging service can give an attacker a foothold. Keep a list of the services that carry the SDK, with their versions, so the next advisory is a quick lookup. Frameworks that wrap the SDK, such as the Symfony, Laravel and WordPress packages the advisory names, update through the same Composer lock, so check the lockfile of each one. Finally, schedule a short regression test: sign in, confirm the cookie is accepted, then alter the cookie by one character and confirm it is rejected.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does upgrading invalidate stolen cookies?
Not by itself. Rotate the secret your app uses for cookies and consider ending current sessions.
Sources
Last reviewed: 19 October 2026.
