ghsa

### Impact Harbor fails to validate the user permissions to view Webhook policies including relevant credentials configured in different projects the user doesn’t have access to, resulting in malicious users being able to read Webhook policies of other users/projects. API call is   GET /projects/{project_name_or_id}/webhook/policies/{webhook_policy_id} By sending the below request and specifying different Webhook policy ids in the last part of the URL, the malicious user may disclose Webhook policies related to other repositories/projects.: none;"> ### Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible. ### Workarounds There are no workarounds available. ### For more information If you have any questions or comments about this advisory: * Open an issue in [the Harbor GitHub repository](https://github.com/goharbor/harbor) ### Credits Thanks to [Gal Goldstein](https://www.linkedin.com/in/gal-goldshtein/) and [Daniel Abeles](http...

### Impact Harbor fails to validate the user permissions when updating tag retention policies. API call: PUT /retentions/{id} By sending a request to update a tag retention policy with an id that belongs to a project that the currently authenticated user doesn’t have access to, the attacker could modify tag retention policies configured in other projects. ### Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible. ### Workarounds There are no workarounds available. ### For more information If you have any questions or comments about this advisory: * Open an issue in [the Harbor GitHub repository](https://github.com/goharbor/harbor) ### Credits Thanks to [Gal Goldstein](https://www.linkedin.com/in/gal-goldshtein/) and [Daniel Abeles](https://www.linkedin.com/in/daniel-abeles/) from [Oxeye Security](https://www.oxeye.io/) for reporting this issue.

### Impact Due to missing canonicalization when `readDir` is called recursively, it was possible to display directory listings outside of the defined `fs` scope. This required a crafted symbolic link or junction folder inside an allowed path of the `fs` scope. No arbitrary file content could be leaked. ### Patches The issue has been resolved in https://github.com/tauri-apps/tauri/pull/5123 and the implementation now properly checks if the requested (sub) directory is a symbolic link outside of the defined `scope`. ### Workarounds Disable the `readDir` endpoint in the `allowlist` inside the `tauri.conf.json`. ### For more information This issue was initially reported by [martin-ocasek]( https://github.com/martin-ocasek) in [#4882](https://github.com/tauri-apps/tauri/issues/4882). If you have any questions or comments about this advisory: * Open an issue in [tauri](https://github.com/tauri-apps/tauri) * Email us at [[email protected]](mailto:[email protected])

### Observation When handling dependencies that come from a Git repository instead of a registry, Poetry uses various commands, such as `git clone`. These commands are being constructed using user input (e.g. the repository URL). When building the commands, Poetry correctly avoids Command Injection vulnerabilities by passing an array of arguments instead of a command string. However, there is the possibility that a user input starts with a dash (`-`) and is therefore treated as an optional argument instead of a positional one. This can lead to Code Execution because some of the commands have options that can be leveraged to run arbitrary executables. To clone a repository, Poetry builds a git clone command, but fails to validate or sanitize the repository location properly: [`poetry/core/vcs/git.py`](https://github.com/python-poetry/poetry-core/blob/ad33bc2f92be03dc5b31a666664903c439fb1173/poetry/core/vcs/git.py#L207): ```python def clone(self, repository: str, dest: Path) -> str: ...

### Impact If `tf.sparse.cross` receives an input `separator` that is not a scalar, it gives a `CHECK` fail that can be used to trigger a denial of service attack. ```python import tensorflow as tf tf.sparse.cross(inputs=[],name='a',separator=tf.constant(['a', 'b'],dtype=tf.string)) ``` ### Patches We have patched the issue in GitHub commit [83dcb4dbfa094e33db084e97c4d0531a559e0ebf](https://github.com/tensorflow/tensorflow/commit/83dcb4dbfa094e33db084e97c4d0531a559e0ebf). The fix will be included in TensorFlow 2.10.0. We will also cherrypick this commit on TensorFlow 2.9.1, TensorFlow 2.8.1, and TensorFlow 2.7.2, as these are also affected and still in supported range. ### 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 vulnerability has been reported by Kang Hong Jin.

