| Risiko / Label | Veröffentlichung | |
|---|---|---|
| Risiko 9.5 / 10 CVE-2026-44935 | vor 55 Minute(n) | |
| ### Impact A vulnerability in Fleet for Rancher Manager affects multi-tenancy environments where different tenants share the same downstream clusters (e.g., different privileged or untrusted teams inside the same organization). On unpatched versions, tenants could bypass restrictions to access any config map or secret across all namespaces on the downstream cluster. They can create cluster-wide resources using `HelmOp` or `Bundle` without authorization. Specifically, an attacker can exploit this vulnerability in the following ways: 1. Use `valuesFrom` in `fleet.yaml`(through a `GitRepo` resource) or a `HelmOp resource to read the contents of any secret an on the downstream cluster, provided they know or can guess the name, namespace, and key. 2. Deploy `HelmOp` and `Bundle` resources without being restricted to a specific service account for the Fleet agent. If you use Fleet in a multi-tenant environment, it's recommended that you: - Review your cluster and Fleet deployments logs for indicators of unauthorized access across tenant namespaces. - Rotate any service accounts and credentials that might have been exposed. Please consult the associated [MITRE ATT&CK - Technique - Unsecured Credentials](https://attack.mitre.org/techniques/T1552/) for further information about this category of attack. ### Patches To resolve this vulnerability, upgrade to a patched version of Fleet. The new Policy resource allows you to: - Configure `GitRepos`, `HelmOps`, and `Bundles` to require a specific service account for the Fleet agent on downstream clusters used for deployment. The agent uses these designated service accounts for operations, blocking access to unauthorized resources. - Restrict `HelmOp` repository and chart URLs by using a regular expression. The regular expression is automatically anchored with `^` and `$`, meaning it must match the entire URL string. Like `GitRepoRestriction`, a Policy resource must be created in the specific namespace you want to restrict, and it only applies to that namespace. **Note:** Before applying a policy, ensure that the required service account is available on the downstream clusters and is configured with least-privilege permissions. Patched versions of Fleet include releases `v0.15.2`, `v0.14.6`, `0.13.11`, and `v0.12.15`. ### Workarounds If you can't upgrade to a fixed version, please make sure that tenants do not have shared access to the same downstream clusters. ### Credits This security issue was reported by the following collaborators according to our responsible disclosure policy: - Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC). ### References If you have any questions or comments about this advisory: - Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries. - Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository. - Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/). | ||
| Risiko 5 / 10 CVE-2026-44936 | vor 55 Minute(n) | |
| ### Impact A vulnerability has been identified in Fleet when the `helmRepoURLRegex` field isn't set on a `GitRepo` resource. Fleet's bundle reader forwards Helm authentication credentials (`BasicAuth`) to any URL specified in the `helm.repo` field of a `fleet.yaml` file. An attacker with git push access to a Fleet-monitored repository can exploit this behavior by specifying a malicious URL in `helm.repo`. This causes the Fleet controller to send the configured Helm repository credentials to the attacker’s server. As a result, the attacker can capture the username and password that an administrator configured to access a private Helm chart repository. However, the response body from the attacker's server isn't included in the error message (this behavior was fixed in Fleet `v0.13.3` and later), which prevents additional internal data from leaking through the status condition. The final severity of this vulnerability depends on the specific permissions of the leaked credentials. Fleet recommends you to: 1. Review your system for potentially leaked credentials. 2. Replace any credentials that might be compromised. Please consult the associated [MITRE ATT&CK - Technique - Stored Data Manipulation](https://attack.mitre.org/techniques/T1565/001/) and [MITRE ATT&CK - Technique - Steal Application Access Token](https://attack.mitre.org/techniques/T1528/) for further information about this category of attack. ### Patches To resolve this vulnerability, upgrade to a patched version of Fleet. The patched version of Fleet now requires you to set the `helmRepoURLRegex` field on the `GitRepo`. If the `helmRepoURLRegex` is empty or missing, Fleet won’t send credentials, regardless of the URL specified in `fleet.yaml`. When you upgrade, a Helm pre-upgrade job automatically migrates existing `GitRepo` resources that have `helmSecretName` or `helmSecretNameForPaths` configured but lack a `helmRepoURLRegex`. The migration job performs the following actions: The job extracts the scheme and host from the Helm repository URLs already stored in the resource's Bundles. For example, a `GitRepo` with Bundles referencing `https://charts.example.com/stable` receives `helmRepoURLRegex: "^https://charts\.example\.com/"`. This limits credential forwarding to the origins already in use before the upgrade. Migrated resources are annotated with `fleet.cattle.io/helm-regex-auto-migrated: "true"` so you can easily audit them. If no Bundles with Helm repository URLs exist during the migration (for example, if the `GitRepo` has never successfully synced), `helmRepoURLRegex` remains empty and credentials aren't forwarded. You must set this field manually before Fleet will send credentials. The migration job runs only once per installation and records its status in a `ConfigMap` named `fleet-helm-url-regex-migrated` in the Fleet system namespace. Any `GitRepo` resources you create after the upgrade require an explicit `helmRepoURLRegex` to forward credentials. Patched versions of Fleet include releases `v0.15.2`, `v0.14.6`, `0.13.11`, and `v0.12.15`. ### Workarounds If you cannot immediately upgrade to a patched version, use the following methods to mitigate the risk and audit your environment. Set `helmRepoURLRegex` on all `GitRepo` resources that use `helmSecretName`. Ensure the regular expression matches only your legitimate Helm repository URL. Example configuration: ```yaml apiVersion: fleet.cattle.io/v1alpha1 kind: GitRepo metadata: name: my-app namespace: fleet-local spec: repo: https://git.example.com/org/my-app.git helmSecretName: helm-creds helmRepoURLRegex: "^https://charts\\.example\\.com/.*" ``` After upgrading to a patched version, review all auto-migrated `GitRepo` resources by running the following command: ``` kubectl get gitrepo -A -o json | \ jq -r '.items[] | select(.metadata.annotations["fleet.cattle.io/helm-regex-auto-migrated"] == "true") | "\(.metadata.namespace)/\(.metadata.name): \(.spec.helmRepoURLRegex)"' ``` Verify that the auto-derived regular expression matches only your intended Helm repository origins. If a regular expression is broader than necessary, replace it with a more specific pattern. ### Credits This security issue was reported by the following collaborators according to our responsible disclosure policy: - Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC). - FluentLogic's security team. ### References If you have any questions or comments about this advisory: - Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries. - Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository. - Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/). | ||
| Risiko 7.5 / 10 CVE-2026-44937 | vor 56 Minute(n) | |
| ### Impact A vulnerability has been identified in Fleet when the webhook endpoint is configured without a secret; an attacker can forge webhook requests. The attacker doesn't need to know the specific repository or path configured in the GitRepo resource to make Fleet process these requests. An attacker can exploit this vulnerability to cause the following impacts: 1. Trigger continuous repository re-cloning, which increases network traffic and can deplete resources on the management cluster. 2. Downgrade running services to any historical revision available in the remote Git repository. This risk applies if the attacker has read access to the target Git repository and knows its configured path. Please consult the associated [MITRE ATT&CK - Technique - T1499.004: Endpoint Denial of Service](https://attack.mitre.org/techniques/T1499/) for further information about this category of attack. ### Patches To resolve this vulnerability, upgrade Fleet to a patched version. This upgrade version escapes the URL and path to the remote repository received from webhooks, which prevents regular expressions from being used as a replacement for the URL and path. Patched versions of Fleet include releases `v0.15.2`, `v0.14.6`, `0.13.11`, and `v0.12.15`. ### Workarounds If you can't upgrade to a fixed version, please make sure to only enable webhooks with a shared secret. ### Credits This security issue was reported by the following collaborators according to our responsible disclosure policy: - Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC). ### References If you have any questions or comments about this advisory: - Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries. - Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository. - Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/). | ||
| Risiko 7.5 / 10 CVE-2026-44938 | vor 1 Stunde(n) | |
| ### Impact A vulnerability has been identified in Fleet's agent-side deployer, which did not filter security-sensitive keys from `namespaceLabels` in `fleet.yaml` (or `BundleDeployment.spec.options.namespaceLabels`) when applying them to the target namespace. An attacker with `git push` access to a Fleet-monitored repository could overwrite Pod Security Standards (PSS) enforcement labels on a target namespace. This allows the attacker to weaken admission controls and deploy workloads that PSS policies would otherwise block. **Important:** The final impact on confidentiality, integrity, and availability depends on the specific permissions of the leaked credentials. Fleet team recommends you: 1. Review your system for potentially leaked credentials. 2. Replace any credentials that may be compromised. Please consult the associated [MITRE ATT&CK - Technique - Disable or Modify Tools](https://attack.mitre.org/techniques/T1685/) for further information about this category of attack. ### Patches To fix this issue, upgrade to a patched version. The updated Fleet deployer filters out labels with the `pod-security.kubernetes.io/` prefix when applying `namespaceLabels` to a namespace. This change preserves the PSS labels set by cluster administrators and prevents them from being overwritten through `fleet.yaml` or `BundleDeployment` options. Patched versions of Fleet include releases `v0.15.2`, `v0.14.6`, `v0.13.11`, and `v0.12.15`. ### Workarounds If you can’t immediately upgrade to a patched version, use one of the following workarounds: **1 - Deploy NeuVector(primary workaround)** Deploy NeuVector (SUSE Security) and configure an admission control Deny rule for "Run as privileged" in Protect mode. - NeuVector evaluates pod specs independently of Kubernetes PSS namespace labels. It blocks privileged containers even if the labels are downgraded. - Although the namespace labels are still overwritten, the attack cannot exploit confidentiality, integrity, or availability without a privileged pod. **2 - Restrict repository access (secondary workaround)** **Note:** The following measure reduces the attack surface but does not close the vulnerability: - In a multi-tenant setup, this restriction removes the primary attack vector. However, this measure only reduces the attack surface and doesn't completely close the vulnerability. It may also not be operationally viable for all organizations. ´ ### Credits This security issue was reported by the following collaborators according to our responsible disclosure policy: - Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC). ### References - Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries. - Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository. - Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/). | ||
| Risiko 9.5 / 10 CVE-2026-49457 | vor 1 Stunde(n) | |
| ### Impact The QUIC client did not authenticate the server during the TLS 1.3 handshake. The CertificateVerify signature was not checked, the certificate chain was not validated, and the hostname was not compared against the certificate, so `verify` was effectively a no-op on the client. A man-in-the-middle on the network path could present any certificate and impersonate any server, defeating the confidentiality and integrity of the connection. HTTP/3 uses the same client and was equally affected. Handshakes authenticated by a PSK (session resumption) are not affected, because the peer is authenticated by the PSK binder and no certificate is sent. ### Patches Fixed in 1.4.4. The client now verifies the CertificateVerify signature, validates the certificate chain against the trust store (`cacerts` option, the operating system store by default), and checks the hostname. Client `verify` now defaults to on; set `verify => false` to accept any certificate (for example a self-signed test server). ### Workarounds None before 1.4.4. `verify => true` had no effect, and inspecting the certificate after connecting does not help because without the signature check the peer is never proven to own the certificate it presents. ### Credit Reported by benmmurphy. | ||
| Risiko 2 / 10 GHSA-j6hm-v3x2-qv6j | vor 1 Stunde(n) | |
| ### Summary
`ArchiveUtils.untar(InputStream, Path)` and `ArchiveUtils.unzip(InputStream, Path)` in `land.oras:oras-java-sdk` create symbolic-link entries from an archive without validating the symlink target. A malicious tar (or zip) shipped as an OCI layer blob can place a symlink under the extraction directory whose target points outside that directory, then ship a regular-file entry whose path traverses through that symlink. The subsequent `Files.newOutputStream` call follows the symlink and writes the file outside the caller's chosen `target` directory.
This bypasses the existing `ensureSafeEntry` containment check, which only validates `entry.getName()` and not `entry.getLinkName()`. Reachable from the public `Registry.pullArtifact` / `OCILayout.pullArtifact` API whenever the manifest layer carries `io.deis.oras.content.unpack=true`, and from any direct caller of `ArchiveUtils.untar` / `ArchiveUtils.uncompressuntar` (e.g. consumers that pull an archive blob and extract it themselves, such as project-scaffolding CLIs that fetch templates from OCI registries).
### Affected versions
`land.oras:oras-java-sdk` `<= 0.6.3` (current `main` commit `8e39dd54f0b9e981a5f246aefb851298187578e5`, file `src/main/java/land/oras/utils/ArchiveUtils.java` lines 400-443 for `untar`, lines 350-393 for `unzip`).
Earlier path-traversal fix in PR #703 (released as `0.6.2`) addressed the `org.opencontainers.image.title` annotation sink (GHSA-xm96-gfjx-jcrc), but did not extend containment to symlink targets inside archive entries.
### Privilege required
Network-position: any party able to serve an OCI artifact / archive blob that the victim's `oras-java-sdk`-based tool pulls and extracts. This includes:
- A compromised or attacker-operated OCI registry endpoint (typo-squat, MITM, supply-chain into a public registry namespace).
- A malicious upstream artifact author who pushes a single tampered blob to a registry the victim trusts.
No registry authentication needed on the victim side beyond what is required to pull the artifact; the attack is fully driven by the contents of the layer the victim downloads.
### Root cause
`src/main/java/land/oras/utils/ArchiveUtils.java` `untar(InputStream, Path)`, lines 400-443:
```java
public static void untar(InputStream fis, Path target) {
try {
try (BufferedInputStream bis = new BufferedInputStream(fis);
TarArchiveInputStream tais = new TarArchiveInputStream(bis)) {
TarArchiveEntry entry;
while ((entry = tais.getNextEntry()) != null) {
// Check if the entry is outside the target directory
ensureSafeEntry(entry, target); // validates entry.getName() only
Path outputPath = target.resolve(entry.getName()).normalize();
if (entry.isDirectory()) {
Files.createDirectories(outputPath);
} else {
Files.createDirectories(outputPath.getParent());
if (entry.isSymbolicLink()) {
// entry.getLinkName() is NOT validated against target
createSymbolicLink(outputPath, Paths.get(entry.getLinkName()));
} else {
// FOLLOWS the symlink if outputPath's parent is one
try (OutputStream out = Files.newOutputStream(outputPath)) {
tais.transferTo(out);
}
}
}
}
}
} catch (IOException e) {
throw new OrasException("Failed to extract tar.gz file", e);
}
}
```
`ensureSafeEntry` (lines 261-268) only normalizes `entry.getName()` against `target`. `entry.getLinkName()` for symlink entries is passed straight to `createSymbolicLink`. The subsequent file-write code path uses `Files.newOutputStream` without `LinkOption.NOFOLLOW_LINKS`, so when a later entry's path traverses through the previously-created symlink, the write resolves the symlink and lands outside `target`.
The same primitive applies to `unzip(InputStream, Path)` at lines 350-393 (symlink path at line 379 uses `createSymbolicLink(outputPath, Paths.get(linkStr))` without target validation).
Reachability into the public API:
- `Registry.pullArtifact` -> `pullLayer` (Registry.java:1088). When `io.deis.oras.content.unpack=true` is set on the layer, `pullLayer` calls `ArchiveUtils.untar(Files.newInputStream(tempArchive.getPath()), path)` at line 1109. The attacker-controlled blob is the input.
- `OCILayout.pullArtifact` similar path through the layout's blob store.
- Any direct caller of `ArchiveUtils.untar` / `ArchiveUtils.uncompressuntar` / `ArchiveUtils.unzip` from a downstream consumer that fetches an archive blob and extracts it.
### Proof of concept (E2E against deployed Maven Central `land.oras:oras-java-sdk:0.6.3`)
`pom.xml`:
```xml
|
||
| Risiko 7.5 / 10 CVE-2026-49998 | vor 1 Stunde(n) | |
| #### Summary
Centrifugo's dynamic JWKS endpoint feature can verify a JWT for one allowed issuer using a public key cached from another allowed issuer. The JWKS cache and `singleflight` lookup are keyed only by the JWT header `kid`, not by the resolved JWKS endpoint, issuer, audience, or other trust-domain namespace.
In a documented multi-issuer dynamic JWKS configuration, an attacker who can obtain or mint a valid token for issuer/tenant A can authenticate as issuer/tenant B if both JWKS documents use the same `kid` value and tenant A's key is cached first. This affects connection token verification and subscription token verification because both paths use the same JWKS verification manager.
#### Details
The vulnerable path is reachable when either of these shipped configuration options is set to a templated JWKS URL using values derived from JWT `iss` or `aud` claims:
- `client.token.jwks_public_endpoint`
- `client.subscription_token.jwks_public_endpoint`
Relevant shipped config fields are defined in `internal/configtypes/types.go:59-65`, mapped into verifier configuration in `internal/confighelpers/jwt.go:36-41`, and exposed in the generated config schema at `internal/cli/configdoc/schema.json:3927`, `3947`, `3967`, `3987`, `4069`, `4089`, `4109`, and `4129`. Dynamic JWKS endpoints based on `iss` and `aud` are documented in the project changelog at `CHANGELOG.md:107`.
External clients control JWT connection and subscription tokens:
- Connection tokens reach `VerifyConnectToken` from `internal/client/handler.go:350-352`.
- Normal subscription tokens reach `VerifySubscribeToken` from `internal/client/handler.go:769-775`.
- Subscription refresh tokens reach `VerifySubscribeToken` from `internal/client/handler.go:628-632`.
The verifier must parse token claims before signature verification to resolve the dynamic JWKS endpoint:
- `VerifyConnectToken` parses without verification at `internal/jwtverify/token_verifier_jwt.go:528-535`, extracts template variables before signature verification at `internal/jwtverify/token_verifier_jwt.go:539-548`, then validates claims only after signature verification at `internal/jwtverify/token_verifier_jwt.go:557-560`.
- `VerifySubscribeToken` follows the same pattern at `internal/jwtverify/token_verifier_jwt.go:700-732`.
The problem is that the JWKS cache lookup ignores the endpoint/trust domain selected by those token variables. `internal/jwtverify/token_verifier_jwt.go:242-245` passes only the JWT header `kid` plus token-derived variables to the JWKS manager:
```go
func (j *jwksManager) verify(token *jwt.Token, tokenVars map[string]any) error {
kid := token.Header().KeyID
key, err := j.Manager.FetchKey(context.Background(), kid, tokenVars)
```
`internal/jwks/manager.go:96-117` checks cache and `singleflight` using only `kid`:
```go
func (m *Manager) FetchKey(ctx context.Context, kid string, tokenVars map[string]any) (*JWK, error) {
if kid == "" {
return nil, ErrKeyIDNotProvided
}
if m.useCache {
key, err := m.cache.Get(kid)
if err == nil {
return key, nil
}
}
v, err, _ := m.group.Do(kid, func() (any, error) {
return m.fetchKey(ctx, kid, tokenVars)
})
```
The resolved JWKS URL is computed only later in `internal/jwks/manager.go:133-149`:
```go
func (m *Manager) fetchKey(ctx context.Context, kid string, tokenVars map[string]any) (*JWK, error) {
jwkURL := m.url.ExecuteString(tokenVars)
...
req, err := http.NewRequestWithContext(ctx, http.MethodGet, jwkURL, nil)
```
The TTL cache also stores and retrieves keys only by `kid` at `internal/jwks/cache_ttl.go:82-101`:
```go
func (tc *TTLCache) Add(key *JWK) error {
...
tc.items[key.Kid] = item
}
func (tc *TTLCache) Get(kid string) (*JWK, error) {
...
item, ok := tc.items[kid]
```
As a result, a key fetched from tenant A's JWKS endpoint can be reused to verify a token claiming tenant B before tenant B's JWKS endpoint is consulted.
I also reviewed the template safety mitigation in `internal/jwtverify/validate.go:99-154`. It restricts placeholder regex groups to finite literal alternatives, which helps prevent arbitrary endpoint substitution, but it does not scope cached keys by the resolved endpoint or issuer/audience namespace. The PoC uses a validator-accepted issuer regex: `^(?P |
||
| Risiko 5 / 10 CVE-2026-49997 | vor 1 Stunde(n) | |
| In SurrealDB, records can be connected as a graph: a `RELATE` statement creates an edge record between two node records. If either endpoint node is deleted, SurrealDB automatically removes the edge row to keep the graph consistent. A user with permission to delete a node could also delete the edges connected to that node, even when the edge table's `PERMISSIONS FOR delete` clause should have stopped them. The automatic edge removal (`Document::purge_edges`) ran with permissions disabled (`opt.clone().with_perms(false)`), so the edge table's `PERMISSIONS FOR delete` and `PERMISSIONS FOR select` clauses were never consulted. The removal step could also observe edge state that the edge's SELECT clause should have hidden. ### Impact What an attacker **can** do: - Delete any edge connected to a node they can delete, regardless of the edge table's `PERMISSIONS FOR delete` clause. - Observe edge contents that `PERMISSIONS FOR select` should have hidden, as a side effect of the same edge-removal step. What it **can't** do: - Delete nodes on tables they do not hold `DELETE` on (the edge removal only runs from an authorised node delete). - Cross namespace or database isolation boundaries. - Escalate to root or operator-level privileges. ### Patches `Document::purge_edges` now propagates the caller's permission context into the edge removal. Each connected edge `DELETE` is evaluated against the edge table's `PERMISSIONS FOR delete` clause, matching a direct `DELETE`. Versions 3.1.0 and later are not affected. ### Workarounds - Restrict node `DELETE` permission to principals trusted to delete all connected edge records. - Use namespace or database isolation as the primary boundary where edge-level `PERMISSIONS` is load-bearing for multi-tenant separation. | ||
| Risiko 5 / 10 GHSA-fwg2-gr34-q3w8 | vor 1 Stunde(n) | |
| When a user configures `ALGORITHM ES512` for any JWT access method (`DEFINE ACCESS ... TYPE JWT ALGORITHM ES512`), SurrealDB silently substitutes ES384 at all four internal algorithm conversion points. This occurs because the underlying `jsonwebtoken` crate (v10.x) does not include an ES512 algorithm variant, so the mapping defaults to ES384 without raising an error, warning, or log message. Users who provide the correct P-521 key type for ES512 will experience authentication handshake failures due to the curve mismatch with ES384 (which expects P-384). ### Impact Authentication handshake failures when using ES512 with the correct P-521 key type, and when tokens are verified by external systems expecting real ES512 signatures. This vulnerability cannot be exploited to forge tokens or compromise the integrity or confidentiality of data handled by SurrealDB, as ES384 remains cryptographically strong. ### Patches Versions prior to SurrealDB `v3.1.0` are vulnerable. The patches for SurrealDB `v3.1.0` block new `DEFINE ACCESS` statements using `ALGORITHM ES512` with a clear error message and add deprecation warnings at runtime for existing stored ES512 definitions. ### Workarounds Users should reconfigure affected JWT access methods to use a supported algorithm such as ES384 (with a P-384 key pair) or another supported algorithm. Review any `DEFINE ACCESS` statements specifying `ALGORITHM ES512` and update them accordingly. | ||
| Risiko 5 / 10 GHSA-c8jx-96c9-8xrp | vor 1 Stunde(n) | |
| A record user could learn the value of a hidden field by counting how many records match a guess. When `DEFINE FIELD ... PERMISSIONS FOR select WHERE ...` hides a field's contents from a caller, and that field is indexed, running `SELECT count() FROM t WHERE hidden_field = "guess" GROUP ALL` returned a count greater than zero whenever a record actually had that value — even though the caller was never allowed to read the field directly. The query planner used an indexed-COUNT shortcut (`Index::Count`, `IndexCountScan`, or the legacy `Iterate Index Count` / `Iterate Index Keys` paths) that counts matching index entries and skips the permission check that would normally hide the value. The same query with `WITH NOINDEX` correctly returned `[]`, confirming the gap. By repeating the count query with different guesses, an attacker can confirm or recover the contents of any restricted field they could not read through a normal `SELECT`. ### Impact What an attacker **can** do: - Confirm or recover values of a field protected by field-level SELECT permissions on any table they hold table-level SELECT on, provided the field is indexed. - Repeat the query with different guesses to read restricted field contents one value at a time. What it **can't** do: - Read fields that are not indexed (the shortcut only fires when an index covers the predicate column). - Cross table, database or namespace isolation boundaries. - Modify data, escalate privileges, or affect availability. ### Patches The legacy planner (`surrealdb/core/src/idx/planner/tree.rs`) and the streaming planner (`surrealdb/core/src/exec/planner/select/mod.rs`) now both refuse the indexed fast path when the WHERE / ORDER tree references a field governed by a non-`Full` SELECT permission: - `resolve_indexes` skips any B-tree / unique index whose columns are governed by such a permission. - A new `cond_touches_restricted_field` flag is propagated; `eval_count` refuses a dedicated `Index::Count` when set. - The streaming planner adds `cond_touches_restricted_select_field`, a `RestrictedIdiomChecker` visitor that matches each idiom against the table's field-permission prefixes (loaded via the plan-time txn), and gates `IndexCountScan` emission on it. - The fast paths are preserved for root / owner sessions via `should_check_perms_for_view`. Versions 3.1.0 and later are not affected. ### Workarounds Users unable to patch are advised to consider the following workarounds: - Avoid `DEFINE INDEX` on fields whose values are protected by field-level SELECT permissions. The class of attack is specific to the indexed fast paths. - Restrict the ability of record users to issue arbitrary `SELECT count() … GROUP ALL` queries against tables containing field-protected columns. - Use namespace / database isolation as the primary boundary where feasible. | ||
| Risiko 5 / 10 GHSA-wp87-mgvq-5j93 | vor 1 Stunde(n) | |
| An anonymous caller could create new namespaces and databases on a running SurrealDB instance without holding `DEFINE NAMESPACE` or `DEFINE DATABASE` permission.
`USE NS |
||
| Risiko 5 / 10 GHSA-97vg-427p-8hx5 | vor 1 Stunde(n) | |
| SurrealDB offers `http::*` functions that can access external network endpoints, with the `--allow-net` and `--deny-net` capabilities used to restrict the set of network targets that can be reached. An authenticated user of SurrealDB can bypass a port-scoped `--deny-net |
||
| Risiko 5 / 10 GHSA-6wqw-vhfr-9999 | vor 1 Stunde(n) | |
| A record user could read records the table's SELECT permission expression should have hidden, when that expression referenced `$value`, `$before`, `$after`, or `$event`. Binding a chosen value to that name before registering a `LIVE SELECT` caused notifications to evaluate the permission against the attacker's input instead of the real document. ### Impact A record user binds a value to `$value`, `$before`, `$after`, or `$event` (e.g. `LET $value = [$auth.id]`) and registers `LIVE SELECT * FROM person`. The captured value shadows the real document at notification time, so a SELECT permission like `WHERE $auth.id.id() IN $value` passes for every record on the table — the subscriber receives notifications for records they should not see. Read-only impact, bounded to one table. Permission expressions that reference only field names, `$auth`, or `$session` are unaffected. ### Patches A patch has been introduced that re-orders the LIVE notification parameter binding so captured user variables are added first and the trusted document-context and session parameters are added last. - Versions 3.1.0 and later are not affected by this issue. ### Workarounds Affected users who are unable to update should avoid table-`PERMISSIONS` and LIVE `WHERE` expressions that read user-named variables (`$value`, `$before`, `$after`, `$event`) without also gating on a system-derived field such as the record id. | ||
| Risiko 5 / 10 GHSA-f82j-v89j-mf86 | vor 1 Stunde(n) | |
| `RELATE` creates an edge record between two existing records, and SurrealDB enforces the `CREATE` permission on the edge table for this operation. When the statement included a `SET id = edge:existing` clause, however, the new edge's id ended up pointing at an record that was already in storage. Rather than failing because the target already existed — which is what a create operation should do — the storage layer silently overwrote the existing edge. A caller with `CREATE` permission could therefore replace any existing edge on the table, even without `UPDATE` permission for that record. ### Impact An authenticated user with `CREATE` permission on an edge table could overwrite any existing record on that table — including edges they had no `UPDATE` permission for — by issuing a `RELATE` whose `SET id = …` resolved to the target record's id. The attack is integrity-only. ### Patches A patch has been introduced that adds an explicit `Statement::Relate` arm using `put_record` instead of `set_record` when the create path is selected. Conflicting writes now return a `RecordExists` error. - Versions 3.1.0 and later are not affected by this issue. This is a behaviour change for applications that relied on RELATE … SET id = … to silently replace existing edges; after the patch those calls return RecordExists instead. Applications that need "create or replace" semantics should use UPSERT (which is correctly permission-gated for the update half). ### Workarounds The defect only fires when the `RELATE` statement includes a `SET id = …` clause that resolves to an existing edge id. Applications that let SurrealDB auto-generate the edge id (the default — `RELATE a:1 -> edge -> b:1 SET ` with no `id` override) are not affected, because auto-generated ids do not collide with existing records. Where applications must use `SET id = …` (for example, to produce deterministic edge ids for idempotency), they should first verify that no record with the target id exists before issuing the statement, or restrict `CREATE` permission on the edge table to principals trusted with `UPDATE` on the same table. | ||
| Risiko 5 / 10 GHSA-fpxg-5xmv-922m | vor 1 Stunde(n) | |
| SurrealDB lets callers modify records using JSON Patch operations via the `UPDATE … PATCH` statement (and SDK equivalents such as `db.patch()`). One of those operations is `copy`, which duplicates one field's value into another field of the same record. A `PATCH` with an empty `from` — for example, `UPDATE thing:1 PATCH [{ op: 'copy', from: '', path: '/leak' }]` — was treated as "copy the entire record" and duplicated every field, including fields the caller has no permission to read, into the destination field the caller chose. The permission filter that hides protected field values from the response only knew to hide the *original* protected field names, not the new destinations, so the protected values were returned to the caller intact under the new field name. ### Impact An authenticated user with permission to issue `UPDATE … PATCH` against a record could read the values of any field on that record, regardless of field-level `PERMISSIONS FOR select` restrictions. The leak is confidentiality-only, and bounded to the fields of the single record the caller targets per PATCH request — it does not expose other records on the same table or any data outside that record's scope. ### Patches A patch has been introduced that rejects an empty `from` pointer at parse time for both `copy` and `move` operations. - Versions 3.1.0 and later are not affected by this issue. ### Workarounds Affected users who are unable to update should restrict `UPDATE … PATCH` to callers who already hold SELECT permission on every field of the target record — for them, the bug exposes nothing they can't already read. Otherwise, switch the mutation to an explicit `SET` or `MERGE` clause, which removes the attack surface since neither form accepts JSON Patch operations. | ||
| Risiko 5 / 10 GHSA-6g9v-7gq3-p2c6 | vor 1 Stunde(n) | |
| A record user with UPDATE access could read field values that field-level SELECT permissions hid from them. Arithmetic operators and `extend` embedded the raw operand into their error messages, and UPDATE permission checks evaluate against the unreduced document — so triggering such an error against a hidden field returned its value in the resulting error. ### Impact A record user issues an UPDATE that performs an incompatible operation against a hidden field — e.g. `UPDATE person:me SET probe = email + 1` when `email` is a string — and reads the value from the returned error (`Tried to compute "alice@example.com" + 1 …`). One field per operation, but the attacker can repeat against any field on any record they can UPDATE. ### Patches A patch has been introduced that replaces the raw operand in every `try_*` operator and in `extend` with the operand's type name (`"string"`, `"int"`, `"array"`, etc.). - Versions 3.1.0 and later are not affected by this issue. ### Workarounds Affected users who are unable to update should not grant UPDATE permission on records whose field-level SELECT permissions are expected to hide values from the same caller. | ||
| Risiko 9.5 / 10 CVE-2026-44939 | vor 12 Tag(en) | |
| ### Impact A critical command injection vulnerability has been identified in the Rancher Manager cluster import endpoint `/v3/import/{token}_{clusterId}.yaml` through unsanitized YAML parameters. This endpoint accepts an `authImage` query parameter that is rendered without sanitization into a generated Kubernetes manifest template. By including URL-encoded newlines in the parameter value, an attacker can break out of the `image:` field to inject arbitrary YAML keys and malicious configurations, such as commands to execute malicious containers. Exploitation of this vulnerability requires the following conditions to be met: - Attackers must obtain a valid cluster registration token (these tokens may be exposed, for example, through documentation, screenshots, or insecure communication channels). - The victim’s cluster operator must execute `kubectl apply` against a maliciously crafted URL. When a victim applies this compromised manifest using `kubectl apply`, a DaemonSet is deployed with the injected configuration. This DaemonSet: - Runs on all control-plane nodes with `hostNetwork: true` enabled. - Uses the `cattle` service account, which possesses `cluster-admin` privileges. - Mounts `/etc/kubernetes` directly from the host. - Executes attacker-controlled commands via the injected `command:` field. An attacker who successfully exploits this vulnerability could: - Achieve full control over downstream Kubernetes clusters. - Execute arbitrary code on control-plane nodes with elevated privileges. - Access sensitive cluster secrets and configurations via the privileged service account. - Disrupt cluster operations by manipulating critical control-plane workloads. - Establish persistent access through the deployed DaemonSet. **Note:** If you believe that you might have been impacted by this vulnerability, it's highly advised to review your clusters' logs and deployment logs for signs of malicious deployments and to rotate all service accounts and credentials that might have been exposed in such a scenario. Please refer to the associated [MITRE ATT&CK - Technique - Deploy Container](https://attack.mitre.org/techniques/T1610/) for further information about this category of attack. ### Patches This vulnerability is addressed by validating the `authImage` parameter to ensure it contains only valid OCI image reference characters, rejecting any input containing newlines, whitespace, or other characters that could break YAML syntax. Patched versions of Rancher include release `v2.14.2`, `v2.13.6`, `v2.12.10`, `v2.11.14` and `v2.10.12`. ### Workarounds If upgrading to a patched version immediately is not feasible, users are encouraged to apply the following workaround: - Review the `kube-api-auth` DaemonSet: Inspect downstream clusters for the `kube-api-auth` DaemonSet within the `cattle-system` namespace (which targets control-plane nodes). Review this resource configuration carefully for: - Unexpected `command:` or `args:` fields in the container specification. - References to non-standard or suspicious container images. - Any modifications occurring after the initial cluster import. - Validate manifest integrity: Before running `kubectl apply` on any import manifests, verify that the source URLs originate from trusted sources and match expected patterns. ### Credits This security issue was reported by the following collaborators according to our responsible disclosure policy: - Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC). - Michael Wollner from Deutsche Telekom AG. ### References If you have any questions or comments about this advisory: - Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries. - Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository. - Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/). | ||
| 18.06.2026 - Operation Endgame 4.0 | 4.160.519 Datensätze geleaked | |
| Email addresses, Passwords On 18 June 2026, the latest phase of Operation Endgame targeted the SocGholish malware operation, a prolific malware distribution network used to compromise systems and facilitate further cybercrime. Coordinated by international law enforcement agencies with support from Europol and Eurojust, the operation remediated almost 15,000 compromised websites and disrupted more than 100 servers and domains used to distribute malware. Authorities initially provided HIBP with 154k impacted email addresses and more than half a million previously unseen passwords recovered during the operation. The following week, a further 4M email addresses and 9M passwords relating to the StealC malware operation targeted by Operation Endgame were provided to HIBP, bringing the total to almost 4.2M unique email addresses. |
||
| 15.06.2026 - June 2026 Stealer Logs | 56.278.397 Datensätze geleaked | |
| Email addresses, Passwords In June 2026, a collection of accumulated stealer logs from various sources was added to HIBP. The corpus comprised 56M unique email addresses across hundreds of millions of stealer log records. The data also contained 124M unique passwords, which have been added to Pwned Passwords and are now searchable. Individuals can view any records captured against their email address in the stealer logs section of their dashboard. Organisations can see logs affecting their domain via the stealer logs API. |
||
| 15.06.2026 - Sysco | 2.691.852 Datensätze geleaked | |
| Customer feedback, Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Usernames In June 2026, the food distribution company Sysco was targeted by a ShinyHunters "pay or leak" extortion campaign. Data was subsequently published containing 2.7M unique email addresses belonging to staff and customers. The data also contained largely corporate contact information including names, phone numbers, physical addresses, internal job titles, and customer feedback. |
||
| 12.06.2026 - American Tower | 216.601 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses In June 2026, telecommunications tower infrastructure company American Tower was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data allegedly taken from the company containing more than 200k unique email addresses belonging to employees, contractors, customers, and leads. Exposed data also included names, addresses, and phone numbers. |
||
| 12.06.2026 - JCPenney | 368.418 Datensätze geleaked | |
| Dates of birth, Email addresses, Government issued IDs, Job titles, Names, Phone numbers, Physical addresses, Usernames In June 2026, retailer JCPenney and associated brands were targeted in a ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from JCPenney through the exploitation of a critical zero-day vulnerability in Oracle PeopleSoft was later published publicly. The exposed records indicated they primarily related to internal HR systems and impacted current and former employees. The data included 368k corporate and personal email addresses, names, dates of birth, Social Security numbers, phone numbers and home addresses. |
||
| 11.06.2026 - Ralph Lauren | 139.903 Datensätze geleaked | |
| Age groups, Email addresses, Genders, Names, Phone numbers In June 2026, fashion retailer Ralph Lauren was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published hundreds of gigabytes of data they claimed was obtained from the organisation's Salesforce instance, including 140k unique email addresses along with names, phone numbers, genders and age groups. |
||
| 09.06.2026 - University of Nottingham | 454.635 Datensätze geleaked | |
| Academic records, Citizenship statuses, Dates of birth, Disabilities, Email addresses, Ethnicities, Genders, IP addresses, Names, Passport numbers, Phone numbers, Physical addresses, Purchases, Salutations, Usernames In June 2026, the University of Nottingham was the target of a cyber attack, later linked to a ShinyHunters "pay or leak" extortion campaign. Tens of gigabytes of data were subsequently published online and included 455k unique email addresses along with extensive personal information including names, addresses, phone numbers, ethnicities, disabilities, passport numbers and information relating to academic enrolments and fee payments. In a post about the incident, the university advised that the breach affected both "current students, and alumni". |
||
| 05.06.2026 - Madison Square Garden Sports | 9.796.738 Datensätze geleaked | |
| Customer service records, Email addresses, Names, Phone numbers, Physical addresses In June 2026, the sports and entertainment company Madison Square Garden Sports was the target of a ShinyHunters "pay or leak" extortion campaign. The group later published the alleged data, which included almost 10M unique email addresses spanning staff and customers, along with extensive personal, employment and customer relationship information. |
||
| 30.05.2026 - Atlas Menu | 63.926 Datensätze geleaked | |
| Email addresses, IP addresses, Passwords, Support tickets, Usernames In May 2026, the GTA V and CS2 cheat service Atlas Menu suffered a data breach. An attacker claimed to have gained access to all Atlas systems and published the service's database to a public GitHub repository. The incident exposed 64k unique email addresses along with usernames, IP addresses, support tickets and passwords stored as bcrypt hashes. |
||
| 29.05.2026 - BCD Travel | 396.313 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Support tickets In May 2026, the corporate travel management company BCD Travel was claimed as a victim of the ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from BCD was subsequently published publicly in early June and contained 396k unique email addresses. Other exposed data included names, addresses, phone numbers, job titles and employer names, spanning a variety of different data sets including leads, internal staff and support tickets. |
||
| 23.05.2026 - Baker Distributing | 102.935 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses, Support tickets In May 2026, the HVAC/R wholesale distributor Baker Distributing Company was added to the ShinyHunters data extortion group's "pay or leak" site. In early June, the group publicly published data they claimed had been obtained from Baker's SharePoint and Salesforce infrastructure including 103k unique email addresses along with names, physical addresses, phone numbers and tickets relating to the company's HVAC contractor customer base. The exposed data was largely corporate contact and support information with limited sensitivity. |
||
| 23.05.2026 - Charter | 4.851.517 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses In May 2026, the telecommunications company Charter Communications (the parent company behind the consumer broadband and cable brand Spectrum) was named by the ShinyHunters group in a "pay or leak" extortion campaign. The group later published the data, which exposed 4.9M unique email addresses along with names, phone numbers and physical addresses. A subset of approximately 85k records originating from an internal employee directory also included job titles. Charter confirmed the incident, but stated that no sensitive personal information or customer proprietary network information (CPNI) was exfiltrated. |
||
| 23.05.2026 - DentaQuest | 2.553.599 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Government issued IDs, Health insurance information, Names, Phone numbers, Physical addresses In May 2026, the dental benefits administrator DentaQuest was the target of a ShinyHunters "pay or leak" extortion campaign that resulted in the group publicly publishing hundreds of gigabytes of data allegedly obtained from the company. The data included 2.6M unique email addresses along with names, addresses and phone numbers. Much of the data appeared in healthcare enrollment files (ASC X12 transaction sets) with some containing Medicaid IDs, while additional data appeared in member records and related files. DentaQuest acknowledged "a cybersecurity incident involving unauthorized access to a limited portion of our network", and advised they had contained the attack and mitigated the threat. |
||
| 05.05.2026 - Cushman & Wakefield | 310.431 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses, Salutations In May 2026, the real estate services firm Cushman & Wakefield was the target of a "pay or leak" extortion campaign by the ShinyHunters group. Following the threat, the group publicly published data they alleged had been obtained from the firm, consisting mostly of C&W email addresses along with tens of thousands of external email addresses and corporate contact records. The exposed data was primarily business information, including names, job titles, company addresses and phone numbers. |
||
| 30.04.2026 - Reborn Gaming | 126 Datensätze geleaked | |
| Email addresses, IP addresses In April 2026, the gaming community Reborn Gaming suffered a data breach due to a vulnerability in cPanel and WebHost Manager (WHM). The breach exposed 126 unique email addresses along with IP addresses and Steam IDs. Reborn Gaming self-submitted the data to Have I Been Pwned. |
||
| 28.04.2026 - Vimeo | 119.167 Datensätze geleaked | |
| Email addresses, Names In April 2026, the ShinyHunters extortion group listed Vimeo on their extortion portal as part of their "pay or leak" campaign. They subsequently published hundreds of gigabytes of data, predominantly consisting of video titles, technical data and metadata. The data also included 119k unique email addresses, sometimes accompanied by names. Vimeo attributed the exposure to a breach of Anodot, a third-party analytics vendor, and advised the incident does not include "Vimeo video content, valid user login credentials, or payment card information". |
||
| 26.04.2026 - CTT | 468.124 Datensätze geleaked | |
| Email addresses, Names, Phone numbers In April 2026, data allegedly obtained from CTT, Portugal's national postal service, was posted to a public hacking forum. The data included 468k unique email addresses along with names, phone numbers and parcel tracking numbers which can be used to retrieve the tracking history of the parcel. |
||
| 24.04.2026 - Udemy | 1.401.259 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Payment methods, Phone numbers, Physical addresses In April 2026, online training company Udemy was the victim of a “pay or leak” extortion attempt perpetrated by the ShinyHunters group. The data was subsequently leaked publicly and contained 1.4M unique email addresses belonging to customers and instructors. The data also included names, physical addresses, phone numbers, employer information and instructor payout methods including PayPal, cheque and bank transfer. |
||
| 20.04.2026 - ADT | 5.488.888 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Partial government issued IDs, Phone numbers, Physical addresses In April 2026, home security firm ADT confirmed a data breach by ShinyHunters, which listed the company on its website as part of a "pay or leak" extortion attempt. The breach impacted 5.5M unique email addresses along with names, phone numbers and physical addresses. ADT also advised that "in a small percentage of cases, dates of birth and the last four digits of Social Security numbers or Tax IDs were included" and that it had contacted all affected people. |
||
| 20.04.2026 - Aman | 215.563 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Language preferences, Names, Nationalities, Phone numbers, Physical addresses, Spouses names, VIP statuses In April 2026, the ultra-luxury hotel brand Aman was named by ShinyHunters as the target of a "pay or leak" extortion campaign, with the data allegedly obtained from their Salesforce CRM. The data was subsequently leaked publicly and contained over 200k unique email addresses. Whilst not present on all records, the data also included genders, physical addresses, phone numbers, nationalities, dates of birth, spouse names and VIP status codes. |
||
| 20.04.2026 - Canada Life | 237.810 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses, Salutations, Support tickets In April 2026, Canada Life was the victim of a "pay or leak" extortion campaign by the ShinyHunters group. The group subsequently published the data which contained over 200k unique email addresses along with names, phone numbers, physical addresses and, in some cases, customer support tickets. In their disclosure notice, Canada Life advised that "it is a small proportion of our customers who may have been impacted". In the wake of the incident, Canada Life also published an alert cautioning customers to be wary of phishing attacks, a pattern often seen after the public release of breached data. |
||
| 20.04.2026 - Pitney Bowes | 8.243.989 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses In April 2026, the hacking collective ShinyHunters claimed to have obtained data from Pitney Bowes as part of a broader extortion campaign that also named several other organisations. After negotiations allegedly failed, the group publicly released the data which included 8.2M unique email addresses, along with names, phone numbers and physical addresses. A subset of the data also included Pitney Bowes employee records with job titles. |
||
| 18.04.2026 - Carnival | 7.531.359 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Geographic locations, Loyalty program details, Names, Salutations In April 2026, the notorious hacking collective ShinyHunters claimed they had obtained a substantial volume of data belonging to the Carnival cruise operator and attempted to extort the organisation to prevent the data from being leaked. The following week, the group published the data publicly, which contained 8.7M records with 7.5M unique email addresses. The data contained fields indicating it related to the Mariner Society loyalty program run by Holland America, a cruise line brand under Carnival, and included names, dates of birth, genders and data relating to status within the loyalty program. Carnival acknowledged a phishing incident involving a single user account and advised they were working to better understand the scope of the unauthorised activity. |
||
| 15.04.2026 - Kemper | 269.299 Datensätze geleaked | |
| Email addresses, Names, Partial credit card data, Phone numbers, Physical addresses, Purchases In April 2026, the American insurance holding company Kemper Corporation was named by the ShinyHunters ransomware group in a "pay or leak" extortion campaign. The attackers allegedly accessed Kemper's Salesforce environment via social engineering as part of a broader campaign targeting hundreds of organisations using the same method. The group later published tens of gigabytes of data they claimed included internal directory data, Salesforce records and Stripe payment logs. Among the 269k unique email addresses were names, phone numbers, physical addresses and partial payment card data including the last 4 digits, expiry dates and card brands. Kemper confirmed the incident and stated they had engaged third-party cybersecurity experts and notified law enforcement. |
||
| 15.04.2026 - Zara | 197.376 Datensätze geleaked | |
| Email addresses, Geographic locations, Purchases, Support tickets In April 2026, the fashion brand Zara was among a number of organisations targeted by the ShinyHunters extortion group as part of their "pay or leak" campaign. The group claimed the breach was related to a compromise of the Anodot analytics platform and subsequently published a terabyte of data allegedly including 95M support ticket records. The data contained 197k unique email addresses alongside product SKUs, order IDs and the market the support ticket originated in. Zara's parent company Inditex advised that the incident didn't affect passwords or payment information. |
||
| 14.04.2026 - Abrigo | 711.099 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses In April 2026, the fintech software company Abrigo was targeted in a "pay or leak" extortion attempt by the ShinyHunters group. Shortly after, data allegedly taken from the company's Salesforce instance was published publicly and contained over 700k unique email addresses belonging to both Abrigo staff and external contacts. Whilst separate from Abrigo's Salesforce compromise via the Drift application connector the previous year, the data fields described in that incident are consistent with the ShinyHunters data, namely that it was "business contact information" including "institution name, employee name, email addresses, and phone numbers". |
||
| 12.04.2026 - Marcus & Millichap | 1.837.078 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses In April 2026, the commercial real estate brokerage firm Marcus & Millichap was named as one of multiple alleged victims of the ShinyHunters hacking and extortion group. Data alleged to have been obtained from the company was subsequently released publicly and included 1.8M unique email addresses, along with names, phone numbers and employment-related information including employer, job title and physical company address. In their disclosure notice, Marcus & Millichap advised that data which may have been accessed appeared limited to "company forms, templates, marketing materials, and general contact information". |
||
| 12.04.2026 - Mytheresa | 84.108 Datensätze geleaked | |
| Email addresses, Names, Partial credit card data, Phone numbers, Physical addresses, Purchases, Salutations In April 2026, the luxury fashion e-commerce platform Mytheresa was listed as a victim of the ShinyHunters "pay or leak" extortion group. After the ransom deadline passed, the group publicly released the data which contained 84k unique email addresses. The exposed data also included names, phone numbers, physical addresses, purchases and partial credit card data including card type, last 4 digits and expiry date. |
||
| 10.04.2026 - McGraw Hill | 13.500.136 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In April 2026, education company McGraw Hill confirmed a data breach following an extortion attempt. Attributed to a Salesforce misconfiguration, the company stated the incident exposed "a limited set of data from a webpage hosted by Salesforce on its platform". More than 100GB of data was later publicly distributed, containing 13.5M unique email addresses across multiple files, with additional fields such as name, physical address and phone number appearing inconsistently across some records. |
||
| 08.04.2026 - 7-Eleven | 185.256 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Phone numbers, Physical addresses In April 2026, 7-Eleven was the victim of a "pay or leak" extortion campaign by ShinyHunters, with the data later published that month. The incident exposed 185k unique email addresses, along with names, physical addresses, dates of birth and phone numbers. A small number of records also contained additional exposed data fields. The company later advised the breach was limited to "certain 7-Eleven systems used to store franchisee documents", a statement consistent with the exposed data. |
||
| 07.04.2026 - My Lovely AI | 106.271 Datensätze geleaked | |
| Email addresses, Social media profiles In April 2026, the NSFW AI girlfriend platform My Lovely AI suffered a data breach that exposed over 100k users. The data included user-created prompts and links to the resulting AI-generated images, along with a small number of Discord and X usernames. |
||
| 06.04.2026 - LegionProxy | 10.144 Datensätze geleaked | |
| Email addresses, Names, Passwords, Purchases In April 2026, the commercial residential and ISP proxy network LegionProxy suffered a data breach. The incident exposed 10k email addresses, bcrypt password hashes, names and purchases. |
||
| 03.04.2026 - Amtrak | 2.147.679 Datensätze geleaked | |
| Email addresses, Names, Physical addresses, Support tickets In April 2026, the hacking group ShinyHunters claimed they had breached Amtrak. The group typically compromises organisations' Salesforce instances before demanding a ransom and later, if not paid, dumping the data publicly. They subsequently published the alleged data which contained over 2M unique email addresses along with names, physical addresses and customer support records. |
||
| 02.04.2026 - SongTrivia2 | 291.739 Datensätze geleaked | |
| Auth tokens, Avatars, Email addresses, Names, Passwords, Usernames In April 2026, the music trivia platform SongTrivia2 suffered a data breach that was subsequently published to a public hacking forum. The data contained a total of 291k unique email addresses sourced from either Google OAuth logins or accounts created on the site, the latter also containing bcrypt password hashes. The data also included names, usernames and avatars. |
||
| 31.03.2026 - Hallmark | 1.736.520 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses, Support tickets In March 2026, Hallmark suffered an alleged breach and subsequent extortion after attackers gained access to data stored within Salesforce. The data was later published after the extortion deadline passed, exposing 1.7M unique email addresses across both Hallmark and the Hallmark+ streaming service, along with names, phone numbers, physical addresses and support tickets. |
||
| 27.03.2026 - ZenBusiness | 5.118.184 Datensätze geleaked | |
| Email addresses, Names, Phone numbers In March 2026, the hacker and extortion group "ShinyHunters" claimed to have obtained a substantial corpus of data from ZenBusiness, a business formation and compliance platform. The group claimed the data had been exfiltrated from platforms including Snowflake, Mixpanel and Salesforce, and threatened to publish it if a ransom was not paid. The following month, after claiming payment had not been made, ShinyHunters publicly released the data. The collection amounted to many terabytes across thousands of files that appeared to originate from multiple systems and business functions, including leads, support records and other CRM-related data. The data contained approximately 5M unique email addresses, often accompanied by name and phone number depending on the source file. |
||
| 26.03.2026 - BreachForums Version 5 | 339.778 Datensätze geleaked | |
| Email addresses, Passwords, Usernames In March 2026, a breach of one of the many iterations of the BreachForums hacking forum known as "Version 5" was publicly disclosed. The incident exposed 340k unique email addresses along with usernames and argon2 password hashes. |
||
| 25.03.2026 - Addi | 34.532.941 Datensätze geleaked | |
| Age groups, Credit scores, Device information, Email addresses, Government issued IDs, Income levels, IP addresses, Latitude and longitude pairs, Names, Phone numbers, Physical addresses, Purchases, Socioeconomic levels In March 2026, the Colombian fintech company Addi identified unauthorised activity on its platform and advised customers that "it is possible that your personal information may have been compromised". The "pay or leak" extortion group ShinyHunters subsequently claimed responsibility and published a large trove of personal data allegedly obtained from Addi. The data included 34M unique email addresses from credit scoring requests, credit bureau records, customer identity records and email validation logs. It also contained government issued IDs (Cédula de Ciudadanía), estimated income, socioeconomic levels, purchases and other credit-related data points. |
||
| 25.03.2026 - Sound Radix | 292.993 Datensätze geleaked | |
| Email addresses, Names, Passwords In March 2026, the audio production tools company Sound Radix disclosed a data breach that they subsequently self-submitted to HIBP. The incident impacted 293k unique email addresses and names. Sound Radix advised that it is possible that additional data including hashed passwords may have been exposed, and that no financial or credit card information was impacted. |
||
| 19.03.2026 - Berkadia | 305.216 Datensätze geleaked | |
| Email addresses, Employers, Names, Phone numbers, Physical addresses In March 2026, the commercial real estate finance company Berkadia was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data they alleged was taken from Berkadia's Salesforce instance, including over 300k unique email addresses as well as names, physical addresses and phone numbers, among other data. |
||