Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-j5fj-rfh6-qj85: Planet's secret file is created with excessive permissions

### Impact The secret file stores the user's Planet API authentication information. It should only be accessible by the user, but its permissions allowed the user's group and non-group to read the file as well. ### Validation Check the permissions on the secret file with `ls -l ~/.planet.json` and ensure that they read as `-rw-------` ### Patches [d71415a8](https://github.com/planetlabs/planet-client-python/commit/d71415a83119c5e89d7b80d5f940d162376ee3b7) ### Workarounds Set the secret file permissions to only user read/write by hand: ``` chmod 600 ~/.planet.json ```

ghsa
#js#git#java#auth
GHSA-3p37-3636-q8wv: Vyper vulnerable to OOB DynArray access when array is on both LHS and RHS of an assignment

### Impact during codegen, the length word of a dynarray is written before the data, which can result in OOB array access in the case where the dynarray is on both the lhs and rhs of an assignment. here is a minimal example producing the issue: ```vyper a:DynArray[uint256,3] @external def test() -> DynArray[uint256,3]: self.a = [1,2,3] self.a = empty(DynArray[uint256,3]) self.a = [self.a[0],self.a[1],self.a[2]] return self.a # return [1,2,3] ``` and here is an example demonstrating the issue can cause data corruption across call frames: ```vyper @external def test() -> DynArray[uint256,3]: self.a() return self.b() # return [1,2,3] @internal def a(): a: uint256 = 0 b: uint256 = 1 c: uint256 = 2 d: uint256 = 3 @internal def b() -> DynArray[uint256,3]: a: DynArray[uint256,3] = empty(DynArray[uint256,3]) a = [a[0],a[1],a[2]] return a ``` examples involving append and pop: ```vyper @internal def foo(): c: DynArray[uint...

GHSA-6r8q-pfpv-7cgj: Vyper vulnerable to integer overflow in loop

### Impact Due to missing overflow check for loop variables, by assigning the iterator of a loop to a variable, it is possible to overflow the type of the latter. In the following example, calling `test` returns `354`, meaning that the variable `a` did store `354` a value out of bound for the type `uint8`. ```Vyper @external def test() -> uint16: x:uint8 = 255 a:uint8 = 0 for i in range(x, x+100): a = i return convert(a,uint16) ``` The issue seems to happen only in loops of type `for i in range(a, a + N)` as in loops of type `for i in range(start, stop)` and `for i in range(stop)`, the compiler is able to raise a `TypeMismatch` when trying to overflow the variable. thanks to @trocher for reporting ### Patches The problem is patched at https://github.com/vyperlang/vyper/commit/3de1415ee77a9244eb04bdb695e249d3ec9ed868 ### Workarounds

GHSA-ph9x-4vc9-m39g: Vyper vulnerable to incorrect ordering of arguments for kwargs passed to internal calls

### Impact Internal calls to internal functions with more than 1 default argument are compiled incorrectly. Depending on the number of arguments provided in the call, the defaults are added not right-to-left, but left-to-right. If the types are incompatible, typechecking is bypassed. In the `bar()` function in the following code, `self.foo(13)` is compiled to `self.foo(13,12)` instead of `self.foo(13,1337)`. ```vyper @internal def foo(a:uint256 = 12, b:uint256 = 1337): pass @internal def bar(): self.foo(13) ``` note that the ability to pass kwargs to internal functions is an undocumented feature that is not well known about. ### Patches _Has the problem been patched? What versions should users upgrade to?_ The problem is patched at https://github.com/vyperlang/vyper/commit/c3e68c302aa6e1429946473769dd1232145822ac ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ ### References _Are there any links users can visit to find ...

GHSA-2mhh-27v7-3vcx: WWBN AVideo command injection vulnerability

