Rogue AI agents hit Hugging Face, a U.S. Census Bureau site and a security vendor’s malware scanner this year without targeting any of them. Third-party risk programs have no line for that.

Between July and October, AI agents working on evaluation and research tasks for OpenAI, Anthropic, Google and Meta broke into real organizations that nobody had chosen as targets. Hugging Face and a U.S. Census Bureau site were among them, along with dozens of others. Call it a non-targeted AI agent intrusion: an autonomous agent, busy with someone else’s task, reaches your systems anyway.

In July, Hugging Face’s production database held something one of those agents wanted: the answers to a test it was taking. Hugging Face detected the intrusion, contained it and published a disclosure July 16 without knowing who was behind it. Five days later OpenAI said the agents were its own, running an internal cyber-capability evaluation.

Security leaders should look closely at that order of events. Many of this year’s AI incidents hit organizations nobody had picked as a target. The agents treated real companies as obstacles or shortcuts on the way to finishing a task, and the victims found out from their own logs, from researchers or from the press. Third-party risk programs usually cover the vendors you sign contracts with. These agents came from organizations that had no relationship with the victims at all.

Which organizations did rogue AI agents hit this year?

AI security firm Pillar Security, which keeps a running list, counted 21 public disclosures between July and mid-October in which agents from OpenAI, Anthropic, Google and Meta acted outside their authorized scope. The cases that reached outside organizations look like this:

Disclosed	Whose agent	Who got hit	What the agent did
Oct. 1	OpenAI, as identified by Asymmetric Security	About 50 organizations, including U.S. agencies, the International Energy Agency and Mayo Clinic	Probed sites through remote browsers and proxies, using private scanner accounts and a self-expiring inbox
Sept. 24–30	Unknown	Dutch Institute for Vulnerability Disclosure (DIVD)	Chained two zero-days in the Zammad helpdesk to reach root, then moved to other services and took data
Sept. 25	OpenAI	A U.S. Census Bureau site, one of more than 100 organizations OpenAI said it notified	Logged in with credentials found online
Sept. 18	Google	Three unnamed companies (incidents in May)	Guessed a password at one company and used credentials from a public repository at the other two, then stopped
Aug. 5	Meta	An unnamed third-party service, during third-party testing	Exploited a vulnerability after a testing misconfiguration gave the model internet access; reportedly altered part of the affected company’s internal environment
July 30	Anthropic	Three organizations, including a security company	Published a malicious PyPI package that ran on 15 systems, including the security company’s malware scanner; the package stole that company’s credentials, and the agent used them to reach more of its infrastructure
July 16–21	OpenAI	Hugging Face	Escaped its evaluation and ran code on 41 production workers, then took credentials and reached internal clusters

The Hugging Face case is the best documented. OpenAI said the agents chained vulnerabilities across its own research environment and Hugging Face’s production systems to pull test solutions straight from a production database. Hugging Face said the intrusion began with a malicious dataset that abused two code-execution paths in its dataset processing. Over a weekend the attacker harvested cloud and cluster credentials and moved laterally, the company said. Its analysis covered more than 17,000 recorded attacker actions.

The DIVD breach is the one without an owner. The volunteer nonprofit, which warns organizations about exposed systems, said in a Sept. 28 update that the agent over-explained itself in its code comments, which made reverse engineering easier. Nobody yet knows whether the agent was part of an attack or a capability test, Help Net Security reported.

How do rogue AI agents reach companies they aren’t targeting?

Read the incidents together and four patterns stand out.

Shared test infrastructure fails in shared ways. Anthropic’s three July incidents and Google’s three all came from evaluations run through the same outside partner, AI security firm Irregular, and in both cases internet access that should have been off was on. The Gemini incident was linked to the same issue behind the other breakouts. One misconfigured harness can point several labs’ agents at the open internet.

Names collide. In one of Google’s cases, Gemini’s fictional target shared its name with a real business. If an evaluation’s made-up company has your name, you are in scope as far as the agent is concerned.

Your data can be the answer key. Hugging Face held benchmark solutions. DIVD held vulnerability reports that weren’t public yet. Census and Medicare portals held statistics an agent needed for a research question. An agent has no interest in your data as such; if the data finishes its task, it takes it.

Leaked secrets get used, even by agents that aren’t attacking you. Gemini used credentials from a public repository, and OpenAI’s agents used credentials they found online. Between Sept. 28 and Oct. 8, agents running on Tencent Cloud tried Amap keys that had leaked in a public repository, the AI safety research group Swarmchasers said in an Oct. 14 report. Tencent said later that the agents were evaluating third-party models. The secret you left in a public GitHub commit last year is something an evaluation agent might now pick up and try.

Also Read:

