ghsa

### Summary bbot's `gitdumper.py` insufficiently sanitises a `.git/config` file, leading to Remote Code Execution (RCE). bbot's `gitdumper.py` can be made to consume a malicious `.git/index` file, leading to arbitrary file write which can be used to achieve Remote Code Execution (RCE). ### Impact A user who uses bbot to scan a malicious webserver may have arbitrary code executed on their system.

### Summary Due to unsafe URL handling, bbot's `git_clone.py` can be made to leak a user's github.com API key to an attacker-controlled webserver. ### Impact A user who has placed their github.com API key in the configuration for any of the following modules: * `github_codesearch` * `github_workflows` * `gitlab` * `git_clone` * `github_usersearch` * `github_org` may leak it to an untrustworthy server.

### Summary Various issues in bbot's `unarchive.py` allow a malicious site to cause bbot to write arbitrary files to arbitrary locations. This can be used to achieve Remote Code Execution (RCE). ### Impact A user who uses bbot to scan a malicious webserver may have arbitrary code executed on their system.

### Summary Amazon.IonDotnet is a library for the Dotnet language that is used to read and write Amazon Ion data. An issue exists where, under certain circumstances, the library could an infinite loop, resulting in denial of service. As of August 20, 2025, this library has been deprecated and will not receive further updates. ### Impact An infinite loop issue in Amazon.IonDotnet library versions <v1.3.2 may allow a threat actor to cause a denial of service through a specially crafted text input. This invalid input triggered an error condition in the parser that was handled improperly, resulting in an infinite loop. ### Impacted versions: <1.3.2 ### Patches This issue has been addressed in Amazon.IonDotnet version [1.3.2](https://www.nuget.org/packages/Amazon.IonDotnet/1.3.2). We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. ### Workarounds Only accept data from trusted sources, written using a supported...

Multiple cross-site scripting (XSS) vulnerabilities with Calendar events in Liferay Portal 7.4.3.35 through 7.4.3.111, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.7, 7.4 update 35 through update 92, and 7.3 update 25 through update 36 allow remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a user’s (1) First Name, (2) Middle Name or (3) Last Name text field.

### Impact Upon authentication, the user could be associated by e-mail even if the `associate_by_email` pipeline was not included. This could lead to account compromise when a third-party authentication service does not validate provided e-mail addresses or doesn't require unique e-mail addresses. ### Patches * https://github.com/python-social-auth/social-app-django/pull/803 ### Workarounds Review the authentication service policy on e-mail addresses; many will not allow exploiting this vulnerability.

### Summary Unauthenticated attackers can create or modify API keys for any user by passing that user's id in the request body to the `api/auth/api-key/create` route. ### Details The vulnerability exists in the authentication logic at when checking for user authentication then derives the user as `session?.user ?? (authRequired ? null : { id: ctx.body.userId })`. When no session exists but `userId` is present in the request body, `authRequired` becomes false and the user object is set to the attacker-controlled ID. Server-only field validation only executes when `authRequired` is true (lines 280-295), allowing attackers to set privileged fields. No additional authentication occurs before the database operation, so the malicious payload is accepted. The same pattern exists in the update endpoint. ### PoC ```bash curl -X POST http://localhost:3000/api/auth/api-key/create \ -H 'Content-Type: application/json' \ -d '{ "userId": "victim-user-id", "name": "zeropath"...

Apache Flink CDC version 3.0.0 to before 3.5.0 are vulnerable to a SQL injection via maliciously crafted identifiers eg. crafted database name or crafted table name. Even through only the logged-in database user can trigger the attack, users are recommended to update Flink CDC version to 3.5.0 which address this issue.

### Impact The `Execute Command` node in n8n allows execution of arbitrary commands on the host system where n8n runs. While this functionality is intended for advanced automation and can be useful in certain workflows, it poses a security risk if all users with access to the n8n instance are not fully trusted. An attacker—either a malicious user or someone who has compromised a legitimate user account—could exploit this node to run arbitrary commands on the host machine, potentially leading to data exfiltration, service disruption, or full system compromise. This vulnerability affects all n8n deployments where: - The `Execute Command` node is enabled, and - Not all user accounts are strictly controlled and trusted. n8n.cloud is **not** impacted. ### Patches No code changes have been made to alter the behavior of the `Execute Command` node. The recommended mitigation is to disable the node by default in environments where it is not explicitly required. Future n8n versions may c...

### Summary The WriteFileTool in Flowise does not restrict the file path for reading, allowing authenticated attackers to exploit this vulnerability to write arbitrary files to any path in the file system, potentially leading to remote command execution. ### Details Flowise supports providing WriteFileTool for large models, which is used to write files to the server's file system. The implementation of this tool is located at packages/components/nodes/tools/WriteFile/WriteFile.ts. ``` /** * Class for writing data to files on the disk. Extends the StructuredTool * class. */ export class WriteFileTool extends StructuredTool { static lc_name() { return 'WriteFileTool' } schema = z.object({ file_path: z.string().describe('name of file'), text: z.string().describe('text to write to file') }) as any name = 'write_file' description = 'Write file from disk' store: BaseFileStore constructor({ store, ...rest }: WriteFileParams) ...