ghsa

### Impact An attacker can use crafted requests to bypass metadata bucket name checking and put an object into any bucket while processing `PostPolicyBucket`. To carry out this attack, the attacker requires credentials with `arn:aws:s3:::*` permission, as well as enabled Console API access. ### Patches ``` commit 67f4ba154a27a1b06e48bfabda38355a010dfca5 Author: Aditya Manthramurthy <[email protected]> Date: Sun Mar 19 21:15:20 2023 -0700 fix: post policy request security bypass (#16849) ``` ### Workarounds Browser API access must be enabled turning off `MINIO_BROWSER=off` allows for this workaround. ### References The vulnerable code: ```go // minio/cmd/generic-handlers.go func setRequestValidityHandler(h http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // ... // For all other requests reject access to reserved buckets bucketName, _ := request2BucketObjectName(r) if isMinioReservedBucket(buc...

Git Providers can read from the wrong environment because they get the same cache directory base name in Salt masters prior to 3005.2 or 3006.2. Anything that uses Git Providers with different environments can get garbage data or the wrong data, which can lead to wrongful data disclosure, wrongful executions, data corruption and/or crash.

Salt masters prior to 3005.2 or 3006.2 contain a DOS in minion return. After receiving several bad packets on the request server equal to the number of worker threads, the master will become unresponsive to return requests until restarted.

### Impact A Parse Pointer can be used to access internal Parse Server classes. It can also be used to circumvent the `beforeFind` query trigger which can be an additional vulnerability for deployments where the `beforeFind` trigger is used as a security layer to modify an incoming query. ### Patches The vulnerability was fixed by implementing a patch in the internal query pipeline to prevent a Parse Pointer to be used to access internal Parse Server classes or circumvent the `beforeFind` trigger. ### Workarounds There is no known workaround to prevent a Parse Pointer to be used to access internal Parse Server classes. A workaround if a `beforeFind` trigger is used as a security layer is to instead use the Parse Server provided [security layers](https://docs.parseplatform.org/parse-server/guide/#security) to manage access levels with Class-Level Permissions and Object-Level Access Control. ### References - GitHub security advisory: https://github.com/parse-community/parse-server...

### Summary `hyper-bump-it` reads a file glob pattern from the configuration file. That is combined with the project root directory to construct a full glob pattern that is used to find files that should be edited. These matched files should be contained within the project root directory, but that is not checked. This could result in changes being written to files outside of the project. The default behaviour of `hyper-bump-it` is to display the planned changes and prompt the user for confirmation before editing any files. However, the configuration file provides a field that can be used cause files to be edited without displaying the prompt. ### Details The vulnerability is present in https://github.com/plannigan/hyper-bump-it/blob/49c726201bbdc02c052302e03fd907d2170e1f47/hyper_bump_it/_hyper_bump_it/files.py#L35 That code joins the project root directory with a string read from the configuration file without checking if the final path is located outside the project root directo...

`lexical` contains multiple soundness issues: 1. [Bytes::read() allows creating instances of types with invalid bit patterns](https://github.com/Alexhuszagh/rust-lexical/issues/102) 1. [BytesIter::read() advances iterators out of bounds](https://github.com/Alexhuszagh/rust-lexical/issues/101) 1. [The `BytesIter` trait has safety invariants but is public and not marked `unsafe`](https://github.com/Alexhuszagh/rust-lexical/issues/104) 1. [`write_float()` calls `MaybeUninit::assume_init()` on uninitialized data, which is is not allowed by the Rust abstract machine](https://github.com/Alexhuszagh/rust-lexical/issues/95) The crate also has some correctness issues and appears to be unmaintained. ## Alternatives For quickly parsing floating-point numbers third-party crates are no longer needed. A fast float parsing algorith by the author of `lexical` has been [merged](https://github.com/rust-lang/rust/pull/86761) into libcore. For quickly parsing integers, consider `atoi` and `btoi` ...

### Impact The order of evaluation of the arguments of the builtin functions `uint256_addmod`, `uint256_mulmod`, `ecadd` and `ecmul` does not follow source order. • For `uint256_addmod(a,b,c)` and `uint256_mulmod(a,b,c)`, the order is `c,a,b`. • For `ecadd(a,b)` and `ecmul(a,b)`, the order is `b,a`. Note that this behaviour is problematic when the evaluation of one of the arguments produces side effects that other arguments depend on. ### Patches https://github.com/vyperlang/vyper/pull/3583 ### Workarounds When using builtins from the list above, make sure that the arguments of the expression do not produce side effects or, if one does, that no other argument is dependent on those side effects. ### References _Are there any links users can visit to find out more?_

### Impact For the following (probably non-exhaustive) list of expressions, the compiler evaluates the arguments from right to left instead of left to right. ``` - unsafe_add - unsafe_sub - unsafe_mul - unsafe_div - pow_mod256 - |, &, ^ (bitwise operators) - bitwise_or (deprecated) - bitwise_and (deprecated) - bitwise_xor (deprecated) - raw_call - <, >, <=, >=, ==, != - in, not in (when lhs and rhs are enums) ``` This behaviour becomes a problem when the evaluation of one of the arguments produces side effects that other arguments depend on. The following expressions can produce side-effect: - state modifying external call - state modifying internal call - `raw_call` - `pop()` when used on a Dynamic Array stored in the storage - `create_minimal_proxy_to` - `create_copy_of` - `create_from_blueprint` For example: ```Vyper f:uint256 @internal def side_effect() -> uint256: self.f = 12 return 1 @external def foo() -> uint256: return unsafe_add(self.f,self.side_effect())...

### Impact It is possible in XWiki to execute Velocity code without having script right by creating an XClass with a property of type "TextArea" and content type "VelocityCode" or "VelocityWiki". For the former, the syntax of the document needs to be set the `xwiki/1.0` (this syntax doesn't need to be installed). In both cases, when adding the property to an object, the Velocity code is executed regardless of the rights of the author of the property (edit right is still required, though). In both cases, the code is executed with the correct context author so no privileged APIs can be accessed. However, Velocity still grants access to otherwise inaccessible data and APIs that could allow further privilege escalation. At least for "VelocityCode", this behavior is most likely very old but only since XWiki 7.2, script right is a separate right, before that version all users were allowed to execute Velocity and thus this was expected and not a security issue. ### Patches This has been pat...

### Impact Improper input validation in the `init` function allows arbitrary javascript to be executed using the `javascript:` prefix ```ts SSO.init('javascript:alert("javascript successfully injected")') ``` ### Patches This vulnerability was patched on version `0.1.0` ### Workarounds This vulnerability can be prevented if user input correctly sanitized or there is no user input pass to the `init` function