According to the allegations, the university campaign targeted more than 100,000 professor accounts, compromised approximately 8,000 of them, and resulted in the theft of at least 31.5 terabytes of research and intellectual property.

The access story is less exotic.

Personalized phishing. Lookalike login pages. Password spraying. Compromised credentials passed between operators. Valid accounts used to retrieve data that those accounts were already trusted to reach.

The objective was strategic. The login was ordinary.

The indictment contains allegations, not findings of guilt; every defendant is presumed innocent. It also does not say Mabna obtained credentials from breach dumps or criminal markets. The case supports a narrower point: state-linked objectives can still depend on familiar credential failures.

DOJ's allegations connect familiar credential routes to strategic data theft. The figures are allegations, not findings of guilt.

The expanded case still starts with a login

The Justice Department's 2018 account described a deliberate university workflow.

The alleged operators first researched professors and their published work. They then sent personalized messages that appeared to come from another academic. Links led to domains designed to resemble the victim's university and pages made to look like its login screen. Entered credentials were captured and used to obtain research and academic material.

Against private companies and government organizations, DOJ alleged a second route: collect employee names and email addresses from open sources, then try commonly used or default passwords across many accounts. That is password spraying—testing a small number of likely passwords against a large population to avoid the noise and lockouts produced by hammering one account.

The 2026 superseding case adds eight defendants and again describes password-spray attacks and exfiltration. It also alleges that one defendant tracked spearphishing, created target lists, crafted messages, and exchanged compromised logins.

The signed superseding indictment adds a distinct continuation. From approximately October 2018 through March 2022, three defendants allegedly reused password spraying against companies and government entities, and sought to monetize compromised credentials through dark-web forums. That direction matters: the credential market was an alleged output of the intrusions, not the documented source of the passwords.

The account was the delivery mechanism.

Three credential supplies, one trusted session

Credential attacks are often flattened into one category, but the supply routes are different.

• Phishing captures a secret from the user through a deceptive sign-in experience.

• Password spraying tries a few common or default passwords across many known accounts.

• Credential stuffing takes username-and-password pairs exposed elsewhere and tests whether password reuse makes them valid on another service.

The Mabna allegations support the first two routes. They do not publicly establish the third.

Leaks and dumps still belong in the defensive model. In a 2022 warning to academic institutions, the FBI said it had observed stolen higher-education credentials posted on publicly accessible forums and offered through criminal markets. The bureau also identified more than 36,000 .edu email-and-password combinations posted in 2021, while cautioning that some may have been duplicates. Its warning was direct: password reuse can turn credentials exposed in one place into successful access somewhere else.

NIST SP 800-63B requires conforming verifiers and credential service providers to check new passwords against blocklists containing common, expected, and compromised values, including passwords from previous breach corpora. Previous breaches already document which password choices recur.

The source changes. The resulting sign-in can look the same.

Breach dumps belong in the defensive model, but DOJ does not allege that they supplied credentials for this campaign.

Valid accounts make theft look routine

A stolen credential does not need to break the target system. It asks the target system to work as designed—for the wrong person.

DOJ alleges that compromised professor accounts were used to retrieve material those identities could legitimately access. One affiliated service allegedly allowed customers to use compromised professor accounts to reach university library systems directly. In corporate and government victims, the earlier case alleged that entire mailboxes were taken and, in some cases, forwarding rules were created to capture future messages.

Additional consequential evidence can appear after authentication: a new location, unfamiliar device, unusual library retrieval, mailbox export, forwarding rule, OAuth grant, MFA-method change, or access pattern that does not fit the owner.

A successful login is an authentication result. It is not proof of a legitimate user.

The strongest evidence may appear after authentication, when a valid account behaves unlike its owner.

An attacker operating through a real account inherits the trust and visibility gaps already attached to that identity.

Make old credentials stop working

Reduce the power of a captured, guessed, or recycled password.

Start with authentication. CISA identifies FIDO/WebAuthn as the widely available phishing-resistant option because authentication is bound to the legitimate service rather than handed to a lookalike page. Prioritize email, VPN, SSO, privileged administration, research repositories, and library or publishing access. Where phishing-resistant authentication cannot be deployed immediately, number matching is a stronger interim control than blind push approval.

Then close the password routes that remain:

• reject common and previously compromised passwords, allow password managers, and rate-limit failed attempts;

• eliminate default credentials and prevent password reuse across institutional services;

• detect a small set of candidate passwords spread across many usernames, not just repeated failures against one user;

• treat a confirmed credential exposure as an incident trigger rather than waiting for a successful intrusion alert; and

• after compromise, reset the secret, revoke sessions and tokens, review MFA registrations, mailbox forwarding, OAuth grants, and prove that forced reauthentication occurred.

Microsoft's password-spray investigation guidance makes the same containment boundary explicit: identity recovery includes examining affected data, blocking compromised access, and checking for persistence such as forwarding rules or delegated mailbox access.

A reset changes a password. It does not erase prior access or necessarily terminate every existing session, and it cannot establish what the account did while it was controlled.

