Latest News

**Overview** In Auth0 Next.js SDK versions 4.0.1 to 4.6.0, __session cookies set by auth0.middleware may be cached by CDNs due to missing Cache-Control headers. **Am I Affected?** You are affected by this vulnerability if you meet the following preconditions: 1. Applications using the NextJS-Auth0 SDK, versions between 4.0.1 to 4.6.0, 2. Applications using CDN or edge caching that caches responses with the Set-Cookie header. 3. If the Cache-Control header is not properly set for sensitive responses. **Fix** Upgrade auth0/nextjs-auth0 to v4.6.1.

## Summary It is possible to bypass Deno's read/write permission checks by using `ATTACH DATABASE` statement. ## PoC ```js // poc.js import { DatabaseSync } from "node:sqlite" const db = new DatabaseSync(":memory:"); db.exec("ATTACH DATABASE 'test.db' as test;"); db.exec("CREATE TABLE test.test (id INTEGER PRIMARY KEY, name TEXT);"); ``` ``` $ deno poc.js ```

### Summary The [Deno.env.toObject](https://docs.deno.com/api/deno/~/Deno.Env.toObject) method ignores any variables listed in the `--deny-env` option of the `deno run` command. When looking at the [documentation](https://docs.deno.com/runtime/fundamentals/security/#environment-variables) of the `--deny-env` option this might lead to a false impression that variables listed in the option are impossible to read. ### PoC ``` export AWS_SECRET_ACCESS_KEY=my-secret-aws-key # Works as expected. The program stops with a "NotCapable" error message echo 'console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY"));' | deno run \ --allow-env \ --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY - # All enviroment variables are printed and the --deny-env list is completely disregarded echo 'console.log(Deno.env.toObject());' | deno run \ --allow-env \ --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY - ``` The first example using `get` exits with the following error: ``` error: Uncaught (in p...

### Summary `deno run --allow-read --deny-read main.ts` results in allowed, even though 'deny' should be stronger. Same with all global unary permissions given as `--allow-* --deny-*`. ### Details Caused by the fast exit logic in #22894. ### PoC Run the above command expecting no permissions to be passed. ### Impact This only affects a nonsensical combination of flags, so there shouldn't be a real impact on the userbase.

### Summary Source code may be stolen when you access a malicious web site with non-Chromium based browser. ### Details The `Origin` header is checked to prevent Cross-site WebSocket hijacking from happening which was reported by CVE-2018-14732. But webpack-dev-server always allows IP address `Origin` headers. https://github.com/webpack/webpack-dev-server/blob/55220a800ba4e30dbde2d98785ecf4c80b32f711/lib/Server.js#L3113-L3127 This allows websites that are served on IP addresses to connect WebSocket. By using the same method described in [the article](https://blog.cal1.cn/post/Sniffing%20Codes%20in%20Hot%20Module%20Reloading%20Messages) linked from CVE-2018-14732, the attacker get the source code. related commit: https://github.com/webpack/webpack-dev-server/commit/72efaab83381a0e1c4914adf401cbd210b7de7eb (note that `checkHost` function was only used for Host header to prevent DNS rebinding attacks so this change itself is fine. This vulnerability does not affect Chrome 94+ (and othe...

### Summary Source code may be stolen when you access a malicious web site. ### Details Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject `<script src="http://localhost:8080/main.js">` in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. Combined with prototype pollution, the attacker can get a reference to the webpack runtime variables. By using `Function::toString` against the values in `__webpack_modules__`, the attacker can get the source code. ### PoC 1. Download [reproduction.zip](https://github.com/user-attachments/files/18426585/reproduction.zip) and extract it 2. Run `npm i` 3. Run `npx webpack-dev-server` 4. Open `https://e29c9a88-a242-4fb4-9e64-b24c9d29b35b.pages.dev/` 5. You can see the source code output in the document and the devtools console.  The scr...

## Impact On Windows, the shared `%PROGRAMDATA%` directory is searched for configuration files (`SYSTEM_CONFIG_PATH` and `SYSTEM_JUPYTER_PATH`), which may allow users to create configuration files affecting other users. Only shared Windows systems with multiple users and unprotected `%PROGRAMDATA%` are affected. ## Mitigations - upgrade to `jupyter_core>=5.8.1` (5.8.0 is patched but breaks `jupyter-server`) , or - as administrator, modify the permissions on the `%PROGRAMDATA%` directory so it is not writable by unauthorized users, or - as administrator, create the `%PROGRAMDATA%\jupyter` directory with appropriately restrictive permissions, or - as user or administrator, set the `%PROGRAMDATA%` environment variable to a directory with appropriately restrictive permissions (e.g. controlled by administrators _or_ the current user) ## Credit Reported via Trend Micro Zero Day Initiative as ZDI-CAN-25932

### Summary This affects AES-256-GCM and AES-128-GCM in Deno, introduced by commit [0d1beed](https://github.com/denoland/deno/commit/0d1beed). Specifically, the authentication tag is not being validated. This means tampered ciphertexts or incorrect keys might not be detected, which breaks the guarantees expected from AES-GCM. Older versions of Deno correctly threw errors in such cases, as does Node.js. Without authentication tag verification, AES-GCM degrades to essentially CTR mode, removing integrity protection. Authenticated data set with set_aad is also affected, as it is incorporated into the GCM hash (ghash) but this too is not validated, rendering AAD checks ineffective. ### PoC ```ts import { Buffer } from "node:buffer"; import { createCipheriv, createDecipheriv, randomBytes, scrypt, } from "node:crypto"; type Encrypted = { salt: string; iv: string; enc: string; authTag: string; }; const deriveKey = (key: string, salt: Buffer) => new Promise<Buffer>((res...

**Overview** The Auth0 PHP SDK contains a vulnerability due to insecure deserialization of cookie data. If exploited, since SDKs process cookie content without prior authentication, a threat actor could send a specially crafted cookie containing malicious serialized data. **Am I Affected?** You are affected by this vulnerability if you meet the following preconditions: 1. Applications using the Auth0-PHP SDK, versions between 8.0.0-BETA3 to 8.3.0. 2. Applications using the following SDKs that rely on the Auth0-PHP SDK versions between 8.0.0-BETA3 to 8.3.0: a. Auth0/symfony, b. Auth0/laravel-auth0, c. Auth0/wordpress. **Fix** Upgrade Auth0/Auth0-PHP to 8.3.1. **Acknowledgement** Okta would like to thank Andreas Forsblom for discovering this vulnerability.

A group Google is tracking as UNC6040 has been tricking users into installing a malicious version of a Salesforce app to gain access to and steal data from the platform.