ghsa

### Impact angular-server-side-configuration detects used environment variables in TypeScript (.ts) files during build time of an Angular CLI project. The detected environment variables are written to a ngssc.json file in the output directory. During deployment of an Angular based app, the environment variables based on the variables from ngssc.json are inserted into the apps index.html (or defined index file). With version 15 the environment variable detection was widened to the entire project, relative to the angular.json file from the Angular CLI. In a monorepo setup, this could lead to environment variables intended for a backend/service to be detected and written to the ngssc.json, which would then be populated and exposed via index.html. This has NO IMPACT, in a plain Angular project that has no backend component. ### Patches Vulnerability has been mitigated in 15.1.0, by adding an option `searchPattern` which restricts the detection file range by default. ```bash # Update vi...

### Summary The vulnerability resides on the Nginx config file: https://github.com/heartexlabs/label-studio/blob/53944e6bcede75ca5c102d655013f2e5238e85e6/deploy/default.conf#L119 The pattern on location /static indicates a popular misconfiguration on Nginx servers presented in 2018 originally by Orange Tsai. This vulnerability allows an attacker to use a single path traversal payload in the matched location to traverse one directory above. This vulnerability only happens due to the location /static directive not having a slash `/` at the end, the following code shows an example of a safe configuration: ```nginx location /static/ { [...] ``` The vulnerability works because Nginx will think that `/static../` is a directory that should also be aliased to the folder, allowing /static/../ to be reached. In Label Studio's case, this means all files on /label_studio/core/ are exposed. Of course, this means that only Label Studio instances that were deployed using the default nginx files int...

OpenSSL has a `modified` bit that it can set on on `X509_NAME` objects. If this bit is set then the object is not thread-safe even when it appears the code is not modifying the value. Thanks to David Benjamin (Google) for reporting this issue.

`SubjectAlternativeName` and `ExtendedKeyUsage` arguments were parsed using the OpenSSL function `X509V3_EXT_nconf`. This function parses all input using an OpenSSL mini-language which can perform arbitrary file reads. Thanks to David Benjamin (Google) for reporting this issue.

These functions would crash when the context argument was None with certain extension types. Thanks to David Benjamin (Google) for reporting this issue.

### Impact Users of the MLflow Open Source Project who are hosting the MLflow Model Registry using the `mlflow server` or `mlflow ui` commands using an MLflow version older than MLflow 2.2.1 may be vulnerable to a remote file existence check exploit if they are not limiting who can query their server (for example, by using a cloud VPC, an IP allowlist for inbound requests, or authentication / authorization middleware). This issue only affects users and integrations that run the `mlflow server` and `mlflow ui` commands. Integrations that do not make use of `mlflow server` or `mlflow ui` are unaffected; for example, the Databricks Managed MLflow product and MLflow on Azure Machine Learning do not make use of these commands and are not impacted by these vulnerabilities in any way. The vulnerability detailed in https://nvd.nist.gov/vuln/detail/CVE-2023-1176 enables an actor to check the existence of arbitrary files unrelated to MLflow from the host server, including any files stored in ...

### Impact Users of the MLflow Open Source Project who are hosting the MLflow Model Registry using the `mlflow server` or `mlflow ui` commands using an MLflow version older than MLflow 2.2.1 may be vulnerable to a remote file access exploit if they are not limiting who can query their server (for example, by using a cloud VPC, an IP allowlist for inbound requests, or authentication / authorization middleware). This issue only affects users and integrations that run the `mlflow server` and `mlflow ui` commands. Integrations that do not make use of `mlflow server` or `mlflow ui` are unaffected; for example, the Databricks Managed MLflow product and MLflow on Azure Machine Learning do not make use of these commands and are not impacted by these vulnerabilities in any way. The vulnerability detailed in https://nvd.nist.gov/vuln/detail/CVE-2023-1177 enables an actor to download arbitrary files unrelated to MLflow from the host server, including any files stored in remote locations to whi...

### Impact An issue was discovered in the `Versionize::deserialize` implementation provided by the `versionize` crate for `vmm_sys_util::fam::FamStructWrapper`, which can lead to out of bounds memory accesses. ### Patches The impact started with version 0.1.1. The issue was corrected in version 0.1.10 by inserting a check that verifies, for any deserialized header, the lengths of compared flexible arrays are equal and aborting deserialization otherwise. ### Workarounds \- ### References - https://github.com/firecracker-microvm/versionize/pull/53

The NATS official Rust clients are vulnerable to MitM when using TLS. The common name of the server's TLS certificate is validated against the `host`name provided by the server's plaintext `INFO` message during the initial connection setup phase. A MitM proxy can tamper with the `host` field's value by substituting it with the common name of a valid certificate it controls, fooling the client into accepting it. ## Reproduction steps 1. The NATS Rust client tries to establish a new connection 2. The connection is intercepted by a MitM proxy 3. The proxy makes a separate connection to the NATS server 4. The NATS server replies with an `INFO` message 5. The proxy reads the `INFO`, alters the `host` JSON field and passes the tampered `INFO` back to the client 6. The proxy upgrades the client connection to TLS, presenting a certificate issued by a certificate authority present in the client's keychain. In the previous step the `host` was set to the common name of said certificate 7. `rus...

### Impact If the parameter `indices` for `DynamicStitch` does not match the shape of the parameter `data`, it can trigger an stack OOB read. ```python import tensorflow as tf func = tf.raw_ops.DynamicStitch para={'indices': [[0xdeadbeef], [405], [519], [758], [1015]], 'data': [[110.27793884277344], [120.29475402832031], [157.2418212890625], [157.2626953125], [188.45382690429688]]} y = func(**para) ``` ### Patches We have patched the issue in GitHub commit [ee004b18b976eeb5a758020af8880236cd707d05](https://github.com/tensorflow/tensorflow/commit/ee004b18b976eeb5a758020af8880236cd707d05). The fix will be included in TensorFlow 2.12. We will also cherrypick this commit on TensorFlow 2.11.1. ### For more information Please consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions. ### Attribution This has been reported via Google OSS VRP.