Latest News

### Summary The ReadFileTool in Flowise does not restrict file path access, allowing authenticated attackers to exploit this vulnerability to read arbitrary files from the file system, potentially leading to remote command execution. ### Details Flowise supports providing ReadFileTool for large models to read files in the server's file system. The implementation of this tool is located at packages/components/nodes/tools/ReadFile/ReadFile.ts. ``` /** * Class for reading files from the disk. Extends the StructuredTool * class. */ export class ReadFileTool extends StructuredTool { static lc_name() { return 'ReadFileTool' } schema = z.object({ file_path: z.string().describe('name of file') }) as any name = 'read_file' description = 'Read file from disk' store: BaseFileStore constructor({ store }: ReadFileParams) { super(...arguments) this.store = store } async _call({ file_path }: z.infer<typeof this.sche...

### Summary _Authlib’s JWE `zip=DEF` path performs unbounded DEFLATE decompression. A very small ciphertext can expand into tens or hundreds of megabytes on decrypt, allowing an attacker who can supply decryptable tokens to exhaust memory and CPU and cause denial of service._ ### Details - Affected component: Authlib JOSE, JWE `zip=DEF` (DEFLATE) support. - In `authlib/authlib/jose/rfc7518/jwe_zips.py`, `DeflateZipAlgorithm.decompress` calls `zlib.decompress(s, -zlib.MAX_WBITS)` without a maximum output limit. This permits unbounded expansion of compressed payloads. - In the JWE decode flow (`authlib/authlib/jose/rfc7516/jwe.py`), when the protected header contains `"zip": "DEF"`, the library routes the decrypted ciphertext into the `decompress` method and assigns the fully decompressed bytes to the plaintext field before returning it. No streaming limit or quota is applied. - Because DEFLATE achieves extremely high ratios on highly repetitive input, an attacker can craft a tiny `zip=...

A vulnerability in Allstar’s Reviewbot component caused inbound webhook requests to be validated against a hard-coded, shared secret: https://github.com/ossf/allstar/blob/294ae985cc2facd0918e8d820e4196021aa0b914/pkg/reviewbot/reviewbot.go#L59 The value used for the secret token was compiled into the Allstar binary and could not be configured at runtime. In practice, this meant that every deployment using Reviewbot would validate requests with the same secret unless the operator modified source code and rebuilt the component - an expectation that is not documented and is easy to miss. While Reviewbot is not commonly enabled in standard Allstar setups, we are issuing this advisory to reach any environments where it may have been deployed. ## Affected Versions All Allstar releases prior to v4.5 that include the Reviewbot code path are affected. Deployments on v4.5 and later are not affected. If you have not enabled or exposed the Reviewbot endpoint, this issue does not apply to your i...

### Summary `ldap.dn.escape_dn_chars()` escapes `\x00` incorrectly by emitting a backslash followed by a literal NUL byte instead of the RFC-4514 hex form `\00`. Any application that uses this helper to construct DNs from untrusted input can be made to consistently fail before a request is sent to the LDAP server (e.g., AD), resulting in a client-side denial of service. ### Details Affected function: `ldap.dn.escape_dn_chars(s)` File: Lib/ldap/dn.py Buggy behavior: For NUL, the function does: `s = s.replace('\000', '\\\000') # backslash + literal NUL` This produces Python strings which, when passed to python-ldap APIs (e.g., `add_s`, `modify_s`, r`ename_s`, or used as search bases), contain an embedded NUL. python-ldap then raises ValueError: embedded null character (or otherwise fails) before any network I/O. With correct RFC-4514 encoding (`\00`), the client proceeds and the server can apply its own syntax rules (e.g., AD will reject NUL in CN with result: 34), proving t...

### Summary The sanitization method `ldap.filter.escape_filter_chars` can be tricked to skip escaping of special characters when a crafted `list` or `dict` is supplied as the `assertion_value` parameter, and the non-default `escape_mode=1` is configured. ### Details The method `ldap.filter.escape_filter_chars` supports 3 different escaping modes. `escape_mode=0` (default) and `escape_mode=2` happen to raise exceptions when a `list` or `dict` object is supplied as the `assertion_value` parameter. However, `escape_mode=1` happily computes without performing adequate logic to ensure a fully escaped return value. ### PoC ``` >>> import ldap.filter ``` **Exploitable** ``` >>> ldap.filter.escape_filter_chars(["abc@*()/xyz"], escape_mode=1) 'abc@*()/xyz' >>> ldap.filter.escape_filter_chars({"abc@*()/xyz": 1}, escape_mode=1) 'abc@*()/xyz' ``` **Not exploitable** ``` >>> ldap.filter.escape_filter_chars("abc@*()/xyz", escape_mode=1) 'abc@\\2a\\28\\29\\2fxyz' >>> ldap.filter.escape_filter_chars...

Cross-site request forgery (CSRF) vulnerability in Liferay Portal 7.4.1 through 7.4.3.112, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.10, and 7.4 GA through update 92 allows remote attackers to add and edit publication comments.

An authenticated stored XSS vulnerability exists in the Bagisto 2.3.6 admin panel's product creation path, allowing an attacker to upload a crafted SVG file containing malicious JavaScript code. This vulnerability can be exploited by an authenticated admin user to execute arbitrary JavaScript in the browser, potentially leading to session hijacking, data theft, or unauthorized actions.

The security company looks to tackle new authentication challenges that could lead to credential leakage, as enterprises increasingly leverage AI browser agents.

### Summary There is a denial of service vulnerability in the `If-Match` and `If-None-Match` header parsing component of Sinatra, if the `etag` method is used when constructing the response and you are using Ruby < 3.2. ### Details Carefully crafted input can cause `If-Match` and `If-None-Match` header parsing in Sinatra to take an unexpected amount of time, possibly resulting in a denial of service attack vector. This header is typically involved in generating the `ETag` header value. Any applications that use the `etag` method when generating a response are impacted if they are using Ruby below version 3.2. ### Resources * https://github.com/sinatra/sinatra/issues/2120 (report) * https://github.com/sinatra/sinatra/pull/2121 (fix) * https://github.com/sinatra/sinatra/pull/1823 (older ReDoS vulnerability) * https://bugs.ruby-lang.org/issues/19104 (fix in Ruby >= 3.2)

**Summary** Authlib’s JOSE implementation accepts unbounded JWS/JWT header and signature segments. A remote attacker can craft a token whose base64url‑encoded header or signature spans hundreds of megabytes. During verification, Authlib decodes and parses the full input before it is rejected, driving CPU and memory consumption to hostile levels and enabling denial of service. **Impact** - Attack vector: unauthenticated network attacker submits a malicious JWS/JWT. - Effect: base64 decode + JSON/crypto processing of huge buffers pegs CPU and allocates large amounts of RAM; a single request can exhaust service capacity. - Observed behaviour: on a test host, the legacy code verified a 500 MB header, consuming ~4 GB RSS and ~9 s CPU before failing. - Severity: High. CVSS v3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5). Affected Versions Authlib ≤ 1.6.3 (and earlier) when verifying JWS/JWT tokens. Later snapshots with 256 KB header/signature limits are not affected. **Proof of concep...