ghsa

### Impact [go-tuf](https://github.com/theupdateframework/go-tuf) does not correctly implement the [client workflow](https://theupdateframework.github.io/specification/v1.0.28/index.html#detailed-client-workflow) for updating the metadata files for roles other than the root role. Specifically, checks for rollback attacks are not implemented correctly meaning an attacker can cause clients to install software that is older than the software which the client previously knew to be available, and may include software with known vulnerabilities. In more detail, the client code of go-tuf has several issues in regards to preventing rollback attacks: 1. It does not take into account the content of any previously trusted metadata, if available, before proceeding with updating roles other than the root role (i.e., steps 5.4.3.1 and 5.5.5 of the detailed client workflow). This means that any form of version verification done on the newly-downloaded metadata is made using the default value of zer...

### Overview In versions before and including `11.32.2`, when the “additional signup fields” feature [is configured](https://github.com/auth0/lock#additional-sign-up-fields), a malicious actor can inject invalidated HTML code into these additional fields, which is then stored in the service `user_metdata` payload (using the `name` property). Verification emails, when applicable, are generated using this metadata. It is therefor possible for an actor to craft a malicious link by injecting HTML, which is then rendered as the recipient's name within the delivered email template. ### Am I affected? You are impacted by this vulnerability if you are using `auth0-lock` version `11.32.2` or lower and are using the “additional signup fields” feature in your application. ### How to fix that? Upgrade to version `11.33.0`. ### Will this update impact my users? Additional signup fields that have been added to the signup tab on Lock will have HTML tags stripped from user input from version `11....

### Impact The malicious user is able to upload a crafted SVG file as the issue attachment to archive XSS. All installations [allow uploading SVG (`text/xml`) files as issue attachments (non-default)](https://github.com/gogs/gogs/blob/e51e01683408e10b3dcd2ace65e259ca7f0fd61b/conf/app.ini#L283-L284) are affected. ### Patches Correctly setting the Content Security Policy for the serving endpoint. Users should upgrade to 0.12.7 or the latest 0.13.0+dev. ### Workarounds [Disable uploading SVG files (`text/xml`) as issue attachments](https://github.com/gogs/gogs/blob/e51e01683408e10b3dcd2ace65e259ca7f0fd61b/conf/app.ini#L283-L284). ### References https://huntr.dev/bounties/34a12146-3a5d-4efc-a0f8-7a3ae04b198d/ ### For more information If you have any questions or comments about this advisory, please post on https://github.com/gogs/gogs/issues/6919.

### Impact A critical vulnerability has been discovered in Argo CD which would allow unauthenticated users to impersonate as any Argo CD user or role, including the `admin` user, by sending a specifically crafted JSON Web Token (JWT) along with the request. In order for this vulnerability to be exploited, [anonymous access](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#anonymous-access) to the Argo CD instance must have been enabled. In a default Argo CD installation, anonymous access is disabled. To find out if anonymous access is enabled in your instance, please see the *Workarounds* section of this advisory below. The vulnerability can be exploited to impersonate as any user or role, including the built-in `admin` account regardless of whether that account is enabled or disabled. Also, the attacker does not need an account on the Argo CD instance in order to exploit this. If anonymous access to the instance is enabled, an attacker can: * Escalate their privile...

### Impact A bug was found in runc where `runc exec --cap` executed processes with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set. ### Patches This bug has been fixed in runc 1.1.2. Users should update to this version as soon as possible. This fix changes `runc exec --cap` behavior such that the additional capabilities granted to the process being executed (as specified via `--cap` arguments) do not include inheritable capabilities. In addition, `runc spec` is changed to not set any inheritable capabilities in the created example OCI spec (`config.json`) file. ### Credits The opencontainers project would like to thank [Andrew G. Morgan](https://github.com...

