#vulnerability

HashiCorp Vault and Vault Enterprise versions 0.9.0 through 1.3.3 may, under certain circumstances, have an Entity's Group membership inadvertently include Groups the Entity no longer has permissions to. Fixed in 1.3.4.

HashiCorp Vault and Vault Enterprise versions 0.11.0 through 1.3.3 may, under certain circumstances, have existing nested-path policies grant access to Namespaces created after-the-fact. Fixed in 1.3.4.

By Waqas Small businesses are faced with unique challenges in terms of data security. You don’t have the vast resources… This is a post from HackRead.com Read the original post: Approaching Complex Data Security for Small Businesses

### Impact The vulnerability could potentially allow a malicious actor to gain control over the destination URL of the HttpClient used in the API classes. For applications using the SDK, requests to unexpected resources on local networks or to the internet could be made which could lead to information disclosure. ### Patches Versions of TrueLayer.Client `v1.6.0` and later are not affected. ### Workarounds The issue can be mitigated by having strict egress rules limiting the destinations to which requests can be made, and applying strict validation to any user input passed to the TrueLayer.Client library.

### Impact The @apollo/experimental-apollo-client-nextjs NPM package is vulnerable to a cross-site scripting vulnerability. This vulnerability arises from improper handling of untrusted input when @apollo/experimental-apollo-client-nextjs performs server-side rendering of HTML pages. To fix this vulnerability, we implemented appropriate escaping to prevent javascript injection into rendered pages. ### Patches To fix this issue, please update to version 0.7.0 or later. ### Workarounds There are no known workarounds for this issue. Please update to version 0.7.0

## impact The `@urql/next` package is vulnerable to XSS. To exploit this an attacker would need to ensure that the response returns `html` tags and that the web-application is using streamed responses (non-RSC). This vulnerability is due to improper escaping of html-like characters in the response-stream. To fix this vulnerability upgrade to version 1.1.1

### Impact The `@tanstack/react-query-next-experimental` NPM package is vulnerable to a cross-site scripting vulnerability. To exploit this, an attacker would need to either inject malicious input or arrange to have malicious input be returned from an endpoint. This vulnerability arises from improper handling of untrusted input when `@tanstack/react-query-next-experimental` performs server-side rendering of HTML pages. To fix this vulnerability, we implemented appropriate escaping to prevent javascript injection into rendered pages. ### Patches To fix this issue, please update to version 5.18.0 or later. ### Workarounds There are no known workarounds for this issue. Please update to version 5.18.0 or later.

### Summary There is an arbitrary file read vulnerability in the CrateDB database, and authenticated CrateDB database users can read any file on the system. ### Details There is a COPY FROM function in the CrateDB database that is used to import file data into database tables. This function has a flaw, and authenticated attackers can use the COPY FROM function to import arbitrary file content into database tables, resulting in information leakage. ### PoC ``` CREATE TABLE info_leak(info_leak STRING); COPY info_leak FROM '/etc/passwd' with (format='csv', header=false); or COPY info_leak FROM '/crate/config/crate.yml' with (format='csv', header=false); SELECT * FROM info_leak; ```  ### Impact This vulnerability affects all current versions of the CrateDB database. Attackers who exploit this vulnerability to obtain sensitive information may carry out further attacks, while a...

### Impact There are no checks on whether the input is encrypted if a task is created in an encrypted collaboration. Therefore, a user may accidentally create a task with sensitive input data that will then be stored unencrypted in a database. ### Workarounds This is not an issue with the normal workflow, only if e.g. a user with the python client sets encryption to the wrong value.

### Impact Nodes and servers get a ssh config by default that permits root login with password authentication. In a proper deployment, the SSH service is not exposed so there is no risk, but not all deployments are ideal. The default should therefore be less permissive. We will probably opt to completely remove the ssh option as it is only used for debugging. Later, we can add a debug mode where we can activate it if necessary. ### Workarounds Remove the ssh part from the docker file and build your own docker image