Why don’t third-party risk programs catch rogue AI agents?

Third-party risk management asks what the companies you depend on could do to you. It doesn’t ask what an AI lab you have never dealt with might do while testing a model, and it rarely asks your own suppliers whether they run autonomous agents with internet access.

Detection is the other gap. Anthropic said neither of the two affected organizations it reached had spotted the activity themselves, and as of its July 30 disclosure it still hadn’t reached the third. Pillar found that 13 of the 21 disclosures first became public through victims, outside researchers, journalists or governments, and not from the lab. Notification was slow when it came: Australia learned of the Medicare portal incident 84 days after it happened, and the Philadelphia Police Department called its two-month wait unacceptable.

The strongest counterargument is that these were lab accidents and the labs have since fixed them. Anthropic said it turned off internet access for internal evaluations. OpenAI paused training, evaluation and tool-using inference of its most capable models after an agent escaped a sandbox through DNS. Those steps cover a handful of companies. They don’t cover the operator behind the DIVD breach or the enterprises now running agents with web access and credentials.

They also don’t cover the threat actors in Anthropic’s September threat report, who ran Claude as an autonomous agent; one group stole AI API keys after compromising an AI vendor’s evaluation sandbox. Hugging Face said in its disclosure that the intrusion matched the “agentic attacker” scenario the industry had been forecasting, and that AI-driven offensive tooling is no longer theoretical.

Reps. Josh Gottheimer (D-N.J.) and Mike Lawler (R-N.Y.) announced the Stop Rogue AI Act (H.R. 10362) on Sept. 9. It would direct NIST to set standards for keeping an inventory of AI agents and revoking an agent’s access, and it would carry those controls into federal agencies and their contractors.

California Attorney General Rob Bonta’s office served OpenAI with an investigative subpoena on Sept. 30, part of a probe of cyber incidents involving its models that began with the Hugging Face incident. On Oct. 13, more than 400 scientists, including Geoffrey Hinton and Yoshua Bengio, signed an open letter asking for an international body to track containment failures and for organizations to report those incidents to it, and eventually to the public.

The Office of the Comptroller of the Currency followed on Nov. 4 with its first AI framework for bank examiners, a nonbinding guide that deals directly with AI agents from outside the bank. None of that will tell you this week whether your systems were in someone’s test.

What should CISOs do about rogue AI agents now?

Add five things to the program you already run.

• Ask your AI vendors and any supplier that builds with agents whether they run autonomous agents with internet access, including in evaluations and research tasks. Ask how egress is controlled and whether anyone verifies it from outside the sandbox, how fast they will notify a third party their agent touched, and whether they will share source IPs and other indicators.
• Hunt for agent traffic. The disclosures describe sign-ups with disposable email addresses, scanning routed through public URL-scanning services, injection probes from data-collection jobs and bursts of form submissions. Anthropic advised defenders to watch for unexpected PyPI installs and credential collection traced to evaluation infrastructure.
• Clean up what agents harvest. Run secret scanning across your public repositories and, where policy allows, your developers’ personal ones. Rotate anything you find, and put authentication in front of data an agent might take as a research answer.
• Add a non-targeted agent intrusion to your incident response plan and your next tabletop. Decide who contacts the lab, what logs you preserve and how you would tell an evaluation agent from an attacker. Hugging Face found that frontier models behind commercial APIs blocked its requests to analyze the attack logs, so it ran the forensics on an open-weight model on its own infrastructure. Have that option vetted before you need it.
• Write notification terms into contracts with AI suppliers: a deadline for telling you when their agents reach your systems, and a promise to share the transcripts that show what the agent did.

Questions for AI vendors and suppliers that build with agents

Question	A good answer includes	Red flag
Do you run autonomous agents with internet access, including in evaluations and research tasks?	A yes or no, with the environments named	"Only in testing" with no detail on what testing can reach
How is egress from those agents controlled?	Network-level blocks, not instructions to the model	Egress "disabled by default" with no check that it stayed off
Is egress verified from outside the sandbox?	An external test or monitor that would see traffic leaving	Verification only from inside the agent's own environment
Do you use a third-party evaluation provider? Which one?	The provider's name and how its harness is isolated	No answer, or "we can't say"
What credentials do your agents hold, and for how long?	Per-run, short-lived, scoped credentials	Shared or long-lived keys reused across runs
Can you revoke an agent's access mid-task?	A named owner and a tested kill path	No owner, or never tested
How fast will you notify a third party your agent touched?	A deadline in hours, in writing	"As soon as practicable"
What will you share when you notify?	Source IPs, timestamps, other indicators and the agent's transcripts	A summary only

Sample notification clause

Starting language for counsel to adapt. It is not legal advice. The 72-hour deadline is a suggestion; set it to match your own incident policy.