### Impact When `Conv2DBackpropInput` receives empty `out_backprop` inputs (e.g. `[3, 1, 0, 1]`), the current CPU/GPU kernels `CHECK` fail (one with dnnl, the other with cudnn). This can be used to trigger a denial of service attack. ```python import tensorflow as tf import numpy as np input_sizes = [3, 1, 1, 2] filter = np.ones([1, 3, 2, 3]) out_backprop = np.ones([3, 1, 0, 3]) strides = [1, 1, 2, 1] padding = 'VALID' tf.raw_ops.Conv2DBackpropInput( input_sizes = input_sizes, filter = filter, out_backprop = out_backprop, strides = strides, padding = padding ) ``` ### Patches We have patched the issue in GitHub commit [27a65a43cf763897fecfa5cdb5cc653fc5dd0346](https://github.com/tensorflow/tensorflow/commit/27a65a43cf763897fecfa5cdb5cc653fc5dd0346). The fix will be included in TensorFlow 2.10.0. We will also cherrypick this commit on TensorFlow 2.9.1, TensorFlow 2.8.1, and TensorFlow 2.7.2, as these are also affected and still in supported range. ### For more inform...

## Summary A number of vulnerabilities have been found in `cosign verify-blob`, where Cosign would successfully verify an artifact when verification should have failed. ## Vulnerability 1: Bundle mismatch causes invalid verification. ### Summary A cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature. ### Details Cosign supports "bundles" which intend to allow offline verification of the signature and rekor inclusion. By using the --bundle flag in cosign sign-blob, cosign will create a JSON file called a "bundle". These bundles include three fields: base64Signature, cert, and rekorBundle. The desired behavior is that the verification of these bundles would: - verify the provided blob using the included signature and certificate - verify the rekorBundle SET - verify the rekorBundle payload references the given artifact. It appears that step three is not being performed, allowing "any old rekorBundle" to p...

> ### Meta > * CVSS: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N/E:F/RL:O/RC:C` (5.7) ### Problem Due to a parsing issue in upstream package [`masterminds/html5`](https://packagist.org/packages/masterminds/html5), malicious markup used in a sequence with special HTML comments cannot be filtered and sanitized. This allows to by-pass the cross-site scripting mechanism of `typo3/html-sanitizer`. ### Solution Update to `typo3/html-sanitizer` versions 1.0.7 or 2.0.16 that fix the problem described. ### Credits Thanks to David Klein who reported this issue, and to TYPO3 security team member Oliver Hader who fixed the issue.

Helm controller is tightly integrated with the Helm SDK. [A vulnerability](https://github.com/helm/helm/security/advisories/GHSA-7hfp-qfw3-5jxh) found in the Helm SDK allows for specific data inputs to cause high memory consumption, which in some platforms could cause the controller to panic and stop processing reconciliations. ### Impact In a shared cluster multi-tenancy environment, a tenant could create a HelmRelease that makes the controller panic, denying all other tenants from their Helm releases being reconciled. ### Credits The initial crash bug was reported by [oss-fuzz](https://github.com/google/oss-fuzz). The Flux Security team produced the first exploit and worked together with the Helm Security team to ensure that both projects were patched timely. ### For more information If you have any questions or comments about this advisory: - Open an issue in any of the affected repositories. - Contact us at the CNCF Flux Channel. ### References - https://bugs.chromium.org/p/...

### Impact In ReactPHP's HTTP server component versions below v1.7.0, when ReactPHP is processing incoming HTTP cookie values, the cookie names are url-decoded. This may lead to cookies with prefixes like `__Host-` and `__Secure-` confused with cookies that decode to such prefix, thus leading to an attacker being able to forge cookie which is supposed to be secure. See also CVE-2020-7070 and CVE-2020-8184 for more information. ### Patches * https://github.com/reactphp/http/commit/663c9a3b77b71463fa7fcb76a6676ffd16979dd6 - Fixed in [reactphp/http `v1.7.0`](https://github.com/reactphp/http/releases/tag/v1.7.0) ### Workarounds Infrastructure or DevOps can place a reverse proxy in front of the ReactPHP HTTP server to filter out any unexpected `Cookie` request headers. ### References * CVE-2020-7070, https://bugs.php.net/bug.php?id=79699 and https://github.com/php/php-src/commit/6559fe912661ca5ce5f0eeeb591d928451428ed0 * CVE-2020-8184, https://hackerone.com/reports/895727 and https:...