| 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 ? / 10 MAL-2026-19118 | vor 1 Stunde(n) | |
| --- _-= Per source details. Do not edit below this line.=-_ ## Source: ghsa-malware (6ca0694213fab27d0292d43aee954b81c13e551a81563903fb9afd7e54a9dda2) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it. | ||
| Risiko ? / 10 RUSTSEC-2026-0503 | vor 1 Stunde(n) | |
| When extracting archives, `eazip` validates symlink entries before writing them. The validation function `validate_symlink()` (`src/utils/mod.rs`) scans for backslash and NUL bytes, but passes the symlink's *name* where the symlink's *target* was intended: ```rust memchr2(b'\\', b'\0', name.as_bytes()) // should be target.as_bytes() ``` As a result, symlink *targets* containing backslash or NUL bytes pass validation. On Windows, backslash is a path separator, so targets such as `..\..\..\Windows\system32\evil.exe` also defeat the remaining depth check, which splits on `/` only. A crafted archive can therefore create symlinks that resolve outside the extraction directory — including UNC targets such as `\\host\share\...` — redirecting writes to arbitrary filesystem locations chosen by the attacker. Applications that extract untrusted archives with `eazip` on Windows targets are affected; on Unix targets backslash is not a separator, which limits exposure there. The vulnerability was introduced in version 0.2.5 and fixed in 0.2.7 ([a1phyr/eazip@0e4caa13](https://github.com/a1phyr/eazip/commit/0e4caa13d59f5ba15aaac332f5534260c3b8fc43)), which rejects backslash and NUL bytes in the symlink target. It was privately reported to the maintainer on 2026-11-06 and credited in the 0.2.7 release notes. | ||
| Risiko 5.5 / 10 CVE-2026-119375 | vor 1 Stunde(n) | |
| SQLite versions before 3.54.0 can return uninitialized page-cache memory when a process opens a database file together with a sibling write-ahead-log (`-wal`) file whose page size differs from the database's. A crafted pair of files can make ordinary queries return stale bytes from the process's memory. The attack vector is local and needs the victim to open the files. `sqlcipher-src` ships the SQLCipher amalgamation (SQLCipher is built on SQLite and contains the same `sqlite3WalReadFrame` code) for `-sys` crates to compile, so a build that uses it is susceptible to the vulnerability. The releases `419.0.3` to `419.0.6` bundle SQLCipher `4.19.0` on SQLite `3.53.4` and are affected. `sqlcipher-src` was updated in `420.0.0` (SQLCipher `4.20.0` on SQLite `3.54.1`), which contains the fix. The releases `0.1.0` and `0.1.1` contain no SQLCipher source. `libsqlite3-sys` `0.39.0` and `0.39.1` depend on `sqlcipher-src =419.0.6` for their `bundled-sqlcipher` feature. Only a process that opens a database file, with its `-wal`, that a less trusted party could have written is exposed. | ||
| Risiko ? / 10 RUSTSEC-2026-0501 | vor 1 Stunde(n) | |
| `KeyShares::from_backup_format` (the Shamir backup share reader, public since 0.2.0, the crate's first release) accepted a share whose x coordinate is 0, and `KeyShares::recover_private_key` interpolates the shares at x = 0 to recover the key. At an x of 0 the interpolation answers that share's y value alone, so an attacker who supplies one share in that form — with the share's integrity tag ground to match the honest set's — chooses the recovered key outright. The non-canonical zero x = p works the same way, and a repeated x past the threshold window also passed. An application that recovers a Shamir backup from shares it did not produce — a custodian's medium, a share pasted by hand, a set restored from another writer — could be handed the attacker's key as the recovered one. A set the crate's own writer produces never carries such a share; the door is the reader. 0.8.7 refuses such a set before interpolating (the 0.9 line's next prerelease carries the same refusal). Where upgrading is not possible, before recovering split each share on `.` into four fields, base58-decode the x field, and refuse the set if it decodes to zero (the one-character field `1`, or a value at or above the field prime) or if two shares carry the same x. | ||
| Risiko ? / 10 RUSTSEC-2026-0500 | vor 1 Stunde(n) | |
| `Beef::merge_raw_tx` and `BeefTx::from_raw_tx` accept raw bytes without a `Result`. For bytes that are not exactly one transaction (a transaction followed by bytes, a cut transaction, bytes that are no transaction at all), `Beef::sort_txs`, `verify_structure`, `verify_valid` and `is_valid` could answer valid, even with no BUMP and no parent in the BEEF, and, where the entry carried a BUMP index, treat the hash of those bytes as a proven transaction id; an entry that names it as a parent was answered valid too. The wire readers (`Beef::from_binary`, `verify_stream`, `Transaction::from_beef`, `from_atomic_beef`) parse every entry and are not affected. Reaching this needs an application that passes bytes it did not parse to `merge_raw_tx` or `BeefTx::from_raw_tx` and then relies on the verdict or on the transaction the BEEF hands back. 0.8.5 refuses such an entry at all four verdict doors, with or without a BUMP index, and every entry that names it as a parent. Where upgrading is not possible, do not rely on `is_valid` or `verify_valid` alone for such an entry: check that the bytes are exactly one transaction before merging them. | ||
| Risiko ? / 10 RUSTSEC-2026-0499 | vor 1 Stunde(n) | |
| `Signature::from_der` read a DER-encoded ECDSA signature leniently. It read as the signature: the signature followed by other bytes; a sequence length shorter than its contents, or longer with bytes after them (a length byte with its high bit set among them); and an R or S preceded by a zero byte it did not need. It read a lone-zero R or S as zero. `messages::verify`, `compat::bsm::verify_message_der`, `auth::Certificate::verify`, `auth::VerifiableCertificate::verify`, `wallet::ProtoWallet::verify_signature` and `kvstore::KVStoreInterpreter::verify_signature` read through it, and each verified such a form of a valid signature. Given one signature a key holder made, anyone could produce other byte strings that verify as that signature over the same data. No form verifies over other data: an application that acts on the verdict alone is not affected; one that compares, hashes or stores a signature's bytes is. 0.8.6 refuses each form as `Error::InvalidSignature`. A signature's bytes are still not unique after the patch: the same signature with S replaced by n - S verifies, so an application that keys on the bytes also requires `Signature::is_low_s()`. | ||
| Risiko ? / 10 RUSTSEC-2026-0498 | vor 1 Stunde(n) | |
| `Transaction::from_binary` and `Transaction::from_hex` read one transaction from the front of their input, did not check that the input ended there, and kept the whole input as the transaction's cached serialization: `to_binary`, `to_hex` and `id()` then answered for bytes that are not the transaction's. `Transaction::from_json`, given a `hex` field, reads it through `from_hex` and answers the same. `from_ef`, `from_hex_ef` and `parse_script_offsets` also read a prefix. An application that takes bytes or hex from outside, parses them with these readers and then uses `id()` or the serialization could be given one transaction under another identity: the same parsed fields, a different id. An application that passes them only bytes it produced or has already checked is not affected. 0.8.5 refuses a byte after the transaction; `Transaction::from_reader` reads from the front of a longer buffer. Where upgrading is not possible, parse with `Transaction::from_binary`, call `tx.invalidate_caches()` (public from 0.3.16) and require `tx.to_binary() == bytes`. | ||
| Risiko ? / 10 RUSTSEC-2026-0497 | vor 1 Stunde(n) | |
| `Transaction::from_json`, for a document with no `hex` member, held each input's `txid` member as given. An input `txid` that is not 64 hex digits (`"zz"`, `""`, 63 or 65 digits, characters that are not hex digits) answered `Ok`: `source_txid` and `to_json` gave the text back, while `to_binary` wrote the input as spending the txid of 32 zero bytes and `id()` hashed those bytes. Documents naming different texts were one transaction, spending an outpoint none of them named. An application that reads a peer's transaction document with `from_json` and relies both on the text of its inputs and on its bytes or `id()` is affected; one that reads only documents it produced is not. 0.8.6 refuses such a txid (`Invalid txid of input N: expected 64 hex digits`). Where upgrading is not possible, require each input's `txid` to be 64 ASCII hex digits before calling `from_json`. | ||
| Risiko 7.5 / 10 CVE-2026-42189 | vor 1 Stunde(n) | |
| A server that answers a keyboard-interactive authentication request with prompts (`Auth::Partial`, as a TOTP or other second-factor login does) then parses the client's `SSH_MSG_USERAUTH_INFO_RESPONSE`. russh read the number of responses from that message and reserved a vector of that many entries before reading any of them. A client that has not authenticated can send a very large count in a packet that carries no responses at all, and the server tries to allocate several gigabytes and may be killed for running out of memory. Servers whose handler keeps the default behaviour, which rejects keyboard-interactive authentication, are not affected. From 0.60.1 the count is limited by how many responses the remaining packet data could actually hold. | ||
| Risiko ? / 10 CVE-2026-116794 | vor 1 Stunde(n) | |
| A key added to an SSH agent with the confirm constraint (what `ssh-add -c` sends) must not be used to sign until the user approves each use. russh's agent server (`russh::keys::agent::server`) accepted the constraint, but when a sign request arrived for such a key it used a fixed `true` in place of the result of `Agent::confirm`, so the application's confirmation step never ran. This started in 0.50.0-beta.12; 0.50.0-beta.8 to beta.11 still called `confirm`, and earlier russh releases have no agent server. Any process that can reach the agent, including a remote host when the agent is forwarded, can then sign with the protected key without the user's approval, for example to log in elsewhere as the user. The private key itself is not disclosed. Agents whose `Agent::confirm` keeps the default, which always returns `true`, behave the same before and after the fix. From 0.65.0 the agent server calls `Agent::confirm` for confirm-constrained keys and refuses to sign when it returns `false`. Implementations that left `confirm` unimplemented (for example as `todo!()`) will now reach that code. | ||
| Risiko 7.5 / 10 CVE-2026-48110 | vor 1 Stunde(n) | |
| Many of russh's client and server message handlers decoded length-prefixed strings, byte fields and name-lists from the peer into owned `String`, `Vec` or name-list values first and only checked their size and meaning afterwards. This includes the algorithm name-lists in `SSH_MSG_KEXINIT`, which a server parses during the initial key exchange, before any authentication. A peer can fill these fields with oversized or highly fragmented values, for example a name-list of hundreds of thousands of one-letter algorithm names, and make russh allocate far more memory than the packet itself takes. With many concurrent connections this can exhaust the memory of a server process. From 0.61.0, name-lists are rejected before they are split into separate strings when they are longer than 16 KiB or hold more than 1,024 entries, and the key exchange decodes its algorithm lists through this bounded decoder. | ||
| Risiko 7.5 / 10 CVE-2026-46702 | vor 1 Stunde(n) | |
| With `zlib` or `zlib@openssh.com` compression negotiated, the packet length that russh checks applies to the compressed payload only. The decompressor kept growing its output buffer until the whole payload was inflated, with no limit of its own, so a packet that is small on the wire could expand to hundreds of megabytes before it was parsed. The default server configuration offers both zlib methods, and a client that lists compression first can select it during the initial key exchange. That client can then send such a packet after `NEWKEYS` but before authenticating, so a russh server with default settings can be made to use large amounts of memory by an unauthenticated peer. A malicious server can do the same to a client that negotiated compression. From 0.61.1, decompressed output is capped at the same maximum as an uncompressed packet (256 KiB plus a few bytes of header room), and larger packets are rejected with `Error::PacketSize`. | ||
| Risiko 7.5 / 10 CVE-2026-102823 | vor 1 Stunde(n) | |
| On the client side, russh passed channel messages from the server (data, extended data, EOF, close, success, failure, open failure and the exit-status, exit-signal and xon-xoff requests) to the application's `client::Handler` callbacks without checking that the channel number belonged to a channel the client had opened and the server had confirmed. The server side already performed this check. A malicious or compromised SSH server can therefore send these messages for any channel number, including the next number the client will allocate (they are assigned in order) or one it has already closed. An application that tracks per-channel state can be made to record a false exit status, see a channel close before its real output arrives, or panic when it looks up a channel it does not know. From 0.63.1 the client ignores channel messages for channels that are not established and confirmed, and handles an open failure only for a channel it is actually opening. | ||
| Risiko 7.5 / 10 CVE-2024-43410 | vor 1 Stunde(n) | |
| When reading a packet, russh took the 4-byte packet length sent by the peer and sized its receive buffer from it without any upper bound. The length is fully controlled by the other side of the connection and is read before authentication, so an unauthenticated client can claim packets of up to about 4 GiB and make a server allocate that much memory per connection. A few such connections are enough to run the process out of memory. From 0.44.1, lengths above 256 KiB are rejected with `Error::PacketSize` before the buffer is sized. | ||
| 04.10.2026 - Double Counter | 274.922 Datensätze geleaked | |
| Email addresses, Geographic locations, Names, Usernames In October 2026, the Discord server protection service Double Counter suffered a data breach attributed to a vulnerability in the Metabase analytics tool. In its disclosure notice, Double Counter advised that attackers gained access to a subset of its data. A corpus of data was subsequently published publicly and contained 275k unique email addresses and Discord usernames. A small number of records belonging to paying subscribers whose purchases were processed via Stripe were also present and included names, countries and postcodes. |
||
| 09.09.2026 - AfD | 345.439 Datensätze geleaked | |
| Email addresses, Email messages In September 2026, the German political party Alternative für Deutschland (AfD) suffered a data breach which exposed 345k unique email addresses. The following month, hundreds of gigabytes of data containing hundreds of thousands of emails and attachments was published online, with searchable AI-generated summaries and downloadable original files. An analysis of the incident reported that the breach was detected as early as 9 September, with a subsequent intrusion occurring five days later. In its public statement, AfD attributed the breach to an attack on a hosting provider, identified in subsequent reporting as the party-owned Alternita Dienstleistungs GmbH. |
||
| 07.09.2026 - Medela | 423.947 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Salutations, Support tickets In September 2026, Swiss medical device company Medela was the target of a ShinyHunters "pay or leak" extortion campaign. The data allegedly obtained in the breach was later published publicly and included 424k unique email addresses belonging predominantly to healthcare professionals, Medela staff and leads. The exposed data consisted primarily of corporate contact information, including names, physical addresses and phone numbers, with some records also containing associated support tickets. |
||
| 29.08.2026 - Neogen | 435.963 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Salutations In August 2026, the food and animal safety organisation Neogen was the target of a ShinyHunters "pay or leak" extortion attempt. The group later published data it claimed had been obtained from Neogen. The data consisted largely of corporate contact records and included 436k unique email addresses from mailing lists, employee records and other contacts. |
||
| 27.08.2026 - Manchester Airports Group | 8.849.657 Datensätze geleaked | |
| Browser user agent details, Email addresses, Geographic locations, IP addresses, Names, Phone numbers, Purchases, Vehicle registration plates In August 2026, Manchester Airports Group (MAG) disclosed a data breach impacting their services. The incident was later claimed by the FulcrumSec hacking group, who subsequently published email addresses and phone numbers relating to 8.8M customers of Manchester, Stansted and East Midlands airports. The data contained personal information relating to airport services, including vehicle registrations and parking history, Fast Track purchases and lounge bookings. In their disclosure notice, MAG advised that "at no point has passenger safety or aviation security been compromised". |
||
| 21.08.2026 - McKesson | 6.404.340 Datensätze geleaked | |
| Dates of birth, Email addresses, Employers, Genders, Names, Personal health data, Phone numbers, Physical addresses In August 2026, healthcare and pharmaceutical company McKesson was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published a substantial corpus of data they alleged was sourced from the company, which included 6.4M unique email addresses among other personal and corporate data attributes. The impacted data related to a range of individuals and roles, including marketing campaign recipients, patients, staff and healthcare provider contacts. In McKesson's disclosure notice, the company advised it had identified unauthorised access to "certain third-party applications and the exfiltration of certain data was associated with a subset of customers within our Oncology & Multispecialty and Medical-Surgical business units", but had "reasonable assurance of no ongoing unauthorized activity". |
||
| 15.08.2026 - Oz Hair and Beauty | 1.988.331 Datensätze geleaked | |
| Email addresses, Geographic locations, Names, Phone numbers, Purchases In August 2026, Australian beauty retailer Oz Hair and Beauty was the target of an xpl0itrs extortion attack. The group subsequently published data allegedly obtained from the company, which included 2M unique email addresses along with names, phone numbers, geographic locations (suburb and postcode) and purchases. |
||
| 13.08.2026 - Carhartt | 12.933.413 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In August 2026, clothing retailer Carhartt was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data allegedly obtained from the company including 12.9M unique email addresses, names, phone numbers and physical addresses. The published corpus also contained millions of synthetic records that did not relate to real individuals and were excluded from the breach. |
||
| 12.08.2026 - Sharecare | 318.185 Datensätze geleaked | |
| Dates of birth, Email addresses, Employers, Genders, Government issued IDs, Job titles, Marital statuses, Names, Phone numbers, Physical addresses In August 2026, the digital health company Sharecare was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data it claimed was taken from Sharecare's systems, containing 318k unique email addresses. Most of the data consisted of B2B sales and marketing records with names, physical addresses, phone numbers, job titles and employers. The data also included a small number of Brazilian health insurance plan members, including dates of birth, genders, marital statuses and CPF numbers (Brazilian taxpayer identification numbers). |
||
| 06.08.2026 - Fanlore | 144.520 Datensätze geleaked | |
| Email addresses, Names, Passwords, Usernames In August 2026, the Organization for Transformative Works (OTW) identified unauthorised access to the Fanlore wiki it operates. The breach resulted in the exposure of 145k unique email addresses along with usernames and passwords stored as either MD5 or PBKDF2 hashes. OTW self-submitted the exposed data to HIBP. |
||
| 05.08.2026 - CyrusOne | 373.460 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Support tickets In August 2026, data centre operator CyrusOne was the target of a ShinyHunters "pay or leak" extortion attempt. The group subsequently published data allegedly obtained from the company, which included 373k unique email addresses across records relating to users, sales leads and CyrusOne employees. The data largely consisted of corporate contact information, including names, physical addresses, phone numbers and job titles. It also included support tickets and other information related to the organisation's operations. |
||
| 03.08.2026 - Chess.com (2026) | 4.653.212 Datensätze geleaked | |
| Email addresses, Geographic locations, Names, Usernames In August 2026, millions of records allegedly sourced from Chess.com were posted online. The data contained 7.3M rows with 4.6M unique email addresses, along with usernames, names, countries and data relating to users' Chess.com accounts. Analysis of the data suggested it had been obtained by scraping. When loaded into HIBP, 99% of the email addresses had already appeared in previous data breaches, further supporting the scraping theory. Read more about scrapes and data breaches. |
||
| 01.08.2026 - Alcon | 218.395 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In August 2026, the Alcon eye care company was named in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data allegedly sourced from Alcon containing 218k unique email addresses along with other largely corporate B2B contact fields, including name, phone number and physical address. |
||
| 01.08.2026 - Questel | 1.226.209 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses, Support tickets In August 2026, the French intellectual property software and services company Questel was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published an extensive corpus of data they alleged was obtained from the company, largely comprising corporate contact information associated with sales leads, support cases and marketing activities, with 1.2M unique email addresses. The data also included names, employers and job titles, along with physical addresses and phone numbers. |
||
| 27.07.2026 - RingCentral | 1.596.490 Datensätze geleaked | |
| Email addresses, Names, Phone numbers, Physical addresses In July 2026, the cloud-based business communications platform RingCentral was the target of a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data they claimed was obtained from the platform, which included 1.6M unique email addresses along with names, physical addresses and phone numbers. In their disclosure notice, RingCentral advised that the incident affected "a limited portion of RingCentral customers" and that it was communicating directly with those affected. |
||
| 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). |
||
| 15.07.2026 - Exact Sciences | 10.869.543 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Names, Personal health data, Phone numbers, Physical addresses In July 2026, Exact Sciences (now owned by Abbott Laboratories) was the target of a ShinyHunters "pay or leak" extortion campaign. The group claimed to have obtained data from the company's cancer diagnostics business, which they later published publicly. The breach contained 10.9M unique email addresses belonging to customers, patients and healthcare providers, along with names, addresses, phone numbers and health records. Abbott subsequently published a public notice advising that "some of the impacted files contain personal information and/or personal health information" and that more specific information would follow once their review of the incident was complete. For context, Exact Sciences is the maker of the Cologuard at-home colorectal cancer screening test. |
||
| 13.07.2026 - Brinks Home | 732.162 Datensätze geleaked | |
| Dates of birth, Email addresses, Names, Partial credit card data, Phone numbers, Physical addresses, Purchases In July 2026, Brinks Home was targeted in a ShinyHunters "pay or leak" extortion campaign. The group subsequently published data they alleged was taken from the company, including 732k unique email addresses and other personal information relating to leads, customers and Brinks staff such as name, phone numbers and physical addresses. The data also included purchases from Brinks along with partial credit card data (last 4 digits, card type and expiry). In Brinks' disclosure notice, they acknowledged the incident and risk of disclosure, and advised that they would notify impacted parties "consistent with applicable law". |
||
| 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 - Inter-Con Security | 276.114 Datensätze geleaked | |
| Email addresses, Employers, Job titles, Names, Phone numbers, Physical addresses In June 2026, Inter-Con Security was targeted in a ShinyHunters “pay or leak” extortion campaign. The group subsequently published data it alleged was taken from the company, including 276k unique email addresses along with names, physical addresses, job titles and phone numbers. The data encompassed a combination of contacts, internal users and leads. |
||
| 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. |
||
| 16.05.2026 - Gîtes de France | 117.574 Datensätze geleaked | |
| Booking details, Email addresses, Names, Phone numbers, Physical addresses In May 2026, the French holiday rental network Gîtes de France suffered a data breach affecting some of its departmental branches. The incident exposed hundreds of thousands of customer records, including 118k unique email addresses alongside names, phone numbers, postal addresses and booking details. |
||
| 14.05.2026 - Golf Canada | 568.972 Datensätze geleaked | |
| Dates of birth, Email addresses, Genders, Geographic locations, Names, Usernames In mid-2026, hundreds of thousands of user records allegedly sourced from Golf Canada began circulating via Telegram. The data included 569k unique email addresses along with names, usernames, dates of birth, genders and approximate geographic locations (city, province and postcode). It remains unclear whether the data was obtained via unintentionally exposed website features or a security vulnerability. |
||
| 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. |
||