deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-52h2-m2cf-9jh6
Package: linux-loader (RUST)
Severity: LOW (CVSS 1.9)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer, CWE-125: Out-of-bounds Read, CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: < 0.8.1
Patched in: 0.8.1

Summary: linux-loader reading beyond EOF could lead to infinite loop

Details:
### Impact
The linux-loader crate used the offsets and sizes provided in the ELF headers to determine the offsets to read from. If those offsets pointed beyond the end of the file this could lead to an infinite loop. Virtual Machine Monitors using the `linux-loader` crate could enter an infinite loop if the ELF header of the kernel they are loading was modified in a malicious manner.

### Patches
The issue has been addressed in 0.8.1

### Workarounds
The issue can be mitigated by ensuring that only trusted kernel images are loaded or by verifying that the headers to not point beyond the end of the file.

### References

See: https://github.com/rust-vmm/linux-loader/pull/125
GitHub Security Advisory: GHSA-9v25-r5q2-2p6w
Package: mpl-candy-machine (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: = 4.5.0
Patched in: 4.5.1

Summary: Candy Machine Set Collection During Mint Missing Check

Details:
A problem with Candy Machine V2 allow minting NFTs to an arbitrary collection due to a missing check.

Here is a description of the exploit:
Details:
Here is the tx/ix to exploit:
Transaction:
Ix 1: candy_machine v2, mint_nft, passing in empty metadata -1
Ix 2: custom handler, 0
		cpi A --> token_metadata create_metadata_account, creates NFT
		cpi B --> candy_machine v2, set_collection_during_mint
Ix 1 passes our first check for empty metadata, but eventually will hit a bot tax and return Ok.  We do have a CPI check in this function but even if we hit that or moved it to the top, it returns Ok as a bot tax and still enables the issue.
Ix 2, cpi A is Ok and mints an arbitrary NFT.
Ix 2, cpi B checks the previous instruction using index_relative_to_current-1.  This turns out to be Ix 1 which was Ok, so then your newly minted arbitrary NFT is successfully added to the collection.
Conclusion:
Candy machine could be out of NFTs and it still works.  If the CM is closed, (we think?) it doesn't get to the check.
The fix needs to be in set_collection_during_mint that current program ID id candy_machine_v2.  It checks previous program ID but doesn't check current.

NOTE: THIS DOES NOT AFFECT Cmv3
GitHub Security Advisory: GHSA-8r76-fr72-j32w
Package: mpl-token-metadata (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: >= 1.5.0, < 1.6.3
Patched in: 1.6.3

Summary: Creator Verification Error when Bubblegum Activate

Details:
This was an error found by @metamania01 of the Audit Company Solshield.

It allowed one to verify a creator that did not sign by making use of a provision in Token Metadata that allows Creators who have signed compressed nfts to allow them to decompress with verified creators.

The issue is now patched.
For more info see.
https://twitter.com/thehasheddude/status/[PII_REDACTED]43375360
GitHub Security Advisory: GHSA-8r76-fr72-j32w
Package: mpl-bubblegum (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: < 0.6.0
Patched in: 0.6.0

Summary: Creator Verification Error when Bubblegum Activate

Details:
This was an error found by @metamania01 of the Audit Company Solshield.

It allowed one to verify a creator that did not sign by making use of a provision in Token Metadata that allows Creators who have signed compressed nfts to allow them to decompress with verified creators.

The issue is now patched.
For more info see.
https://twitter.com/thehasheddude/status/[PII_REDACTED]43375360
GitHub Security Advisory: GHSA-jvgw-gccv-q5p8
Package: libp2p (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 0.45.0
Patched in: 0.45.1

Summary: libp2p DoS vulnerability from lack of resource management

Details:
### Impact

An attacker node can cause a victim node to allocate a large number of small memory chunks, which can ultimately lead to the victim’s process running out of memory and thus getting killed by its operating system. When executed continuously, this can lead to a denial of service attack, especially relevant on a larger scale when run against more than one node of a libp2p based network.

### Details

In the original version of the attack, the malicious node would continuously open new streams on a single connection using a stream multiplexer that doesn’t provide sufficient back pressure (mplex or yamux). While allocations per stream might be considered small, they multiply with the number of streams and connections. It is easy to defend against this one attack, e.g. by setting a strict per connection stream limit and connection limit. But there are other variations of this attack, e.g. causing memory allocations by sending partial payloads on various protocol levels, forcing the victim to buffer the partial payload for a period of time or by tricking the victim into pre-allocating buffers for messages which are never sent by the attacker.

### Patches

Users are advised to upgrade to `libp2p` `v0.45.1` or above.

### References
Please see our DoS Mitigation page for more information on how to incorporate mitigation strategies, monitor your application, and respond to attacks: https://docs.libp2p.io/reference/dos-mitigation/.

Please see the related disclosure for go-libp2p: https://github.com/libp2p/go-libp2p/security/advisories/GHSA-j7qp-mfxf-8xjw and js-libp2p: https://github.com/libp2p/js-libp2p/security/advisories/GHSA-f44q-634c-jvwv

### For more information
If you have any questions or comments about this advisory, please email us at security@libp2p.io.
GitHub Security Advisory: GHSA-7p7c-pvvx-2vx3
Package: hyper-staticfile (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: = 0.10.0-alpha.1
Patched in: 0.10.0-alpha.2

Summary: hyper-staticfile's improper validation of Windows paths could lead to directory traversal attack

Details:
Path resolution in `hyper-staticfile` 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.
GitHub Security Advisory: GHSA-7p7c-pvvx-2vx3
Package: hyper-staticfile (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.9.2
Patched in: 0.9.2

Summary: hyper-staticfile's improper validation of Windows paths could lead to directory traversal attack

Details:
Path resolution in `hyper-staticfile` 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.
GitHub Security Advisory: GHSA-3w3h-7xgx-grwc
Package: aliyun-oss-client (RUST)
Severity: MODERATE (CVSS 5.6)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 0.8.1
Patched in: 0.8.1

Summary: Leak in Aliyun  KeySecret 

Details:
### Impact
Users of this library will be affected when using this library, the incoming secret will be disclosed unintentionally.

### Patches
This have already been solved.

### Workarounds
No, It cannot be patched without upgrading

### References
No

### For more information
If you have any questions or comments about this advisory:
* Email us at [email address](mailto:772364230@qq.com)
GitHub Security Advisory: GHSA-q9wv-22m9-vhqh
Package: Tauri (RUST)
Severity: LOW (CVSS 2.3)
CWE: CWE-284: Improper Access Control
Vulnerable versions: >= 1.1.0, < 1.1.2
Patched in: 1.1.2

Summary: Tauri Filesystem Scope can be Partially Bypassed

Details:
### Impact

Due to incorrect escaping of special characters in paths selected via the file dialog and drag and drop functionality, it was possible to partially bypass the `fs` scope definition. It was not possible to traverse into arbitrary paths, as the issue was limited to neighboring files and sub folders of already allowed paths.

The impact differs on Windows, MacOS and Linux due to different specifications of valid path characters.

On Linux or MacOS based systems it was possible to use the `*`, `**` and `[a-Z]` patterns inside a path, which allowed to read the content of sub directories and single character files in a folder, where only specific files or the directory itself were allowed.

On Windows `[a-Z]` was the possible bypass pattern, as `*` is not treated as a valid path component. This implies that only single character files inside an already allowed directory were unintentionally accessible.

This bypass depends on the file picker dialog or dragged files, as user selected paths are automatically added to the allow list at runtime.

A successful bypass requires the user to select a pre-existing malicious file or directory during the file picker dialog and an adversary controlled logic to access these files. This means the issue by itself can not be abused and requires further intentional or unintentional privileges.

### Workaround

Disable the `dialog` and `fileDropEnabled` component inside the `tauri.conf.json`.

### Patches

The issue has been resolved in #5237 and the implementation now properly escapes the special characters. The patch has been included in releases: `1.0.7`, `1.1.2` and `1.2.0`

### For more information

This issue was initially reported by MessyComposer in #5234.

If you have any questions or comments about this advisory:

Open an issue in tauri
Email us at security@tauri.app
GitHub Security Advisory: GHSA-q9wv-22m9-vhqh
Package: Tauri (RUST)
Severity: LOW (CVSS 2.3)
CWE: CWE-284: Improper Access Control
Vulnerable versions: >= 1.0.0, < 1.0.7
Patched in: 1.0.7

Summary: Tauri Filesystem Scope can be Partially Bypassed

Details:
### Impact

Due to incorrect escaping of special characters in paths selected via the file dialog and drag and drop functionality, it was possible to partially bypass the `fs` scope definition. It was not possible to traverse into arbitrary paths, as the issue was limited to neighboring files and sub folders of already allowed paths.

The impact differs on Windows, MacOS and Linux due to different specifications of valid path characters.

On Linux or MacOS based systems it was possible to use the `*`, `**` and `[a-Z]` patterns inside a path, which allowed to read the content of sub directories and single character files in a folder, where only specific files or the directory itself were allowed.

On Windows `[a-Z]` was the possible bypass pattern, as `*` is not treated as a valid path component. This implies that only single character files inside an already allowed directory were unintentionally accessible.

This bypass depends on the file picker dialog or dragged files, as user selected paths are automatically added to the allow list at runtime.

A successful bypass requires the user to select a pre-existing malicious file or directory during the file picker dialog and an adversary controlled logic to access these files. This means the issue by itself can not be abused and requires further intentional or unintentional privileges.

### Workaround

Disable the `dialog` and `fileDropEnabled` component inside the `tauri.conf.json`.

### Patches

The issue has been resolved in #5237 and the implementation now properly escapes the special characters. The patch has been included in releases: `1.0.7`, `1.1.2` and `1.2.0`

### For more information

This issue was initially reported by MessyComposer in #5234.

If you have any questions or comments about this advisory:

Open an issue in tauri
Email us at security@tauri.app
GitHub Security Advisory: GHSA-mcmr-49x3-4jqm
Package: ckb (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: >= 0.100.0, < 0.102.0
Patched in: 0.102.0

Summary: ckb type_id script resume may randomly fail

Details:
### Impact
https://github.com/nervosnetwork/ckb/blob/v0.101.2/script/src/verify.rs#L871-L879
TypeIdSystemScript resume handle is not correct when max_cycles is not enough, `ScriptError::ExceededMaximumCycles` will be raised directly ranther than suspend as expect, and also because script_group execution order is random, so this will happen randomly.
GitHub Security Advisory: GHSA-7fw6-6mfj-g3q2
Package: ckb (RUST)
Severity: CRITICAL (CVSS 0.0)
Vulnerable versions: <= 0.101.0
Patched in: 0.101.1

Summary: ckb: Transaction header_deps validation issue (network forking)

Details:
### Impact
fn `HeaderChecker#check_valid` skipped main chain checking after this PR: https://github.com/nervosnetwork/ckb/pull/1646/files#diff-c4e017b67c1b3005ca0c446a9b0879571aa36a858b1f7ddd1b9328a884e3214bR171-R176

It will cause network forking if one transaction is using a forked block header which is not exists in local node's storage.

### Patches

0.101.1 and later versions
GitHub Security Advisory: GHSA-9mfc-chwf-7whf
Package: ckb (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.43.3
Patched in: 0.43.3

Summary: ckb: Large dep group requires a lot of resources to process but the cost to commit the transaction is very low.

Details:
### Impact

When a transaction contains a dep group with many cells, the resources required to process it are not linear to the transaction size nor spent script cycles. 

### Patches

In 0.43.3, nodes drop the transactions relayed to them when they contain a dep group with more than 64 cells. They do not ban peers who send them such transactions.

In 0.100, the consensus disallow transactions using a dep group with more than 64 cells. Peers relaying such transaction must be banned. Blocks committing such transactions must be rejected.
GitHub Security Advisory: GHSA-h8jm-2x53-xhp5
Package: openssl-src (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Vulnerable versions: >= 300.0.0, < 300.0.11
Patched in: 300.0.11

Summary: X.509 Email Address Variable Length Buffer Overflow

Details:
A buffer overrun can be triggered in X.509 certificate verification,
specifically in name constraint checking. Note that this occurs after
certificate chain signature verification and requires either a CA to
have signed a malicious certificate or for an application to continue
certificate verification despite failure to construct a path to a trusted
issuer. An attacker can craft a malicious email address in a certificate
to overflow an arbitrary number of bytes containing the `.` character
(decimal 46) on the stack. This buffer overflow could result in a crash
(causing a denial of service).

In a TLS client, this can be triggered by connecting to a malicious
server. In a TLS server, this can be triggered if the server requests
client authentication and a malicious client connects.
GitHub Security Advisory: GHSA-9398-5ghf-7pr6
Package: conduit-hyper (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-1284: Improper Validation of Specified Quantity in Input
Vulnerable versions: >= 0.2.0-alpha.3, < 0.4.2
Patched in: 0.4.2

Summary: conduit-hyper vulnerable to Denial of Service from unchecked request length

Details:
Prior to version 0.4.2, `conduit-hyper` did not check any limit on a request's length before calling [`hyper::body::to_bytes`](https://docs.rs/hyper/latest/hyper/body/fn.to_bytes.html). An attacker could send a malicious request with an abnormally large `Content-Length`, which could lead to a panic if memory allocation failed for that request.

In version 0.4.2, `conduit-hyper` sets an internal limit of 128 MiB per request, otherwise returning status 400 ("Bad Request").

This crate is part of the implementation of Rust's [crates.io](https://crates.io/), but that service is not affected due to its existing cloud infrastructure, which already drops such malicious requests. Even with the new limit in place, `conduit-hyper` is not recommended for production use, nor to directly serve the public Internet.

The vulnerability was discovered by Ori Hollander from the JFrog Security Research team.
GitHub Security Advisory: GHSA-hhc4-47rh-cr34
Package: evm (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-670: Always-Incorrect Control Flow Implementation
Vulnerable versions: <= 0.35.0
Patched in: 0.36.0

Summary: Incorrect is_static parameter for custom stateful precompiles in SputnikVM (evm)

Details:
### Impact

A custom stateful precompile can use the `is_static` parameter to determine if the call is executed in a static context (via `STATICCALL`), and thus decide if stateful operations should be done. Previously, the passed `is_static` parameter was incorrect -- it was only set to `true` if the call comes from a **direct** `STATICCALL` opcode. However, once a static call context is entered, it should stay static. 

The issue only impacts custom precompiles that actually uses `is_static`. The maintainers estimate the usage is low. However, for those affected, it can lead to possible incorrect state transitions.

### Patches

PR: https://github.com/rust-blockchain/evm/pull/133
Released in v0.36.0.

Older patch versions can be released on request if anyone needs them. Simply contact @sorpaas by email to request it.

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [evm repo](https://github.com/rust-blockchain/evm)
* Email Wei at [wei@that.world](mailto:wei@that.world)
GitHub Security Advisory: GHSA-fc4h-xcf3-qj5f
Package: matrix-sdk (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.6.0, < 0.6.2
Patched in: 0.6.2

Summary: matrix-sdk 0.6.0 logs access tokens

Details:
When sending Matrix requests using an affected version of `matrix-sdk` in an application that writes logs using `tracing-subscriber` (in a way that includes fields of tracing spans such as `tracing_subscriber`s default text output from the `fmt` module), these logs will contain the user's access token.
GitHub Security Advisory: GHSA-3jch-9qgp-4844
Package: flatbuffers (RUST)
Severity: CRITICAL (CVSS 9.8)
Vulnerable versions: < 22.9.29
Patched in: 22.9.29

Summary: Generated code can read and write out of bounds in safe code

Details:
Code generated by flatbuffers' compiler is `unsafe` but not marked as such.
See https://github.com/google/flatbuffers/issues/6627 for details.

All users that use generated code by `flatbuffers` compiler are recommended to:
1. not expose flatbuffer generated code as part of their public APIs
2. audit their code and look for any usage of `follow`, `push`, or any method that uses them
   (e.g. `self_follow`).
3. Carefuly go through the crates' documentation to understand which "safe" APIs are not
   intended to be used.
GitHub Security Advisory: GHSA-4mjx-2gh5-ph8h
Package: slack-morphism (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1258: Exposure of Sensitive System Information Due to Uncleared Debug Information
Vulnerable versions: < 1.3.2
Patched in: 1.3.2

Summary: Exposure of sensitive Slack webhook URLs in debug logs and traces

Details:
### Impact

Debug logs expose sensitive URLs for Slack webhooks that contain private information.

### Patches
The problem is fixed in v1.3.2 which redacts sensitive URLs for webhooks.

### Workarounds
Disabling/filtering debug logs in case you use Slack webhooks using tracing log level and filters.

### References
https://github.com/abdolence/slack-morphism-rust/releases/tag/v1.3.2

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [repo](https://github.com/abdolence/slack-morphism-rust)
* Read our [security policy](https://github.com/abdolence/slack-morphism-rust/blob/master/SECURITY.md)
GitHub Security Advisory: GHSA-px9g-8hgv-jvg2
Package: kamadak-exif (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: = 0.5.2
Patched in: 0.5.3

Summary: kamadak-exif vulnerable to Infinite loop when parsing PNG files

Details:
### Impact
Reader::read_from_container can cause an infinite loop when a crafted PNG file is given.

### Patches
Version 0.5.3 includes the fix.

### Workarounds
No workaround is available.
Applications that do not pass files with the PNG signature to Reader::read_from_container are not affected.

### References
* <https://github.com/kamadak/exif-rs/security/advisories/GHSA-px9g-8hgv-jvg2>
* <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21235>

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [github.com/kamadak/exif-rs](https://github.com/kamadak/exif-rs)
GitHub Security Advisory: GHSA-28r9-pq4c-wp3c
Package: personnummer (RUST)
Severity: LOW (CVSS 0.0)
Vulnerable versions: < 3.0.1
Patched in: 3.0.1

Summary: personnummer/rust vulnerable to Improper Input Validation

Details:
This vulnerability was reported to the personnummer team in June 2020. The slow response was due to locked ownership of some of the affected packages, which caused delays to update packages prior to disclosure.

The vulnerability is determined to be low severity.

### Impact

This vulnerability impacts users who rely on the for last digits of personnummer to be a _real_ personnummer.  

### Patches

The issue have been patched in all repositories. The following versions should be updated to as soon as possible:

[C#](https://github.com/advisories/GHSA-qv8q-v995-72gr) 3.0.2  
D 3.0.1  
[Dart](https://github.com/advisories/GHSA-4xh4-v2pq-jvhm) 3.0.3  
Elixir 3.0.0  
[Go](https://github.com/advisories/GHSA-hv53-vf5m-8q94) 3.0.1  
[Java](https://github.com/advisories/GHSA-q3vw-4jx3-rrr2) 3.3.0  
[JavaScript](https://github.com/advisories/GHSA-vpgc-7h78-gx8f) 3.1.0  
Kotlin 1.1.0  
Lua 3.0.1  
[PHP](https://github.com/advisories/GHSA-2p6g-gjp8-ggg9) 3.0.2  
Perl 3.0.0  
[Python](https://github.com/advisories/GHSA-rxq3-5249-8hgg) 3.0.2  
[Ruby](https://github.com/advisories/GHSA-vp9c-fpxx-744v) 3.0.1  
[Rust](https://github.com/advisories/GHSA-28r9-pq4c-wp3c) 3.0.0  
Scala 3.0.1  
Swift 1.0.1  

If you are using any of the earlier packages, please update to latest.

### Workarounds

The issue arrieses from the regular expression allowing the first three digits in the last four digits of the personnummer to be
000, which is invalid. To mitigate this without upgrading, a check on the last four digits can be made to make sure it's not
000x.

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [Personnummer Meta](https://github.com/personnummer/meta/issues)
* Email us at [Personnummer Email](mailto:security@personnummer.dev)
GitHub Security Advisory: GHSA-m4vx-ccrf-w399
Package: routinator (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-617: Reachable Assertion
Vulnerable versions: >= 0.9.0, < 0.11.3
Patched in: 0.11.3

Summary: NLnet Labs Routinator has Reachable Assertion vulnerability

Details:
In NLnet Labs Routinator 0.9.0 up to and including 0.11.2, due to a mistake in error handling, data in RRDP snapshot and delta files which are not correctly base 64 encoded are treated as a fatal error and causes Routinator to exit. Worst case impact of this vulnerability is denial of service for the RPKI data that Routinator provides to routers. This may stop your network from validating route origins based on RPKI data. This vulnerability does not allow an attacker to manipulate RPKI data.