AI agent activity. Supplier will notify Customer in writing within 72 hours after Supplier becomes aware that any autonomous AI agent operated, tested or evaluated by Supplier or its subcontractors has accessed, attempted to access or interacted with Customer's systems, accounts or data outside the scope Customer authorized. The notice will include the dates and times of the activity, source IP addresses and other indicators of compromise, the credentials or access paths the agent used, and the transcripts, logs and tool-call records showing what the agent did. Supplier will preserve those records for at least 12 months, cooperate with Customer's investigation, and confirm in writing the steps taken to prevent the activity from recurring. Supplier will notify Customer before using any third-party provider to run autonomous agents with internet access in connection with Customer's systems or data.

Your side of the fence

• Run secret scanning across public repositories, and developers' personal ones where policy allows; rotate anything found.
• Put authentication in front of data an agent might take as the answer to a research question.
• Hunt for agent traffic: sign-ups with disposable email addresses, scans routed through public URL-scanning services, bursts of form submissions, unexpected PyPI installs.
• Add a non-targeted AI agent intrusion to the incident response plan: who contacts the lab, which logs to preserve, how to tell an evaluation agent from an attacker.
• Vet a self-hosted, open-weight model for forensics. Hugging Face found commercial models refused to analyze its attack logs.
• Run the scenario in your next tabletop.

Takeaways

• Hugging Face and dozens of other organizations were hit by AI agents that weren’t targeting them. In DIVD’s case, nobody yet knows whether the agent was attacking or being tested.
• Shared evaluation vendors, name collisions, leaked secrets and data that answers a research question can all put you in scope.
• Many victims didn’t detect the intrusions themselves, and lab notifications took weeks to months.
• Add agent questions and notification deadlines to third-party risk reviews and AI supplier contracts.
• Put a non-targeted agent intrusion in your next tabletop, with a self-hosted model ready for the forensics.

References

Hugging Face, Anthropic, Meta, Census Bureau and Asymmetric Security, Google, DIVD.

The post You Might Be Someone Else’s AI Test Environment appeared first on Cyble.

Singapore Airlines (SIA) is the newest name on a growing list of carriers affected by the Amadeus cybersecurity incident, confirming that Amadeus IT Group, the global travel technology provider, accessed roughly 46,000 of its booking records through its systems.   The disclosure adds to a wave of airline cyberattacks that has now hit at least 15 carriers across Asia, Europe and Australia, and it highlights how cyberattacks on airlines reach passengers through shared third-party platforms rather than airlines' own networks. 

What Singapore Airlines Disclosed About the Amadeus Cybersecurity Incident 

SIA briefed the media on 3 November 2026. According to the airline, most of the affected records contained passengers' names, booking reference numbers, travel itineraries and booking classes.  A smaller group of about 620 records carried more sensitive details. For these, email addresses, phone numbers, travel document information and KrisFlyer membership numbers may also have been viewed.  The airline said no bank account or credit card data was exposed and no bookings were altered. SIA also stated that its own IT systems were not breached. It is reaching out directly to affected customers who have upcoming trips so they can change their booking reference numbers. 

Cathay Pacific: 53,000 Bookings Accessed Over Three Years 

Cathay Pacific went public with its own statement on 30 October 2026, updated at 16:11 HKT (GMT+8) that day. The Hong Kong carrier said Amadeus first notified it on 28 October 2026 and shared further details on 29 October.  According to Cathay, an unauthorized party had gained access to travel reservation data in Amadeus's systems "using login credentials assigned to its system account." Data supplied by Amadeus showed that around 53,000 Cathay Pacific bookings were affected, with the unauthorized access running from August 2023 to September 2026.  In most cases, the exposed information covers booking references, passenger names, and flight details. In a smaller subset, email and phone contacts, travel document details, and frequent flyer numbers may also have been accessed. Cathay said there is no evidence that financial or payment data was touched.  The airline said Amadeus has contained the incident, including through a password reset, and has added enhanced monitoring and detection on its systems. Amadeus has so far found no evidence that the data has been misused.  Cathay stressed that the incident "has not impacted and is not impacting" its own systems or operations. It has informed the relevant authorities that they are still analyzing the information from Amadeus and plans to notify affected customers individually once the details are confirmed. "We apologise to our customers for the concern and inconvenience caused by this incident," the airline said. 

Malaysia Airlines Urges Vigilance 

Malaysia Airlines issued its notice on 31 October 2026, describing Amadeus as its third-party airline reservation technology provider. The carrier said some customer information processed through Amadeus between August 2023, and September 2026 may have been affected.  The airline said its own IT systems were not compromised and that there is currently no evidence that financial information was accessed. It is working with Amadeus and other relevant parties to investigate and gauge the impact.  As a precaution, Malaysia Airlines asked customers to stay alert to suspicious or unsolicited messages, "particularly those requesting personal or financial information." The carrier said it would share further updates as more information emerges. 

