ghsa

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

### Summary pyLoad web interface contained insufficient input validation in both the Captcha script endpoint and the Click'N'Load (CNL) Blueprint. This flaw allowed untrusted user input to be processed unsafely, which could be exploited by an attacker to inject arbitrary content into the web UI or manipulate request handling. The vulnerability could lead to client-side code execution (XSS) or other unintended behaviors when a malicious payload is submitted. user-supplied parameters from HTTP requests were not adequately validated or sanitized before being passed into the application logic and response generation. This allowed crafted input to alter the expected execution flow. CNL (Click'N'Load) blueprint exposed unsafe handling of untrusted parameters in HTTP requests. The application did not consistently enforce input validation or encoding, making it possible for an attacker to craft malicious requests. ### PoC 1. Run a vulnerable version of pyLoad prior to commit [`f9d27f2`](ht...

### Impact PyTorch reported a [**critical** vulnerability](https://github.com/pytorch/pytorch/security/advisories/GHSA-53q9-r3pm-6pq6) when using `torch.load`, even with option `weights_only=True`, for `torch <= 2.5.1`. In `scio <= 1.0.0`, the lower bound for `torch` is `2.3`. ### Patches The lower bound was changed to `torch >= 2.6`, starting from `scio >= 1.0.1` (currently in dev state). ### Workarounds You can manually check that you are using `torch >= 2.6`.

A flaw was found in org.keycloak/keycloak-model-storage-service. The `KeycloakRealmImport` custom resource substitutes placeholders within imported realm documents, potentially referencing environment variables. This substitution process allows for injection attacks when crafted realm documents are processed. An attacker can leverage this to inject malicious content during the realm import procedure. This can lead to unintended consequences within the Keycloak environment.