Recovery means invalidating every remaining path to the account and proving that the old access no longer works.

Research access belongs inside the identity boundary

Universities combine valuable data with fluid identity populations: faculty, students, visiting researchers, contractors, alumni, partners, publishers, and federated services. Collaboration is the operating model—and why a seemingly narrow account can bridge into expensive research or private correspondence.

Those identities need controls sized to the data behind them, not the application's administrative label. Prioritize phishing-resistant authentication for high-value research and email accounts. Expire dormant and guest access. Join authentication telemetry with post-login behavior. Treat exposed credentials as a trigger to review every service where reuse or federation could carry the identity.

The DOJ's new charges broaden the alleged network. They do not reveal a revolutionary entry technique. The university campaign described by the government ran from approximately 2013 through at least December 2017, and the mechanics were already familiar then.

They remain familiar because they still work.

The lesson is not that the attackers invented a new technique. It is that institutions still leave password-based access powerful enough to enable new theft.

Sources

• U.S. Department of Justice — 17 Iranians charged in superseding Mabna Institute indictment

• U.S. Attorney's Office, SDNY — 2026 superseding indictment announcement

• U.S. Attorney's Office, SDNY — 2018 Mabna Institute indictment announcement and credential methods

• FBI/IC3 — Compromised U.S. academic credentials identified across public and criminal forums

• NIST SP 800-63B — Authentication and authenticator management

• CISA — More Than a Password

• Microsoft — Password spray investigation playbook

• Microsoft — Revoke user access in Microsoft Entra ID

The rest of the notice explains why that is not the end of the identity risk.

PNLD says names, organisations, and work email addresses belonging to police officers, staff, criminal justice professionals, government partners, and customers were compromised and published on the dark web. Some names and email addresses belonging to people who had previously submitted questions through Ask the Police were also published.

A stolen password opens an account. A stolen institutional identity helps an attacker make the next request believable.

The confirmed exposure is contact and affiliation data. PNLD reports no evidence that passwords or other security credentials were compromised.

A directory can be operational data

PNLD identified the incident on Sunday, July 26. It says affected organisations were contacted, the Information Commissioner's Office was notified, and the National Crime Agency and specialist cybersecurity organisations are assisting the investigation.

The notice gives no victim count, intrusion start, dwell time, data volume, or confirmed access method. Those gaps rule out claims about the incident's full scale or mechanics.

PNLD's 2025–26 annual summary reports a service metric labeled 108,429 Police Registrations and support for all 43 Home Office police forces in England and Wales. PNLD does not define that metric as unique active users. It is not the number of breached records or affected people.

The disclosed field set is narrower than credentials, but it is still useful for targeting. A name paired with a police or justice organisation and a work email address can help an adversary choose a credible sender identity, subject line, escalation path, or password-reset pretext. That is an assessment of likely abuse, not evidence that such follow-on attacks have already occurred.

Two exposed groups, two different risks

For professionals, names and affiliations can make a fraudulent message look less random and more like routine inter-agency traffic.

The Ask the Police cohort presents a different problem. PNLD says some people who previously submitted a question had their names and email addresses published. PNLD has not said question text was published. The disclosed association with a police information service may itself be sensitive—and it can support a tailored message pretending to follow up on an earlier inquiry.

The two cohorts need different communications, but both benefit from stronger verification when an unexpected message claims official context.

PNLD also draws an important boundary: it is not a crime-recording system and does not hold confidential information about victims, witnesses, or offenders. That statement should remain intact. The breach should not be inflated into an exposure of police case records without evidence.

The campaign clue is not a root-cause finding

Security Affairs and The Hacker News report that the extortion group ExfilSquad listed PNLD on July 26. PNLD has not publicly attributed the incident to that group.

A separate VenariX investigation provides useful campaign context. Researchers reviewed samples tied to 11 of 15 organisations claimed by ExfilSquad and found structures consistent with Microsoft Dataverse across all 11. In one case involving Houston's public-service portal, VenariX confirmed that records were accessible without authentication and were consistent with data published by the group.

The researchers assess overly broad anonymous access in public Power Pages portals as a likely route for at least part of the campaign. Microsoft documents that table permissions and web roles govern access to Dataverse records. Its Power Pages Web API overview says the API follows table permissions through the associated web role.

But the boundary is decisive: VenariX did not confirm the same route for every claimed victim, and the public reporting does not identify a PNLD-specific endpoint, permission, log entry, or access path. The Power Pages pattern is a hypothesis to investigate, not the established cause of the PNLD breach.

Confirmed facts, open questions, and campaign-level hypotheses belong in separate columns until PNLD or investigators publish more evidence.

Move the controls to the identity boundary

A blanket password reset should not be the primary response based only on this notice. Forensics should determine whether password resets, session invalidation, or token revocation are warranted. The confirmed exposure already requires controls that make leaked identity context less useful.

• Harden sign-in against convincing lures. Require phishing-resistant MFA where possible and investigate unexpected prompts instead of treating a denied login as the end of the event.

• Raise the bar for help-desk recovery. A name, organisation, role context, or work email address can no longer function as meaningful proof of identity. Use device-bound or out-of-band checks that are not derived from directory data.

