ghsa

### Impact This vulnerability would allow any user, regardless of permissions, to upload content into a repository. This affects installations of Islandora core 2.0 or greater. ### Patches Upgrade immediately to the [latest release](https://github.com/Islandora/islandora/releases/tag/2.4.1) of Islandora. ### Workarounds In lieu of an upgrade the [following module](https://github.com/Islandora/islandora_ghsa_route_fix) can be leveraged that will resolve the issue until such a time an upgrade can take place. ### For more information If you have any questions or comments about this advisory: * Open an issue in [Islandora](https://github.com/Islandora/islandora) * Contact [email protected].

### Impact Vulnerable library protobuf-java 3.11.4 (CVE-2021-22569) ### Patches Dependency updated in jadx 1.4.3 ### References According to the AquaSecurity report:  Also, Maven repository have links to this and other vulnerabilities from dependencies: https://mvnrepository.com/artifact/com.google.protobuf/protobuf-java/3.11.4

### Impact There was a bug in Wasmtime's code generator, Cranelift, for AArch64 targets where constant divisors could result in incorrect division results at runtime. The translation rules for constants did not take into account whether sign- or zero-extension should happen, which resulted in an incorrect value being placed into a register when a division was encountered. For example, a constant 32-bit unsigned divisor of `0xfffffffe` would be incorrectly sign-extended to 64-bits to `0xfffffffffffffffe`. Any kind of division of operands smaller than 64 bits is implemented with a 64-bit division instruction which would then result in an incorrect result because the divisor was larger than expected. The impact of this bug is that programs executing within the WebAssembly sandbox would not behave according to the WebAssembly specification. This means that it is hypothetically possible for execution within the sandbox to go awry and WebAssembly programs could produce unexpected results. ...

### Impact `SignatureChecker.isValidSignatureNow` is not expected to revert. However, an incorrect assumption about Solidity 0.8's `abi.decode` allows some cases to revert, given a target contract that doesn't implement EIP-1271 as expected. The contracts that may be affected are those that use `SignatureChecker` to check the validity of a signature and handle invalid signatures in a way other than reverting. We believe this to be unlikely. ### Patches The issue was patched in 4.7.1. ### References https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3552 ### For more information If you have any questions or comments about this advisory, or need assistance deploying the fix, email us at [[email protected]](mailto:[email protected]).

### Impact `ERC165Checker.supportsInterface` is designed to always successfully return a boolean, and under no circumstance revert. However, an incorrect assumption about Solidity 0.8's `abi.decode` allows some cases to revert, given a target contract that doesn't implement EIP-165 as expected, specifically if it returns a value other than 0 or 1. The contracts that may be affected are those that use `ERC165Checker` to check for support for an interface and then handle the lack of support in a way other than reverting. ### Patches The issue was patched in 4.7.1. ### References https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3552 ### For more information If you have any questions or comments about this advisory, or need assistance deploying the fix, email us at [[email protected]](mailto:[email protected]).

### Impact #### Affected versions - 0.3.60 and earlier. - 1.0.0 to 1.2.9 when used with the Ruby data source (tzinfo-data). #### Vulnerability With the Ruby data source (the tzinfo-data gem for tzinfo version 1.0.0 and later and built-in to earlier versions), time zones are defined in Ruby files. There is one file per time zone. Time zone files are loaded with `require` on demand. In the affected versions, `TZInfo::Timezone.get` fails to validate time zone identifiers correctly, allowing a new line character within the identifier. With Ruby version 1.9.3 and later, `TZInfo::Timezone.get` can be made to load unintended files with `require`, executing them within the Ruby process. For example, with version 1.2.9, you can run the following to load a file with path `/tmp/payload.rb`: ```ruby TZInfo::Timezone.get("foo\n/../../../../../../../../../../../../../../../../tmp/payload") ``` The exact number of parent directory traversals needed will vary depending on the location of t...

### Impact A vulnerability has been discovered in the Grails data-binding logic which allows for Remote Code Execution in a Grails application. This exploit requires the application to be running on Java 8, either deployed as a WAR to a servlet container, or an executable JAR. ### Patches Grails framework versions 5.2.1, 5.1.9, 4.1.1, and 3.3.15 ### References https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35912 https://grails.org/blog/2022-07-18-rce-vulnerability.html ### For more information If you have any questions or comments about this advisory: * https://grails.org/blog/2022-07-18-rce-vulnerability.html * https://github.com/grails/grails-core/issues/12626 * Email us at [[email protected]](mailto:[email protected]) ### Credit This vulnerability was discovered by [meizjm3i](https://github.com/meizjm3i) and [codeplutos](https://github.com/codeplutos) of AntGroup FG Security Lab

### Impact Authorization headers are already cleared on cross-origin redirect in https://github.com/nodejs/undici/blob/main/lib/handler/redirect.js#L189, based on https://github.com/nodejs/undici/issues/872. However, cookie headers which are sensitive headers and are official headers found in the spec, remain uncleared. There also has been active discussion of implementing a cookie store https://github.com/nodejs/undici/pull/1441, which suggests that there are active users using cookie headers in undici. As such this may lead to accidental leakage of cookie to a 3rd-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the 3rd party site. ### Patches This was patched in v5.8.0. ### Workarounds By default, this vulnerability is not exploitable. Do not enable redirections, i.e. `maxRedirections: 0` (the default). ### References https://hackerone.com/reports/1635514 https://curl.se/docs/CVE-2018-1000007.html https...

### Impact It is possible to inject CRLF sequences into request headers in Undici. ```js const undici = require('undici') const response = undici.request("http://127.0.0.1:1000", { headers: {'a': "\r\nb"} }) ``` The same applies to `path` and `method` ### Patches Update to v5.8.0 ### Workarounds Sanitize all HTTP headers from untrusted sources to eliminate `\r\n`. ### References https://hackerone.com/reports/409943 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12116 ### For more information If you have any questions or comments about this advisory: * Open an issue in [undici repository](https://github.com/nodejs/undici/issues) * To make a report, follow the [SECURITY](https://github.com/nodejs/node/blob/HEAD/SECURITY.md) document

There is a bug in Wasmtime's code generator, Cranelift, where functions using reference types may be incorrectly missing metadata required for runtime garbage collection (GC). This means that if a GC happens at runtime then the collector will mistakenly think some Wasm stack frames do not have live references to garbage collected values and therefore reclaim and deallocate them. The function can then subsequently continue to use the values, leading later to use-after-free bugs. This bug was introduced in Cranelift's migration to the `regalloc2` register allocator in the Wasmtime 0.37.0 release on 2022-05-20. This bug has been patched and users should upgrade to Wasmtime version 0.38.2. Mitigations for this issue can be achieved by doing one of: * Disabling the reference types proposal by passing `false` to [`wasmtime::Config::wasm_reference_types`](https://docs.rs/wasmtime/0.38.0/wasmtime/struct.Config.html#method.wasm_reference_types). * Downgrading to Wasmtime 0.36.0 or prior.