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/