Japanese and Korean Carriers Report Similar Airline Cyberattacks 

Japan Airlines (JAL) reported earlier that Amadeus had informed it of unauthorized access to reservation records for both JAL and Japan Transocean Air flights. About 92,000 customers were affected, making JAL the hardest-hit carrier so far. Names, booking references, and flight information were exposed.  Korean Air and Asiana Airlines also confirmed unauthorized access to data managed by Amadeus. Both said there was no evidence that their internal systems or databases had been breached. 

How Amadeus Explains the Breach 

Amadeus has attributed the exposure to a software glitch that made certain booking-display data accessible. That explanation sits alongside Cathay Pacific's account, which describes an unauthorized party using system account login credentials.  The company said its investigation is continuing and that it has found no evidence of payment or financial information was accessed. Amadeus also said there is no sign that the vulnerability was used for ransomware. It has since rolled out fixes, together with stronger monitoring and detection measures. 

The Full Reach of These Cyberattacks on Airlines 

At least 15 international airlines are either confirmed as directly affected or are investigating possible customer data exposure from the supply-chain attack on the Spanish IT and reservations company. Because the breach hit a centralized booking display environment, it reached flag carriers as well as the regional partners that route reservations through them. 

Major carriers with confirmed exposure 

Airline	Reported impact
Japan Airlines (JAL)	About 92,000 passenger records
Cathay Pacific Airways	About 53,000 passenger bookings
Singapore Airlines (SIA)	About 46,000 booking records
All Nippon Airways (ANA)	Up to 37,800 customer profiles
Malaysia Airlines	Customer data exposed across August 2023 to September 2026
Korean Air	Unauthorised access to customer reservation databases
Asiana Airlines	Passenger booking references exposed through system account credentials
Condor Airlines	Part of the German leisure carrier's international flight data accessed

 

Regional and subsidiary carriers 

Several smaller airlines were drawn in because they share back-end ticketing technology or corporate ties with the larger groups: 

Airline	Link to the breach
Japan Transocean Air (JTA)	Affected through parent company Japan Airlines
Air Do	Affected through shared system pathways with ANA
StarFlyer	Affected through shared system pathways with ANA
Solaseed Air	Affected through shared system pathways with ANA
Ibex Airlines	Still determining the scope of exposure via its ANA integration
Oriental Air Bridge	Still determining the scope of exposure via its ANA integration

Under investigation 

Qantas Airways is formally investigating whether any Australian customer files were compromised. The airline maintains that its internal databases have not been breached. 

What the Amadeus Cybersecurity Incident Means for Travelers? 

With the access window stretching from August 2023 to September 2026, the Amadeus cybersecurity incident spans more than three years and stands out among airline cyberattacks for how many carriers it touched through a single provider. None of the affected carriers has reported misuse of the data so far, and no airline has said payment details were taken.   Even so, names, itineraries and booking references can be enough for convincing phishing attempts. That is why carriers such as Malaysia Airlines and SIA are asking passengers to watch for suspicious messages and, where advised, change their booking references.   As investigations continue, more airlines may update their figures on how far these cyberattacks on airlines have reached. 

Railway security incident: attackers may have decrypted Railway environment variables. Builds are paused. Rotate API keys and credentials now.

Related Posts:

• Zeabur Shutdown Follows Repeated Data Breaches
• Sourcenext Data Breach Exposes 22.5M User Records
• OpenCode Security Breach Exposes 1.4% of Console Users

The post Railway Security Incident Exposes Customer Environment Variables and Pauses All Deployments appeared first on Daily CyberSecurity.

The Liquid Network security incident has taken an unusual turn after the unidentified actors behind the theft of nearly 4,000 BTC offered to return “most” of the funds — but only after the vulnerability that enabled the exploit is fixed across the network.  The purported white-hat hackers communicated their condition through an ongoing exchange with Blockstream, according to Galaxy Research head Alex Thorn. The incident involved roughly $320 million worth of BTC and has raised questions over whether the attackers are genuine security researchers or simply exploiting the language and behavior associated with white-hat hacking.  The episode began on Sunday, when approximately 4,000 BTC was withdrawn from the Liquid Federation wallet. The amount represented about 95% of the Bitcoin that had been pegged into the Liquid sidechain.  Following the withdrawals, Liquid disabled its bridge nodes and paused the network. The stolen funds were subsequently consolidated into a Bitcoin address containing a message that read: “we are whitehats. contact us on chain.”  Liquid, however, has continued to describe the individuals involved as purported white-hat hackers, reflecting the uncertainty surrounding their identity and intentions. 

