deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-84m6-5m72-45fp
Package: apollo-router (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 2.0.0-alpha.0, < 2.1.1
Patched in: 2.1.1

Summary: Apollo Router Operation Limits Vulnerable to Bypass via Integer Overflow

Details:
# Impact

## Summary

A vulnerability in Apollo Router allowed certain queries to bypass configured operation limits, specifically due to integer overflow.

## Details

The operation limits plugin uses unsigned 32-bit integers to track limit counters (e.g. for a query's height). If a counter exceeded the maximum value for this data type (4,294,967,295), it wrapped around to 0, unintentionally allowing queries to bypass configured thresholds. This could occur for large queries if the payload limit were sufficiently increased, but could also occur for small queries with deeply nested and reused named fragments.

## Fix/Mitigation

Logic was updated to ensure counter overflow is handled correctly and does not wrap around to 0.

# Patches

This has been remediated in `apollo-router` versions 1.61.2 and 2.1.1.

# Workarounds

The only known workaround is "Safelisting" or "Safelisting with IDs only" per [Safelisting with Persisted Queries - Apollo GraphQL Docs](https://www.apollographql.com/docs/graphos/routing/security/persisted-queries#router-security-levels).

## Acknowledgements

We appreciate the efforts of the security community in identifying and improving the performance and security of operation limiting mechanisms.
GitHub Security Advisory: GHSA-84m6-5m72-45fp
Package: apollo-router (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 1.61.2
Patched in: 1.61.2

Summary: Apollo Router Operation Limits Vulnerable to Bypass via Integer Overflow

Details:
# Impact

## Summary

A vulnerability in Apollo Router allowed certain queries to bypass configured operation limits, specifically due to integer overflow.

## Details

The operation limits plugin uses unsigned 32-bit integers to track limit counters (e.g. for a query's height). If a counter exceeded the maximum value for this data type (4,294,967,295), it wrapped around to 0, unintentionally allowing queries to bypass configured thresholds. This could occur for large queries if the payload limit were sufficiently increased, but could also occur for small queries with deeply nested and reused named fragments.

## Fix/Mitigation

Logic was updated to ensure counter overflow is handled correctly and does not wrap around to 0.

# Patches

This has been remediated in `apollo-router` versions 1.61.2 and 2.1.1.

# Workarounds

The only known workaround is "Safelisting" or "Safelisting with IDs only" per [Safelisting with Persisted Queries - Apollo GraphQL Docs](https://www.apollographql.com/docs/graphos/routing/security/persisted-queries#router-security-levels).

## Acknowledgements

We appreciate the efforts of the security community in identifying and improving the performance and security of operation limiting mechanisms.
GitHub Security Advisory: GHSA-75m2-jhh5-j5g2
Package: apollo-router (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 2.0.0-alpha.0, < 2.1.1
Patched in: 2.1.1

Summary: Apollo Router Query Planner Vulnerable to Excessive Resource Consumption via Named Fragment Expansion

Details:
# Impact

## Summary

A vulnerability in Apollo Router allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically during named fragment expansion. This could lead to excessive resource consumption and denial of service.

## Details

Named fragments were being expanded once per fragment spread during query planning, leading to exponential resource usage when deeply nested and reused fragments were involved.

## Fix/Mitigation

A new **Query Fragment Expansion Limit** metric has been introduced:
  - This metric computes the number of selections a query would have if its fragment spreads were fully expanded.
  - The metric is checked against a limit to prevent excessive computation.

# Patches

This has been remediated in `apollo-router` versions 1.61.2 and 2.1.1.

# Workarounds

The only known workaround is "Safelisting" or "Safelisting with IDs only" per [Safelisting with Persisted Queries - Apollo GraphQL Docs](https://www.apollographql.com/docs/graphos/routing/security/persisted-queries#router-security-levels).

# References

[Query Planning Documentation](https://www.apollographql.com/docs/graphos/reference/federation/query-plans)

## Acknowledgements

We appreciate the efforts of the security community in identifying and improving the performance and security of query planning mechanisms.
GitHub Security Advisory: GHSA-75m2-jhh5-j5g2
Package: apollo-router (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.61.2
Patched in: 1.61.2

Summary: Apollo Router Query Planner Vulnerable to Excessive Resource Consumption via Named Fragment Expansion

Details:
# Impact

## Summary

A vulnerability in Apollo Router allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically during named fragment expansion. This could lead to excessive resource consumption and denial of service.

## Details

Named fragments were being expanded once per fragment spread during query planning, leading to exponential resource usage when deeply nested and reused fragments were involved.

## Fix/Mitigation

A new **Query Fragment Expansion Limit** metric has been introduced:
  - This metric computes the number of selections a query would have if its fragment spreads were fully expanded.
  - The metric is checked against a limit to prevent excessive computation.

# Patches

This has been remediated in `apollo-router` versions 1.61.2 and 2.1.1.

# Workarounds

The only known workaround is "Safelisting" or "Safelisting with IDs only" per [Safelisting with Persisted Queries - Apollo GraphQL Docs](https://www.apollographql.com/docs/graphos/routing/security/persisted-queries#router-security-levels).

# References

[Query Planning Documentation](https://www.apollographql.com/docs/graphos/reference/federation/query-plans)

## Acknowledgements

We appreciate the efforts of the security community in identifying and improving the performance and security of query planning mechanisms.
GitHub Security Advisory: GHSA-94hh-jmq8-2fgp
Package: apollo-router (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 2.0.0-alpha.0, < 2.1.1
Patched in: 2.1.1

Summary: Apollo Router Query Planner Vulnerable to Excessive Resource Consumption via Optimization Bypass

Details:
# Impact

## Summary

A vulnerability in Apollo Router allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically due to internal optimizations being frequently bypassed. This could lead to excessive resource consumption and denial of service.

## Details

The query planner includes an optimization that significantly speeds up planning for applicable GraphQL selections. However, queries with deeply nested and reused named fragments can generate many selections where this optimization does not apply, leading to significantly longer planning times. Because the query planner does not enforce a timeout, a small number of such queries can exhaust router's thread pool, rendering it inoperable.

## Fix/Mitigation

- A new **Query Optimization Limit** metric has been added:
  - This metric approximates the number of selections that cannot be skipped by the existing optimization.
  - The metric is checked against a limit to prevent excessive computation.

Given the complexity of query planning optimizations, we will continue refining these solutions based on real-world performance and accuracy tests.

# Patches

This has been remediated in `apollo-router` versions 1.61.2 and 2.1.1.

# Workarounds

The only known workaround is "Safelisting" or "Safelisting with IDs only" per [Safelisting with Persisted Queries - Apollo GraphQL Docs](https://www.apollographql.com/docs/graphos/routing/security/persisted-queries#router-security-levels).

# References

[Query Planning Documentation](https://www.apollographql.com/docs/graphos/reference/federation/query-plans)

## Acknowledgements

We appreciate the efforts of the security community in identifying and improving the performance and security of query planning mechanisms.
GitHub Security Advisory: GHSA-94hh-jmq8-2fgp
Package: apollo-router (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.61.2
Patched in: 1.61.2

Summary: Apollo Router Query Planner Vulnerable to Excessive Resource Consumption via Optimization Bypass

Details:
# Impact

## Summary

A vulnerability in Apollo Router allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically due to internal optimizations being frequently bypassed. This could lead to excessive resource consumption and denial of service.

## Details

The query planner includes an optimization that significantly speeds up planning for applicable GraphQL selections. However, queries with deeply nested and reused named fragments can generate many selections where this optimization does not apply, leading to significantly longer planning times. Because the query planner does not enforce a timeout, a small number of such queries can exhaust router's thread pool, rendering it inoperable.

## Fix/Mitigation

- A new **Query Optimization Limit** metric has been added:
  - This metric approximates the number of selections that cannot be skipped by the existing optimization.
  - The metric is checked against a limit to prevent excessive computation.

Given the complexity of query planning optimizations, we will continue refining these solutions based on real-world performance and accuracy tests.

# Patches

This has been remediated in `apollo-router` versions 1.61.2 and 2.1.1.

# Workarounds

The only known workaround is "Safelisting" or "Safelisting with IDs only" per [Safelisting with Persisted Queries - Apollo GraphQL Docs](https://www.apollographql.com/docs/graphos/routing/security/persisted-queries#router-security-levels).

# References

[Query Planning Documentation](https://www.apollographql.com/docs/graphos/reference/federation/query-plans)

## Acknowledgements

We appreciate the efforts of the security community in identifying and improving the performance and security of query planning mechanisms.
GitHub Security Advisory: GHSA-794x-2rpg-rfgr
Package: jj-cli (RUST)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-328: Use of Weak Hash
Vulnerable versions: < 0.28.1
Patched in: 0.28.1

Summary: Jujutsu does not have SHA-1 collision detection

Details:
### Summary
Jujutsu 0.28.0 and earlier rely on versions of gitoxide that use SHA-1 hash implementations without any collision detection, leaving them vulnerable to hash collision attacks.

### Details
This is a result of the underlying [CVE-2025-31130 / GHSA-2frx-2596-x5r6](https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-2frx-2596-x5r6) vulnerability in the gitoxide library Jujutsu uses to interact with Git repositories; see that advisory for technical details. This separate advisory is being issued due to the downstream impact on users of Jujutsu.

### Impact
An attacker with the ability to mount a collision attack on SHA-1 like the [SHAttered](https://shattered.io/) or [SHA-1 is a Shambles](https://sha-mbles.github.io/) attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in Jujutsu’s logic to cause further vulnerabilities.
GitHub Security Advisory: GHSA-794x-2rpg-rfgr
Package: jj-lib (RUST)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-328: Use of Weak Hash
Vulnerable versions: < 0.28.1
Patched in: 0.28.1

Summary: Jujutsu does not have SHA-1 collision detection

Details:
### Summary
Jujutsu 0.28.0 and earlier rely on versions of gitoxide that use SHA-1 hash implementations without any collision detection, leaving them vulnerable to hash collision attacks.

### Details
This is a result of the underlying [CVE-2025-31130 / GHSA-2frx-2596-x5r6](https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-2frx-2596-x5r6) vulnerability in the gitoxide library Jujutsu uses to interact with Git repositories; see that advisory for technical details. This separate advisory is being issued due to the downstream impact on users of Jujutsu.

### Impact
An attacker with the ability to mount a collision attack on SHA-1 like the [SHAttered](https://shattered.io/) or [SHA-1 is a Shambles](https://sha-mbles.github.io/) attacks could create two distinct Git objects with the same hash. This is becoming increasingly affordable for well‐resourced attackers, with the Shambles researchers in 2020 estimating $45k for a chosen‐prefix collision or $11k for a classical collision, and projecting less than $10k for a chosen‐prefix collision by 2025. The result could be used to disguise malicious repository contents, or potentially exploit assumptions in Jujutsu’s logic to cause further vulnerabilities.
GitHub Security Advisory: GHSA-4fcv-w3qc-ppgg
Package: openssl (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.10.39, < 0.10.72
Patched in: 0.10.72

Summary: rust-openssl Use-After-Free in `Md::fetch` and `Cipher::fetch`

Details:
When a `Some(...)` value was passed to the `properties` argument of either of these functions, a use-after-free would result.

In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to `CString::drop`'s behavior).

The maintainers thank [quitbug](https://github.com/quitbug/) for reporting this vulnerability to us.
GitHub Security Advisory: GHSA-c9pr-q8gx-3mgp
Package: tauri-plugin-shell (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 2.2.1
Patched in: 2.2.1

Summary: Improper Scope Validation in the `open` Endpoint of `tauri-plugin-shell`

Details:
### Impact

The Tauri [`shell`](https://tauri.app/plugin/shell/)  plugin exposes functionality to execute code and open programs on the system. The [`open`](https://tauri.app/reference/javascript/shell/#open) endpoint of this plugin is designed to allow open functionality with the system opener (e.g. 
 `xdg-open` on Linux). This was meant to be restricted to a reasonable number of protocols like `https` or `mailto` by default.

This default restriction was not functional due to improper validation of the allowed protocols, allowing for potentially dangerous protocols like `file://`, `smb://`, or `nfs://` and others  to be opened by the system registered protocol handler.

By passing untrusted user input to the `open` endpoint these potentially dangerous protocols can be abused to gain remote code execution on the system. This either requires direct exposure of the endpoint to application users or code execution in the frontend of a Tauri application.

You are not affected if you have explicitly configured a validation regex or manually set the `open` endpoint to `true` in the plugin configuration. 

Technically the scope was never a limitation for the rust side as it is not seen as an enforceable security boundary but we decided to mark the rust crate as affected since the plugin does not need to be a frontend dependency to be exposed.

### Patches

The issue has been patched in the `2.2.1` version of the plugin.
The plugin now differentiates between an unset scope and an explicit validation disable for the `open` endpoint.

### Workarounds 

A way to prevent arbitrary protocols would be setting the shell plugin configuration value `open` to `true`.

`tauri.conf.json`
```json5 
"plugins": {
    "shell": {
          "open": true
     },
}
```

The above will only allow `mailto`, `http` and `https` links to be opened.

If the `open` endpoint should not be allowed at all there are two possible workarounds.
- Defining a non matching regex like `tauri^` in the plugin configuration
- Removing `shell:default` and all instances of `shell:allow-open` from the [`capabilities`](https://tauri.app/security/capabilities/) 

Alternatively we recommend usage of the [`opener`](https://tauri.app/plugin/opener/)  plugin, as the shell plugin deprecated the `open` endpoint previously.
### References

#### PoC

This is a windows specific proof of concept.

1. Use `create-tauri-app` to make a new Tauri app.
2. Run `tauri add shell` to add the shell plugin.
3. Execute `await window.__TAURI_INTERNALS__.invoke("plugin:shell|open", {path: "file:///c:/windows/system32/calc.exe"});` in the developer console.
4. Observe the calculator being executed
GitHub Security Advisory: GHSA-pph8-gcv7-4qj5
Package: pyo3 (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: >= 0.1.0, < 0.24.1
Patched in: 0.24.1

Summary: PyO3 Risk of buffer overflow in `PyString::from_object`

Details:
`PyString::from_object` took `&str` arguments and forwarded them directly to the Python C API without checking for terminating nul bytes. This could lead the Python interpreter to read beyond the end of the `&str` data and potentially leak contents of the out-of-bounds read (by raising a Python exception containing a copy of the data including the overflow).

In PyO3 0.24.1 this function will now allocate a `CString` to guarantee a terminating nul bytes. PyO3 0.25 will likely offer an alternative API which takes `&CStr` arguments.
GitHub Security Advisory: GHSA-6xfj-hhwh-r3c2
Package: ouch (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: Ouch Improper Restriction of Operations within the Bounds of a Memory Buffer vulnerability

Details:
A vulnerability was found in ouch-org ouch up to 0.3.1. It has been classified as critical. This affects the function ouch::archive::zip::convert_zip_date_time of the file zip.rs. The manipulation of the argument month leads to memory corruption. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 0.4.0 is able to address this issue. It is recommended to upgrade the affected component.
GitHub Security Advisory: GHSA-67r5-rqwv-9p9q
Package: array-init-cursor (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: < 0.2.1
Patched in: 0.2.1

Summary: array-init-cursor is unsound when used with types that implement `Drop`

Details:
The `Drop` implementation will get run twice when using the cursor.

This issue does not affect you, if you are using only using the crate with types that are `Copy` such as `u8`.

This issue also does not affect you, if you are only depending on it through the crate `planus`.
GitHub Security Advisory: GHSA-j8x2-777p-23fc
Package: tough (RUST)
Severity: LOW (CVSS 2.7)
Vulnerable versions: < 0.20.0
Patched in: 0.20.0

Summary: tough cyclic delegation graphs are not detected

Details:
## Summary

In a TUF repository, the targets role’s signature indicates which target files are trusted by clients. The role can delegate full or partial trust to other roles, meaning that that role is trusted to sign target file metadata. Delegated roles can further delegate trust to other delegated roles. When searching for metadata about a given target, tough failed to detect cyclical role delegations.

## Impact

When interacting with TUF repositories which contain cyclical role delegations, tough will fail to detect the cycles and will exhaust its stack while recursively searching the delegation graph. The exhausted call stack will cause the process to abort.

Impacted versions: < v0.20.0

## Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

## Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

## References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.


[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

## Acknowledgement

These issues were identified by the [TUF-Conformance project](https://github.com/theupdateframework/tuf-conformance). We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.
GitHub Security Advisory: GHSA-v4wr-j3w6-mxqc
Package: tough (RUST)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-670: Always-Incorrect Control Flow Implementation
Vulnerable versions: < 0.20.0
Patched in: 0.20.0

Summary: tough terminating targets role delegations are not respected

Details:
## Summary

Delegations are a mechanism defined by the TUF specification that allow multiple different identities to provide and sign content within a single repository. Terminating delegations and delegation priority give a TUF repository unambiguous control over how overlapping delegations are resolved. tough erroneously will not terminate a search as required, and will accept information from a lower-priority delegation that should have been ignored.

## Impact

When interacting with TUF repositories that use delegations, the tough client could fetch targets owned by the incorrect role. An actor which had delegated ownership of a subset of a TUF repository could provide arbitrary contents to tough clients for targets owned by the delegating identity.

Impacted versions: < v0.20.0

## Patches

A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes.

## Workarounds

There is no recommended work around. Customers are advised to upgrade to version 0.20.0 or the latest version.

## References

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page [1] or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.


[1] Vulnerability reporting page: https://aws.amazon.com/security/vulnerability-reporting

## Acknowledgement

These issues were identified by the [TUF-Conformance project](https://github.com/theupdateframework/tuf-conformance). We would like to thank Google for collaborating on this issue through the coordinated vulnerability disclosure process.