deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-g59m-gf8j-gjf5
Package: aws-sdk-acmpca (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.94.0
Patched in: 1.94.0

Summary: AWS SDK for Rust v1 adopted defense in depth enhancement for region parameter value

Details:
## **Summary**
This notification is related to the use of specific values for the region input field when calling AWS services. An actor with access to the environment in which the SDK is used could set the region input field to an invalid value.

A defense-in-depth enhancement has been implemented in the AWS SDK for Rust. This enhancement validates that a region used to construct an endpoint URL is a valid host label. The change was released on November 6, 2025. This advisory is informational to help customers understand their responsibilities regarding configuration security.

## **Impact**
Customer applications could be configured to improperly route AWS API calls to non-existent or non-AWS hosts. While the SDK was functioning safely within the requirements of the shared responsibility model, additional safeguards have been added to support secure customer implementations.

**Impacted versions**: All versions prior to [November 6, 2025 release](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2025-11-06)

## **Patches**
On November 6, 2025, an enhancement [1] was made to the AWS SDK for Rust release, which validates the formatting of a region, providing additional safeguards.

## **Workarounds**
No workarounds are needed, but as always developers should ensure that their application is following security best practices:
- Implement proper input validation in your application code
- Update to the latest AWS SDK for Rust release on a regular basis
- Follow AWS security best practices [2] for SDK configuration

## **References**
Contact AWS Security via the vulnerability reporting page or email [aws-security@amazon.com](mailto:aws-security@amazon.com).

## **Acknowledgement**
AWS Security thanks Guy Arazi for bringing these customer security considerations to our attention through the coordinated disclosure process.


[1] https://github.com/smithy-lang/smithy-rs/pull/4383
[2] https://docs.aws.amazon.com/sdk-for-rust/latest/dg/security.html
GitHub Security Advisory: GHSA-g59m-gf8j-gjf5
Package: aws-sdk-acm (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.92.0
Patched in: 1.92.0

Summary: AWS SDK for Rust v1 adopted defense in depth enhancement for region parameter value

Details:
## **Summary**
This notification is related to the use of specific values for the region input field when calling AWS services. An actor with access to the environment in which the SDK is used could set the region input field to an invalid value.

A defense-in-depth enhancement has been implemented in the AWS SDK for Rust. This enhancement validates that a region used to construct an endpoint URL is a valid host label. The change was released on November 6, 2025. This advisory is informational to help customers understand their responsibilities regarding configuration security.

## **Impact**
Customer applications could be configured to improperly route AWS API calls to non-existent or non-AWS hosts. While the SDK was functioning safely within the requirements of the shared responsibility model, additional safeguards have been added to support secure customer implementations.

**Impacted versions**: All versions prior to [November 6, 2025 release](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2025-11-06)

## **Patches**
On November 6, 2025, an enhancement [1] was made to the AWS SDK for Rust release, which validates the formatting of a region, providing additional safeguards.

## **Workarounds**
No workarounds are needed, but as always developers should ensure that their application is following security best practices:
- Implement proper input validation in your application code
- Update to the latest AWS SDK for Rust release on a regular basis
- Follow AWS security best practices [2] for SDK configuration

## **References**
Contact AWS Security via the vulnerability reporting page or email [aws-security@amazon.com](mailto:aws-security@amazon.com).

## **Acknowledgement**
AWS Security thanks Guy Arazi for bringing these customer security considerations to our attention through the coordinated disclosure process.


[1] https://github.com/smithy-lang/smithy-rs/pull/4383
[2] https://docs.aws.amazon.com/sdk-for-rust/latest/dg/security.html
GitHub Security Advisory: GHSA-g59m-gf8j-gjf5
Package: aws-sdk-account (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.92.0
Patched in: 1.92.0

Summary: AWS SDK for Rust v1 adopted defense in depth enhancement for region parameter value

Details:
## **Summary**
This notification is related to the use of specific values for the region input field when calling AWS services. An actor with access to the environment in which the SDK is used could set the region input field to an invalid value.

A defense-in-depth enhancement has been implemented in the AWS SDK for Rust. This enhancement validates that a region used to construct an endpoint URL is a valid host label. The change was released on November 6, 2025. This advisory is informational to help customers understand their responsibilities regarding configuration security.

## **Impact**
Customer applications could be configured to improperly route AWS API calls to non-existent or non-AWS hosts. While the SDK was functioning safely within the requirements of the shared responsibility model, additional safeguards have been added to support secure customer implementations.

**Impacted versions**: All versions prior to [November 6, 2025 release](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2025-11-06)

## **Patches**
On November 6, 2025, an enhancement [1] was made to the AWS SDK for Rust release, which validates the formatting of a region, providing additional safeguards.

## **Workarounds**
No workarounds are needed, but as always developers should ensure that their application is following security best practices:
- Implement proper input validation in your application code
- Update to the latest AWS SDK for Rust release on a regular basis
- Follow AWS security best practices [2] for SDK configuration

## **References**
Contact AWS Security via the vulnerability reporting page or email [aws-security@amazon.com](mailto:aws-security@amazon.com).

## **Acknowledgement**
AWS Security thanks Guy Arazi for bringing these customer security considerations to our attention through the coordinated disclosure process.


[1] https://github.com/smithy-lang/smithy-rs/pull/4383
[2] https://docs.aws.amazon.com/sdk-for-rust/latest/dg/security.html
GitHub Security Advisory: GHSA-g59m-gf8j-gjf5
Package: aws-sdk-accessanalyzer (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.96.0
Patched in: 1.96.0

Summary: AWS SDK for Rust v1 adopted defense in depth enhancement for region parameter value

Details:
## **Summary**
This notification is related to the use of specific values for the region input field when calling AWS services. An actor with access to the environment in which the SDK is used could set the region input field to an invalid value.

A defense-in-depth enhancement has been implemented in the AWS SDK for Rust. This enhancement validates that a region used to construct an endpoint URL is a valid host label. The change was released on November 6, 2025. This advisory is informational to help customers understand their responsibilities regarding configuration security.

## **Impact**
Customer applications could be configured to improperly route AWS API calls to non-existent or non-AWS hosts. While the SDK was functioning safely within the requirements of the shared responsibility model, additional safeguards have been added to support secure customer implementations.

**Impacted versions**: All versions prior to [November 6, 2025 release](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2025-11-06)

## **Patches**
On November 6, 2025, an enhancement [1] was made to the AWS SDK for Rust release, which validates the formatting of a region, providing additional safeguards.

## **Workarounds**
No workarounds are needed, but as always developers should ensure that their application is following security best practices:
- Implement proper input validation in your application code
- Update to the latest AWS SDK for Rust release on a regular basis
- Follow AWS security best practices [2] for SDK configuration

## **References**
Contact AWS Security via the vulnerability reporting page or email [aws-security@amazon.com](mailto:aws-security@amazon.com).

## **Acknowledgement**
AWS Security thanks Guy Arazi for bringing these customer security considerations to our attention through the coordinated disclosure process.


[1] https://github.com/smithy-lang/smithy-rs/pull/4383
[2] https://docs.aws.amazon.com/sdk-for-rust/latest/dg/security.html
GitHub Security Advisory: GHSA-rjf8-2wcw-f6mp
Package: salvo (RUST)
Severity: HIGH (CVSS 8.8)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.88.1
Patched in: 0.88.1

Summary: Salvo is vulnerable to reflected XSS in the list_html function

Details:
# Summary

The function `list_html` generates an file view of a folder which includes a render of the current path, in which its inserted in the HTML without proper sanitation, leading to reflected XSS. The request path is decoded and normalized in the matching stage but is not inserted raw in the HTML view (current.path). The only constraint here is for the root path (e.g., /files in the PoC example) to have a subdirectory (e. g., common ones like styles/scripts/etc.) so that the matching returns the list HTML page instead of the Not Found page.

# Details

The vulnerable snippet of code is the following:
[**dir.rs**](https://github.com/salvo-rs/salvo/blob/16efeba312a274739606ce76366d[PII_REDACTED]54/crates/serve-static/src/dir.rs#L593)

```rust
// ... fn list_html(...
    let mut ftxt = format!(
        r#"<!DOCTYPE html><html><head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width">
        <title>{}</title>
        <style>{}</style></head><body><header><h3>Index of: {}</h3></header><hr/>"#,
        current.path,
        HTML_STYLE,
        header_links(&current.path)
    );
// ...
```

As seen here `<title>{}</title>` it is inserted unsafely.

# PoC

https://github.com/user-attachments/assets/92a29a67-547b-40a5-af26-f1b0dd332702

Here is the example app, note this doesn’t need an upload feature (e.g to the other reported vulnerability), only the sub-folder is required.

`main.rs`
```rust
use salvo::prelude::*;
use salvo::serve_static::StaticDir;
use tokio::fs;

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt().init();
    fs::create_dir_all("uploads").await.expect("create uploads dir");

    let router = Router::new()
        .push(
            Router::with_path("files/{**rest_path}")
                .get(StaticDir::new("uploads").auto_list(true)),
        );

    let acceptor = TcpListener::new("127.0.0.1:5800").bind().await;
    Server::new(acceptor).serve(router).await;
}
```

`Cargo.toml`
```rust
[package]
name = "salvo-staticdir-xss-poc"
version = "0.1.0"
edition = "2024"

[dependencies]
salvo = { version = "0.85.0", features = ["serve-static"] }
tokio = { version = "1", features = ["macros", "rt-multi-thread", "fs"] }
tracing-subscriber = "0.3"
```

Setup commands:
```bash
mkdir uploads
mkdir uploads/bla
```

# Impact

JavaScript execution, most likely leading to an account takeover, depending on the site's constraint (CSP, etc…).
GitHub Security Advisory: GHSA-vcwh-pff9-64cc
Package: rustfs (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-285: Improper Authorization
Vulnerable versions: < 1.0.0-alpha.79
Patched in: 1.0.0-alpha.79

Summary: RustFS has IAM Incorrect Authorization in ImportIam that Allows Privilege Escalation

Details:
### Summary

The `ImportIam` admin API validates permissions using **`ExportIAMAction`** instead of **`ImportIAMAction`**, allowing a principal with *export-only* IAM permissions to perform *import* operations. Since importing IAM data performs privileged **write** actions (creating/updating users, groups, policies, and service accounts), this can lead to **unauthorized IAM modification and privilege escalation**.

---

### Details

In `ImportIam`, the authorization check is implemented as follows:

```rust
validate_admin_request(
    &req.headers,
    &cred,
    owner,
    false,
    vec![Action::AdminAction(AdminAction::ExportIAMAction)],
).await?;
```

However, this code resides in the **Import IAM** operation (`struct ImportIam {}`), which performs **state-changing IAM writes**.

The expected behavior is to validate against **`AdminAction::ImportIAMAction`** (or an equivalent import-specific admin action), not `ExportIAMAction`.

---

### PoC

**Prerequisites**

1. A RustFS deployment with IAM enabled.
2. An IAM user or role that has **Export IAM** permission but **does not** have Import IAM or full admin permissions.
3. Access credentials for that user.

**Steps**

1. Create or obtain an IAM principal with permission equivalent to:

   ```
   AdminAction::ExportIAMAction
   ```

   and without Import IAM privileges.

2. Prepare a valid IAM import ZIP archive containing, for example:

   * A new policy granting administrative permissions
   * A user or service account bound to that policy

3. Send a request to the Import IAM endpoint (the same endpoint handled by `ImportIam::call`), authenticating with the export-only credentials.

4. Observe that:

   * The request passes authorization.
   * IAM entities from the archive are created or modified successfully.

**Expected Result**

* The request should be rejected with an authorization error (e.g., AccessDenied).

**Actual Result**

* The request succeeds, and IAM state is modified.
GitHub Security Advisory: GHSA-rhfx-m35p-ff5j
Package: lru (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: >= 0.9.0, < 0.16.3
Patched in: 0.16.3

Summary: `IterMut` violates Stacked Borrows by invalidating internal pointer

Details:
Affected versions of this crate contain a soundness issue in the `IterMut` iterator implementation. The `IterMut::next` and `IterMut::next_back` methods temporarily create an exclusive reference to the key when dereferencing the internal node pointer.

This invalidates the shared pointer held by the internal `HashMap`, violating Stacked Borrows rules.
GitHub Security Advisory: GHSA-gw2x-q739-qhcr
Package: rustfs (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-755: Improper Handling of Exceptional Conditions
Vulnerable versions: >= 1.0.0-alpha.13, <= 1.0.0-alpha.77
Patched in: 1.0.0-alpha.78

Summary: RustFS gRPC GetMetrics deserialization panic enables remote DoS

Details:
### Summary
A malformed gRPC `GetMetrics` request causes `get_metrics` to `unwrap()` failed deserialization of `metric_type`/`opts`, panicking the handler thread and enabling remote denial of service of the metrics endpoint.

### Details
- Vulnerable code: `rustfs/src/storage/tonic_service.rs:1775-1782`:
  - `MetricType` and `CollectMetricsOpts` are deserialized with `Deserialize::deserialize(...).unwrap()` from client-supplied bytes.
  - Malformed `metric_type`/`opts` (e.g., empty or truncated rmp-serde payloads) trigger `InvalidMarkerRead` and panic.
- Reachability: same TCP listener as S3 (default `:9000`); only a static interceptor token `authorization: rustfs rpc` is checked in `server/http.rs:677`.
- Impact scope: panic terminates the worker handling the request, causing metrics service interruption and potential process instability.

### PoC

[rustfs-grpc-metrics-invalid-metric-type-panic-poc.tar.gz](https://github.com/user-attachments/files/24038341/rustfs-grpc-metrics-invalid-metric-type-panic-poc.tar.gz)


1) Start RustFS (example local dev):
```bash
mkdir -p /tmp/rustfs-data1 /tmp/rustfs-data2
RUSTFS_ACCESS_KEY=devadmin RUSTFS_SECRET_KEY=devadmin \
  cargo run --bin rustfs -- --address 0.0.0.0:9000 \
  /tmp/rustfs-data1 /tmp/rustfs-data2
```
2) From `rustfs-grpc-metrics-invalid-metric-type-panic-poc/`, run:
```bash
ENDPOINT=127.0.0.1:9000 make run
# or: grpcurl -plaintext \
#   -H 'authorization: rustfs rpc' \
#   -import-path ../crates/protos/src -proto node.proto \
#   -d '{"metric_type":"","opts":""}' \
#   127.0.0.1:9000 node_service.NodeService/GetMetrics
```
3) Observe panic in server logs at `tonic_service.rs:get_metrics` with `InvalidMarkerRead` and worker crash; client output saved to `poc-response.txt`/`poc-grpcurl.log`.

### Impact
- Vulnerability type: remote unauthenticated (static token) denial of service via panic in gRPC handler.
- Who is impacted: any deployment exposing the gRPC endpoint where an attacker can reach port 9000 and supply the known `authorization: rustfs rpc` header; metrics service is disrupted and may affect overall stability depending on runtime crash handling.
GitHub Security Advisory: GHSA-9c48-w39g-hm26
Package: rsa (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-703: Improper Check or Handling of Exceptional Conditions
Vulnerable versions: <= 0.9.9
Patched in: 0.9.10

Summary: rsa crate has potential panic on a prime being equal to 1

Details:
When creating a RSA private key from its components, the construction panics, instead of returning an error, when one of the primes is `1`. 

Discovered by Christian Reitter from [Radically Open Security](https://www.radicallyopensecurity.com/) during a security review for [Proton AG](https://proton.me/).
GitHub Security Advisory: GHSA-6mw6-mj76-grwc
Package: gix-date (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: < 0.12.0
Patched in: 0.12.0

Summary: gix-date can create non-utf8 string with `TimeBuf::as_str`

Details:
The function `gix_date::parse::TimeBuf::as_str` can create an illegal string containing non-utf8 characters. This violates the safety invariant of `TimeBuf` and can lead to undefined behavior when consuming the string.

The bug can be prevented by adding `str::from_utf8` to the function `TimeBuf::write`.
GitHub Security Advisory: GHSA-95qg-89c2-w5hj
Package: theshit (RUST)
Severity: HIGH (CVSS 7.3)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: < 0.1.1
Patched in: 0.1.1

Summary: theshit vulnerable to unsafe loading of user-owned Python rules when running as root

Details:
### Impact

**Vulnerability Type:** Local Privilege Escalation (LPE) / Arbitrary Code Execution.

The application loads custom Python rules and configuration files from user-writable locations (e.g., `~/.config/theshit/`) without validating ownership or permissions when executed with elevated privileges.

If the tool is invoked with `sudo` or otherwise runs with an effective UID of root, it continues to trust configuration files originating from the unprivileged user's environment. This allows a local attacker to inject arbitrary Python code via a malicious rule or configuration file, which is then executed with root privileges.

**Who is impacted:**
Any system where this tool is executed with elevated privileges is affected. In environments where the tool is permitted to run via `sudo` without a password (`NOPASSWD`), a local unprivileged user can escalate privileges to root without additional interaction.

### Patches

The issue has been fixed in version **0.1.1**.

The patch introduces strict ownership and permission checks for all configuration files and custom rules. The application now enforces that rules are only loaded if they are owned by the effective user executing the tool.

When executed with elevated privileges (`EUID=0`), the application refuses to load any files that are not owned by root or that are writable by non-root users. When executed as a non-root user, it similarly refuses to load rules owned by other users. This prevents both vertical and horizontal privilege escalation via execution of untrusted code.

### Workarounds

If upgrading is not possible, users should avoid executing the pplication with `sudo` or as the root user.

As a temporary mitigation, ensure that directories containing custom rules and configuration files are owned by root and are not writable by non-root users. Administrators may also audit existing custom rules before running the tool with elevated privileges.

### References

* [Commit fixing the issue](https://github.com/AsfhtgkDavid/theshit/commit/3dc12905cafb5fd47fff4071a05c231f925ac113)
* CWE-269: Improper Privilege Management
* CWE-284: Improper Access Control
* CWE-829: Inclusion of Functionality from Untrusted Control Sphere
GitHub Security Advisory: GHSA-9fjq-45qv-pcm7
Package: ruint (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: <= 1.17.0
Patched in: unpatched

Summary: ruint affected by unsoundness of safe `reciprocal_mg10`

Details:
The function `reciprocal_mg10` is marked as safe but can trigger undefined behavior (out-of-bounds access) because it relies on `debug_assert!` for safety checks instead of `assert!`.

When compiled in release mode, the `debug_assert!` is optimized out, potentially allowing invalid inputs to cause memory corruption.
GitHub Security Advisory: GHSA-v6x3-9r38-r27q
Package: sequoia-openpgp (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-195: Signed to Unsigned Conversion Error
Vulnerable versions: < 2.1.0
Patched in: 2.1.0

Summary: Sequoia PGP has Subtraction Overflow when aes_key_unwrap function is provided ciphertext that is too short

Details:
In Sequoia before 2.1.0, aes_key_unwrap panics if passed a ciphertext that is too short. A remote attacker can take advantage of this issue to crash an application by sending a victim an encrypted message with a crafted PKESK or SKESK packet.
GitHub Security Advisory: GHSA-qwcc-2r77-5w2f
Package: sd (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-266: Incorrect Privilege Assignment
Vulnerable versions: <= 1.0.0
Patched in: unpatched

Summary: sd changes the group ownership of the source file

Details:
An issue in sd command v1.0.0 and before allows attackers to escalate privileges to root via a crafted command.
GitHub Security Advisory: GHSA-459f-x8vq-xjjm
Package: static-web-server (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: <= 2.40.0
Patched in: 2.40.1

Summary: Static Web Server vulnerable to a symbolic link path traversal

Details:
### Summary

Symbolic links (_symlinks_) could be used to access files or directories outside the intended web root folder.

### Details

SWS generally does not prevent symlinks from escaping the web server’s root directory. Therefore, if a malicious actor gains access to the web server’s root directory, they could create symlinks to access other files outside the designated web root folder either by URL or via the directory listing.

### PoC

- Serve a directory (web root) with SWS.
- Create a symlink inside the web root that points to a file outside the web root.
  e.g. `ln -s escape.txt $HOME/.bashrc`
- Open `http://localhost/escape.txt` in your browser.
- The file content will be served.

### Impact

Any web server that runs with elevated privileges (e.g., root/administrator) and handles user-supplied file uploads is primarily impacted.