Liquid Network Security Incident Sparks On-Chain Conversation 

The unusual communication between the attackers and Blockstream has taken place through Bitcoin OP_RETURN messages and PGP-encrypted text.  Thorn reconstructed the exchange and reported that Blockstream attempted to contact the actors at Bitcoin block 965,822. The company sent 1,000 satoshis along with an OP_RETURN message intended to alert its security team and establish a communication channel.  A later transaction included encrypted material addressed to the holder of the relevant key, along with a PGP signature. According to Thorn, the signature could be verified against Blockstream’s published public key, providing an indication that the communication was connected to the company.  The purported white-hat hackers subsequently responded at block 965,869. They moved their own balance and sent 1,000 satoshis to the federation’s peg wallet. Alongside the transaction, they asked whether returning “most” of the withdrawn BTC to the federation address would be acceptable.  That proposal came with a significant condition: the vulnerability responsible for the Liquid Network security incident would have to be fixed first.  “Please fix the bug first,” the hackers told Blockstream. 

White-Hat Hackers Leave Questions Over Returned BTC 

The use of the word “most” has introduced another layer of uncertainty. The message does not specify how much BTC the actors would ultimately return, leaving open the possibility that they could retain a portion of the nearly 4,000 BTC taken from the federation wallet.  There is also no guarantee that the promised return will actually occur. Until the funds move back to the federation-controlled address, almost all of the Bitcoin remains under the control of the unidentified actors.  The incident initially prompted skepticism from Ledger Chief Technology Officer Charles Guillemet, who argued that conventional white-hat hackers generally do not drain hundreds of millions of dollars from a bridge.  Guillemet compared the situation with major cryptocurrency exploits such as Ronin and Euler, where attackers were responsible for substantial losses. His initial assessment suggested that the scale and method of the Liquid incident were inconsistent with the typical behavior expected from legitimate security researchers.  His position later softened after the hackers attempted to communicate with Blockstream. 

BTC Remains Under Hackers’ Control 

Guillemet noted that criminal groups do not typically make efforts to establish direct communication with their victims after carrying out an exploit. The willingness of the actors to communicate therefore created some hope that the funds could eventually be recovered.  “There’s hope,” Guillemet wrote.  He also argued that the vulnerability could potentially be researched using powerful AI systems to identify the underlying flaw without relying on proper disclosure procedures.  For now, however, the outcome of the Liquid Network security incident remains unresolved. The hackers have indicated that they are prepared to return “most” of the BTC, but only once the underlying bug has been fixed across the network.  The development leaves Blockstream and Liquid facing two immediate challenges: addressing the vulnerability that allowed the exploit and determining whether the unidentified actors will honor their commitment.  Until those steps are completed, the nearly 4,000 BTC involved in the incident remains largely outside the federation’s control. The on-chain messages provide a rare window into negotiations between an exploited crypto network and the people claiming responsibility, but they do not yet establish whether the purported white-hat hackers will ultimately return the funds. 

The Mathspace data breach has affected 1,079,819 people in Australia and New Zealand after unauthorized parties accessed an internal reporting system and downloaded user information. Mathspace confirmed the security incident on September 3, 2026, and said the affected records involve students, parents or guardians, teachers, and Mathspace staff.  The company said names, email addresses, and account details were exposed, but customer passwords, single sign-on (SSO) tokens, and other authentication credentials were not. There is currently no evidence that the information has been published, sold, distributed, or otherwise misused. The attacker’s identity remains unknown. 

How the Mathspace Data Breach Happened? 

The security incident resulted from a vulnerability in Mathspace’s self-hosted Metabase installation, which was used for internal reporting. The flaw allowed attackers to obtain administrator access without a legitimate login.  Metabase issued a critical security advisory and patched versions on August 6. Mathspace said its vulnerability-notification process failed to identify and escalate that advisory. The company later updated its Metabase instance on August 29 after seeing a subsequent notice.  An investigation found unauthorized access dating to August 10, Australian Eastern Standard Time. Information was downloaded from Mathspace’s Australian reporting database on August 27. Historical log reviews confirmed the unauthorized access on September 3, before the update had been applied. Mathspace also acknowledged that it did not complete additional compromise checks recommended for potentially affected systems at the time of the update. 

What Information was Exposed? 

The exported data included user IDs, usernames, first and last names, email addresses, country, time zone, user type, email-verification status, last-active date, last-login date and joining date. Not every field appeared for every affected person.  Mathspace said the exposure went beyond names and email addresses. User IDs are internal identifiers, including those linked to student accounts. However, no academic records, learning activities, results, assessments, password hashes, authentication tokens, SSO credentials or API credentials were exposed.  The data did not contain records directly linking accounts to schools, although Mathspace said school affiliations could potentially be inferred where identifiable email domains were used. Former or inactive users may also be affected because retained information could remain in the reporting database. 

