#js

Sonatype discovered ‘crypto-encrypt-ts’, a malicious npm package impersonating the popular CryptoJS library to steal crypto and personal data.…

### Summary PKCE was implemented in the OAuth implementation in workers-oauth-provider that is part of[ MCP framework](https://github.com/cloudflare/workers-mcp). However, it was found that an attacker could cause the check to be skipped. ### Impact PKCE is a defense-in-depth mechanism against certain kinds of attacks and was an optional extension in OAuth 2.0 which became required in the OAuth 2.1 draft. (Note that the MCP specification requires OAuth 2.1.) This bug completely bypasses PKCE protection. ### Patches Fixed in: https://github.com/cloudflare/workers-oauth-provider/pull/27 We patched up the vulnerabilities in the latest version, v 0.0.5 of the Workers OAuth provider (https://www.npmjs.com/package/@cloudflare/workers-oauth-provider). You'll need to update your MCP servers to use that version to resolve the vulnerability. ### Workarounds None

### Summary PKCE was implemented in the OAuth implementation in workers-oauth-provider that is part of[ MCP framework](https://github.com/cloudflare/workers-mcp). However, it was found that an attacker could cause the check to be skipped. ### Impact Under certain circumstances (see below), if a victim had previously authorized with a server built on workers-oath-provider, and an attacker could later trick the victim into visiting a malicious web site, then attacker could potentially steal the victim's credentials to the same OAuth server and subsequently impersonate them. In order for the attack to be possible, the OAuth server's authorized callback must be designed to auto-approve authorizations that appear to come from an OAuth client that the victim has authorized previously. The authorization flow is not implemented by workers-oauth-provider; it is up to the application built on top to decide whether to implement such automatic re-authorization. However, many applications do impl...

A misconfigured, non-password-protected database belonging to TicketToCash exposed data from 520,000 customers, including PII and partial financial details.…

### Summary The contents of files in [the project `root`](https://vite.dev/config/shared-options.html#root) that are denied by a file matching pattern can be returned to the browser. ### Impact Only apps explicitly exposing the Vite dev server to the network (using --host or [server.host config option](https://vitejs.dev/config/server-options.html#server-host)) are affected. Only files that are under [project `root`](https://vite.dev/config/shared-options.html#root) and are denied by a file matching pattern can be bypassed. - Examples of file matching patterns: `.env`, `.env.*`, `*.{crt,pem}`, `**/.env` - Examples of other patterns: `**/.git/**`, `.git/**`, `.git/**/*` ### Details [`server.fs.deny`](https://vite.dev/config/server-options.html#server-fs-deny) can contain patterns matching against files (by default it includes `.env`, `.env.*`, `*.{crt,pem}` as such patterns). These patterns were able to bypass for files under `root` by using a combination of slash and dot (`/.`). #...

Overview OpenFGA v1.8.10 or previous (Helm chart <= openfga-0.2.28, docker <= v.1.8.10) are vulnerable to authorization bypass when certain Check and ListObject calls are executed. Am I Affected? If you are using OpenFGA v1.8.10 or previous, specifically under the following conditions, you are affected by this authorization bypass vulnerability: - Calling Check API or ListObjects with an [authorization model](https://openfga.dev/docs/concepts#what-is-an-authorization-model) that has tuple cycle. - [Check query cache](https://github.com/openfga/openfga/blob/9b5974458b777707ed2a30ba6303699499e655ee/.config-schema.json#L528) is enabled, and - There are multiple check / list objects requests involving the tuple cycle within the check query TTL Fix Upgrade to v1.8.11. This upgrade is backwards compatible.

### Impact Attackers can deceive users into sending funds to an unintended address. ### Patches https://github.com/cryptocoinjs/base-x/pull/86

### Overview Auth0 NextJS `v4.0.1` to `v4.5.0` does not invoke `.setExpirationTime` when generating a JWE token for the session. As a result, the JWE does not contain an internal expiration claim. While the session cookie may expire or be cleared, the JWE remains valid. ### Am I Affected? You are affected if you are using Auth0 NextJS SDK v4. ### Fix Upgrade to `v4.5.1`.

Improper sanitization of the value of the 'href' and 'xlink:href' attributes in '<image>' SVG elements in AngularJS allows attackers to bypass common image source restrictions. This can lead to a form of Content Spoofing https://owasp.org/www-community/attacks/Content_Spoofing  and also negatively affect the application's performance and behavior by using too large or slow-to-load images. This issue affects all versions of AngularJS. Note: The AngularJS project is End-of-Life and will not receive any updates to address this issue. For more information see here https://docs.angularjs.org/misc/version-support-status .

### Summary A stored cross-site scripting (XSS) vulnerability was discovered in the application’s comments feature. This issue allows a malicious actor to inject JavaScript payloads that are stored and later executed in the browser of any user viewing the affected comment. The XSS occurs because the application fails to properly sanitize or encode user input submitted to the comments. Notably, the application sanitizes or does not allow execution of `<script>` tags, but does not account for payloads obfuscated using JavaScript block comments like `/* JavaScriptPayload */`. ### PoC Navigate to a site and page that allows comments and place this in the comments section and submit it: `/*<script>alert('pizzapower')</script>*/` Upon submitting to the page, it will run. And then upon every page visit, it will run. ### Impact An attacker can run arbitrary JS in the victim's browser (any user that visits the page with the comments). This can be chained to do many malicious actions, ...