Breaches Weekly, 25–31 Oct 2026: 76.2M Claimed Paidwork Rows and 12.1M Print.sa Records

Also this week: Ransomware Weekly, 25–31 Oct 2026: 21.3M claimed Pitney Bowes rows, plus AngMar and Omni Tanker files.

Covers leaks indexed by HaveIBeenRansom between 2026-10-25 00:00 and 2026-10-31 23:59 UTC. Each case shows when it was posted and when its data became searchable. How we pick cases, read records and score attribution: methodology.

Why these two

Paidwork and Print.sa raise different questions about consumer exposure. The large gig-platform-labelled dataset has independent reporting about financial and account information. The printing-platform-labelled dataset contains order, account and currency fields in the sampled records. The selected copies became searchable during this week. Neither was posted during it. They are explicit volume/impact exceptions to our usual requirement that posting and indexing both fall inside the week. We selected these two cases for their substantive evidence trails. Historical compilations and unresolved labels were excluded.

Key findings

Date exception: Paidwork's indexed repost is dated 2026-07-23 and Print.sa's 2026-09-21; indexing occurred on 2026-10-26 and 2026-10-28 respectively. HIBR's discovered field is the available posting/discovery proxy, not proof of first publication. Paidwork has independent evidence of public circulation in 2026. Print.sa's earliest circulation has not been independently established, so its inclusion remains a provisional impact exception for editorial approval. The edition makes no claim that either intrusion happened this week. Both indexed copies remain claimed; there is no organisation confirmation of these exact files in the evidence collected.

1 · Paidwork (posted by Database World ROC)

HIBR entry: Paidwork on HaveIBeenRansom

What happened. The copy in HIBR is attributed to a data-sharing channel, with a posting/discovery date of 23 July 2026. It became searchable on 26 October. HIBP independently describes data claimed from Paidwork in March 2026 and made public in July, including user-profile information, banking-related fields, payout history and bcrypt password hashes. We treat the file as claimed and keep organisation confirmation separate from the third-party reporting. HIBP's Paidwork analysis.

Scale. HIBR reports 76,155,304 rows and 47,353,125 email-bearing records. HIBP's independently reported 23.3M unique addresses are a different measurement, from a separately described dataset. The HIBR row total must not be marketed as 76.2M users. Seven CSV source-file entries are present in the aggregate metadata; that count describes the indexed sources, not a verified complete inventory of everything an attacker obtained.

What the data contains. Two ordered slices, one for gmail.com and one for paidwork.com, supplied 100 rows each. Every row had id and currency_code labels and a source path with a user keyword. Date strings in those slices fell in 2020–2021. Those dates do not prove a 2020 incident: account records can predate a later extraction, and the independently documented public release is from 2026. Conversely, the samples do not establish freshness for all records. Financial and password categories described by HIBP are independent context; these two small field-only samples did not verify their prevalence or values.

Corporate vs Personal. Recognised personal providers account for 94.61% of email-bearing records. Within that personal bucket, Gmail contributes 93.34%. The remaining corporate-classified bucket is dominated by privaterelay.appleid.com at 65.15%, followed by paidwork.com at 3.74%. With this relay concentration, the bucket cannot be read as a list of employers or corporate victims. Typos and unrecognised providers can also fall into it. No conclusion about Apple, Gmail or another provider being compromised follows from the distribution.

Fig 1. Paidwork: provider classification and top domains. Each top-domain percentage is calculated within its respective category (corporate or personal). Source: HIBR entry.

Corporate-classified: 2,551,291 (5.39%); personal-provider: 44,801,834 (94.61%). Denominator: 47,353,125 email-bearing records, not unique people. Each domain percentage below uses its own bucket total.

Fig 2. Paidwork: email-bearing records by provider classification. Corporate does not mean internal. Source: HIBR entry.

Attribution confidence: 49/100 (medium). The API reports 49/100 (medium), with analyst provenance and external corroboration still pending. Its organisation-domain list includes the announced domain plus an archive-name artefact; the returned score remains a qualified machine output, not a fully validated analyst score. We assess that the indexed material is likely related to the independently reported Paidwork release, with moderate confidence. Independent first-hand reporting is available, but exact dataset matching has not been completed.

Why it stands out this week. This is an explicit volume/impact exception: the 76.2M-row indexed copy and independently reported account/financial categories justify examining its new search visibility, despite its July posting date. Readers need to distinguish searchable account-related rows from unique addresses and verified individual exposure. Inclusion does not announce a new October attack.

2 · Print.sa (posted by Database World ROC)

HIBR entry: Print.sa on HaveIBeenRansom

What happened. HIBR records a print.sa-labelled archive with a 21 September 2026 posting/discovery date and 28 October indexing. We did not find an organisation statement confirming this exact file. Print.sa's own terms describe an online printing platform serving students, educational organisations and other users; that contextual description is not a breach acknowledgement. Print.sa service terms.

