deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-m7rc-8w7m-r9qr
Package: surrealdb (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: < 2.0.5
Patched in: 2.0.5

Summary: SurrealDB vulnerable to memory exhaustion via nested functions and scripts

Details:
In order to prevent DoS situations due to infinite recursions, SurrealDB implements a limit of nested calls for both native functions and embedded JavaScript functions.

However, in SurrealDB instances with embedded scripting functions enabled, it was found that this limit can be circumvented by utilizing both at the same time. If a native function contains JavaScript which issues a new query that calls that function, the recursion limit is not triggered.

Once executed, SurrealDB will follow the path of infinite recursions until the system runs out of memory, prior to the recursion limit being triggered.

This vulnerability can only affect SurrealDB servers explicitly enabling the scripting capability with `--allow-scripting` or 
`--allow-all` and equivalent environment variables `SURREAL_CAPS_ALLOW_SCRIPT=true` and `SURREAL_CAPS_ALLOW_ALL=true`.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Medium, matched by our CVSS v4 assessment.

### Impact
For SurrealDB instances with embedded scripting functions enabled, this attack could be used to perform a DoS attack on the server by an authenticated user. 

### Patches
A patch has been created that further limits scripting function call limit recursion depth and disallows multiple calls to `surreadb.query()` to run in parallel in a scripting function.

- Versions 2.0.5, 2.1.5, 2.2.2 and later are not affected by this issue.

### Workarounds
Deny execution of embedded scripting functions through the configuration of [capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#capabilities) by starting SurrealDB with the `--deny-scripting` flag or the equivalent environment variable `SURREAL_CAPS_DENY_SCRIPT=true`. This has a usability implication, although scripting functions are disabled by default.

### References
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities)
[SurrealQL Documentation - Scripting Functions](https://surrealdb.com/docs/surrealql/functions/script)
GitHub Security Advisory: GHSA-m7rc-8w7m-r9qr
Package: surrealdb (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: >= 2.1.0, < 2.1.5
Patched in: 2.1.5

Summary: SurrealDB vulnerable to memory exhaustion via nested functions and scripts

Details:
In order to prevent DoS situations due to infinite recursions, SurrealDB implements a limit of nested calls for both native functions and embedded JavaScript functions.

However, in SurrealDB instances with embedded scripting functions enabled, it was found that this limit can be circumvented by utilizing both at the same time. If a native function contains JavaScript which issues a new query that calls that function, the recursion limit is not triggered.

Once executed, SurrealDB will follow the path of infinite recursions until the system runs out of memory, prior to the recursion limit being triggered.

This vulnerability can only affect SurrealDB servers explicitly enabling the scripting capability with `--allow-scripting` or 
`--allow-all` and equivalent environment variables `SURREAL_CAPS_ALLOW_SCRIPT=true` and `SURREAL_CAPS_ALLOW_ALL=true`.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Medium, matched by our CVSS v4 assessment.

### Impact
For SurrealDB instances with embedded scripting functions enabled, this attack could be used to perform a DoS attack on the server by an authenticated user. 

### Patches
A patch has been created that further limits scripting function call limit recursion depth and disallows multiple calls to `surreadb.query()` to run in parallel in a scripting function.

- Versions 2.0.5, 2.1.5, 2.2.2 and later are not affected by this issue.

### Workarounds
Deny execution of embedded scripting functions through the configuration of [capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#capabilities) by starting SurrealDB with the `--deny-scripting` flag or the equivalent environment variable `SURREAL_CAPS_DENY_SCRIPT=true`. This has a usability implication, although scripting functions are disabled by default.

### References
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities)
[SurrealQL Documentation - Scripting Functions](https://surrealdb.com/docs/surrealql/functions/script)
GitHub Security Advisory: GHSA-m7rc-8w7m-r9qr
Package: surrealdb (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: >= 2.2.0, < 2.2.2
Patched in: 2.2.2

Summary: SurrealDB vulnerable to memory exhaustion via nested functions and scripts

Details:
In order to prevent DoS situations due to infinite recursions, SurrealDB implements a limit of nested calls for both native functions and embedded JavaScript functions.

However, in SurrealDB instances with embedded scripting functions enabled, it was found that this limit can be circumvented by utilizing both at the same time. If a native function contains JavaScript which issues a new query that calls that function, the recursion limit is not triggered.

Once executed, SurrealDB will follow the path of infinite recursions until the system runs out of memory, prior to the recursion limit being triggered.

This vulnerability can only affect SurrealDB servers explicitly enabling the scripting capability with `--allow-scripting` or 
`--allow-all` and equivalent environment variables `SURREAL_CAPS_ALLOW_SCRIPT=true` and `SURREAL_CAPS_ALLOW_ALL=true`.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Medium, matched by our CVSS v4 assessment.

### Impact
For SurrealDB instances with embedded scripting functions enabled, this attack could be used to perform a DoS attack on the server by an authenticated user. 

### Patches
A patch has been created that further limits scripting function call limit recursion depth and disallows multiple calls to `surreadb.query()` to run in parallel in a scripting function.

- Versions 2.0.5, 2.1.5, 2.2.2 and later are not affected by this issue.

### Workarounds
Deny execution of embedded scripting functions through the configuration of [capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#capabilities) by starting SurrealDB with the `--deny-scripting` flag or the equivalent environment variable `SURREAL_CAPS_DENY_SCRIPT=true`. This has a usability implication, although scripting functions are disabled by default.

### References
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities)
[SurrealQL Documentation - Scripting Functions](https://surrealdb.com/docs/surrealql/functions/script)
GitHub Security Advisory: GHSA-rq86-9m6r-cm3g
Package: surrealdb (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: < 2.0.5
Patched in: 2.0.5

Summary: SurrealDB has uncaught exception in Net module that leads to database crash

Details:
A vulnerability was found where an attacker can crash the database via crafting a HTTP query that returns a null byte. The problem relies on an uncaught exception in the `net` module, where the result of the query will be converted to JSON before showing as the HTTP response to the user in the **/sql** endpoint.

### Impact
This vulnerability allows any authenticated user to crash a SurrealDB instance by sending a crafted query with a null byte to the /sql endpoint. 

Where SurrealDB is used as an application backend, it is possible that an application user can crash the SurrealDB instance and thus the supported application through crafted inputs that exploit this attack vector.


### Patches
A patch has been introduced that ensures the error is caught and converted as an error.
- Versions 2.2.2, 2.1.5 and 2.0.5 and later are not affected by this isssue

### Workarounds

Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

Where SurrealDB is used as an application backend, ensure sanitisation of input at the application layer to prevent injection attacks.

### References
https://github.com/surrealdb/surrealdb/pull/5647
GitHub Security Advisory: GHSA-rq86-9m6r-cm3g
Package: surrealdb (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: >= 2.1.0, < 2.1.5
Patched in: 2.1.5

Summary: SurrealDB has uncaught exception in Net module that leads to database crash

Details:
A vulnerability was found where an attacker can crash the database via crafting a HTTP query that returns a null byte. The problem relies on an uncaught exception in the `net` module, where the result of the query will be converted to JSON before showing as the HTTP response to the user in the **/sql** endpoint.

### Impact
This vulnerability allows any authenticated user to crash a SurrealDB instance by sending a crafted query with a null byte to the /sql endpoint. 

Where SurrealDB is used as an application backend, it is possible that an application user can crash the SurrealDB instance and thus the supported application through crafted inputs that exploit this attack vector.


### Patches
A patch has been introduced that ensures the error is caught and converted as an error.
- Versions 2.2.2, 2.1.5 and 2.0.5 and later are not affected by this isssue

### Workarounds

Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

Where SurrealDB is used as an application backend, ensure sanitisation of input at the application layer to prevent injection attacks.

### References
https://github.com/surrealdb/surrealdb/pull/5647
GitHub Security Advisory: GHSA-rq86-9m6r-cm3g
Package: surrealdb (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-248: Uncaught Exception
Vulnerable versions: >= 2.2.0, < 2.2.2
Patched in: 2.2.2

Summary: SurrealDB has uncaught exception in Net module that leads to database crash

Details:
A vulnerability was found where an attacker can crash the database via crafting a HTTP query that returns a null byte. The problem relies on an uncaught exception in the `net` module, where the result of the query will be converted to JSON before showing as the HTTP response to the user in the **/sql** endpoint.

### Impact
This vulnerability allows any authenticated user to crash a SurrealDB instance by sending a crafted query with a null byte to the /sql endpoint. 

Where SurrealDB is used as an application backend, it is possible that an application user can crash the SurrealDB instance and thus the supported application through crafted inputs that exploit this attack vector.


### Patches
A patch has been introduced that ensures the error is caught and converted as an error.
- Versions 2.2.2, 2.1.5 and 2.0.5 and later are not affected by this isssue

### Workarounds

Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

Where SurrealDB is used as an application backend, ensure sanitisation of input at the application layer to prevent injection attacks.

### References
https://github.com/surrealdb/surrealdb/pull/5647
GitHub Security Advisory: GHSA-6jrf-4jv4-r9mw
Package: tendermint-light-client-verifier (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 0.40.3
Patched in: 0.40.3

Summary: tendermint-rs's Light Client Verifier allows malicious validators to spoof votes from other validators 

Details:
Name: ISA-2025-003: Malicious validator can spoof votes from other validators 
Component: tendermint-rs
Criticality: High (Catastrophic Impact; Rare Likelihood per [ACMv1.2](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md))
Affected versions: <= v0.40.2
Affected users: Everyone

### Description

tendermint-rs contains a critical vulnerability in its light client implementation due to insecure handling of corrupted validator sets. Because it doesn't check that the validator address is correctly derived from the validator's public key when counting votes, it is possible to spoof votes from other validators. The result is being able to construct the malicious block and cheat the light client. The light client will accept such a block, seemingly signed by 2/3+ majority.

### Patches

The new tendermint-rs release [v0.40.3](https://github.com/informalsystems/tendermint-rs/releases/tag/v0.40.3) fixes this issue.

Unreleased code in the main branch is patched as well.

### Workarounds

There are no known workarounds for this issue.

### Timeline

* March 12, 2025, 13:41pm PST: Issue reported
* March 12, 2025, 03:00am PST: Core team completes validation of issue

This issue was reported by Felix Wilhelm from [Asymmetric Research](https://www.asymmetric.re/).
GitHub Security Advisory: GHSA-wr2m-38xh-rpc9
Package: lemmy_server (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-708: Incorrect Ownership Assignment
Vulnerable versions: >= 0.17.0, < 0.19.11
Patched in: 0.19.11

Summary: Lemmy user purging users or communities or banning users can delete images they didn't upload/exclusively use

Details:
### Summary
An improper uploaded media ownership check can result in inadvertent deletion of media when a user is banned with content removal or purged. This can lead to deletion of media that was not uploaded by the banned/purged user. This also applies to purged communities, in which case all media posted in that community will get deleted without proper ownership check.
This is limited to media with an `image/*` content-type returned by pict-rs.

### Details
Lemmy did not associate users with media uploads until version 0.19.0 ([#3927](https://github.com/LemmyNet/lemmy/pull/3927)).
Back when the first parts of content purging were implemented for 0.17.0 ([#1809](https://github.com/LemmyNet/lemmy/pull/1809)), it was therefore not possible to properly identify media belonging to a specific user for situations in which this data should get erased from pict-rs, Lemmy's media storage backend.

Pict-rs deduplicates uploaded files transparently. As a result, it has two types of media deletion. A regular deletion will only remove the referenced alias, and if there are not other aliases pointing to the same file, the backing file will also be deleted. A purge on the other hand will delete all aliases pointing to the specified file, as well as the file itself.

The logic implemented in 0.17.0 iterated over media URLs related to users and communities when purging them and purged them from pict-rs. This results in a full deletion of the backing media, even if either the same URL was the result of an upload by a different user, or the same media being uploaded by another user with a different alias.
For user purges, Lemmy iterated over all posts they created and applied this to all media referenced in post URLs and post thumbnails. For community purges, this applied to all posts within this community.

Additionally, the deletion of user avatars, banners, as well as the media from all their posts was implemented when users were banned with content removal. This includes local bans and also bans received via federation, when a user gets banned on their home instance.

The function for purging images from pict-rs performs a check at the start to verify that the media `Content-Type` header returned by pict-rs starts with `image/`, which limits this to not affect other media types supported by Lemmy and pict-rs, such as videos.

### Impact

#### Instances with open federation
The vast majority of Lemmy instances has open federation, which means that this can be exploited remotely without any authentication.

#### Instances with limited or no federation
Exploitation requires user interaction by an admin of the targeted instance or a federation-linked instance if federation is enabled.
It may also require authentication, as instances may not have open registrations.
GitHub Security Advisory: GHSA-rr8g-9fpq-6wmg
Package: tokio (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-664: Improper Control of a Resource Through its Lifetime
Vulnerable versions: >= 1.39.0, < 1.43.1
Patched in: 1.43.1

Summary: Tokio broadcast channel calls clone in parallel, but does not require `Sync`

Details:
The broadcast channel internally calls `clone` on the stored value when receiving it, and only requires `T:Send`. This means that using the broadcast channel with values that are `Send` but not `Sync` can trigger unsoundness if the `clone` implementation makes use of the value being `!Sync`.

Thank you to Austin Bonander for finding and reporting this issue.
GitHub Security Advisory: GHSA-rr8g-9fpq-6wmg
Package: tokio (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-664: Improper Control of a Resource Through its Lifetime
Vulnerable versions: >= 0.2.5, < 1.38.2
Patched in: 1.38.2

Summary: Tokio broadcast channel calls clone in parallel, but does not require `Sync`

Details:
The broadcast channel internally calls `clone` on the stored value when receiving it, and only requires `T:Send`. This means that using the broadcast channel with values that are `Send` but not `Sync` can trigger unsoundness if the `clone` implementation makes use of the value being `!Sync`.

Thank you to Austin Bonander for finding and reporting this issue.
GitHub Security Advisory: GHSA-rr8g-9fpq-6wmg
Package: tokio (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-664: Improper Control of a Resource Through its Lifetime
Vulnerable versions: >= 1.44.0, < 1.44.2
Patched in: 1.44.2

Summary: Tokio broadcast channel calls clone in parallel, but does not require `Sync`

Details:
The broadcast channel internally calls `clone` on the stored value when receiving it, and only requires `T:Send`. This means that using the broadcast channel with values that are `Send` but not `Sync` can trigger unsoundness if the `clone` implementation makes use of the value being `!Sync`.

Thank you to Austin Bonander for finding and reporting this issue.
GitHub Security Advisory: GHSA-7mpv-9xg6-5r79
Package: apollo-compiler (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.27.0
Patched in: 1.27.0

Summary: Apollo Compiler Named Fragment Processing Vulnerability

Details:
# Impact

## Summary

A vulnerability in Apollo Compiler allowed queries with deeply nested and reused named fragments to be prohibitively expensive to validate. This could lead to excessive resource consumption and denial of service in applications.

## Details

Named fragments were being processed once per fragment spread in some cases during query validation, leading to exponential resource usage when deeply nested and reused fragments were involved.

## Fix/Mitigation

The validation logic has been updated to process each named fragment only once, preventing redundant traversal.

# Patches
This has been remediated in `apollo-compiler` version 1.27.0.

# Workarounds
No known direct workarounds exist.

## Acknowledgements
We appreciate the efforts of the security community in identifying and improving the performance and security of query validation mechanisms.
GitHub Security Advisory: GHSA-3j43-9v8v-cp3f
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 Validation Vulnerable to Excessive Resource Consumption via Named Fragment Processing

Details:
# Impact

## Summary

A vulnerability in Apollo Router's usage of Apollo Compiler allowed queries with deeply nested and reused named fragments to be prohibitively expensive to validate. This could lead to excessive resource consumption and denial of service.

## Details

Named fragments were being processed once per fragment spread in some cases during query validation, leading to exponential resource usage when deeply nested and reused fragments were involved.

## Fix/Mitigation

Apollo Router's usage of Apollo Compiler has been updated so that validation logic processes each named fragment only once, preventing redundant traversal.

# Patches

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

# Workarounds
The only known workaround is "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). The "Safelisting" security level is not sufficient, since that level allows freeform GraphQL queries to be sent to Apollo Router.

# 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 validation mechanisms.
GitHub Security Advisory: GHSA-3j43-9v8v-cp3f
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 Validation Vulnerable to Excessive Resource Consumption via Named Fragment Processing

Details:
# Impact

## Summary

A vulnerability in Apollo Router's usage of Apollo Compiler allowed queries with deeply nested and reused named fragments to be prohibitively expensive to validate. This could lead to excessive resource consumption and denial of service.

## Details

Named fragments were being processed once per fragment spread in some cases during query validation, leading to exponential resource usage when deeply nested and reused fragments were involved.

## Fix/Mitigation

Apollo Router's usage of Apollo Compiler has been updated so that validation logic processes each named fragment only once, preventing redundant traversal.

# Patches

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

# Workarounds
The only known workaround is "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). The "Safelisting" security level is not sufficient, since that level allows freeform GraphQL queries to be sent to Apollo Router.

# 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 validation mechanisms.