#js

### Summary The `fast-jwt` library does not properly validate the `iss` claim based on the RFC https://datatracker.ietf.org/doc/html/rfc7519#page-9. #### Details The `iss` (issuer) claim validation within the fast-jwt library permits an array of strings as a valid `iss` value. This design flaw enables a potential attack where a malicious actor crafts a JWT with an `iss` claim structured as `['https://attacker-domain/', 'https://valid-iss']`. Due to the permissive validation, the JWT will be deemed valid. Furthermore, if the application relies on external libraries like `get-jwks` that do not independently validate the `iss` claim, the attacker can leverage this vulnerability to forge a JWT that will be accepted by the victim application. Essentially, the attacker can insert their own domain into the `iss` array, alongside the legitimate issuer, and bypass the intended security checks. #### PoC Take a server running the following code: ```js const express = require('express') const ...

### Impact User control of the first argument of the `addImage` method results in CPU utilization and denial of service. If given the possibility to pass unsanitized image urls to the `addImage` method, a user can provide a harmful data-url that results in high CPU utilization and denial of service. Other affected methods are: `html`, `addSvgAsImage`. Example payload: ```js import { jsPDF } from "jpsdf" const doc = new jsPDF(); const payload = 'data:/charset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=s\x00base64,undefined'; const startTime = performance.now() try { doc.addImage(payload, "PNG", 10, 40, 180, 180, undefined, "SLOW"); } catch (err) { const endTime = performance.now() console.log(`Call to doc.addImage took ${endTime - startTime} milliseconds`) } doc.save("a4.pdf");...

View CSAF 1. EXECUTIVE SUMMARY CVSS v4 8.7 ATTENTION: Exploitable remotely/low attack complexity Vendor: Schneider Electric Equipment: ASCO 5310 / 5350 Vulnerabilities: Download of Code Without Integrity Check, Allocation of Resources Without Limits or Throttling, Cleartext Transmission of Sensitive Information, Unrestricted Upload of File with Dangerous Type 2. RISK EVALUATION Successful exploitation of these vulnerabilities could allow an attacker to perform a denial of service, loss of availability, or loss of device integrity. 3. TECHNICAL DETAILS 3.1 AFFECTED PRODUCTS Schneider Electric reports the following products are affected: Schneider Electric ASCO 5310 Single-Channel Remote Annunciator: All versions Schneider Electric ASCO 5350 Eight Channel Remote Annunciator: All versions 3.2 VULNERABILITY OVERVIEW 3.2.1 DOWNLOAD OF CODE WITHOUT INTEGRITY CHECK CWE-494 Schneider Electric ASCO 5310 / 5350 remote annunciator is vulnerable to a download of code without integrity check vulner...

A vulnerability allows users to manipulate the final payment amount processed by PayPal. If a user modifies the item quantity in their shopping cart after initiating the PayPal Checkout process, PayPal will not receive the updated total amount. As a result, PayPal captures only the initially transmitted amount, while Sylius incorrectly considers the order fully paid based on the modified total. This flaw can be exploited both accidentally and intentionally, potentially enabling fraud by allowing customers to pay less than the actual order value. ### Impact - Attackers can intentionally pay less than the actual total order amount. - Business owners may suffer financial losses due to underpaid orders. - Integrity of payment processing is compromised. ### Patches The issue is fixed in versions: 1.6.1, 1.7.1, 2.0.1 and above. ### Workarounds To resolve the problem in the end application without updating to the newest patches, there is a need to overwrite `ProcessPayPalOrderAction` wi...

### Impact XSS vulnerability when the sanitizer is used with a `contentEditable` element to set the elements `innerHTML` to a sanitized string produced by the package. If the code is particularly crafted to abuse the code beautifier, that runs AFTER sanitation. ### Patches Patched in version 2.0.3