# WWBN AVideo Authenticated RCE A command injection vulnerability exists at `plugin/CloneSite/cloneClient.json.php` which allows Remote Code Execution if you CloneSite Plugin. This is a bypass to the fix for [CVE-2023-30854](https://cve.report/CVE-2023-30854) which affects WWBN Avideo up to version 12.3 ## Vulnerable Code /plugin/CloneSite/cloneClient.json.php ```php $json->sqlFile = escapeshellarg(preg_replace('/[^a-z0-9_.-]/i', '', $json->sqlFile)); $json->videoFiles = escapeshellarg(preg_replace('/[^a-z0-9_.-]/i', '', $json->videoFiles)); $json->photoFiles = escapeshellarg(preg_replace('/[^a-z0-9_.-]/i', '', $json->photoFiles)); // get dump file $cmd = "wget -O {$clonesDir}{$json->sqlFile} {$objClone->cloneSiteURL}videos/cache/clones/{$json->sqlFile}"; $log->add("Clone (2 of {$totalSteps}): Geting MySQL Dump file"); exec($cmd . " 2>&1", $output, $return_val); ``` The `$objClone->cloneSiteURL` is not properly sanitized. ## Exploit Proof-of-Concept avidexploit.py ```python fro...

GHSA-gvrq-cg5r-7chp: Vert.x STOMP server process client frames that would not send initially a connect frame

### Impact A Vert.x STOMP server processes client STOMP frames without checking that the client send an initial CONNECT frame replied with a successful CONNECTED frame. The client can subscribe to a destination or publish message without prior authentication. Any Vert.x STOMP server configured with an authentication handler is impacted. ### Patches The issue is patched in Vert.x 4.4.2 and Vert.x 3.9.16 ### Workarounds No trivial workaround.

GHSA-3p4g-rcw5-8298: etcd Key name can be accessed via LeaseTimeToLive API

### Impact LeaseTimeToLive API allows access to key names (not value) associated to a lease when `Keys` parameter is true, even a user doesn't have read permission to the keys. The impact is limited to a cluster which enables auth (RBAC). ### Patches < v3.4.26 and < v3.5.9 are affected. ### Workarounds No. ### Reporter Yoni Rozenshein

GHSA-2c4m-59x9-fr2g: Gin Web Framework does not properly sanitize filename parameter of Context.FileAttachment function

The filename parameter of the Context.FileAttachment function is not properly sanitized. A maliciously crafted filename can cause the Content-Disposition header to be sent with an unexpected filename value or otherwise modify the Content-Disposition header. For example, a filename of "setup.bat&quot;;x=.txt" will be sent as a file named "setup.bat". If the FileAttachment function is called with names provided by an untrusted source, this may permit an attacker to cause a file to be served with a name different than provided. Maliciously crafted attachment file name can modify the Content-Disposition header.

GHSA-g8ph-74m6-8m7r: ClickHouse vulnerable to client certificate password exposure in client exception

### Summary As initially reported in issue #1331, when client certificate authentication is enabled with password protection, the password (referred to as the client option `sslkey`) may be exposed in client exceptions (e.g., ClickHouseException or SQLException). This vulnerability can potentially lead to unauthorized access, data breaches, and violations of user privacy. ### Details During the handling of ClickHouseException, the client certificate password may be inadvertently exposed when sslkey is specified. This issue can arise when an exception is thrown during the execution of a query or a database operation. The client certificate password is then included in the exception message, which could be logged or exposed to unauthorized parties. ### Impact This vulnerability enables an attacker with access to client exception error messages or logs to obtain client certificate passwords, potentially allowing unauthorized access to sensitive information, data manipulation, and denial...

GHSA-8vx6-69vg-c46f: Buffer under-read in workerd

### Impact Prior to version v1.20230419.0, the FormData API implementation was subject to an integer overflow. If a FormData instance contained more than 2^31 elements, the `forEach()` method could end up reading from the wrong location in memory while iterating over elements. This would most likely lead to a segmentation fault, but could theoretically allow arbitrary undefined behavior. In order for the bug to be exploitable, the process would need to be able to allocate 160GB of RAM. Due to this, the bug was never exploitable on the Cloudflare Workers platform, but could theoretically be exploitable on deployments of workerd running on machines with a huge amount of memory. Moreover, in order to be remotely exploited, an attacker would have to upload a single form-encoded HTTP request of at least tens of gigabytes in size. The application code would then have to use `request.formData()` to parse the request and `formData.forEach()` to iterate over this data. Due to these limitations...