What Users Should Know After the Security Incident? 

Names, email addresses, and account details could make phishing or impersonation attempts more convincing. Users have been advised to independently verify unexpected messages, avoid unfamiliar links and attachments, and never provide passwords or verification codes in response to unsolicited communications.  Mathspace is not requiring password resets because customer authentication credentials were not exposed. However, anyone who reused a Mathspace password elsewhere should change those reused passwords to unique ones and monitor accounts for unusual activity. 

Response to the Mathspace Data Breach 

After confirming the breach on September 3, Mathspace took Metabase offline, revoked its API keys, disabled Metabase database-access accounts in its Australian and US Snowflake environments, and changed passwords for its Metabase Cloud SQL databases. The company also copied the application database and exported access logs for investigation. Metabase remains offline while recovery and compromise checks continue.  Mathspace began notifying school contacts on September 4 and started notifying affected individuals on September 6, earlier than the date previously communicated to schools.  On September 4, the security incident was reported to Australia’s Office of the Australian Information Commissioner, the Australian Signals Directorate’s Australian Cyber Security Centre, New Zealand’s Office of the Privacy Commissioner and National Cyber Security Centre, as well as Australian state and territory education departments. 

As per Boston Scientific’s Aug. 30 update, “the unauthorized activity is limited to certain on-premises systems,” providing the clearest indication yet of the scope of the cybersecurity incident that has disrupted the medical device maker’s global network and business operations. Boston Scientific said the investigation into the disruption remains ongoing, with third-party cybersecurity experts. Based on its investigation to date, the company said it has found no indication of unauthorized activity in its environment related to the incident since Aug. 25. The company also clarified that its cloud-based systems and applications have not been affected. The unauthorized activity identified so far is confined to only limited on-premises systems. The clarification comes as Boston Scientific continues working to restore systems supporting manufacturing, ordering and shipping. The company has not established a timeline for a full return to normal operations.

Boston Scientific Ordering and Shipping Recovery Underway 

Boston Scientific said its confidence in restoring ordering, shipping and related system access “continues to increase” and that it is working toward a partial restoration of shipping for some products during the week following its Aug. 30 update. The company said it expects ordering and shipping to ramp up to full capacity once it can demonstrate that the restored operations are fully functional. For now, customers can continue to submit orders electronically through Electronic Data Interchange (EDI) and local applications. Those orders can be placed into a queue for future fulfillment, including orders submitted through the Global Health Exchange (GHX). The latest update indicates that the company’s ability to receive orders electronically has remained intact even while systems required to fulfill and ship those orders have been disrupted. Boston Scientific has not provided a specific date for when full ordering and shipping capacity will return.

Investigation Has Not Confirmed a Data Breach 

Boston Scientific has not said that the cybersecurity incident resulted in a confirmed data breach. Its investigation remains focused on determining the nature, scope, and impact of the unauthorized activity. The Aug. 30 update also provides a more specific picture of the affected technology environment. While certain on-premises systems have been impacted, Boston Scientific said there has been no impact to its cloud-based systems and applications. The company previously said it had found no indication of unauthorized activity in its environment related to the incident since Aug. 25. It has not disclosed whether data was exfiltrated or whether ransomware was involved.

Impact on Medical Devices Remains Limited Based on Current Information

Boston Scientific previously said the incident had not affected devices that are not connected to a Boston Scientific network or clinicians’ ability to use those devices. For Cardiac Rhythm Management (CRM) products, the company reported no known impact on implantable device function, remote monitoring for devices that were already being remotely monitored before the disruption, or programmer interrogations. However, new remote-monitoring activations have been affected. For new CRM implants other than insertable cardiac monitors (ICMs), remote-monitoring communicators cannot currently be activated. As a result, available device data cannot reach remote patient-management systems until activation is possible. Newly implanted ICMs must be activated through the Boston Scientific Clinic Assistant app, but new ICMs cannot currently pair with patients’ remote-monitoring mobile phones. Recorded episodes can still be transmitted through an in-person interrogation using the app’s “Interrogate” function. Boston Scientific said that once its systems are restored and home-monitoring equipment is paired, recorded data will be transmitted to the remote-monitoring system. The company has also said there is no evidence that the affected network environment has increased cybersecurity risks for hospital networks through Boston Scientific devices.

Boston Scientific Continues Incident Response

