Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-vj49-j7rc-h54f: Esoteric YamlBeans XML Entity Expansion vulnerability

An issue was discovered in Esoteric YamlBeans through 1.15. A crafted YAML document is able perform am XML Entity Expansion attack against YamlBeans YamlReader. By exploiting the Anchor feature in YAML, it is possible to generate a small YAML document that, when read, is expanded to a large size, causing CPU and memory consumption, such as a Java Out-of-Memory exception.

ghsa
#vulnerability#git#java#maven
GHSA-jm7r-4pg6-gf26: Esoteric YamlBeans Unsafe Deserialization vulnerability

An issue was discovered in Esoteric YamlBeans through 1.15. It allows untrusted deserialisation to Java classes by default, where the data and class are controlled by the author of the YAML document being processed.

GHSA-jcf2-mxr2-gmqp: OpenFGA Authorization Bypass

## Overview Some end users of OpenFGA v1.3.0 or earlier are vulnerable to authorization bypass when calling the ListObjects API. UPDATE: This means that the API sometimes returns more objects than it should. ## Am I Affected? The vulnerability affects customers using `ListObjects` with specific models. The affected models contain expressions of type `rel1 from type1`. ## Fix Update to v1.3.1. ## Backward Compatibility This update is backward compatible.

GHSA-j8g2-6fc7-q8f8: Pyramid static view path traversal up one directory

### Impact This impacts users of Python 3.11 that are using a Pyramid static view with a full filesystem path and have a `index.html` file that is located exactly one directory above the location of the static view's file system path. No further path traversal exists, and the only file that could be disclosed accidentally is `index.html`. Example: ``` config.add_static_view(name='static', path='/usr/src/app/static', cache_max_age=0) ``` And directory tree: ``` /usr/src/app \ | - static \ | - file.css | - index.html | - ... | - index.html <-- (this file could be disclosed with this bug) ``` ### Patches Pyramid now will reject any path that contains a null-byte out of caution. While valid in directory/file names, we would strongly consider it a mistake to use null-bytes in naming files/directories. Secondly, Python 3.11, and 3.12 has fixed the underlying issue in `os.path.nor...

GHSA-826j-8wp2-4x6q: Netmaker Vulnerable to Privilege Escalation From Non Admin To Admin User

### Impact A Mass assignment vulnerability was found allowing a non-admin user to escalate privileges to admin user. ### Patches Issue is patched in 0.17.1, and fixed in 0.18.6+. If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later. ### Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server. ### References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery

GHSA-256m-j5qw-38f4: Netmaker IDOR Allows User to Update Other User's Password

### Impact An IDOR vulnerability was found in the user update function. By specifying another user's username it is possible to update the other user's password. ### Patches Issue is patched in 0.17.1, and fixed in 0.18.6+. If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later. ### Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server. ### References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery

GHSA-8x8h-hcq8-jwwx: Netmaker has Hardcoded DNS Secret Key

### Impact Hardcoded DNS key usage has been found in Netmaker allowing unauth users to interact with DNS API endpoints. ### Patches Issue is patched in 0.17.1, and fixed in 0.18.6+. If Users are using 0.17.1, they should run "docker pull gravitl/netmaker:v0.17.1" and "docker-compose up -d". This will switch them to the patched users If users are using v0.18.0-0.18.5, they should upgrade to v0.18.6 or later. ### Workarounds If using 0.17.1, can just pull the latest docker image of backend and restart server. ### References Credit to Project Discovery, and in particular https://github.com/rootxharsh , https://github.com/iamnoooob, and https://github.com/projectdiscovery

GHSA-8qv2-5vq6-g2g7: webpki: CPU denial of service in certificate path building

When this crate is given a pathological certificate chain to validate, it will spend CPU time exponential with the number of candidate certificates at each step of path building. Both TLS clients and TLS servers that accept client certificate are affected. This was previously reported in <https://github.com/briansmith/webpki/issues/69> and re-reported recently by Luke Malinowski. `rustls-webpki` is a fork of this crate which contains a fix for this issue and is actively maintained.

GHSA-gcq9-qqwx-rgj3: libp2p nodes vulnerable to OOM attack

### Summary In go-libp2p, by using signed peer records a malicious actor can store an arbitrary amount of data in a remote node’s memory. This memory does not get garbage collected and so the victim can run out of memory and crash. It is feasible to do this at scale. An attacker would have to transfer ~1/2 as much memory it wants to occupy (2x amplification factor). The attacker can perform this attack over time as the target node’s memory will not be garbage collected. This can occur because when a signed peer record is received, only the signature validity check is performed but the sender signature is not checked. Signed peer records from randomly generated peers can be sent by a malicious actor. A target node will accept the peer record as long as the signature is valid, and then stored in the peer store. There is cleanup logic in the peer store that cleans up data when a peer disconnects, but this cleanup is never triggered for the fake peer (from which signed peer records wer...

GHSA-rcx8-48pc-v9q8: mail-internals use-after-free vulnerability in `vec_insert_bytes`

Incorrect reallocation logic in the function [`vec_insert_bytes`](https://docs.rs/mail-internals/0.2.3/mail_internals/utils/fn.vec_insert_bytes.html) causes a use-after-free. This function does not have to be called directly to trigger the vulnerability because many methods on [`EncodingWriter`](https://docs.rs/mail-internals/0.2.3/mail_internals/encoder/struct.EncodingWriter.html) call this function internally. The mail-\* suite is unmaintained and the upstream sources have been actively vandalised. A fixed `mail-internals-ng` (and `mail-headers-ng` and `mail-core-ng`) crate has been published which fixes this, and a dependency on another unsound crate.