Security
Headlines
HeadlinesLatestCVEs

Tag

#git

GHSA-f3fg-mf2q-fj3f: NextJS-Auth0 SDK Vulnerable to CDN Caching of Session Cookies

**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.

ghsa
#vulnerability#nodejs#js#git#perl#auth
GHSA-9jgg-88mc-972h: webpack-dev-server users' source code may be stolen when they access a malicious web site with non-Chromium based browser

### 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...

GHSA-4v9v-hfq4-rm2v: webpack-dev-server users' source code may be stolen when they access a malicious web site

### 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. ![image](https://github.com/user-attachments/assets/9d4dcdca-5d24-4c84-a7b4-feb1782bca09) The scr...

GHSA-2x3r-hwv5-p32x: Deno's AES GCM authentication tags are not verified

### 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...

GHSA-v9m8-9xxp-q492: Auth0-PHP SDK Deserialization of Untrusted Data vulnerability

**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.

Exclusive: Hackers Leak 86 Million AT&T Records with Decrypted SSNs

Hackers leak data of 88 million AT&T customers with decrypted SSNs; latest breach raises questions about links to earlier Snowflake-related attack.

How Neuroscience Can Help Us Battle 'Alert Fatigue'

By understanding the neurological realities of human attention, organizations can build more sustainable security operations that protect not only their digital assets but also the well-being of those who defend them.

Attackers Impersonate Ruby Packages to Steal Sensitive Telegram Data

Malicious RubyGems pose as a legitimate plug-in for the popular Fastlane rapid development platform in a geopolitically motivated attack with global supply chain reach.

Photoshop for Beginners – Overview of Top Skills and How to Hone Them

What comes to your mind when you think of Photoshop? A tool for editing and retouching photos –…

The Rise of ‘Vibe Hacking’ Is the Next AI Nightmare

In the very near future, victory will belong to the savvy blackhat hacker who uses AI to generate code at scale.