• Watch for impersonation infrastructure. Monitor lookalike domains, display-name spoofing, newly registered domains, and unusual mail flows targeting affected teams.

• Give each cohort specific guidance. Professionals need a known channel for verifying cross-agency requests. Ask the Police users should receive guidance that does not repeat or expose the subject of their earlier question.

• Audit public data portals if you operate them. Review anonymous web roles, table permissions, web API exposure, legacy data feeds, and logs for bulk access. Microsoft's anonymous-access governance control can block unauthenticated reading while preserving public form submission, but this is a campaign-informed control—not proof of PNLD's root cause.

The goal is to stop public contact data from doubling as an authentication or trust signal.

Don't let the credential caveat close the case

The disclosed facts remain bounded. PNLD reports no evidence that credentials were compromised. No victim total or intrusion method is public. No PNLD-specific Power Pages path has been established.

What is confirmed is enough to change defensive posture: named police and justice contacts, organisational affiliations, work email addresses, and some public-service contact records were published where criminals can use them.

Credentials can be replaced. Names, professional relationships, and the fact that someone contacted a public service cannot be rotated on demand. When identity context escapes, verification has to carry more of the security load.

Sources

• PNLD data-breach notice

• PNLD Annual Summary 2025–26

• Security Affairs source report

• The Hacker News corroborating report

• VenariX campaign research

• Microsoft Power Pages table-permissions guidance

• Microsoft Power Pages Web API overview

• Microsoft Power Pages anonymous-access governance control

According to EY's notice, an unauthorized third party accessed the platform between March 28 and April 12 and downloaded documents pertaining to a number of clients. EY detected anomalous activity on April 23.

A support platform can look like workflow software while quietly accumulating data with repository-grade consequences.

The public record establishes an access window, downloaded documents, and a later detection date. It does not establish the initial-access method, continuous dwell, or the full number of people affected.

The Ticket Was Carrying the File

The platform was not merely routing questions between users and technicians. EY says its IT personnel used it to support teams doing tax work, and that submitted tickets could include client tax documents.

That distinction changes the investigative unit. A support case can combine metadata, comments, internal notes, assignment history, status changes, and one or more attachment objects. An incident may affect only some of those layers.

The notice does not say how the attacker first entered the platform, which vendor operated it, or whether a particular control failed. It does confirm the outcome: documents were downloaded during unauthorized access.

For a ticketing incident, “which cases were touched” is not the same question as “which files were retrieved.” The answer has to resolve the case, attachment, actor, action, and time.

The disclosed path runs from tax-related support work to tickets with possible document attachments, then to unauthorized platform access and downloads. No initial-access technique has been disclosed.

Three Dates Define the Known Timeline

The California Attorney General's filing lists March 28 and April 23 as breach dates. EY's notice provides the more precise sequence: the identified unauthorized-access window ran from March 28 through April 12, and anomalous activity was detected on April 23.

That places detection 11 days after the last access date identified in the investigation. It does not prove the intruder was continuously active for the full period, nor does it show that the attacker retained access after April 12. The public evidence supports a window, not a minute-by-minute dwell calculation.

EY says its information-security team initiated incident response after the April 23 detection, worked with an independent cybersecurity firm, stopped the unauthorized access, secured the affected systems, and notified federal law enforcement.

The timeline still leaves operational questions that matter during third-party incidents: when the relevant logs were first reviewed, which events identified the download activity, what retention existed before discovery, and how quickly the affected-client set could be reconstructed. None of those details has been made public.

The Scope Is Specific—and Still Incomplete

The disclosed documents contained certain personal and financial data held in, or used to prepare, tax filings. BleepingComputer notes that the sample notice uses placeholders for the precise data elements, so the information exposed may differ by recipient.

EY has not publicly stated the total number of affected people or clients. It has not identified the third-party provider, disclosed the initial-access vector, or said whether the impact extends beyond the United States. No ransomware or extortion group had claimed the incident when the reporting was published.

EY also says it is not aware of misuse or further exposure of the affected personal information and has no indication that particular individuals were specifically targeted. That is a useful boundary on what is known, but it is not the same as proving that downloaded data cannot be used later.

Confirmed download and confirmed misuse are different findings. Incident reporting should preserve that distinction without minimizing either one.

Public sources identify tax-work documents plus personal and financial data. The exact fields, affected population, provider, and access method remain undisclosed.

A Ticket Is More Than One Record

EY's notice says documents were downloaded. It does not say whether they were retrieved one by one, through search results, with an administrative export, through an API, or by another mechanism.

Those paths can leave very different evidence. A case-history log may show that a ticket was opened without recording that an attachment was viewed. An attachment event may identify a file but not the support role, session, or API credential behind the action. A tenant-wide export may sit outside the normal case timeline.

A platform can preserve workflow history while losing breach history.

The object model matters because notification scope is built from it. Investigators need to connect each case to its attachments, each attachment to access events, and each event to an actor, session, action, and timestamp. Without those joins, “documents pertaining to a number of clients” becomes a manual reconstruction problem.

