deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-mr34-8733-grr2
Package: github.com/usememos/memos (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: <= 0.18.1
Patched in: 0.18.2

Summary: Memos' Access Tokens Stay Valid after User Password Change

Details:
### Summary
Access Tokens are used to authenticate application access. When a user changes their password, the existing list of Access Tokens stay valid instead of expiring. If a user finds that their account has been compromised, they can update their password. 

The bad actor though will still have access to their account because the bad actor's Access Token stays on the list as a valid token. The user will have to manually delete the bad actor's Access Token to secure their account. The list of Access Tokens has a generic Description which makes it hard to pinpoint a bad actor in a list of Access Tokens. 

### Details

To improve Memos security, all Access Tokens will need to be revoked when a user changes their password. This removes the session for all the user's devices and prompts the user to log in again. You can treat the old Access Tokens as "invalid" because those Access Tokens were created with the older password.

### PoC

1. Have 2 devices on hand
2. Log onto your Memos account on both devices. Notice how Access Tokens are created for each.
3. On one device, successfully change the password. Refresh the page on the 2nd device and notice how it doesn't log out the user.
4. On the 2nd device, change the password again. Refresh the page on the 1st device and notice how it doesn't log out the user.

### Impact

A bad actor will still have access to the user's account because the Access Token does not expire on a password update. Having multi-factor authentication will vastly improve account security in Account Takeover cases instead of just relying on a password.
GitHub Security Advisory: GHSA-vv3h-7qwr-722v
Package: github.com/anyproto/anytype-cli (GO)
Severity: LOW (CVSS 3.6)
CWE: CWE-307: Improper Restriction of Excessive Authentication Attempts
Vulnerable versions: < 0.1.11
Patched in: 0.1.11

Summary: Anytype Heart's gRPC API client challenge verification can be bypassed on localhost

Details:
#### Impact
The challenge-based authentication for the local gRPC client API can be bypassed, allowing an attacker to gain access without the 4-digit code.

Affected components:
- Anytype Desktop (all platforms) ≤ v0.48.2
- Anytype-CLI (headless deployments) ≤ v0.1.9

Not affected:
- Anytype mobile apps (iOS, Android) - do not expose a local gRPC server

Who is impacted:
This vulnerability is scoped to localhost. The gRPC and gRPC-Web ports bind to 127.0.0.1 only and are not exposed to the local network or internet.

### Exploitation requires:
- Local user-level access to the machine running Anytype
- Discovery of the randomized listening port
- A running Anytype instance

Anytype-CLI headless deployments may be at higher risk only if an administrator has chosen to set up their own reverse proxy and configured it in a way that
exposes gRPC or gRPC-Web ports to an external network. **By default, these ports are not externally accessible and there is no built-in mechanism to expose them.**

#### Patches
- anytype-heart library: v0.48.4
- [Anytype Desktop](https://github.com/anyproto/anytype-ts): v0.54.5
- [Anytype-CLI](https://github.com/anyproto/anytype-cli): v0.1.11

#### Workarounds
- Desktop users: No immediate action required. The vulnerability requires existing local access to the machine.
- Anytype-CLI administrators: If using a custom reverse proxy, ensure it does not expose gRPC or gRPC-Web ports to external networks.
GitHub Security Advisory: GHSA-vv3h-7qwr-722v
Package: github.com/anyproto/anytype-heart (GO)
Severity: LOW (CVSS 3.6)
CWE: CWE-307: Improper Restriction of Excessive Authentication Attempts
Vulnerable versions: < 0.48.4
Patched in: 0.48.4

Summary: Anytype Heart's gRPC API client challenge verification can be bypassed on localhost

Details:
#### Impact
The challenge-based authentication for the local gRPC client API can be bypassed, allowing an attacker to gain access without the 4-digit code.

Affected components:
- Anytype Desktop (all platforms) ≤ v0.48.2
- Anytype-CLI (headless deployments) ≤ v0.1.9

Not affected:
- Anytype mobile apps (iOS, Android) - do not expose a local gRPC server

Who is impacted:
This vulnerability is scoped to localhost. The gRPC and gRPC-Web ports bind to 127.0.0.1 only and are not exposed to the local network or internet.

### Exploitation requires:
- Local user-level access to the machine running Anytype
- Discovery of the randomized listening port
- A running Anytype instance

Anytype-CLI headless deployments may be at higher risk only if an administrator has chosen to set up their own reverse proxy and configured it in a way that
exposes gRPC or gRPC-Web ports to an external network. **By default, these ports are not externally accessible and there is no built-in mechanism to expose them.**

#### Patches
- anytype-heart library: v0.48.4
- [Anytype Desktop](https://github.com/anyproto/anytype-ts): v0.54.5
- [Anytype-CLI](https://github.com/anyproto/anytype-cli): v0.1.11

#### Workarounds
- Desktop users: No immediate action required. The vulnerability requires existing local access to the machine.
- Anytype-CLI administrators: If using a custom reverse proxy, ensure it does not expose gRPC or gRPC-Web ports to external networks.
GitHub Security Advisory: GHSA-g32c-4pvp-769g
Package: github.com/anchore/quill (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.7.1
Patched in: 0.7.1

Summary: Quill has DoS via unbounded read of HTTP response body during notarization

Details:
### Impact

Quill before version `v0.7.1` has unbounded reads of HTTP response bodies during the Apple notarization process. Exploitation requires the ability to modify API responses from Apple's notarization service, which is not possible under standard network conditions due to HTTPS with proper TLS certificate validation; however, environments with TLS-intercepting proxies (common in corporate networks), compromised certificate authorities, or other trust boundary violations are at risk.

When processing HTTP responses during notarization, Quill reads the entire response body into memory without any size limit. An attacker who can control or modify the response content can return an arbitrarily large payload, causing the Quill client to run out of memory and crash. The impact is limited to availability; there is no effect on confidentiality or integrity. Both the Quill CLI and library are affected when used to perform notarization operations.


### Patches

Fixed in Quill version `v0.7.1`


### Workarounds

None

### Credit

Anchore would like to thank opera-aklajn (Opera) for reporting this vulnerability

### Resources

- [Apple Get Submission Log API Documentation](https://developer.apple.com/documentation/notaryapi/get-submission-log)
GitHub Security Advisory: GHSA-xj69-m9qq-8m94
Package: github.com/anchore/quill (GO)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.7.1
Patched in: 0.7.1

Summary: Quill has unbounded memory allocation via unvalidated size fields in Mach-O binary parsing

Details:
### Impact

Quill before version `v0.7.1` contains an unbounded memory allocation vulnerability when parsing Mach-O binaries. Exploitation requires that Quill processes an attacker-supplied Mach-O binary, which is most likely in environments such as CI/CD pipelines, shared signing services, or any workflow where externally-submitted binaries are accepted for signing.

When parsing a Mach-O binary, Quill reads several size and count fields from the `LC_CODE_SIGNATURE` load command and embedded code signing structures (`SuperBlob`, `BlobIndex`) and uses them to allocate memory buffers without validating that the values are reasonable or consistent with the actual file size. Affected fields include `DataSize`, `DataOffset`, and `Size` from the load command, `Count` from the `SuperBlob` header, and `Length` from individual blob headers. An attacker can craft a minimal (~4KB) malicious Mach-O binary with extremely large values in these fields, causing Quill to attempt to allocate excessive memory. This leads to memory exhaustion and denial of service, potentially crashing the host process. Both the Quill CLI and Go library are affected when used to parse untrusted Mach-O files.


### Patches

Fixed in Quill `v0.7.1`


### Workarounds

None

### Credit

Anchore would like to thank opera-aklajn (Opera) for reporting this vulnerability

### Resources

- [Inside code signing: hashes (Apple documentation)](https://developer.apple.com/documentation/technotes/tn3126-inside-code-signing-hashes)
GitHub Security Advisory: GHSA-7q3q-5px6-4c5p
Package: github.com/anchore/quill (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.7.1
Patched in: 0.7.1

Summary: Quill vulnerable to SSRF via unvalidated URL from Apple notarization log retrieval

Details:
### Impact

Quill before version `v0.7.1` contains a Server-Side Request Forgery (SSRF) vulnerability when attempting to fetch the Apple notarization submission logs. Exploitation requires the ability to modify API responses from Apple's notarization service, which is not possible under standard network conditions due to HTTPS with proper TLS certificate validation; however, environments with TLS-intercepting proxies (common in corporate networks), compromised certificate authorities, or other trust boundary violations are at risk.

When retrieving submission logs, Quill fetches a URL provided in the API response without validating that the scheme is https or that the host does not point to a local or multicast IP address. An attacker who can tamper with the response can supply an arbitrary URL, causing the Quill client to issue HTTP or HTTPS requests to attacker-controlled or internal network destinations. This could lead to exfiltration of sensitive data such as cloud provider credentials or internal service responses. Both the Quill CLI and library are affected when used to retrieve notarization submission logs.


### Patches

Fixed in Quill version `v0.7.1`


### Workarounds

None

### Credit

Anchore would like to thank opera-aklajn (Opera) for reporting this vulnerability

### Resources

- [Apple Get Submission Log API Documentation](https://developer.apple.com/documentation/notaryapi/get-submission-log)
GitHub Security Advisory: GHSA-rmrf-g9r3-73pm
Package: github.com/open-feature/flagd/flagd (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.14.2
Patched in: 0.14.2

Summary: flagd Vulnerable to Allocation of Resources Without Limits or Throttling

Details:
## Details

flagd exposes OFREP (`/ofrep/v1/evaluate/...`) and gRPC (`evaluation.v1`, `evaluation.v2`) endpoints for feature flag evaluation. These endpoints are designed to be publicly accessible by client applications.

The evaluation context included in request payloads is read into memory without any size restriction. An attacker can send a single HTTP request with an arbitrarily large body, causing flagd to allocate a corresponding amount of memory. This leads to immediate memory exhaustion and process termination (e.g., OOMKill in Kubernetes environments).

flagd does not natively enforce authentication on its evaluation endpoints. While operators may deploy flagd behind an authenticating reverse proxy or similar infrastructure, the endpoints themselves impose no access control by default.

## Impact

- **Denial of Service:** A single crafted request can crash the flagd process.
- **Service Disruption:** All applications relying on the affected flagd instance for feature flag evaluation will lose access to flag evaluations until the process restarts.
- **Repeated Exploitation:** An attacker can continuously send oversized requests to prevent recovery.

## Affected Endpoints

- `/ofrep/v1/evaluate/flags/{flagKey}` (OFREP single flag evaluation)
- `/ofrep/v1/evaluate/flags` (OFREP bulk evaluation)
- `flagd.evaluation.v1.Service/ResolveBoolean` (gRPC/Connect)
- `flagd.evaluation.v1.Service/ResolveString` (gRPC/Connect)
- `flagd.evaluation.v1.Service/ResolveFloat` (gRPC/Connect)
- `flagd.evaluation.v1.Service/ResolveInt` (gRPC/Connect)
- `flagd.evaluation.v1.Service/ResolveObject` (gRPC/Connect)
- `flagd.evaluation.v1.Service/ResolveAll` (gRPC/Connect)
- `flagd.evaluation.v2.Service/ResolveBoolean` (gRPC/Connect)
- `flagd.evaluation.v2.Service/ResolveString` (gRPC/Connect)
- `flagd.evaluation.v2.Service/ResolveFloat` (gRPC/Connect)
- `flagd.evaluation.v2.Service/ResolveInt` (gRPC/Connect)
- `flagd.evaluation.v2.Service/ResolveObject` (gRPC/Connect)
GitHub Security Advisory: GHSA-j443-wcqq-xprh
Package: github.com/arslanbekov/terraform-provider-sendgrid (GO)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: <= 1.1.3-0[PII_REDACTED]2314-b4a2dfeb7b0f
Patched in: unpatched

Summary: Terraform Provider for SendGrid: TLS Session Resumption Bypasses Certificate Authority Trust Store Modifications in Go

Details:
### Summary

A critical vulnerability has been identified at https://security.snyk.io/package/linux/chainguard:latest/terraform-provider-sendgrid, associated with the underlying Go version.

If the server's TLS configuration is mutated between connections — for example, a CA is removed from the trusted list via `Config.Clone()` combined with modification or `GetConfigForClient` — the resumed handshake still succeeds using the cached session. The certificate is not re-checked against the updated CA list.

As a result, a client whose CA was revoked or removed between the first and second connection could still establish a connection on the resumed session.

### Details

If the server's TLS configuration is mutated between connections — for example, a CA is removed from the trusted list via `Config.Clone()` combined with modification or `GetConfigForClient` — the resumed handshake still succeeds using the cached session. The certificate is not re-checked against the updated CA list.

Consequently, a client whose CA was revoked or removed between the first and second connection could still establish a connection on the resumed session.
GitHub Security Advisory: GHSA-c23c-rp3m-vpg3
Package: github.com/envoyproxy/envoy (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 1.36.0, <= 1.36.4
Patched in: unpatched

Summary: Envoy's global rate limit may crash when the response phase limit is enabled and the response phase request is failed directly

Details:
### Summary

At the rate limit filter, if we enabled the response phase limit with `apply_on_stream_done` in the rate limit configuration and the response phase limit request fails directly, it may crash Envoy.

### Details

When both the request phase limit and response phase limit are enabled, the safe gRPC client instance will be re-used for both the request phase request and response phase request.

But after the request phase request is done, the inner state of the request phase limit request in gRPC client is not cleaned up. When we send the second limit request at response phase, and the second limit request fails directly, we may access the previous request's inner state and result in crash.


### PoC

This need to mock the network failure. But we have reproduced by unit test locally.

### Impact

This only happens when both the request phase limit and response phase limit are enabled in the rate limit filter, and requires the request to rate limit service fails directly (For example, if from Envoy's perspective, no healthy endpoint for rate limit service may result the request fails directly). That's say, not easy to trigger this.

### To workaround

This could be worked around by splitting the rate limit filter. That is, if there is a rate limit filter that contains normal rate limit configuration (request phase limit, without `apply_on_stream_done`) and also rate limit configuration with `apply_on_stream_done` (response phase limit). Splitting them into two rate limit filters and ensure one filter only contains normal rate limit configuration (without `apply_on_stream_done`), and one only contains rate limit configuration with `apply_on_stream_done` could avoid this problem. 

### Credit

Mandar Jog (mandarjog@gmail.com)
GitHub Security Advisory: GHSA-c23c-rp3m-vpg3
Package: github.com/envoyproxy/envoy (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-416: Use After Free
Vulnerable versions: = 1.37.0
Patched in: unpatched

Summary: Envoy's global rate limit may crash when the response phase limit is enabled and the response phase request is failed directly

Details:
### Summary

At the rate limit filter, if we enabled the response phase limit with `apply_on_stream_done` in the rate limit configuration and the response phase limit request fails directly, it may crash Envoy.

### Details

When both the request phase limit and response phase limit are enabled, the safe gRPC client instance will be re-used for both the request phase request and response phase request.

But after the request phase request is done, the inner state of the request phase limit request in gRPC client is not cleaned up. When we send the second limit request at response phase, and the second limit request fails directly, we may access the previous request's inner state and result in crash.


### PoC

This need to mock the network failure. But we have reproduced by unit test locally.

### Impact

This only happens when both the request phase limit and response phase limit are enabled in the rate limit filter, and requires the request to rate limit service fails directly (For example, if from Envoy's perspective, no healthy endpoint for rate limit service may result the request fails directly). That's say, not easy to trigger this.

### To workaround

This could be worked around by splitting the rate limit filter. That is, if there is a rate limit filter that contains normal rate limit configuration (request phase limit, without `apply_on_stream_done`) and also rate limit configuration with `apply_on_stream_done` (response phase limit). Splitting them into two rate limit filters and ensure one filter only contains normal rate limit configuration (without `apply_on_stream_done`), and one only contains rate limit configuration with `apply_on_stream_done` could avoid this problem. 

### Credit

Mandar Jog (mandarjog@gmail.com)
GitHub Security Advisory: GHSA-3cw6-2j68-868p
Package: github.com/envoyproxy/envoy (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: <= 1.34.12
Patched in: unpatched

Summary: Envoy vulnerable to crash for scoped ip address during DNS

Details:
### Summary

Calling `Utility::getAddressWithPort` with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

### Details

The crashing function is `Utility::getAddressWithPort`. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The **original src filter**: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. **DNS response address resolution**: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

### PoC

To reproduce the vulnerability:

1. **Method A (Original Src Filter):** Configure the `original src` filter in Envoy and provide a scoped IPv6 address as the original source.
2. **Method B (DNS Resolution):** Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

### Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the `original src` filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.
GitHub Security Advisory: GHSA-3cw6-2j68-868p
Package: github.com/envoyproxy/envoy (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 1.35.0, <= 1.35.8
Patched in: unpatched

Summary: Envoy vulnerable to crash for scoped ip address during DNS

Details:
### Summary

Calling `Utility::getAddressWithPort` with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

### Details

The crashing function is `Utility::getAddressWithPort`. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The **original src filter**: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. **DNS response address resolution**: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

### PoC

To reproduce the vulnerability:

1. **Method A (Original Src Filter):** Configure the `original src` filter in Envoy and provide a scoped IPv6 address as the original source.
2. **Method B (DNS Resolution):** Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

### Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the `original src` filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.
GitHub Security Advisory: GHSA-3cw6-2j68-868p
Package: github.com/envoyproxy/envoy (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 1.36.0, <= 1.36.4
Patched in: unpatched

Summary: Envoy vulnerable to crash for scoped ip address during DNS

Details:
### Summary

Calling `Utility::getAddressWithPort` with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

### Details

The crashing function is `Utility::getAddressWithPort`. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The **original src filter**: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. **DNS response address resolution**: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

### PoC

To reproduce the vulnerability:

1. **Method A (Original Src Filter):** Configure the `original src` filter in Envoy and provide a scoped IPv6 address as the original source.
2. **Method B (DNS Resolution):** Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

### Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the `original src` filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.