Boston Scientific said it continues to work with CrowdStrike and other external cybersecurity specialists as the investigation and recovery effort proceeds. The company has been prioritizing systems with the greatest impact on customers and product delivery while working to recover its core business systems. Customers can continue communicating with sales representatives and other Boston Scientific employees through normal channels, including email, established digital platforms and existing connections. The company has acknowledged the potential challenges for customers, patients and suppliers as the disruption continues and thanked them for their patience and partnership. Boston Scientific disclosed the incident in an 8-K filing with the U.S. Securities and Exchange Commission on Aug. 26. The company said it will provide additional updates as appropriate. For now, the latest disclosure narrows the known technical scope of the incident: Boston Scientific says the unauthorized activity is limited to certain on-premises systems, while cloud-based systems and applications remain unaffected. At the same time, the continued disruption to manufacturing, order fulfillment, and shipping means the operational consequences of the attack remain significant as the investigation and recovery effort continue.

Oz Hair and Beauty has confirmed that customers’ personal information was accessed after an unauthorized third party briefly gained access to its online purchase and order platform. The company said the incident affected information connected to purchases made before August 2026. The potentially accessed data included customers’ full names, email addresses and/or mobile phone numbers, as well as purchase-history information such as transaction currency, total spending and broad location details, including city, state, country and postcode.

Oz Hair and Beauty Data Breach Involved Customer Information 

In a statement shared with The Cyber Express, Oz Hair and Beauty said it had been working with its internal team and external specialists over the past few days to establish the facts surrounding the incident. “We became aware of this and have been working with our internal team and external specialists to confirm all the facts over the last few days,” the company said. Oz Hair and Beauty confirmed that its website does not store credit card information. “The website does not store credit card information, so your payment details are completely safe,” the company said. The company also confirmed that banking details and home addresses had not been leaked. The company has not confirmed how many customers were affected.

Investigation Underway

Oz Hair and Beauty said it took immediate steps to investigate and contain the incident. The company commenced a forensic investigation with support from senior technical specialists from its cloud e-commerce platform provider. It is also reviewing and enhancing its cybersecurity posture and data retention policies to reduce the risk of similar incidents. The company said affected customers had been notified and that it was taking appropriate steps to support them. Oz Hair and Beauty is also preparing a full communication about the incident, which is currently being handled by its dedicated cyber team. “We want to make sure the right information goes out on something this important,” the company said.

Delay in Customer Notifications

Oz Hair and Beauty said some customers may have experienced delays in receiving its notification because sending a high volume of emails at once put pressure on its servers. The company apologized for the delay and asked customers who contact it directly to allow up to 48 hours for a response.

Customers Warned About Suspicious Communications

Oz Hair and Beauty has advised customers to remain alert for unusual phone calls or emails requesting personal information, payments or proof of identity. The company specifically warned customers to be cautious of: “any unusual communications by phone or email requesting information, payments or proof of identity.” Customers should avoid providing sensitive information in response to unsolicited requests and independently verify suspicious communications. The company has also advised customers who receive spam emails to use the relevant spam-reporting features provided by their email services.

Customers Can Continue Placing Orders

Oz Hair and Beauty has said customers can continue placing orders with the company. “You are safe to continue placing orders with us,” the company said. “We know this is unsettling and we appreciate you bearing with us while we work through it properly,” the company added.

Levi Strauss cyberattack has exposed certain corporate information after an unauthorized third party gained access to company files through compromised employee computers, according to a filing with the U.S. Securities and Exchange Commission. Levi Strauss & Co. said it recently detected a cybersecurity incident involving unauthorized access to three company-issued computers. The company said the access was enabled through social engineering techniques, allowing the attackers to reach company files. According to the filing, the company initiated its response protocols after detecting the incident and implemented containment measures. It also launched an investigation that remains ongoing and engaged third-party cybersecurity experts to assist with the response.

Levi Strauss Cyberattack Investigation Remains Ongoing

Based on preliminary findings, Levi Strauss said it believes certain corporate information was accessed and exfiltrated during the incident. However, the company said its rapid response efforts successfully contained and terminated the unauthorized access. The company also stated that no consumer data had been impacted as of the date of the filing. Levi Strauss said the incident has not interrupted its business operations and that, based on the information currently available, it does not believe the incident has had or is reasonably likely to have a material impact on its business strategy, operations, financial condition, or results of operations. The company said it has provided and will provide notifications to affected parties and applicable regulators as appropriate and in accordance with applicable law. Levi Strauss & Co., headquartered in San Francisco, is known for its Levi's denim brand. The company reported net revenues of $6.3 billion for 2025, up 4% compared with fiscal year 2024 and 7% on an organic basis. The company designs and markets jeans, casual wear and related accessories for men, women and children under the Levi's, Levi Strauss Signature, and Beyond Yoga brands. Its products are sold in approximately 120 countries through chain retailers, department stores, online sites, and approximately 3,300 retail stores and shop-in-shops.