Closed cases matter too. If completion removes a ticket from the active queue but leaves an attachment retrievable, the evidence trail needs to preserve that state. If deletion removes the file, investigators still need a tombstone showing what object existed, who could reach it, and when it disappeared.

Build the Case-Level Evidence Trail

Ticket-platform detection should be designed around the actions that change exposure, not only the actions that move work.

• Give attachments durable identity. Preserve a stable object ID, integrity hash, parent-case relationship, sensitivity label, and lifecycle state without retaining the sensitive content in the audit log itself.

• Separate views from retrieval. Record preview, download, API fetch, bulk export, and administrative access as distinct events.

• Bind every event to context. Capture the actor, support role, session or API identity, privilege state, timestamp, and source context needed to distinguish expected case work from broad collection.

• Watch the paths outside the case page. Search, reporting, integration, backup, and tenant-administration functions can expose multiple objects without producing an ordinary ticket interaction.

• Preserve permission history. Group membership, inherited queues, temporary elevation, reassignment, and role changes determine who could reach an attachment at a particular moment.

• Test the incident export. A response team should be able to retrieve raw attachment-access events, administrative changes, and case-object relationships with consistent timestamps and integrity metadata.

• Rehearse the scoping query. Start with a suspect actor or session, enumerate every case and attachment reached, map those objects to clients and recipients, and identify any gap that requires provider-side evidence.

A defensible scope connects the case object to the attachment, actor, action, and time. Workflow logs alone may not preserve that chain.

Data minimization still helps: controlled links can keep sensitive source documents out of the queue, and attachment expiry can reduce the available corpus. But once a platform accepts the file, case-level auditability becomes part of the protection model.

No intrusion technique—novel or otherwise—has been disclosed. The operating fact is narrower and more useful: a support platform held tax-work documents, an unauthorized party reached it, and files were downloaded.

When the support platform becomes the incident scene, the decisive question is whether every retrieved object can be tied back to a case and forward to an accountable event.

Sources

• California Department of Justice — submitted EY breach-notification sample

• EY — sample U.S. notice letter filed with the California Attorney General

• BleepingComputer — Ernst & Young discloses data breach after support system hack

• Security Affairs — EY investigates breach involving third-party support tickets

The retailer notified online-shop customers in Germany, Belgium, and the Netherlands after unknown actors accessed a separately stored customer file at an external IT service provider. The exposed fields included salutation, first and last name, phone number, email address, date of birth, and customer number.

Passwords, billing and delivery addresses, bank details, and other payment information were not affected, according to Lidl's notices. Customer accounts were not compromised.

The system boundary held. The data boundary did not. That distinction is the operational story: organizations can protect the application a customer sees while identity material leaves through infrastructure the customer never knew existed.

The public notices separate an unaffected online shop from a stolen customer file at an external provider. The exposed fields are confirmed; the incident's total scope and intrusion path are not public.

The Data Left Through a Different Door

Lidl's Belgian notice and Dutch notice describe brief unauthorized access to a separately stored file. Both say the online-shop system itself was not affected.

That is useful scoping evidence, but it is not the same as a complete incident map. The notices do not name the provider, state how many customers were affected, or describe the initial access method, quantify the access duration, or explain the exfiltration path. They say the provider filed a police report and brought in forensic specialists. Lidl also reported the incident to the relevant data-protection authority.

The known boundary is therefore narrow: a third party, a specific file, and a defined set of fields. Everything beyond it should remain marked as unknown until the investigation produces evidence.

A Small Record Can Carry a Strong Pretext

This was not a password or payment-card disclosure. It still creates usable context for social engineering.

A name, email address, phone number, date of birth, and retailer customer number can make a message feel specific. A criminal could use those attributes to frame a plausible account alert, delivery problem, refund, identity check, or security follow-up. That is a risk scenario, not evidence that Lidl customers are currently being targeted.

The distinction matters. Security teams should neither minimize the incident because credentials were excluded nor inflate it into an account takeover that has not been observed.

No password exposure does not mean no identity risk. The value of the record is its ability to lower a recipient's suspicion before the attacker asks for something more sensitive.

The first step is confirmed data exposure. Personalization, a fraudulent request, and victim action are conditional follow-on risks, not observed outcomes of this incident.

Read the Exclusions Precisely

The notices rule out several high-impact categories: passwords, billing and delivery addresses, bank data, payment information, and compromise of customer accounts. Lidl also says it has no concrete evidence that the stolen data has been misused.

Those statements reduce the known blast radius. They do not close the case.

"No evidence of misuse" means the investigation has not established misuse at the time of the notice. It does not show that every copy was recovered, that future fraud is impossible, or that all downstream exposure is already visible. Independent reporting from BleepingComputer records the same boundary and Lidl's warning about phishing and identity abuse.

Good incident communication separates three things: confirmed exposure, explicitly excluded data, and facts still under investigation. Collapsing them into a single word such as "limited" makes both response and customer guidance weaker.

The figure distinguishes confirmed facts from details not stated publicly. "Not disclosed" is not evidence of a particular cause or scope.