### Impact The implementation of [`tf.raw_ops.TensorSummaryV2`](https://github.com/tensorflow/tensorflow/blob/f3b9bf4c3c0597563b289c0512e98d4ce81f886e/tensorflow/core/kernels/summary_tensor_op.cc#L33-L58) does not fully validate the input arguments. This results in a `CHECK`-failure which can be used to trigger a denial of service attack: ```python import numpy as np import tensorflow as tf tf.raw_ops.TensorSummaryV2( tag=np.array('test'), tensor=np.array(3), serialized_summary_metadata=tf.io.encode_base64(np.empty((0)))) ``` The code assumes `axis` is a scalar but there is no validation for this. ```cc const Tensor& serialized_summary_metadata_tensor = c->input(2); // ... ParseFromTString(serialized_summary_metadata_tensor.scalar<tstring>()(), v->mutable_metadata()); ``` ### Patches We have patched the issue in GitHub commit [290bb05c80c327ed74fae1d089f1001b1e2a4ef7](https://github.com/tensorflow/tensorflow/commit/290bb05c80c327ed74fae1d089...

### Impact XWiki Crypto API will generate X509 certificates signed by default using SHA1 with RSA, which is not considered safe anymore for use in certificate signatures, due to the risk of collisions with SHA1. Note that this API is never used in XWiki Standard but it might be used in some extensions of XWiki. ### Patches The problem has been patched in XWiki version 13.10.6, 14.3.1 and 14.4-rc-1. Since then, the Crypto API will generate X509 certificates signed by default using SHA256 with RSA. ### Workarounds Administrators are advised to upgrade their XWiki installation to one of the patched versions. If the upgrade is not possible, it is possible to patch the module xwiki-platform-crypto in a local installation by applying the change exposed in https://github.com/xwiki/xwiki-platform/commit/26728f3f23658288683667a5182a916c7ecefc52 and re-compiling the module. ### References https://jira.xwiki.org/browse/XWIKI-19676 https://github.com/openssl/openssl/blob/master/CHANGES.md?plain...

### Impact A vulnerability was found in Argo CD that allows an attacker to spoof error messages on the login screen when SSO is enabled. In order to exploit this vulnerability, an attacker would have to trick the victim to visit a specially crafted URL which contains the message to be displayed. As far as the research of the Argo CD team concluded, it is not possible to specify any active content (e.g. Javascript) or other HTML fragments (e.g. clickable links) in the spoofed message. ### Patched versions A patch for this vulnerability has been released in the following Argo CD versions: * v2.3.4 * v2.2.9 * v2.1.15 ### Workarounds No workaround available. #### Mitigations It is advised to update to an Argo CD version containing a fix for this issue (see *Patched versions* above). ### Credits This vulnerability was discovered by Naufal Septiadi (<[email protected]>) and reported to us in a responsible way. ### For more information <!-- Use only one of the paragraphs below...

### Summary Nokogiri `< v1.13.6` does not type-check all inputs into the XML and HTML4 SAX parsers. For CRuby users, this may allow specially crafted untrusted inputs to cause illegal memory access errors (segfault) or reads from unrelated memory. ### Severity The Nokogiri maintainers have evaluated this as **High 8.2** (CVSS3.1). ### Mitigation CRuby users should upgrade to Nokogiri `>= 1.13.6`. JRuby users are not affected. ### Workarounds To avoid this vulnerability in affected applications, ensure the untrusted input is a `String` by calling `#to_s` or equivalent. ### Credit This vulnerability was responsibly reported by @agustingianni and the Github Security Lab.

### Impact All unpatched versions of Argo CD starting with v0.7.0 are vulnerable to a symlink following bug allowing a malicious user with repository write access to leak sensitive files from Argo CD's repo-server. A malicious Argo CD user with write access for a repository which is (or may be) used in a directory-type Application may commit a symlink which points to an out-of-bounds file. * If the target file is a valid JSON or YAML manifest file, and the resource is allowed in the Application, the attacker can read the contents of that manifest file. (In versions <2.3.2, <2.2.8, and <2.1.14, the attacker may read the files contents even if the resource is _not_ allowed in the Application). * If the target file is valid JSON but is _not_ a manifest file, the attacker may read the contents of the file. * If the target file is not valid JSON or YAML, the attacker may read partial file contents (usually just the first character of the file). Sensitive files which could be leaked in...