ghsa

Apache Commons Configuration performs variable interpolation, allowing properties to be dynamically evaluated and expanded. The standard format for interpolation is "${prefix:name}", where "prefix" is used to locate an instance of org.apache.commons.configuration2.interpol.Lookup that performs the interpolation. Starting with version 2.4 and continuing through 2.7, the set of default Lookup instances included interpolators that could result in arbitrary code execution or contact with remote servers. These lookups are: - "script" - execute expressions using the JVM script execution engine (javax.script) - "dns" - resolve dns records - "url" - load values from urls, including from remote servers Applications using the interpolation defaults in the affected versions may be vulnerable to remote code execution or unintentional contact with remote servers if untrusted configuration values are used. Users are recommended to upgrade to Apache Commons Configuration 2.8.0, which disables the pro...

### Impact go-ipfs nodes crash when trying to import certain malformed CAR files due to an issue in the go-car dependency. This impacts nodes running `ipfs dag import` on untrusted user inputs, for example, pinning services with a car ingest endpoint. This include the corresponding [HTTP RPC API `v0/dag/import`](https://docs.ipfs.io/reference/http/api/#api-v0-dag-import) endpoint. An attacker controlling the car file passed in can also make the node allocate arbitrary sized buffers creating memory exhaustion attacks. ### Patches 0.13.1, 0.14 and later. #### Forks For those running on forked versions of go-ipfs, simply updating the version of `github.com/ipld/go-car/v2` you are using to >= v2.4.0 should resolve the issue. #### Libraries consumers Any users of libraries within the go-ipfs ecosystem, even if not the go-ipfs package or binary itself, may be affected and should upgrade their dependency on go-car. You can check if your Go module has a dependency on go-car by running a c...

AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised implementation will not encrypt the entirety of the data under some circumstances. This could reveal sixteen bytes of data that was preexisting in the memory that wasn't written. In the special case of "in place" encryption, sixteen bytes of the plaintext would be revealed. Since OpenSSL does not support OCB based cipher suites for TLS and DTLS, they are both unaffected.

### Impact Parse Server LiveQuery does not remove protected fields in classes, passing them to the client. ### Patches The LiveQueryController now removes protected fields from the client response. ### Workarounds Use `Parse.Cloud.afterLiveQueryEvent` to manually remove protected fields. ### References - https://github.com/parse-community/parse-server/security/advisories/GHSA-crrq-vr9j-fxxh - https://github.com/parse-community/parse-server ### For more information If you have any questions or comments about this advisory: - For questions or comments about this vulnerability visit our [community forum](http://community.parseplatform.org/) or [community chat](http://chat.parseplatform.org/) - Report other vulnerabilities at [report.parseplatform.org](https://report.parseplatform.org/)

### Impact An attacker can pass a compromised input to the e-mail [signin endpoint](https://next-auth.js.org/getting-started/rest-api#post-apiauthsigninprovider) that contains some malicious HTML, tricking the e-mail server to send it to the user, so they can perform a phishing attack. Eg.: `balazs@email.com, <a href="http://attacker.com">Before signing in, claim your money!</a>`. This was previously sent to `balazs@email.com`, and the content of the email containing a link to the attacker's site was rendered in the HTML. This has been remedied in the following releases, by simply not rendering that e-mail in the HTML, since it should be obvious to the receiver what e-mail they used: next-auth v3 users before version 3.29.8 are impacted. (We recommend upgrading to v4, as v3 is considered unmaintained. See our [migration guide](https://next-auth.js.org/getting-started/upgrade-v4)) next-auth v4 users before version 4.8.0 are impacted. ### Patches We've released patches for this vuln...

### Impact **Versions impacted** * `<=` go-car@v0.3.3 * `<=` go-car@v2.3.0 **Description** Decoding CAR data from untrusted user input can cause: - Panics: - Out of bound memory access - Out of memory - Divide by zero - Excessive memory usage Such panics can be triggered by intentionally malformed CARv1 data, including CARv1 data within a CARv2 container; and also CARv2 data with excessively large indexes. These vulnerabilities are not known to be exploited in the wild and were discovered primarily with the use of code fuzzing tooling. **Details** **Out of bound memory access** (OOB), **out of memory** (OOM) panics or **excessive memory usage** can be triggered by decode of malformed CARv1 headers, malformed CARv1 sections, and malformed CIDv0 data used in CARv1 sections. This also applies to CARv1 data within a CARv2 container. Additionally, we wish to use this security advisory to make clear to consumers of CARv2 format data that **loading CARv2 indexes from untrus...

### Impact If a field of a key is shorter than it is declared to be, the parser raises an error with a message containing the raw field value. An attacker able to modify the declared length of a key's sensitive field can thus expose the raw value of that field. ### Patches Upgrade to version 0.0.6, which no longer includes the raw field value in the error message. ### Workarounds N/A ### References N/A ### For more information If you have any questions or comments about this advisory: * Open an issue in [openssh_key_parser](https://github.com/scottcwang/openssh_key_parser)

### Impact * using string-to-date parsing in moment (more specifically rfc2822 parsing, which is tried by default) has quadratic (N^2) complexity on specific inputs * noticeable slowdown is observed with inputs above 10k characters * users who pass user-provided strings without sanity length checks to moment constructor are vulnerable to (Re)DoS attacks ### Patches The problem is patched in 2.29.4, the patch can be applied to all affected versions with minimal tweaking. ### Workarounds In general, given the proliferation of ReDoS attacks, it makes sense to limit the length of the user input to something sane, like 200 characters or less. I haven't seen legitimate cases of date-time strings longer than that, so all moment users who do pass a user-originating string to constructor are encouraged to apply such a rudimentary filter, that would help with this but also most future ReDoS vulnerabilities. ### References There is an excellent writeup of the issue here: https://github.com/mo...

NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.

An Access Control vulnerability exists in Nacos 2.0.3 in the access prompt page; enter username and password, click on login to capture packets and then change the returned package, which lets a malicious user login.