ghsa

HashiCorp Nomad and Nomad Enterprise 1.2.15 up to 1.3.8, and 1.4.3 jobs using a maliciously compressed artifact stanza source can cause excessive disk usage. Fixed in 1.2.16, 1.3.9, and 1.4.4.

HashiCorp go-getter up to 1.6.2 and 2.1.1 is vulnerable to decompression bombs. Fixed in 1.7.0 and 2.2.0.

### Impact All Argo CD versions starting with v2.3.0-rc1 are vulnerable to an improper authorization bug which allows users who have the ability to update at least one cluster secret to update any cluster secret. The attacker could use this access to escalate privileges (potentially controlling Kubernetes resources) or to break Argo CD functionality (by preventing connections to external clusters). #### How the Attack Works Argo CD stores [cluster access configurations](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#clusters) as Kubernetes Secrets. To take advantage of the vulnerability, an attacker must know the server URL for the cluster secret they want to modify. The attacker must be authenticated with the Argo CD API server, and they must be authorized to update at least one ([non project-scoped](https://argo-cd.readthedocs.io/en/stable/user-guide/projects/#project-scoped-repositories-and-clusters)) cluster. Then they must craft a malicious reque...

### Impact A XML External Entity (XXE) vulnerability found in the apoc.import.graphml procedure of APOC core plugin in Neo4j graph database. XML External Entity (XXE) injection occurs when the XML parser allows external entities to be resolved. The XML parser used by the apoc.import.graphml procedure was not configured in a secure way and therefore allowed this. External entities can be used to read local files, send HTTP requests, and perform denial-of-service attacks on the application. Abusing the XXE vulnerability enabled assessors to read local files remotely. Although with the level of privileges assessors had this was limited to one-line files. With the ability to write to the database, any file could have been read. Additionally, assessors noted, with local testing, the server could be crashed by passing in improperly formatted XML. ### Patches The users should aim to use the latest released version compatible with their Neo4j version. The minimum versions containing patch ...

### Impact undici library does not protect `host` HTTP header from CRLF injection vulnerabilities. ### Patches This issue was patched in Undici v5.19.1. ### Workarounds Sanitize the `headers.host` string before passing to undici. ### References Reported at https://hackerone.com/reports/1820955. ### Credits Thank you to Zhipeng Zhang ([@timon8](https://hackerone.com/timon8)) for reporting this vulnerability.

### Impact The `Headers.set()` and `Headers.append()` methods are vulnerable to Regular Expression Denial of Service (ReDoS) attacks when untrusted values are passed into the functions. This is due to the inefficient regular expression used to normalize the values in the `headerValueNormalize()` utility function. ### Patches This vulnerability was patched in v5.19.1. ### Workarounds There is no workaround. Please update to an unaffected version. ### References * https://hackerone.com/bugs?report_id=1784449 ### Credits Carter Snook reported this vulnerability.

### Description When using the non-default "fallback" crypto back-end, ECC operations in `node-jose` can trigger a Denial-of-Service (DoS) condition, due to a possible infinite loop in an internal calculation. For some ECC operations, this condition is triggered randomly; for others, it can be triggered by malicious input. #### Technical summary The JOSE logic implemented by `node-jose` usually relies on an external cryptographic library for the underlying cryptographic primitives that JOSE operations require. When WebCrypto or the Node `crypto` module are available, they are used. When neither of these libraries is available, `node-jose` includes its own "fallback" implementations of some algorithms based on `node-forge`, in particular implementations of ECDH and ECDSA. A various points, these algorithm implementations need to compute to the X coordinate of an elliptic curve point. This is done by calling the `getX()` method of the object representing the point, which is an a...

### Summary Missing check vulnerability in the static file handler allows any client to access the files in the server's file system ### Details When `staticFiles` is set in the `serve` settings in the configuration file, the following handler doesn't check if `absolutePath` is still under the directory provided as `staticFiles`; ```ts if (staticFiles) { router.get('/:relativePath+', async request => { let { relativePath } = request.params; if (!relativePath) { relativePath = 'index.html'; } const absolutePath = path.join(baseDir, staticFiles, relativePath); if (absolutePath.includes(staticFiles) && (await pathExists(absolutePath))) { const readStream = fs.createReadStream(absolutePath); return new Response(readStream as any, { status: 200, }); } return undefined; }); ``` ### Example scenario To reproduce it, set `staticFiles` to the relative path of a directory in `.meshrc.yml`; ```yml s...

### Impact When importing an OCI image, there was no limit on the number of bytes read for certain files. A maliciously crafted image with a large file where a limit was not applied could cause a denial of service. ### Patches This bug has been fixed in containerd 1.6.18 and 1.5.18. Users should update to these versions to resolve the issue. ### Workarounds Ensure that only trusted images are used and that only trusted users have permissions to import images. ### Credits The containerd project would like to thank [David Korczynski](https://github.com/DavidKorczynski) and [Adam Korczynski](https://github.com/AdamKorcz) of ADA Logics for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md) during a security fuzzing audit sponsored by CNCF. ### For more information If you have any questions or comments about this advisory: * Open an issue in [containerd](https://github.com/containerd/...

### Impact An attacker with read-only access to a Strongbox secret could craft a valid encrypted secret (same id/version). It also makes the audit logs from KMS less useful. The issue is caused by a bug in the underlying AWS Encryption SDK. By default, the encrypted secrets are stored in DynamoDB and an attacker with read-only access would not be able to write the encrypted secret to DynamoDB. So in practice the impact should be limited for most users. Strongbox supports storing data in files as an alternative to DynamoDB. If the attacker had write access to where the files are stored they could make the attack work end-to-end. Similarly, any custom storage backend could also be affected. In order to be backwards compatible Strongbox will not make use of key commitments (another improvement to the AWS Encryption SDK). Strongbox enforces that only one KMS key can be used, and it must match the expected one. This means that an attacker needs write access to both KMS and DynamoDB (or o...