### Summary An attacker could write files with arbitrary content to the filesystem via the `/api/v1/document-store/loader/process` API. An attacker can reach RCE(Remote Code Execution) via file writing. ### Details All file writing functions in [packages/components/src/storageUtils.ts](https://github.com/FlowiseAI/Flowise/blob/main/packages/components/src/storageUtils.ts) are vulnerable. - addBase64FilesToStorage - addArrayFilesToStorage - addSingleFileToStorage The fileName parameter, which is an untrusted external input, is being used as an argument to path.join() without verification. ```javascript const filePath = path.join(dir, fileName) fs.writeFileSync(filePath, bf) ``` Therefore, users can move to the parent folder via `../` and write files to any path. Once file writing is possible in all paths, an attacker can reach RCE (Remote Code Execution) in a variety of ways. In PoC (Proof of Concept), RCE was reached by overwriting package.json. ### PoC In PoC, `package.json` is o...

# Impact An attacker may be able to exploit this vulnerability to bypass authentication or authorization mechanisms in systems that rely on xml-crypto for verifying signed XML documents. The vulnerability allows an attacker to modify a valid signed XML message in a way that still passes signature verification checks. For example, it could be used to alter critical identity or access control attributes, enabling an attacker to escalate privileges or impersonate another user. # Patches All versions <= 6.0.0 are affected. Please upgrade to version 6.0.1. If you are still using v2.x or v3.x please upgrade to the associated patch version. # Indicators of Compromise When logging XML payloads, check for the following indicators. If the payload includes encrypted elements, ensure you analyze the decrypted version for a complete assessment. (If encryption is not used, analyze the original XML document directly). This applies to various XML-based authentication and authorization flows, such ...

# Impact An attacker may be able to exploit this vulnerability to bypass authentication or authorization mechanisms in systems that rely on xml-crypto for verifying signed XML documents. The vulnerability allows an attacker to modify a valid signed XML message in a way that still passes signature verification checks. For example, it could be used to alter critical identity or access control attributes, enabling an attacker with a valid account to escalate privileges or impersonate another user. # Patches All versions <= 6.0.0 are affected. Please upgrade to version 6.0.1. If you are still using v2.x or v3.x please upgrade to the associated patch version. # Indicators of Compromise When logging XML payloads, check for the following indicators. If the payload includes encrypted elements, ensure you analyze the decrypted version for a complete assessment. (If encryption is not used, analyze the original XML document directly). This applies to various XML-based authentication and autho...

## Summary An unauthorized attacker can leverage the whitelisted route `/api/v1/attachments` to upload arbitrary files when the `storageType` is set to **local** (default). ## Details When a new request arrives, the system first checks if the URL starts with `/api/v1/`. If it does, the system then verifies whether the URL is included in the whitelist (*whitelistURLs*). If the URL is whitelisted, the request proceeds; otherwise, the system enforces authentication. @ */packages/server/src/index.ts* ```typescript this.app.use(async (req, res, next) => { // Step 1: Check if the req path contains /api/v1 regardless of case if (URL_CASE_INSENSITIVE_REGEX.test(req.path)) { // Step 2: Check if the req path is case sensitive if (URL_CASE_SENSITIVE_REGEX.test(req.path)) { // Step 3: Check if the req path is in the whitelist const isWhitelisted = whitelistURLs.some(...

### Issue Snowflake discovered and remediated a vulnerability in the Snowflake JDBC driver (“Driver”). When the logging level was set to DEBUG, the Driver would log locally the client-side encryption master key of the target stage during the execution of GET/PUT commands. This key by itself does not grant access to any sensitive data without additional access authorizations, and is not logged server-side by Snowflake. This vulnerability affects Driver versions 3.0.13 through 3.23.0. Snowflake fixed the issue in version 3.23.1. ### Vulnerability Details When the logging level was set to DEBUG, the Driver would locally log the client-side encryption master key of the target stage during the execution of GET/PUT commands. The key was logged in a JSON object under the queryStageMasterKey key. The key by itself does not grant access to any sensitive data. ### Solution Snowflake released version 3.23.1 of the Snowflake JDBC driver, which fixes this issue. We highly recommend users upgrad...