Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-ff28-f46g-r9g8: Cross-site Scripting in Gogs

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

ghsa
#xss#git
GHSA-r642-gv9p-2wjj: Argo CD will blindly trust JWT claims if anonymous access is enabled

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

GHSA-f3fp-gc8g-vw66: Default inheritable capabilities for linux container should be empty

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

GHSA-2p9q-h29j-3f5v: Missing validation causes `TensorSummaryV2` to crash

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

GHSA-h8v5-p258-pqf4: Use of a Broken or Risky Cryptographic Algorithm in XWiki Crypto API

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

GHSA-xmg8-99r8-jc2j: Login screen allows message spoofing if SSO is enabled

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

GHSA-xh29-r2w5-wx8m: Improper Handling of Unexpected Data Type in Nokogiri

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

GHSA-6gcg-hp2x-q54h: Symlink following allows leaking out-of-bound manifests and JSON files from Argo CD repo-server

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

GHSA-44pw-h2cw-w3vq: Uncontrolled Resource Consumption in Hawk

Hawk is an HTTP authentication scheme providing mechanisms for making authenticated HTTP requests with partial cryptographic verification of the request and response, covering the HTTP method, request URI, host, and optionally the request payload. Hawk used a regular expression to parse `Host` HTTP header (`Hawk.utils.parseHost()`), which was subject to regular expression DoS attack - meaning each added character in the attacker's input increases the computation time exponentially. `parseHost()` was patched in `9.0.1` to use built-in `URL` class to parse hostname instead.`Hawk.authenticate()` accepts `options` argument. If that contains `host` and `port`, those would be used instead of a call to `utils.parseHost()`.

GHSA-37hr-348p-rmf4: Improper handling of multiline messages in node-irc affects matrix-appservice-irc

matrix-appservice-irc provides an IRC bridge for Matrix. The vulnerability in node-irc allows an attacker to manipulate a Matrix user into executing IRC commands by having them reply to a maliciously crafted message. The vulnerability has been patched in matrix-appservice-irc 0.33.2. In terms of a workaround, users should refrain from replying to messages from untrusted participants in IRC-bridged Matrix rooms.