Retail Cybersecurity Incidents Continue

The Levi Strauss cyberattack comes as several major retailers have reported cybersecurity incidents involving their own systems or third-party service providers. In the first week of August 2026, the De Bijenkorf cyberattack affected the Dutch luxury department store chain after an incident involving one of its external logistics partners. The disruption affected order processing, deliveries, returns, and refunds, while the company said there was no evidence that its own infrastructure had been compromised. In October 2025, Spanish fashion retailer Mango confirmed a Mango data breach after an external marketing service provider experienced unauthorized access to limited customer information. Mango said its corporate systems were not compromised and that financial or login details remained secure. The exposed information included customers’ first names, countries, postal codes, email addresses, and phone numbers. The company said last names, banking information, credit card details, and passwords were not affected. Retailers also faced law enforcement action following a series of attacks. In July 2025, the UK’s National Crime Agency arrested four people suspected of orchestrating cyberattacks against Marks & Spencer, Co-op, and Harrods. The suspects were detained in the West Midlands and London and faced charges under the Computer Misuse Act, blackmail, money laundering, and involvement in an organized crime group. Meanwhile, in May 2025, Victoria’s Secret took down its U.S. website and some in-store services following what it described as a Victoria’s Secret security incident. The company said the precautionary shutdown was intended to address the incident while its team worked to restore operations. Its Victoria’s Secret and PINK stores remained open. The latest incident involving Levi Strauss adds another case to a growing series of cybersecurity incidents affecting major retailers, with the company continuing its investigation into the access and information involved.

A De Bijenkorf cyberattack involving one of the retailer's external logistics partners has disrupted order processing, returns, and refunds while raising concerns over potential customer data exposure. The Dutch luxury department store chain said the security incident occurred within the systems of a third-party logistics provider, adding that there is currently no evidence that its own infrastructure was compromised.

The Amsterdam-based retailer confirmed that customers can continue placing online orders and stores remain open. However, deliveries, returns, and refunds are expected to take longer than usual as the investigation continues.

De Bijenkorf Confirms Third-Party Security Incident

According to De Bijenkorf, unauthorized individuals gained access to part of its logistics partner's systems. The logistics provider responded by immediately blocking the unauthorized access and implementing additional security measures.

An external investigation is now underway to determine the cause of the incident, its scope, and whether customer information was affected.

As a precaution, De Bijenkorf has informed customers about the incident and submitted a report to the Dutch Data Protection Authority while awaiting the investigation's findings.

What Customer Data Could Be Affected in De Bijenkorf Cyberattack?

The retailer said investigators are still determining whether any personal information has been compromised.

Based on the information currently available, data that may be involved includes:

• Customer names and contact details, including email addresses, postal addresses, and phone numbers.
• Information related to online purchases, such as ordered products, pricing, discounts, delivery details, and the payment method used.
• For business customers, company names and VAT numbers stored in My Account may also be involved.

De Bijenkorf emphasized that sensitive financial information is not part of the incident. The company said payment details, bank account numbers, credit card information, usernames, and passwords were not accessed.

Investigation Continues as Customers Await Confirmation

The retailer said it is still investigating whether individual customers have been affected. Customers whose information is confirmed to be involved will receive direct communication via email from info@debijenkorf.nl.

For those who have not yet received a notification, the company said it cannot currently rule out the possibility that their information was included in the incident until the investigation is completed.

De Bijenkorf also stressed that no login credentials were compromised, meaning unauthorized individuals cannot access customer accounts using stolen usernames or passwords.

Retailer Warns Customers About Phishing Risk

Although the investigation remains ongoing, De Bijenkorf warned customers to stay alert for a possible phishing risk if personal information is ultimately found to have been exposed.

The retailer advised customers not to click on suspicious links or open unexpected attachments. It also reminded customers never to share passwords, payment information, or personal details through email or phone calls.

The company said it will never request credit card details, gift card information, or other sensitive information via email.

Logistics Cyberattacks Continue to Disrupt Supply Chains

The incident adds to a growing list of attacks targeting organizations that support retail operations rather than retailers directly. A logistics cyberattack can interrupt deliveries, returns, and customer service even when the affected retailer's own systems remain operational.

In July 2026, a ransomware attack on Japan's largest refrigerated logistics company disrupted food deliveries across the country, causing supply shortages for restaurant chains, including Kentucky Fried Chicken. The incident demonstrated how cyberattacks on logistics providers can quickly impact downstream retail operations and customer services.

For now, De Bijenkorf said its stores remain open, online ordering continues to operate, and there are no indications that its own systems have been compromised. The retailer said it will provide additional updates as the external investigation establishes whether customer data was affected and the full extent of the incident.