ghsa

Similar to CVE-2022-36359 for Django, django-sendfile2 did not protect against a reflected file download attack in version 0.6.1 and earlier. If the file name used by django-sendfile2 was derived from user input, then it would be possible to perform a such an attack. A new version of django-sendfile2 will be released. Either download django-sendfile2 0.7.0 as a workaround or sanitize user input yourself, using Django's patch as a template: https://github.com/django/django/commit/bd062445cffd3f6cc6dcd20d13e2abed818fa173

Uninit memory is used as a RNG seed in temporary. This has been resolved in the 0.6.4 release. The crate is not intended to be used outside of a testing environment. For a general purpose crate to create temporary directories, [`tempfile`](https://crates.io/crates/tempfile) is an alternative for this crate.

In Cronos nodes running versions before v0.7.0, the contract selfdestruct invocation permanently removes the corresponding bytecode from the internal database storage. However, due to a bug in Ethermint, all contracts that used the identical bytecode (i.e shared the same CodeHash) will also stop working once one contract invokes selfdestruct, even though the other contracts did not invoke the selfdestruct OPCODE. Thanks to the successfully coordinated security vulnerability disclosure, no smart contracts were impacted through the use of this vulnerability. Smart contract states and storage values are not affected by this vulnerability. This problem has been patched in Cronos v0.8.0. The patch has state machine-breaking changes and the required coordinated network upgrade was done on the block height 3982500 on the Cronos mainnet beta network. If a contract is subject to DoS due to this issue, the user can redeploy the same contract, i.e with identical bytecode, so that the original con...

The `xml.etree.ElementTree` module that mofh used up until version `1.0.1` implements a simple and efficient API for parsing and creating XML data. But it makes the application vulnerable to: - [Billion Laughs attack](https://en.wikipedia.org/wiki/Billion_laughs_attack): It is a type of denial-of-service attack aimed at XML parsers. It uses multiple levels of nested entities. If one large entity is repeated with a couple of thousand chars repeatedly, the parser gets overwhelmed. - [Quadratic blowup attack](https://www.acunetix.com/vulnerabilities/web/xml-quadratic-blowup-denial-of-service-attack/): It is similar to a Billion Laughs attack. It abuses entity expansion, too. Instead of nested entities, it repeats one large entity with a couple of thousand chars repeatedly. The Problem has been patched starting from version `1.0.1` by utilising the `defusedxml` package instead of `xml.etree.ElementTree`. ### Workarounds For this vulnerability to be exploited the user must be using a c...

Core Components version 2.20.6 (and earlier) suffer from a reflected cross-site scripting (XSS) vulnerability in `AdaptiveImageServlet` via SVG images. An attacker with author access can upload a special crafted SVG image (including a malicious Javascript) and obtain a link that, when loaded by another authenticated users, will execute the malicious script and gain access to other user's session. The issue has been resolved in 2.20.8. There are currently no known workarounds.

The Rust Security Response WG and the crates.io team [were notified][1] on 2022-05-02 of the existence of the malicious crate `rustdecimal`, which contained malware. The crate name was intentionally similar to the name of the popular [`rust_decimal`][2] crate, hoping that potential victims would misspell its name (an attack called "typosquatting"). To protect the security of the ecosystem, the crates.io team permanently removed the crate from the registry as soon as it was made aware of the malware. An analysis of all the crates on crates.io was also performed, and no other crate with similar code patterns was found. Keep in mind that the [`rust_decimal`][2] crate was **not** compromised, and it is still safe to use. ## Analysis of the crate The crate had less than 500 downloads since its first release on 2022-03-25, and no crates on the crates.io registry depended on it. The crate contained identical source code and functionality as the legit `rust_decimal` crate, except for the ...

`tower_http::services::fs::ServeDir` didn't correctly validate Windows paths, meaning paths like `/foo/bar/c:/windows/web/screen/img101.png` would be allowed and respond with the contents of `c:/windows/web/screen/img101.png`. Thus users could potentially read files anywhere on the filesystem. This only impacts Windows. Linux and other unix likes are not impacted by this. See [tower-http#204] for more details. [tower-http#204]: https://github.com/tower-rs/tower-http/pull/204

An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.

All versions of package mc-kill-port are vulnerable to Arbitrary Command Execution via the `kill` function, due to missing sanitization of the `port` argument.

`cosign verify-attestation` used with the `--type` flag will report a false positive verification when: - There is at least one attestation with a valid signature - There are NO attestations of the type being verified (--type defaults to "custom") This can happen when signing with a standard keypair and with "keyless" signing with Fulcio. Users should upgrade to cosign version 1.10.1 or greater for a patch. Currently the only workaround is to upgrade.