Vendor Risk Becomes Customer Trust Risk

The customer relationship belongs to the retailer even when the compromised storage belongs to a provider. That makes third-party data handling part of the incident surface, not a procurement footnote.

The practical inventory is not just a list of vendors. It is a map of which customer fields each provider holds, where copies are stored, how long they remain, which identities can export them, and what logs survive after an incident. A provider that can only say its systems are secure is less useful than one that can quickly show the access path, affected object, export activity, and containment timeline.

The same discipline applies before an incident. If a provider does not need dates of birth or phone numbers for a process, removing those fields shrinks the future pretext. If it does need them, segmentation, short retention, narrowly scoped service identities, export monitoring, and preserved audit evidence become part of the control design.

Make Follow-On Fraud Expensive

For organizations handling similar incidents, the next steps should connect technical evidence to customer protection:

• Reconcile the provider's affected file against the authoritative data inventory, including backups and derived exports.

• Search identity, storage, and egress logs for access outside the stated window; record where visibility is missing.

• Increase monitoring around account recovery, customer-support verification, and changes to contact details without assuming compromise has already occurred.

• Give customers a verification path that does not depend on links or phone numbers inside an unexpected message.

• Track phishing reports for themes that use the exposed fields, then update customer-service scripts and fraud controls with observed patterns.

Map the data, minimize what leaves the primary system, preserve provider evidence, and give customers an independent verification route.

The Boundary That Matters

An unaffected storefront is good news. It is not the final measure of impact.

Customer data often exists in support systems, export files, analytics pipelines, fulfillment workflows, and vendor platforms. Attackers only need one reachable copy. Response teams need to know every copy, every access path, and every evidence owner.

Lidl's public notices provide a disciplined starting point: what was stolen, what was excluded, and what customers should watch for. The remaining work is proving the third-party boundary in enough detail to contain the incident and make the next convincing message fail.

Sources

• Security Affairs — Lidl notified online-shop customers of a third-party breach

• Lidl Belgium — customer security notice

• Lidl Netherlands — customer security notice

• BleepingComputer — independent incident report and Lidl statement

The Argos fraud spike is not just another reminder that people reuse passwords.

It is a reminder that retail identity controls now have a physical endpoint.

According to BushidoToken's write-up of UK police reporting, Report Fraud saw 652 reports mentioning Argos in May 2026, up from 154 in April. That is a reported 323% month-over-month spike in cases tied to a familiar fraud pattern: criminals gain access to customer retail accounts, place orders, and collect goods in person.

The useful lesson is not that Argos is uniquely exposed. The lesson is broader and more uncomfortable for retail risk teams: when online identity is weak, store operations inherit the fraud.

The Account Is The Pickup Ticket

The City of London Police warning cited by BushidoToken says criminals are using credentials leaked in historical data breaches to hijack Argos accounts. Once inside, they can place orders and retrieve goods through Click & Collect.

That makes the customer account more than a login.

It becomes the fraud actor's pickup ticket, purchase context, and legitimacy layer. A familiar account with order history can look less suspicious than a brand-new identity, especially if the transaction is routed through ordinary retail workflows.

BushidoToken also notes that some fraudulent orders were reportedly paid for using payment details not connected to the account victim. That matters because it blends two signals that many teams still treat separately: compromised customer identity and separate payment fraud.

The result is a messy operational case. The victim may own the account. A different stolen payment instrument may fund the order. The goods may leave through a legitimate collection lane.

No single team owns that whole chain by default.

Convenience Became The Attack Surface

Click & Collect is designed to be fast. That is the product promise.

But speed changes the fraud window. If a criminal can move from account access to order placement to in-store collection before the real account holder notices an email or push notification, the control point has shifted from the website to the store counter.

That does not mean retailers should make collection painful for everyone. It means high-risk collection events need context.

An account that suddenly orders higher-value goods, changes delivery or collection behavior, uses a new device, or combines suspicious login patterns with separate payment signals should not be treated like a normal repeat purchase.

The practical question is simple: can the retail system tell store staff when a pickup requires stronger verification without turning every collection into a manual investigation?

The Numbers Point To A Control Gap

The police figures in the BushidoToken summary are sharp enough to treat as an operational warning.

May had 652 reports mentioning Argos. April had 154. Since the start of 2026, there were 1,175 reports mentioning the retailer, with May the highest month cited in the alert.

There was earlier public warning activity too. BushidoToken references a November 2025 East Midlands Cyber Resilience Centre warning about Argos and Currys accounts being compromised and unauthorized purchases being made. In some Currys cases, the report says Buy Now Pay Later options were used, creating finance-plan risk for account holders.

That earlier warning matters because it shows the pattern is not limited to one month or one retailer's queue. Retail accounts, saved identity context, payment workflows, finance options, and pickup operations are all converging into one fraud surface.

Breach Data Is Still Paying Dividends

This is where historical data breaches keep compounding.

Credential stuffing does not require a new breach at the targeted retailer. It relies on old username and password pairs, password reuse, and weak or optional step-up controls. Cloudflare describes credential stuffing as attackers using previously exposed login pairs against other services at scale.

