deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-pq7p-mc74-g65w
Package: github.com/pocketbase/pocketbase (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-287: Improper Authentication
Vulnerable versions: < 0.22.42
Patched in: 0.22.42

Summary: PocketBase vulnerable to account pre-hijacking via OAuth2 unverfied->verified autolinking upgrade

Details:
A pre-hijacking issue was discovered with the OAuth2 autolinking by [Alardiians](https://github.com/Alardiians).

In some situations, if an attacker knows the email address of the victim they can create and link an **unverified** PocketBase user in advance by authenticating with one of the OAuth2 app providers, e.g. "A". When the victim gets invited or decides to sign up to your app on their own with provider "B" _(PocketBase OAuth2 auth requires to be with a different provider because we don't allow multiple OAuth2 accounts from the same provider to be associated to a single PocketBase user)_, the user created previously by the attacker will be autolinked, upgraded to **"verified"** and its old password reset.

The upgrade flow operates within the expectations but the problem is that I forgot to clear the previous OAuth2 link(s) leaving the attacker to still have access to the initially created user.

Or in other words, the vulnerability is similar to the [mixed password + OAuth2 auth pre-hijacking issue](https://github.com/pocketbase/pocketbase/security/advisories/GHSA-m93w-4fxv-r35v) that we had in the past but with a slightly different angle.

So with that in mind, and to avoid introducing breaking changes to the auth flows, a new fix was applied that automatically deletes all such pre-existing OAuth2 links on "unverified" to "verified" upgrades.

**While the vulnerability requires some prerequisites, it is considered severe and it is strongly recommended to upgrade to v0.37.4 _(or to v0.22.42 if you are using an older <v0.23.0 release)_.**
GitHub Security Advisory: GHSA-2g9v-7mr5-fgjg
Package: github.com/l3montree-dev/devguard (GO)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel
Vulnerable versions: < 1.2.2
Patched in: 1.2.2

Summary: DevGuard has an unauthenticated identity assertion via `X-Admin-Token` header

Details:
### Impact
The `SessionMiddleware` accepts a client-supplied `X-Admin-Token` HTTP request header and uses its raw string value as the authenticated `userID` when no Kratos session cookie is present. An unauthenticated attacker who knows or can guess a target user's Kratos identity UUID can issue requests as that user. Where the target user is an organisation `admin` or `owner`, this gives the attacker full control over that organisation's DevGuard resources.

### Patches
The release v1.2.2 patches this issue. Update your DevGuard API Instances to this version.

### Workarounds
Configure a reverse proxy to strip the `X-Admin-Token` header before sending requests to the DevGuard API.

### Resources
Fixed commit: https://github.com/l3montree-dev/devguard/commit/6f38310bf93b2a63df3055038f4da82b1f4e6d9a
GitHub Security Advisory: GHSA-x99g-8v8j-25j2
Package: github.com/ollama/ollama (GO)
Severity: LOW (CVSS 5.6)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.20.2
Patched in: unpatched

Summary: Ollama is Vulnerable to Path Traversal

Details:
A security flaw has been discovered in Ollama up to 0.20.2. This affects the function digestToPath of the file x/imagegen/transfer/transfer.go of the component Tensor Model Transfer Handler. The manipulation of the argument digest results in path traversal. The attack may be performed from remote. This attack is characterized by high complexity. The exploitability is reported as difficult. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-jj45-xvq5-rhh9
Package: github.com/go-kratos/kratos/v2 (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')
Vulnerable versions: <= 2.9.2
Patched in: unpatched

Summary: Kratos has a Confused Deputy issue

Details:
A security flaw has been discovered in go-kratos kratos up to 2.9.2. This impacts the function NewServer of the file transport/http/server.go of the component http.DefaultServeMux Fallback Handler. The manipulation results in unintended intermediary. The attack may be launched remotely. The exploit has been released to the public and may be used for attacks. The patch is identified as 0284a5bcf92b5a7ee015300ce3051baf7ae4718d. Applying a patch is advised to resolve this issue.
GitHub Security Advisory: GHSA-vv66-6rp4-wr4f
Package: github.com/openbao/openbao (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer
Vulnerable versions: < 0.0.0[PII_REDACTED]3541-6d2e0506e2b4
Patched in: 0.0.0[PII_REDACTED]3541-6d2e0506e2b4

Summary: OpenBao's Namespace Deletion May Not Delete Data Properly

Details:
### Impact

When OpenBao's initial namespace deletion fails, subsequent retries fail to properly remove all data before marking the namespace as deleted. This can affect any outstanding leases as well as potentially leaving unrelated storage entries around. 

### Patches

This will be patched in OpenBao v2.5.3.

### Workarounds

Users may manually remove mounts prior to deleting the namespace. 

Audit logs may be used to identify repeated deletion attempts against the same namespace; `sys/raw` can be used to see what leases were not correctly deleted.
GitHub Security Advisory: GHSA-8rm2-7qqf-34qm
Package: github.com/prometheus/prometheus (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: < 0.311.3
Patched in: 0.311.3

Summary: Prometheus: Remote read endpoint allows denial of service via crafted snappy payload

Details:
### Impact

The remote read endpoint (`/api/v1/read`) does not validate the declared decoded length in a snappy-compressed request body before allocating memory.
An unauthenticated attacker can send a small payload that causes a huge heap allocation per request. Under concurrent load this can exhaust available memory and crash the Prometheus process.

### Patches
_Has the problem been patched? What versions should users upgrade to?_

Fixed in 3.11.3 and 3.5.3 LTS. Users should upgrade to these versions or later.

### Workarounds
User who can not upgrade can place Prometheus behind a reverse proxy or firewall that requires authentication before requests reach /api/v1/read.
GitHub Security Advisory: GHSA-wg65-39gg-5wfj
Package: github.com/prometheus/prometheus (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-312: Cleartext Storage of Sensitive Information
Vulnerable versions: >= 0.45.2, < 0.311.3
Patched in: 0.311.3

Summary: Prometheus Azure AD remote write OAuth client secret exposed via config API

Details:
### Impact

Users who use Azure AD remote write with OAuth authentication are impacted.

The `client_secret` field in the Azure AD remote write OAuth configuration (`storage/remote/azuread`) was typed as `string` instead of `Secret`. Prometheus redacts fields of type `Secret` when serving the configuration via the `/-/config` HTTP API endpoint. Because the field was a plain string, the Azure OAuth client secret was exposed in plaintext to any user or process with access to that endpoint.

### Patches

The problem has been patched by changing `ClientSecret` in `OAuthConfig` to `Secret`. Users should upgrade to 3.11.3 or 3.5.3 LTS.

### Workarounds

Users  who can not upgrade can switch to Managed Identity or Workload Identity authentication for Azure AD remote write, which do not involve a client secret.
GitHub Security Advisory: GHSA-wv26-88m5-6h59
Package: github.com/external-secrets/external-secrets (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-285: Improper Authorization, CWE-668: Exposure of Resource to Wrong Sphere
Vulnerable versions: < 2.4.0
Patched in: 2.4.0

Summary: External Secrets Operator has Namespace Isolation Bypass in CAProvider ConfigMap Resolution for SecretStore

Details:
### Impact

Namespaced SecretStore resources that used CAProvider with type `ConfigMap` could resolve CA material from another namespace when `caProvider.namespace` was set. 
This bypassed the namespace boundary enforced for SecretStore-backed references in providers that rely on the shared runtime CA resolver. 

The accessible data is used as CA validation material, hence it is not directly exposed.

Impact:
- Direct data exfiltration risk: low
- Existence disclosure: an attacker can infer whether a target ConfigMap/key exists in another namespace.
- Trust-boundary violation: a tenant can make its SecretStore consume CA material owned by another namespace.
GitHub Security Advisory: GHSA-h5fq-653g-gxrm
Package: github.com/Luzifer/ots (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: <= 1.21.4
Patched in: 1.21.5

Summary: ots has a negative expire override that can bypass its secret retention policy

Details:
## Summary

The `/api/create` endpoint accepted negative `expire` query values. For the memory storage backend, negative values were passed to secret creation as a negative duration and treated as no expiry, allowing callers to create secrets that persisted longer than intended.

## Impact

Unauthenticated users could bypass configured retention expectations for secrets they create by sending `POST /api/create?expire=-1`.

This does not allow reading or modifying secrets created by other users. Secrets remain one-time-read and, in the normal web flow, client-side encrypted.

## Affected versions

Versions up to and including v1.21.4 are affected.

## Patched versions

Fixed in v1.21.5.

## Workarounds

Disable expiry overrides via `disableExpiryOverride: true` until upgrading.

## Credit

Reported by Chai Cheng Xun via email.
GitHub Security Advisory: GHSA-qpv2-rwc8-c993
Package: github.com/gravitl/netmaker (GO)
Severity: CRITICAL (CVSS 8.2)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 1.5.0
Patched in: 1.5.0

Summary: Netmaker does not verify JWT signatures for host tokens

Details:
Netmaker by Gravitl is an open-source WireGuard-based networking platform for creating and managing virtual overlay networks. The `VerifyHostToken` function in `logic/jwts.go` does not validate the JWT signature when verifying host tokens. After calling `jwt.ParseWithClaims`, the function only checks whether the returned token object is non-nil. It does not check `token.Valid` or the returned error. An attacker can forge a JWT signed with any key, set the claims to any host ID, and pull that host's full configuration including bcrypt-hashed passwords, MQTT credentials, and WireGuard peer data. The issue was patched in v1.5.0.
GitHub Security Advisory: GHSA-p4r4-xvrq-gvmc
Package: github.com/grafana/tempo (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 2.10.0, < 2.10.2
Patched in: 2.10.2

Summary: Grafana Tempo has an Uncontrolled Resource Consumption issue

Details:
Tempo queries with large limits can cause large memory allocations which can impact the availability of the service, depending on its deployment strategy.

Mitigation can be done by setting max_result_limit in the search config, e.g. to 262144 (2^18).
GitHub Security Advisory: GHSA-p4r4-xvrq-gvmc
Package: github.com/grafana/tempo (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 2.9.0, < 2.9.2
Patched in: 2.9.2

Summary: Grafana Tempo has an Uncontrolled Resource Consumption issue

Details:
Tempo queries with large limits can cause large memory allocations which can impact the availability of the service, depending on its deployment strategy.

Mitigation can be done by setting max_result_limit in the search config, e.g. to 262144 (2^18).
GitHub Security Advisory: GHSA-p4r4-xvrq-gvmc
Package: github.com/grafana/tempo (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 1.3.0, < 2.8.4
Patched in: 2.8.4

Summary: Grafana Tempo has an Uncontrolled Resource Consumption issue

Details:
Tempo queries with large limits can cause large memory allocations which can impact the availability of the service, depending on its deployment strategy.

Mitigation can be done by setting max_result_limit in the search config, e.g. to 262144 (2^18).
GitHub Security Advisory: GHSA-hcwr-pq9g-rq3m
Package: chainguard.dev/apko (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-345: Insufficient Verification of Data Authenticity, CWE-494: Download of Code Without Integrity Check
Vulnerable versions: < 1.2.7
Patched in: 1.2.7

Summary: apko doesn't verify downloaded apk packages against APKINDEX checksum (package substitution possible)

Details:
apko verifies the signature on `APKINDEX.tar.gz` but never compares individually downloaded `.apk` packages against the checksum recorded in the signed index. The checksum is parsed and available via `ChecksumString()`, and the downloaded package control hash is computed, but the two values are never compared in `getPackageImpl()`. Mismatched packages are silently accepted. An attacker who can substitute download responses (compromised mirror, HTTP repository, poisoned CDN cache) can install arbitrary packages into built images.

**Fix:** No fix available yet.

**Acknowledgements**

apko thanks Oleh Konko from [1seal](https://1seal.org/) for discovering and reporting this issue.
GitHub Security Advisory: GHSA-qq3r-w4hj-gjp6
Package: chainguard.dev/apko (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: >= 0.14.8, < 1.2.5
Patched in: 1.2.5

Summary: apko dirFS has a symlink-following path traversal that allows multiple entry points to escape the build root

Details:
### Impact

A crafted `.apk` could install a `TypeSymlink` tar entry whose target pointed outside the build root, and a subsequent directory-creation or file-write entry in the same or later archive could traverse that symlink to reach host paths the build user could write to. The root cause was the `sanitizePath` helper in `pkg/apk/fs/rwosfs.go`, which rejected only lexical `..` traversal and did not resolve or refuse symlinks. Every disk-backed `DirFS` method that handed its caller-supplied path to a symlink-following stdlib call — `ReadFile`, `WriteFile`, `Chmod`, `Chown`, `Chtimes`, `MkdirAll`, `Mkdir`, and `Mknod` — was affected. The reachable primitive from a malicious APK during tar extraction is the `MkdirAll` / `Mkdir` / `WriteFile` chain via `apko build-cpio` and disk-backed consumers such as `melange`; the remaining sinks are reachable by direct callers of the `pkg/apk/fs` package. The in-memory `tarfs` install path used by `apko build`, `apko publish`, and `apko build-minirootfs` is not affected.

### Patches

Fixed in apko **v1.2.5** by [#2187](https://github.com/chainguard-dev/apko/pull/2187) / commit [f5a96e1](https://github.com/chainguard-dev/apko/commit/f5a96e1299ac81c7ea9441705ec467688086f442), which scopes all `DirFS` operations through a Go 1.24 `*os.Root`. The `sanitizePath` helper has been removed; `*os.Root` refuses traversal via `..`, absolute-target symlinks, relative-target symlinks, and hardlinks by construction. Regression tests in `pkg/apk/apk/path_traversal_test.go` cover each composite primitive.

### Workarounds

No complete workaround. Operators running pre-1.2.5 apko (or downstream tools such as melange that embed pre-1.2.5 `pkg/apk/fs`) should upgrade. Consuming only APKs from trusted, signed sources reduces but does not eliminate exposure.

### Resources

- https://github.com/chainguard-dev/apko/pull/2187
- https://github.com/chainguard-dev/apko/commit/f5a96e1299ac81c7ea9441705ec467688086f442
- https://github.com/chainguard-dev/apko/releases/tag/v1.2.5
- Related: GHSA-5g94-c2wx-8pxw (CVE-2026-25121) — prior lexical `..` traversal fix

### Credits

apko thanks Oleh Konko ([@1seal](https://github.com/1seal) from [1seal.org](https://1seal.org/)) for the initial report of the symlink-escape class, and to [@Xh081iX](https://github.com/Xh081iX) for a follow-up set of reports covering additional reachable primitives (`ReadFile`, `Chmod`/`Chown`, `Mknod`, `MkdirAll`/`Mkdir`) that shaped the comprehensive fix.
GitHub Security Advisory: GHSA-m7hm-vm4x-28jf
Package: chainguard.dev/apko (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-704: Incorrect Type Conversion or Cast
Vulnerable versions: < 1.2.7
Patched in: 1.2.7

Summary: apko `DiscoverKeys` has a panic on non-rsa jwks key that causes crash during key discovery

Details:
`DiscoverKeys` in `pkg/apk/apk/implementation.go` unconditionally type-asserts JWKS keys as `*rsa.PublicKey` without checking the key type. If a repository JWKS endpoint returns a non-RSA key (e.g. EC), the unchecked assertion panics and crashes apko. This affects any workflow that initializes the APK database and fetches repository keys. Affected versions <= 0.30.34.

**Fix:** No fix available yet.

**Acknowledgements**

apko thanks Oleh Konko from [1seal](https://1seal.org/) for discovering and reporting this issue.
GitHub Security Advisory: GHSA-6pjf-3r9x-m592
Package: github.com/distribution/distribution (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: <= 2.8.3
Patched in: unpatched

Summary: Distribution's tag deletion bypasses `storage.delete.enabled` configuration

Details:
### Summary

Tag deletion via the `DELETE /v2/<name>/manifests/<tag>` endpoint bypasses the `storage.delete.enabled: false` configuration, allowing any API client to remove tags from repositories even when the operator has explicitly disabled deletion.

### Details

When `storage.delete.enabled` is configured to false, digest-based manifest deletion is correctly rejected by the guard in [registry/storage/linkedblobstore.go:212-215](https://github.com/distribution/distribution/blob/main/registry/storage/linkedblobstore.go#L213-L215). 

However, tag deletion takes a separate code path that never checks this setting:

In [`registry/handlers/manifests.go:439-453`](https://github.com/distribution/distribution/blob/main/registry/handlers/manifests.go#L439-L453), `DeleteManifest`  detects a tag reference, calls `tagService.Untag()`, returns,  never consulting `registry.deleteEnabled`.

In turn, [`tagStore.Untag()`](https://github.com/distribution/distribution/blob/main/registry/storage/tagstore.go#L111-L121) calls the storage driver directly to delete the tag path without checking whether deletes are enabled.

### PoC

Using a paired down Distribution configuration that explicitly disables deletes, such as this one, stored as `config.yaml`:

```yaml
version: 0.1
storage:
  delete:
    enabled: false
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: :5000
```

Start a local Distribution, mounting in the above configuration from the current directory:

```shell
docker run -p 5000:5000 -v "$(pwd)/config.yaml":/config.yaml --restart=always --name registry registry:3.1.0 /config.yaml
```

In a separate terminal session/tab, push `alpine:3.23` into the running instance:
```shell
docker pull alpine:3.23
docker tag alpine:3.23 localhost:5000/alpine:3.23
docker push localhost:5000/alpine:3.23
```

Confirm that the tag shows up as expected:
```shell
curl 'http://localhost:5000/v2/alpine/tags/list'
{"name":"alpine","tags":["3.23"]}
```

Issue a delete for the `3.23` tag:
```shell
curl -X DELETE 'http://localhost:5000/v2/alpine/manifests/3.23'
```

Observe that the tag is now gone, despite deletes being disabled:
```shell
curl 'http://localhost:5000/v2/alpine/tags/list'
{"name":"alpine","tags":null}
```

### Impact

This is an authorization bypass vulnerability. Any client with network access to the registry can delete tags despite the operator having disabled deletion. This can cause denial of service for consumers pulling by tag and enables supply-chain disruption by removing trusted tags from a registry that the operator and/or users believed to be immutable.
GitHub Security Advisory: GHSA-6pjf-3r9x-m592
Package: github.com/distribution/distribution/v3 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 3.1.1
Patched in: 3.1.1

Summary: Distribution's tag deletion bypasses `storage.delete.enabled` configuration

Details:
### Summary

Tag deletion via the `DELETE /v2/<name>/manifests/<tag>` endpoint bypasses the `storage.delete.enabled: false` configuration, allowing any API client to remove tags from repositories even when the operator has explicitly disabled deletion.

### Details

When `storage.delete.enabled` is configured to false, digest-based manifest deletion is correctly rejected by the guard in [registry/storage/linkedblobstore.go:212-215](https://github.com/distribution/distribution/blob/main/registry/storage/linkedblobstore.go#L213-L215). 

However, tag deletion takes a separate code path that never checks this setting:

In [`registry/handlers/manifests.go:439-453`](https://github.com/distribution/distribution/blob/main/registry/handlers/manifests.go#L439-L453), `DeleteManifest`  detects a tag reference, calls `tagService.Untag()`, returns,  never consulting `registry.deleteEnabled`.

In turn, [`tagStore.Untag()`](https://github.com/distribution/distribution/blob/main/registry/storage/tagstore.go#L111-L121) calls the storage driver directly to delete the tag path without checking whether deletes are enabled.

### PoC

Using a paired down Distribution configuration that explicitly disables deletes, such as this one, stored as `config.yaml`:

```yaml
version: 0.1
storage:
  delete:
    enabled: false
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: :5000
```

Start a local Distribution, mounting in the above configuration from the current directory:

```shell
docker run -p 5000:5000 -v "$(pwd)/config.yaml":/config.yaml --restart=always --name registry registry:3.1.0 /config.yaml
```

In a separate terminal session/tab, push `alpine:3.23` into the running instance:
```shell
docker pull alpine:3.23
docker tag alpine:3.23 localhost:5000/alpine:3.23
docker push localhost:5000/alpine:3.23
```

Confirm that the tag shows up as expected:
```shell
curl 'http://localhost:5000/v2/alpine/tags/list'
{"name":"alpine","tags":["3.23"]}
```

Issue a delete for the `3.23` tag:
```shell
curl -X DELETE 'http://localhost:5000/v2/alpine/manifests/3.23'
```

Observe that the tag is now gone, despite deletes being disabled:
```shell
curl 'http://localhost:5000/v2/alpine/tags/list'
{"name":"alpine","tags":null}
```

### Impact

This is an authorization bypass vulnerability. Any client with network access to the registry can delete tags despite the operator having disabled deletion. This can cause denial of service for consumers pulling by tag and enables supply-chain disruption by removing trusted tags from a registry that the operator and/or users believed to be immutable.