Pitney Bowes — Salesforce CRM phishing breach, ShinyHunters dump

What happened

On the night of 8 April 2026, an attacker delivered a phishing email to a Pitney Bowes employee and harvested the resulting credentials. The compromised email account was used as the foothold to reach the company’s Salesforce customer-relationship-management environment, where the attacker exfiltrated records on Pitney Bowes’s business-customer accounts and contacts. Pitney Bowes identified the unauthorised access on 9 April, secured the environment, revoked the compromised access, and engaged law enforcement and outside cybersecurity advisers, according to statements provided to The Register and Teiss.

The same actor cluster behind a string of 2026 Salesforce-linked dumps — publicly branded ShinyHunters and operating in close coordination with the wider Scattered Lapsus$ Hunters collective — listed Pitney Bowes on its dark-web extortion portal in mid-April. Pitney Bowes did not negotiate. On 27 April ShinyHunters published the full dataset openly, and on the same day Have I Been Pwned ingested the dump and recorded 8,243,989 unique email addresses, along with names, phone numbers and physical addresses, and a smaller subset of records containing job titles and employer-name fields. ShinyHunters has separately claimed the underlying dump runs to approximately 25 million records before deduplication; that claim is not independently verified, and the HIBP figure represents the unique-identity scope that is publicly checkable. The Register’s report landed on 28 April and remains the most-cited account of Pitney Bowes’s own statement.

Pitney Bowes maintains that the activity was confined to its Salesforce CRM environment, that no other internal Pitney Bowes systems were accessed, and that no sensitive personal data (such as payment data, social-security numbers or passwords) was exposed. The affected records relate to business-customer accounts and contacts, and Pitney Bowes has notified those business customers directly.

How it worked

The Pitney Bowes intrusion is one of the cleanest 2026 illustrations of a chain the wider ShinyHunters cluster has now run against more than forty named organisations: a phishing email to a regular employee, mailbox or session-token theft, lateral pivot into a SaaS application the user is already authorised against, and bulk export from that SaaS application. The chain bypasses the controls most defenders associate with each layer in isolation.

The phishing stage is the part most organisations have built training and detection around. Pitney Bowes has not described the lure publicly, but the wider 2026 ShinyHunters campaign — covered in this index via SalesLoft / Drift and through the parallel listings of Charter Communications, Cushman & Wakefield, Vimeo, Medtronic, Carnival, 7-Eleven and others — has variously used vishing (voice phishing), email-based credential harvesting, fake support-portal landing pages, and OAuth-token theft via third-party SaaS integrations. The specific lure matters less than what the lure delivers: a working employee identity inside the corporate tenant.

The lateral stage is where the breach becomes a Salesforce breach rather than a mailbox breach. A Pitney Bowes employee with a business reason to use Salesforce will typically have either direct authenticated sessions or single-sign-on into the CRM, with read access — sometimes broad read access — to the customer object hierarchy. An attacker who controls the mailbox controls the SSO flow that runs from it. From inside Salesforce, the attacker uses native query tooling — reporting, list views, the SOQL query interface, or the bulk API where reach is broad enough — to enumerate and export the customer dataset. None of that activity is malware. None of it involves a vulnerability in Salesforce. It is the legitimate user, queried by the legitimate user’s session, returning the legitimate user’s data — to the wrong person.

The exfiltration stage in the ShinyHunters playbook has generally been HTTP-based and unobtrusive. Salesforce’s own audit logs record the query activity but, in most enterprise configurations, are not reviewed in close-to-real-time. The detection that worked at Pitney Bowes operated on the mailbox-compromise side rather than the Salesforce-data-export side, which is why the access was revoked within roughly twenty-four hours but the data had nevertheless left the building before the revocation.

What sits behind all of this is the SaaS supply chain compromise already on the index from August 2025: UNC6395 / ShinyHunters stole OAuth tokens from the SalesLoft Drift conversational marketing platform and used them to query Salesforce environments at hundreds of major enterprises without ever logging in to those enterprises directly. The 2026 spree is the same actor cluster, the same target architecture, and the same theft model, with employee-credential phishing now substituted for compromised integration tokens. The architecture is what made both work.

Timeline

• August 2025 — SalesLoft Drift OAuth tokens stolen; UNC6395 / ShinyHunters begins querying customer Salesforce instances at scale (see SalesLoft / Drift).
• April 2026 (early) — ShinyHunters opens a sequenced extortion campaign against Salesforce-using enterprises; victims listed across consumer goods, telecoms, healthcare, professional services, education and technology.
• Night of 8 April 2026 — Phishing email compromises a Pitney Bowes employee account; attacker pivots into Salesforce CRM and begins exfiltrating business-customer records.
• 9 April 2026 — Pitney Bowes identifies the unauthorised access, secures the environment and revokes the compromised credential.
• Mid-April 2026 — Pitney Bowes listed on the ShinyHunters extortion portal alongside a sequence of co-listed victims.
• 27 April 2026 — ShinyHunters dumps the dataset publicly; Have I Been Pwned ingests the leak and records 8,243,989 unique email addresses.
• 28 April 2026 — The Register publishes Pitney Bowes’s confirmation of the Salesforce-CRM intrusion and the phishing entry vector.
• May 2026 — Direct customer notifications under way; full record taxonomy and any regulator disclosure beyond the public Pitney Bowes statement are not yet published.

What defenders should learn

Pitney Bowes responded competently within the conventional model. The mailbox compromise was caught within twenty-four hours, credentials were revoked, sessions were killed, the environment was secured, and the company was direct in its public statement. The data left anyway. That is the model’s actual failure mode in 2026: the SaaS reach of a single authenticated user account exceeds what the email-security stack, EDR or even most cloud-access-broker tooling can stop while the user is logged in.

The first lever for defenders is reducing what a single compromised employee identity can read out of a SaaS estate. Salesforce’s own profile, permission-set and field-level security model makes least-privilege configurable; remarkably few enterprises have it tuned to anywhere near the read-scope an account-management user actually needs. Bulk-export gating, API rate-limit alerting and Salesforce Shield’s event monitoring all sit in the customer’s own administrative control and, when configured, surface the kind of anomalous reads the Pitney Bowes intrusion produced. None of these are exotic controls. They are the controls the breach made unambiguously load-bearing.

The second lever is identity-side: phishing-resistant authentication (hardware-bound passkeys, FIDO2 security keys) on the SSO front door, conditional-access policies that treat administrative or bulk-read actions inside Salesforce as a separately authenticated event, and session-binding so that a stolen cookie cannot be replayed against the CRM from an attacker-controlled device. Pitney Bowes has not publicly described its identity posture; the wider 2026 ShinyHunters dataset suggests very few of the named victims had all three.

The third lever is the segmentation lens, and it is left lighter here on purpose. Treat each major SaaS integration as a separate trust zone whose blast radius is the user account that connects to it, not the user account that owns it. The work of bounding that radius — clipping read scopes, enforcing per-app conditional access, monitoring SaaS-to-SaaS data movement at the API layer, and assuming any one user identity will eventually be the foothold — is now defender work. The forty other companies in the ShinyHunters spree are evidence that nobody else is going to do it for you.