For retail, that means yesterday's breach at an unrelated service can become today's account takeover queue.

MFA, passkeys, password managers, breached-password checks, and anomaly detection are not cosmetic account-security features. They are loss-prevention controls. They decide whether a stolen password becomes a completed collection.

The same applies to rate, source, and device context. If a proxy-heavy source IP is attempting logins across many accounts, or if successful sessions cluster around new devices and unusual purchase behavior, the fraud program needs that signal before goods are handed over.

The Store Counter Needs Risk Context

The least useful response would be to push the whole problem onto store staff.

Collection workers should not have to become fraud analysts. They need simple, reliable prompts backed by online identity telemetry: request ID, require a one-time pickup code, ask for stronger identity verification, or escalate the order before release.

That is where online and physical controls need to meet.

High-risk actions can trigger step-up authentication before the order is confirmed. High-value Click & Collect purchases can require a single-use PIN or QR code sent through a trusted channel. BNPL or finance-plan creation can require stronger identity proofing than a normal basket checkout. Collection events can inherit risk decisions already made online.

None of this needs exploit detail. It needs business-process discipline.

Treat Retail ATO As An End-To-End Workflow

The useful control model is end-to-end.

Detect credential-stuffing patterns. Step up risky sessions. Review unusual orders before fulfillment. Verify the person collecting high-risk goods. Notify customers quickly when account behavior changes.

The order matters less than the handoff. A login risk signal that never reaches fulfillment is wasted. A store verification policy that has no idea which orders are risky becomes friction without precision. A fraud review that starts after goods leave the store is already late.

Retail account takeover is no longer contained inside the browser.

For defenders, that is the central point. Account security, fraud operations, payment risk, BNPL governance, and store collection processes are now part of the same incident surface. If they do not share signals, criminals can move through the gaps using the retailer's own convenience model as the path.

Sources

• BushidoToken Threat Intel: UK Cybercrime Journal: Argos Account Takeover Fraud

• City of London Police: Report Fraud alert warning for Argos shoppers after spike in fraud reports

• East Midlands Cyber Resilience Centre: Currys and Argos account warning issued by police

• Cloudflare: What is credential stuffing?

Nissan's latest breach disclosure is not limited to whether employee data may have been exposed.

It is where that data lived.

Nissan says the incident is tied to Oracle PeopleSoft, the enterprise system it uses for employee information, payroll, tax administration, and personnel records. That shifts the risk from a narrow software incident into something larger: a third-party enterprise platform compromise can become a payroll, identity, and workforce-trust event almost immediately.

According to BleepingComputer, Nissan warned current and former employees that attackers exploited an Oracle PeopleSoft vulnerability in a broader data theft campaign previously linked to ShinyHunters. The disclosure says Nissan was specifically targeted and that the company is still assessing the full impact.

For defenders outside Nissan, the useful signal is clear: a business-application incident can force payroll and identity-control decisions before the final breach scope is settled.

The Business System Became The Incident

PeopleSoft is not a random application buried in the corner of the estate. For many organizations, it sits close to the data employees depend on: payroll, tax records, HR workflows, benefits, and identity-adjacent administrative data.

That is why this disclosure matters.

Nissan says the investigation is still early and the company has not finalized the full scope. But the categories under review are sensitive by design. The affected information may include employee contact information, banking details, Social Security numbers, Social Insurance Numbers, national identification numbers, financial and tax information, and dependent or beneficiary information.

The reported geography is broad. BleepingComputer says the incident is believed to affect current and former Nissan employees in the United States, Canada, Mexico, and Brazil.

This is the uncomfortable shape of modern enterprise risk: an application compromise can quickly become an employee identity problem even when customer-facing systems are not the headline.

The PeopleSoft Thread

BleepingComputer ties the Nissan disclosure to a wider set of Oracle PeopleSoft data theft attacks first reported earlier in June. The reporting says threat actors exploited a zero-day vulnerability in PeopleSoft instances and stole data.

Oracle later disclosed a critical PeopleSoft PeopleTools vulnerability, tracked as CVE-2026-35273, and released emergency mitigations. BleepingComputer also reports that Mandiant confirmed exploitation of that vulnerability as a zero-day in data theft attacks between May 27 and June 9.

That does not mean every detail of the Nissan impact is settled.

This is not just a single-company anomaly. Business applications with privileged data access can become collection points when a vulnerability is exploited at scale.

The reported ShinyHunters connection adds extortion context, but it should not distract from the more operational point. The named group matters less to most defenders than the system class, the data class, and the control failures attackers can turn into leverage.

The Data Is Identity-Heavy

Nissan has not said every listed data type was definitely exposed for every person. That caveat matters.

But the possible categories are enough to make this a high-friction employee-risk event. Contact data supports targeting. Banking and payroll-related details raise fraud concerns. Government identifiers can affect long-term identity exposure. Dependent and beneficiary information widens the human blast radius beyond the employee alone.

The sensitive data model of HR systems makes containment harder after compromise.