Scale. The indexed total is 12,054,618 records, including 2,250,811 email-bearing rows, or 18.67%. The file-type breakdown reports 12,053,299 CSV-associated rows and 1,319 PDF-associated rows. The source-file counters are 209 CSV files and 1,197 PDFs. Records extracted from PDFs and PDF source-file counts are different units. Neither number establishes how many uploaded customer documents or affected individuals are involved.

What the data contains. All 100 rows in the Gmail-domain slice contained userId, currency and createdAt labels, and each contained a 2026 date string. In the separate 100-row print.sa slice, order_id appeared in 79 rows, user_id in 81 and created_at in 88; smaller subsets contained password and password_hash labels. Label presence does not establish that a value was present, usable or stored in plaintext. In the print.sa slice, the source-path keywords order and invoice were each counted in seven sample appearances; their overlap was not measured. The observed structures support a mixed account/order dataset assessment, but the samples are ordered and domain-filtered, not random.

The year distribution in the print.sa slice spans 2018–2026. This is relevant to retention questions, but it does not establish the age of the entire dataset or the date of intrusion. We did not open document images. No personal values were retained or reproduced, and we make no claim about the sensitivity of any particular PDF. An index's zero identity-document count must not be interpreted as proof that documents or identifiers are absent.

Corporate vs Personal. Personal-provider records account for 93.30% of the email-bearing total. The corporate bucket contains 150,787 records, and print.sa contributes 48.29% of that bucket. Student and university domains appear among the remaining entries, but that does not identify the users as students, the owners as victims or any education provider as an access route. The printing use case gives context to the mix; it does not resolve attribution on its own.

Fig 3. Print.sa: provider classification and top domains. Each top-domain percentage is calculated within its respective category (corporate or personal). Source: HIBR entry.

Corporate-classified: 150,787 (6.70%); personal-provider: 2,100,024 (93.30%). Denominator: 2,250,811 email-bearing records, not unique people. Each domain percentage below uses its own bucket total.

Fig 4. Print.sa: email-bearing records by provider classification. Corporate does not mean internal. Source: HIBR entry.

Attribution confidence: Insufficient evidence. The API returns insufficient evidence and no numerical score. Its organisation-domain field contains an archive suffix, so a reliable entity resolution is missing. There is no replacement percentage. Our assessment is that the file is likely related to the named printing service, with low confidence: its label, domain concentration and account/order structures are consistent, while independent confirmation and earliest-publication evidence remain absent. An authoritative incident notice or validated dataset comparison would change that assessment.

Why it stands out this week. This is a provisional impact exception for a 12.1M-row copy containing account and order labels, with 2026 dates observed in a bounded sample. Its September posting/discovery date and unknown earliest circulation are explicit. The account/order mix raises specific verification and retention questions that warrant editorial consideration; it must not be presented as a newly confirmed incident or as proof that every uploaded document was exposed.

What they have in common

• The personal-provider buckets dominate the email-bearing records in both cases, but a provider classification is not an employment or identity label.
• Searchable row counts exceed what can responsibly be said about unique users. Repeated records, multiple tables and incomplete extraction prevent a direct conversion into people.
• The field-level findings support practical account and transaction checks. They do not establish that credentials are usable, that financial loss occurred or that every indexed row contains sensitive information.

What defenders can do

Paidwork users should use the service's own account settings and support channels to review login security and payout details. Where a password was reused, replace it on the affected accounts with unique credentials and enable MFA where available. Independent reporting describes bcrypt password hashes and banking-related information; it does not establish that any particular account has been taken over. Treat unsolicited requests to verify a payout, disclose a one-time code or change bank details as a reason to contact support through an existing channel.

For Print.sa users, the sampled order and currency labels make delivery, invoice and account-update messages a relevant verification target. Check an unexpected request inside the service rather than following a link in the message. The observed password and password_hash field names justify reviewing password reuse; this analysis did not test any credentials or establish the format, validity or exposure of an individual password.

Fraud and trust-and-safety teams should separate notification of a claim from confirmation that a customer is affected. Use authorised internal records and incident-response findings to establish the relevant account population. For the printing-platform claim, review retention and access rules for uploaded documents and order exports; the aggregate PDF counter does not reveal what any individual document contains.

For organisations managing these services, require strong authentication, tightly limit bulk export privileges and monitor unexpected access to account and transaction data. CISA's joint prevention guidance supports phishing-resistant MFA and least-privilege access. These precautions follow from the exposure scenarios; this edition has not identified either case's entry point.

---

Is your email or phone number in one of these leaks? Check it for free · Get an alert if it shows up in a new leak

DarkEye Threat Research · Data: HaveIBeenRansom · Indexing methodology peer-reviewed in MDPI Electronics · Attribution confidence is a heuristic estimate (method v2.0), not a formal attribution.

← Previous edition · All Breaches Weekly editions