Once a personnel system is in play, the organization has to answer more than whether unauthorized access happened. It has to answer which workflows can still be trusted, which records may have been touched, who needs notice, and what compensating controls should stay in place until the review is complete.

Payroll Is Now A Security Boundary

Nissan's reported response is worth paying attention to because it focuses on workflow restriction, not just notification.

BleepingComputer says Nissan activated incident response, brought in external cybersecurity experts, secured affected systems, and worked with Oracle on the issue. The company also said it took steps to end unauthorized access and prevent further disclosure of employee information.

The operationally important control move is around payroll.

As an additional precaution, Nissan is reportedly restricting access to employee pay slips and direct deposit changes to company network computers or secured VPN connections while it adds identity verification before processing payroll requests.

That is exactly the kind of post-breach control security teams should expect from an HR-system incident. When employee banking or payroll-adjacent data may be exposed, the next risk is not theoretical. It is account takeover, payroll redirection, social engineering, and fraudulent change requests.

This is where security and HR operations have to stop pretending they are separate systems.

The Vendor Question Cannot Wait

The Oracle layer is not background detail. It is central to the risk model.

When a core enterprise application is implicated in a zero-day campaign, defenders need more than a patch-status screenshot. They need a live operating picture across vendor advisories, incident notifications, identity logs, privileged access, data export paths, and business-process restrictions.

In practice, that means asking blunt questions:

• Which PeopleSoft instances were exposed or reachable during the reported exploitation window?

• Which service accounts, administrators, and integrations had access to personnel records?

• Which payroll, benefits, and tax workflows can change employee financial outcomes?

• Which data exports, reports, or batch jobs touched the affected record sets?

• Which employee-facing actions should be restricted until scope is validated?

Those questions are not exploit steps. They are governance steps.

Before Sensitive Workflows Reopen

The strongest move after an HR platform data theft incident is to treat identity, payroll, and notification as one response track.

Contain the affected environment. Verify privileged access. Restrict payroll and direct-deposit changes. Monitor sensitive-data access and authentication anomalies. Notify employees with clear guidance when the record review supports it.

The timing matters too. Sensitive workflows should not reopen simply because a system is back online. They should reopen when the organization can show that access was reviewed, risky changes are controlled, and employees are not being pushed into a fraud window without support.

The Nissan disclosure points to the same control problem.

The breach is not only about a vulnerability. It is about the business process attached to the vulnerable system.

If the system holds workforce identity and payroll data, the incident response has to protect workforce identity and payroll decisions, not just servers.

Sources

• BleepingComputer: Nissan discloses employee data breach linked to Oracle zero-day attacks

The insider threat that cybersecurity teams train for just became real — and the target was one of the most guarded pieces of technology in consumer electronics: Google’s Tensor processor, the custom silicon inside every Pixel phone.

The U.S. Department of Justice has indicted three people — two sisters who worked at Google and the husband of one of them — for an alleged scheme to systematically steal trade secrets from Google and at least two other major tech companies, and transfer them to unauthorized locations, including Iran.

The defendants: Samaneh Ghandali, 41, a former Google engineer; her husband Mohammadjavad Khosravi, 40; and her sister Soroor Ghandali, 32, also a former Google engineer. All three are Iranian nationals who were living in San Jose. All three were arrested on Thursday and appeared in federal district court the same day.

The Anatomy of the Scheme

This wasn’t a sophisticated cyberattack from the outside. It was patient, methodical betrayal from the inside — and the operational security the defendants used makes it more alarming, not less.

The exfiltration method: Both sisters used their legitimate employee access at Google to pull hundreds of files — including trade secrets related to processor security, cryptography, and chip architecture — and transferred them to a third-party communications platform. The channels they used were named after each defendant’s first name.

The cover-up: When Google’s internal security systems flagged Samaneh Ghandali’s activity in August 2023 and revoked her access, she signed a sworn affidavit claiming she had never shared Google’s confidential information with anyone outside the company. She had.

The analogue workaround: After digital channels were closed off, the defendants pivoted. Rather than electronically transferring files — which would leave a clear forensic trail — they manually photographed computer screens containing trade secret documents with their phones. The night before the couple traveled to Iran in December 2023, Samaneh allegedly photographed approximately 24 screens of her husband’s work computer, which contained trade secrets from his employer. Those photographs were later accessed from a device associated with her — in Iran.

The cleanup attempt: The defendants searched online for how to delete communications and how long cellular providers retain messages. They then destroyed exfiltrated files from their electronic devices.

Why This Case Matters Beyond the Headlines

The Ghandali case doesn’t exist in isolation. Less than a month ago, former Google engineer Linwei Ding was convicted for stealing thousands of Google’s confidential AI documents to build a startup in China. Now this.

Two separate insider theft cases. Two different nation-state destinations. Both targeting Google’s most strategically sensitive technologies.

The pattern forces a hard question: If Google — with its world-class security team, internal monitoring systems, and vast resources — can have trade secrets photographed off a screen and walked to Iran, what does that mean for everyone else?

The answer is uncomfortable. Google’s systems did detect Samaneh Ghandali’s digital exfiltration. What they couldn’t fully prevent was the human workaround — the pivot to photographing screens, the signed false affidavit, the physical transport. No DLP system catches a phone camera aimed at a monitor.

The Charges and What’s at Stake

Each defendant faces up to 10 years per count of trade secret theft and up to 20 years for the obstruction of justice charge, plus a $250,000 fine per count.

The trade secrets at the center of this case — Tensor processor security architecture and cryptographic implementations — are not abstract intellectual property. They are the technical foundation of how Google secures its hardware at the silicon level. In the wrong hands, that knowledge could inform attacks on Pixel devices at scale, or accelerate a foreign nation’s semiconductor development program.

CodeAIntel Insight: The analog pivot is the most chilling detail in this indictment. These defendants got caught digitally — and responded by picking up a phone and photographing screens. That is a threat vector that lives entirely outside the reach of most enterprise DLP, CASB, and endpoint monitoring tools. The lesson for security leaders: insider threat programs can’t stop at the network edge. Physical data exfiltration — cameras, printed documents, verbal disclosure — requires a different detection model entirely. The fact that a signed false affidavit almost worked as a cover story suggests the human element of your insider threat program matters as much as the technical one. Who is reviewing those exit certifications? Who is cross-referencing them against behavioral anomalies?

Sources:

https://www.courtlistener.com/docket/72303995/united-states-v-ghandali-etal/

The Hacker News

PayPal has disclosed a data breach that is, in many ways, more alarming than a headline-grabbing hack. There was no sophisticated adversary. No nation-state exploit. No dark web auction. Just a software bug in a loan application that quietly exposed the sensitive personal information of small business customers for nearly six months before anyone noticed.

The affected product is PayPal Working Capital (PPWC) — a financing tool designed to give small businesses fast access to cash. The window of exposure: July 1 to December 13, 2025. PayPal discovered the issue on December 12th and reversed the faulty code change the following day. The data left in the wind: names, email addresses, phone numbers, business addresses, Social Security numbers, and dates of birth.

For the people affected, that is essentially the full identity theft starter pack.

The Anatomy of the Exposure

This wasn’t a smash-and-grab. It was a door left quietly ajar.

• The Root Cause: An error introduced through a code change made the PII of a “small number” of PPWC customers visible to unauthorized parties.

• The Duration: 165 days. Five and a half months of exposure before PayPal’s own systems flagged it.

• The Damage: PayPal confirmed unauthorized transactions occurred on a subset of affected accounts as a direct result of the incident and has issued refunds to those customers.

• The Response: The faulty code was rolled back within 24 hours of discovery. Affected users are being offered two years of free three-bureau credit monitoring and identity restoration services through Equifax, with enrollment required by June 30, 2026.

PayPal stated it has not delayed notification due to a law enforcement investigation — which is notable, suggesting no criminal referral is currently in play.

This Is Not PayPal’s First Rodeo

Context matters here. This breach doesn’t exist in a vacuum.

In December 2022, PayPal suffered a large-scale credential stuffing attack exposing roughly 35,000 accounts — including Social Security numbers and tax identification data. That incident eventually cost the company a $2 million settlement with the New York State Department of Financial Services in January 2025 for failing to comply with cybersecurity regulations. The DFS found that PayPal lacked proper CAPTCHA protections, rate limiting, and mandatory multi-factor authentication at the time.

Now, less than a year after that settlement was announced, PayPal is back in breach territory — this time not from an external attacker exploiting weak controls, but from an internal code change that bypassed its own data protection framework.

The pattern is hard to ignore: PayPal keeps putting sensitive data at risk through process failures, not just external threats.

What Small Business Owners Need to Do Now

If you use or have used PayPal Working Capital, treat this as a confirmed identity risk:

• Enroll immediately in the Equifax credit monitoring offer PayPal is providing. Do not wait.

• Place a fraud alert or credit freeze with all three bureaus (Equifax, Experian, TransUnion) if you want to go further.

• Monitor your business and personal accounts for unauthorized transactions — PayPal has already confirmed some accounts were fraudulently accessed.

• Watch for follow-on phishing. Attackers who obtained this data now have everything they need to craft highly convincing impersonation attempts. PayPal will never ask for your password, one-time codes, or authentication credentials via phone, text, or email.

• File with the FTC at IdentityTheft.gov if you believe your Social Security number has been misused.

CodeAIntel Insight: The 165-day exposure window is the real story here. Modern breach detection should catch anomalous data access in hours or days — not months. The fact that a code-level error in a loan application could silently expose Social Security numbers for five and a half months points to a deeper problem: insufficient data-access monitoring at the application layer. For enterprises, the lesson is not “don’t write buggy code” — that’s a given. The lesson is: if sensitive PII is being touched by any application, you need runtime visibility into who is accessing it, when, and whether that access pattern looks normal. PayPal didn’t have that. Do you?

Sources:

https://www.bleepingcomputer.com/news/security/paypal-discloses-data-breach-exposing-users-personal-information/

https://www.documentcloud.org/documents/27345193-paypal-february-2026-breach-notification/