WISECHECKER / SECURITY
Official updates on global cyber incidents: affected information, later findings, service recovery and the steps affected customers should take.
Sources reviewed:
Scheduled source reviews every 6 hours. This is not a live security scanner or a complete list of incidents. Check the linked official notice for urgent decisions.
The six-hour review window has passed. Treat time-sensitive details as awaiting reconfirmation.
Find the official notice for a company you use, understand what changed after the first announcement, and check what you can do now. An outage, a security investigation and confirmed theft of personal data are different events.
40 of 40 cases
Recent incidents and current notices
Airline reservation access disclosed; investigations continue
Affected service or information: Cathay Pacific booking records and certain Malaysia Airlines customer information processed by Amadeus; no global total published
- Cathay’s October 30 notice, updated at 16:11 HKT (08:11 UTC), says Amadeus notified it on October 28 and supplied more details on October 29. According to Amadeus data cited by Cathay, unauthorized access in the supplier’s system between August 2023 and September 2026 affected around 53,000 Cathay bookings. This is a booking-record count, not a confirmed number of people or a total across airlines. Most accessed records contained booking reference, passenger name and flight details; a smaller subset potentially included email/phone contacts, travel-document and/or frequent-flyer numbers. Cathay reports no evidence of financial/payment data access, no impact on its own systems or operations, and continued investigation. It says Amadeus reset a password and strengthened monitoring, with no evidence of misuse identified to date; this is not recovery of copied data. Individual customer notifications are planned once relevant details are established.
- Malaysia Airlines’ October 31 notice says certain customer information processed through Amadeus between August 2023 and September 2026 may have been affected. That is the stated information-processing period, not a separately confirmed intrusion duration. It reports its own IT systems were not compromised, currently no evidence of financial-information access, and ongoing investigation/impact assessment. It publishes no affected count or complete data-field list. Do not transfer Cathay’s 53,000 bookings or data categories to Malaysia Airlines. Neither notice gives a compensation entitlement or claim deadline.
What you can do Open the airline’s known app, website or support channel directly to check individual notices. Be alert to messages that use accurate trip details to request personal information, financial information, payments or login codes. Keep travel arrangements unchanged unless the airline advises otherwise; these disclosures do not themselves require cancellation or a password reset of every customer account.
Cathay · October 30 notice · Malaysia Airlines · October 31 notice
Medical-resident and patient notices; data fields vary
Affected service or information: U.S. notification templates for medical residents and patients; no worldwide affected-person total stated
- HCA says it detected suspicious IT activity on August 12 and determined that an unauthorized party accessed systems and copied files that day. It secured systems, engaged outside experts and notified law enforcement; the letter gives no precise dates for each later response step.
- The November 2 templates distinguish medical residents’ employment records from patient records. The resident template lists names, SSNs, birth dates, contact details and immigration information where applicable. The patient template leaves the personal-data list as a recipient-specific variable; it does not establish the same fields for every patient. The letter date is not proof all letters were sent or received. Notified recipients are offered two years of IDX identity protection, with enrollment by February 2, 2027 using their individual code. Credit monitoring needs activation and an established credit record plus internet/computer access. The offer is not a cash award or a guarantee of eligibility in every country. HCA says it has no indication of publication, further disclosure or misuse at the notice date; that does not undo the copying.
What you can do Verify your individual notice through HCA’s established contact channel, check the data fields that apply to you and use the enrollment instructions in that notice. Do not send personal information through an unexpected claim link.
HCA · November 2 notification templates filed with Massachusetts
Environment variables accessed; investigation continues
Affected service or information: A subset of organizations using Trigger.dev; countries, count and attack dates not disclosed
- The November 1 disclosure at 22:50 UTC confirms unauthorized access to environment variables for a subset of organizations. Trigger.dev says it blocked the exploit and emailed all impacted account owners mitigation steps. Although the status page labels the notice resolved, the body and original blog describe an ongoing investigation and further updates. This does not prove copied secrets were recovered or every customer completed rotation. The disclosure time is not the intrusion time.
What you can do Affected organization owners should verify the message through the known dashboard or support channel and follow the supplied secret-replacement steps. Check dependent applications and upstream activity; do not send secret values in a reply or assume every organization was affected.
November 1 official status disclosure · Original incident disclosure
Provider incident: managed TLS certificates reissued; node access unconfirmed
One CDN node in Armenia; this location does not define the countries of affected customers
- bunny.net said its infrastructure provider had reported unauthorized access involving third-party server-management software the previous week. Traffic was removed from the Armenia node within 20 minutes of the alert, and the server was permanently removed. Neither investigation found evidence that the node was accessed, but access could not be ruled out. Potential exposure, if access occurred, was cached CDN content, Pull Zone configurations and TLS certificates on that server; account data was not stored there and internal systems were not affected.
- Managed custom-domain certificates were being replaced in controlled batches with new private keys while existing certificates continued to serve content. The estimated completion was revised to the end of October 31; this was a forecast.
- All managed custom-domain TLS certificates had been reissued with new private keys and their previous certificates revoked. The provider was no longer in use while its investigation continued. This completes the stated certificate task; it does not prove a data theft occurred or that an investigation ended.
Operators using managed certificates do not need to act, according to bunny.net. Operators managing their own TLS certificates should revoke and reissue them with new private keys as a precaution. Coordinate deployment to preserve service. Visitors are not being asked to change DNS, clear data or disable certificate checks.
Account-information exposure and phased individual notices
Users of the four named services; affected countries, account count and intrusion dates not specified
- The page metadata shows an October 1 update; this is not an intrusion or discovery date. Scribd says an unauthorized party reached internal systems and accessed user information. Basic account information was involved for most affected accounts; more sensitive information was involved for a smaller number. The page does not enumerate the fields; partial-card details circulating elsewhere are not confirmed here. Scribd says it closed the vulnerability, brought in forensic experts and notified law enforcement and data-protection authorities. Epiq sends notices on its behalf in phases. Not receiving a notice does not establish that an account is unaffected. The page does not give an exact notification start date, victim total or compensation deadline.
Use the known official site to reset passwords for the named accounts as Scribd recommends. Verify any Epiq notice against the linked help page; never supply a password or one-time code through an unsolicited message. Use the official support details on that page.
Private-project metadata exposed; files and passwords excluded
OSF users and moderators; countries unspecified and exact affected-user count unknown
- The October 29 notice dates the earliest logged unauthorized access to October 24 at 15:42 ET. An access-control flaw introduced on October 17 affected sixteen endpoints in an internal administrative application. Names, user IDs, email addresses and project/registration/preprint titles, descriptions and GUIDs were accessed, including metadata for private projects.
- OSF discovered the issue at 08:15 ET, disabled administrative-tool access by 10:00 ET, then released and verified fixes around 21:00 ET before restoring authorized staff access. This repair does not recover information already accessed.
- The notice says files, including private-project files, were not viewed or downloaded; passwords were not accessed, and no user content was changed or deleted. All OSF users are being notified because the exact affected count is unknown. Do not turn sixteen endpoints into sixteen users or private metadata exposure into file theft.
OSF says users do not need to take action in response to this incident. Read the official notice and use its known support contact for questions; do not impose unrelated password resets or delete research material.
Checkout redirects and later merchant-access recovery
Swym Wishlist Plus storefronts; countries and victim totals unspecified
- The October 16 notice dates unauthorized configuration activity to October 14, 10:06–11:56 UTC. A script could redirect checkout clicks to an imitation payment page. Mitigations began at 15:02; fixes finished at 16:32 UTC.
- The FAQ distinguishes app-held data from details shoppers manually entered on an external page. No evidence of app-held data compromise does not rule out that exposure. All merchants were paused as a precaution; victim counts and compensation terms are not stated.
- The later status says patches are applied and merchant access is open, with monitoring and an external audit continuing. This supersedes the FAQ’s earlier access pause; it does not confirm recovery of information already submitted elsewhere.
If you entered card details on an unexpected checkout page, contact your card issuer through a known channel. Merchants should check current Swym guidance and customer reports; avoid blanket deletions or unnecessary account changes.
Swym · October 16 notice · Swym · October 20 FAQ · Swym · October 27 status
Customer profile information accessed; review by organization continues
Chainalysis platform users; affected countries and total number of people or organizations not specified
- The October 30 company notice includes the customer email it sent. Chainalysis says an external actor accessed internal systems and tools during October and accessed user IDs, full names, email addresses and organization role labels for platform users. It has not given exact intrusion or discovery dates, a total or a country list. Records affected for each organization are still being determined; notification of all customers is not a count of confirmed victims.
- Based on the investigation so far, the company reports no indication of unauthorized access to investigation graphs, notes or cases, transaction/query results, clear-text passwords, MFA secrets or session tokens. External experts are investigating and strengthening systems. These findings are limited to the evidence reviewed and do not recover copied profile data. The investigation continues; no compensation terms are stated. Chainalysis explicitly says this incident is unrelated to the Binance theft.
Follow your organization’s notice and confirm unexpected password-reset or authentication prompts through a known channel. If your organization has not enabled two-factor authentication, contact its administrator or established Chainalysis account manager. Do not send passwords or one-time codes in response to an unsolicited message.
Business services restored; data-impact investigation continues
LOXONE internal CRM and applicant systems; affected individuals and countries not enumerated
- LOXONE says it detected an attack on internal systems on October 18. It assumes data was copied from its CRM and applicant systems, potentially including business-partner contacts, support requests and applicant data. The exact scope remains under investigation; affected people will be contacted directly. The company reports no indication that LOXONE.com accounts or passwords were compromised and says credit-card and banking details were not affected.
- At 11:27 CET on October 30 (10:27 UTC), LOXONE reported its website, webshop, Partner Portal, Configurator and Library available again, with order processing, production, logistics and support operating normally. It says Miniservers and customer installations, Remote Connect and Exosphere were not affected. Service restoration does not recover copied data or complete the data-impact investigation. Installing PHP patches during recovery does not establish PHP as the attack vector.
- The October 26 notice says Remote Connect will require Miniserver version 17.2.10.21 or later from December 1, 2026, and generally allows four weeks after future releases to update. Older versions would no longer have connections brokered by Remote Connect; local-network operation is unchanged. This is a future precaution, not a current loss of local control or evidence that Remote Connect was breached.
Partners and affected applicants should use known LOXONE contacts and follow their individual notice. Administrators should plan supported Miniserver updates through Loxone Config or the app and use the added account two-factor authentication. Verify payment requests independently: LOXONE says its bank details have not changed. Do not send credentials in plain text or bypass certificate warnings.
Employee information accessed at a software supplier; scope under review
Laerdal group employees; affected countries, individuals and data fields not specified
- In its October 15 notice, Laerdal says an attack on a third-party software provider led to unauthorized access to employee personal information. It is establishing the affected fields and individuals, engaging external experts and notifying relevant authorities. It reports no indication of compromise of customer data, product data, intellectual property or customer transactions, and says customer-facing services are unaffected. These findings do not identify the supplier or confirm that every employee was affected.
- The October 23 update invites people who worked in a Laerdal company between January 1, 2018 and October 5, 2026 to contact incidentresponse@laerdal.com with data questions. That employment period is a contact criterion, not the attack duration or a confirmed list of victims. The notice gives no affected-person total, compensation terms or completed investigation date.
Current and former staff should verify the notice through Laerdal’s known channels and contact the published incident-response address for individual questions. Be cautious about unsolicited requests for identity documents, credentials or payment. Customers should not change unrelated product settings solely because of this employee-data notice.
Potential order-data exposure; compensation registration now open
91APP Commerce Cloud order database; affected countries not enumerated in the cited notice
- The October 29 investor announcement gives a maximum potential scope of 1,329 brands and 4,798,255 consumers with online orders from April 4, 2025 through October 14, 2026. These are not confirmed totals of people whose data was taken. Potential fields include names, phone numbers, delivery addresses, email addresses where provided, and order records; the notice excludes passwords and payment data. 91APP says it first received a client report on October 4, blocked the attack on October 14, notified police and the regulator on October 15, and publicly disclosed it on October 16.
- The separate October 29 compensation notice includes people in the maximum potential scope, including those without financial loss. Handling through this process depends on brand authorization and the affected-person notification. Email notices, or SMS when no email is available, and publication of the official registration process are expected from November 2, 2026. At the October 29 review, online registration was not yet open. November 2 is a planned opening, not a claim deadline or guaranteed payment date; no fixed award is stated. Questions can go directly to the published company contacts while authorization and notification proceed.
- The compensation FAQ describes the October 30 forced sign-in as a precautionary security update, not a new incident. Reuse of already exposed data in scams does not establish another intrusion. Containment does not recover copies of exposed data.
- The official compensation page checked on November 2 now states that online registration is open, with separate forms for financial loss and personal-data harm without financial loss. It says individual notices begin from November 2 after the relevant brand authorizes 91APP: by email, or SMS where no email address is held. This does not prove everyone has already been notified, a claim has been accepted, or compensation has been paid. The page does not state a fixed award or claim deadline. Use the registration entries reached directly from the official page and confirm brand authorization and your notification; do not submit personal information through unsolicited message links. The page gives no precise publication time for this change.
Open the official compensation page directly and verify the brand-specific notice. Do not follow unsolicited links to submit personal data, join a messaging group, operate an ATM, or disclose passwords or financial details. Preserve suspicious messages and loss records. No eligibility check or claim form is provided on WiseChecker.
91APP · Investor Relations · 2026-10-29 · 91APP · Compensation and notifications · checked November 2, 2026
Client-related files accessed; investigation and direct notification continue
Borden Ladner Gervais LLP (BLG), Canada; affected client countries and counts not specified
- Company statement; publication date from official metadata: In its current statement, BLG confirms unauthorized access to certain files, including client-related files, within a limited portion of its Microsoft cloud environment. It says internal controls contained the incident shortly afterward, Mandiant is supporting the ongoing investigation and remediation, affected clients are being contacted directly, and regulators and law enforcement have been notified. Official structured metadata dates the statement to October 30, 2026. The incident date, exposed data fields, affected totals and compensation terms are not specified. This is a disclosure about BLG, not evidence that Microsoft services generally were compromised.
Affected clients should contact their established BLG relationship partner through a known channel and follow their individual notice. Treat unexpected requests for confidential files, payment changes or credentials cautiously. Containment is not proof that copied files were recovered, and an ongoing investigation is not a completed data-impact review.
CVE investigation; no evidence of platform exploitation
Akamai Compute / Linode customer workloads; affected countries and counts unspecified
- Akamai published a CVE-2026-98432 remote-code-execution advisory on October 30. At 01:55 UTC on October 31, it said mitigations for the known attack vector were being deployed while investigation continued, with no evidence of exploitation on Akamai Compute at that time. It advises customers to apply upstream operating-system updates to workloads when available. This is not confirmation of a breach, universal patch completion or a blanket service outage.
- At 10:55 UTC on November 2, Akamai says it deployed network rules dropping IPv4 packets with optional headers on public and VPC interfaces, eliminating the immediate remote attack vector while kernel patching continues. Updated distributions and the Linode-provided kernel should be applied when available and applicable. This is a provider mitigation statement, not confirmation of customer compromise or completed patching of every workload. It is not an instruction for customers to copy broad network rules.
Authorized workload administrators should follow the exact vendor advisory, verify package applicability, prepare recovery and test normal functions after updates. Ordinary visitors should follow their service operator’s notice. Do not run an unknown exploit to test exposure.
Environment variables must be treated as compromised
Northflank workloads, secret groups and global secrets; countries and affected-account count unspecified
- At 13:40 UTC on October 30, Northflank advised immediate rotation; at 13:58 it told all users to assume environment variables were decrypted. At 15:12 it enabled Postgres/MongoDB secret rotation for all users and reported multiple users saying their AI keys had been used. Its 19:28 UTC update says the investigation continues with no further confirmed findings and repeats rotation of all secrets and credentials, including workloads, secret groups and global secrets, plus disabling public addon access where enabled. This is a protective instruction, not proof that every value was stolen or that the incident is resolved.
- Sentry says its small Northflank footprint contains internal, demo or experimental services and no production infrastructure. It reports no evidence of impact to customer data or customer-facing services and continues monitoring. That finding applies to Sentry, not every Northflank customer; no exact publication time is provided.
- At 23:38 UTC on October 30, Northflank reported unauthorized use of customer-supplied AI API keys and instructed customers who had not completed rotation to revoke credentials with the issuing providers, generate replacements and update affected secrets/workloads. Review provider usage and billing logs for unexpected activity and contact the relevant support teams. At 01:04 UTC on October 31 it enabled audit logs for all customers, including free users. Similarities to other attacks are not confirmed attribution; this does not establish recovery or require repeating a verified completed rotation.
- At 13:34 UTC on October 31, Northflank said MySQL and Redis secret rotation was available to all customers and asked users who had not already done so to rotate all secrets. This adds to the earlier Postgres/MongoDB tools; availability is not proof that each customer has completed rotation or that the security incident is resolved.
- At 22:32 UTC on October 31, Minio secret rotation became available to all customers; RabbitMQ followed at 23:31 UTC. These tools extend the earlier database rotation options. Customers who have not completed the required rotation should follow current official guidance. Tool availability is not evidence that every secret has been replaced or that the incident is resolved; do not repeat an already verified completed rotation without a new reason.
- At 11:09 UTC on November 2, Northflank moved the notice to monitoring. It believes the vector was contained within an hour of the first alert and reports no sign of later attacker presence. Independent forensic auditors are still reviewing the incident. Its evidence points to control-plane secrets, with no sign that running workloads or their data were accessed; forward-deployed and dedicated control planes are excluded. Some customers report unauthorized AI-secret use. Rotate all integration and project secrets, prioritizing AI, cloud, payment, private-key and database credentials; review provider logs and contact AI providers about unexpected spend. Northflank says CVE-2026-98432 was patched across its fleet and connected BYOC clusters; disconnected BYOC users should contact support. Reconnect revoked integrations as instructed. These statements do not establish retrieval of copied secrets or a completed investigation.
If you operate affected Northflank resources, have the authorized administrator follow the current official rotation instructions and review dependent services. If you only use an application hosted there, follow its operator’s notice; do not change unrelated accounts or disable protections.
Official sources: Northflank · 2026-10-30 · Sentry · 2026-10-30
Security incident; database theft remains unconfirmed
Archive of Our Own (AO3); affected countries and account counts unspecified
- OTW reports a security incident and continued AO3 downtime. It says works and bookmarks were not deleted, but cannot rule out theft of account usernames, email/IP addresses and password hashes. Donor information is separate. It estimates at least two weeks offline, possibly four; degraded or read-only access is only a possibility, not a restoration promise.
- On November 1, OTW added a note pointing readers to a Tumblr safety update concerning possible scammers and suspicious sites. That addition does not confirm user-database theft, a new exposed-data category or service restoration. The linked safety post itself was not retrieved in this review; no additional claims from it are adopted.
What you can do Change passwords reused on other services as a precaution. Use known official notices; avoid unofficial recovery pages. Do not treat unavailable access as proof that your works were deleted.
Official source: OTW · AO3 · 2026-10-30
Selected withdrawals reopened; FBI attribution is a separate finding
Binance platform; countries, affected users and final loss not specified
- Binance is investigating a potential security issue. It says user funds remain safe, a company statement rather than an independent loss assessment. A later post says withdrawals await completed security checks; no restart deadline is given.
- Binance’s preliminary investigation points to a potentially compromised DevOps engineer’s laptop and unauthorized withdrawal transactions through a service container. It reports no evidence of wallet private-key leakage. The company estimates total impact around US$6.3 billion and about US$3 billion frozen on-chain; frozen assets are not confirmed returned funds or a final loss figure. At that stage, deposits and withdrawals were suspended. Binance pledges to cover losses using SAFU and company funds, with a post-mortem and updated Proof of Reserves to follow. These are company statements, not confirmation that reimbursement or recovery is complete. That announcement did not state a reopening time or claim deadline.
- In a later service update, Binance says deposits are operating normally while withdrawals remain paused during security changes to its withdrawal service and associated address controls. It expects resumption within 48 hours of this announcement. That is the company’s estimate, not a guaranteed completion time or confirmation that withdrawals have restarted. Its investigation and root-cause report remain pending; this update does not establish completed reimbursement or recovery.
- Binance says its subsequent investigation found additional breach points beyond the initially suspected laptop. At 08:47 UTC it gave an expected 45-hour timeline for withdrawal resumption and said deposits remain unaffected. This is a dated company estimate, not a countdown restarted at our review time or proof of reopening. The full cause remains under investigation.
- Binance says it has reserved more than US$6.34 billion of company funds, including US$5 billion already held in the affected token assets. Remaining token purchases and OTC settlement are still in progress. These figures exclude frozen or protected assets; roughly US$3 billion frozen remains subject to recovery and verification. Reserved funds, frozen assets and completed customer reimbursement are different outcomes.
- In Update #2, headed October 30, Binance targeted phased withdrawal resumption in approximately 34 hours, subject to security checks. The official Binance Announcement account also publishes the full notice. It planned a Proof of Reserves snapshot within 12 hours, results by November 2 and technical findings in about 48 hours only if verified and safe to disclose. These are dated plans, not a fresh countdown or proof of reopening, recovered frozen assets or customer repayment.
- In its October 31 Recovery Update #3, Binance reports replenishing 90% of the affected assets, up from about 80%. It says BTC, ETH, USDT, BNB, SOL, USDC, XRP, USD1, RLUSD and ZEC are fully backed; the remaining 10% consists of less-liquid tokens still being purchased. This is a company replenishment statement, not proof that 90% of the stolen assets were recovered or customers repaid. The listed funding includes company treasury, a portion of Futures insurance funds and partial SAFU deployment described as expected over the next 24 hours. The same notice says a new PoR snapshot as of October 31 at 00:00 UTC has been posted. It separately targets the full zero-knowledge proof for November 3 (UTC), replacing the earlier November 2 target. A published snapshot is not a completed proof or an independent audit. Withdrawals remain a planned November 1 milestone in the notice, not confirmed resumed. Its displayed publication time has no explicit time zone, so only the date is recorded.
- In its October 31 alert, the FBI attributes the theft of more than US$6 billion on or about October 29 to North Korean activity it calls TraderTraitor. This is an official law-enforcement attribution, not an attacker claim, a final loss audit or proof that stolen assets have been recovered.
- The November 1 Recovery Update #4 says Binance is preparing phase one of withdrawals for 06:00–09:00 UTC that day. At the earlier 04:58 UTC review, the window was still ahead; the title does not establish that withdrawals have started. Only the asset/network pairs in its table are included, such as BTC on BTC and ETH/USDT/USDC on ETH; additional pairs depend on readiness checks. Users should check their exact pair on the official withdrawal or network-status page, and expect possible rollout delays. Deposits remain open. Binance reports about 95% of affected assets replenished, with the remaining 5% in less-liquid tokens. This is not recovery of 95% of the stolen assets or proof of completed user repayment. Investigation and a later post-incident report remain pending; the earlier full-proof target is not confirmation of completion.
- At this review, the current official profile explicitly lists these reopened pairs: Bitcoin: BTC; Ethereum: ETH/USDT/USDC; BNB Smart Chain: BNB/USDT/USDC; XRP: XRP; Base: ETH/USDC; Dogecoin: DOGE; Optimism: ETH/USDT/USDC; Arbitrum: ARB/ETH/USDT/USDC; TRON: TRX/USDT; Solana: SOL/USDT/USDC; Polygon: POL/USDT/USDC; Avalanche C-Chain: AVAX/USDT/USDC; Zcash: ZEC; TON: USDT/GRAM; Sui: SUI. These are statements of availability by Binance, not individual account tests. Other pairs are not confirmed here. The profile extract does not provide exact publication times for the individual updates. Phased reopening does not establish full restoration, completed repayment or recovery of stolen assets.
- The current official Binance profile says withdrawals began reopening in phases at 06:00 UTC on November 1 and all 15 networks and assets in the initial phase had resumed by 12:36 UTC. This confirms completion of that first phase only, not reopening of every remaining asset/network, completed customer repayment or recovery of stolen assets. The individual post publication time is not available in the extract. Conflicting transaction-window figures in secondary or regional reposts were not adopted.
- In its November 2 post published at 08:00:38 UTC, Binance adds fiat withdrawals in USD, AED, VND, PHP and IDR. This is separate from the initial 15-network crypto phase; currency availability does not establish every regional/account entitlement, all crypto withdrawals, completed repayment or recovery of stolen assets. Check the exact currency, available channel, eligibility requirements and any existing request through the official service. Update #2’s original body was also reopened at this review, but its heading says October 30 while its signature says October 31; that date conflict remains unresolved. The #3/#4 originals still could not be reopened. Earlier dated findings are retained and the full-page check time remains unchanged.
- Recovery Update #5, published November 2 at 12:49 UTC, says Binance completed the full zero-knowledge proof for its October 31 00:00 UTC PoR snapshot for BTC, ETH, USDT, BNB, SOL, USDC, XRP, USD1, RLUSD and ZEC. This is a company claim about ten-token snapshot verification, not our account verification, an independent full financial audit, recovery of stolen funds or all withdrawals restored. It continues to report about 95% replenishment and a less-liquid 5% outstanding. It plans the next withdrawal phase for November 3 and another snapshot for November 4, with an estimated 40–50 hours to compute its proof; these are future plans, not a fresh countdown or completed rollout. The 14:35 UTC security reminder warns of paid priority withdrawals, fake vaults and wallet-signing requests. Use known official channels and never transfer or authorize assets to unlock withdrawals. Older Update #2/#3/#4 could not be reopened this run; the previously observed Update #2 heading/signature date conflict remains, and the page-wide review clock stays held.
What you can do Follow official account notices; distrust unsolicited recovery links and requests for credentials.
Official sources: Initial investigation · Preliminary findings · Frozen assets · Deposits and withdrawals · Latest service update · Later investigation update · Asset recovery and company funding · Binance · Update #2 · 2026-10-30
Binance · Recovery Update #3 · English text
Binance · Recovery Update #4 · 2026-11-01
Binance · X · FBI · 2026-10-31
Partial source recheck: the two ICO notices, older Binance Update #2/#3/#4 and the OTW/AO3 notice could not be reopened this run. Update #2 also has an unresolved heading/signature date conflict from a previous readable version. Earlier dated findings remain; the overall page review time has not been extended.
Binance · November 2 fiat withdrawal update
Binance · Recovery Update #5 · November 2 · Binance · November 2 scam warning
Postmortem reports 95% of affected wallets refunded
International Polymarket.com; countries, victim counts and losses unspecified in the notice
- Polymarket reported a compromised provider and promised to reimburse affected users. Its 18:05–19:05 UTC trading interruption is explicitly resolved. This does not confirm completed reimbursements; the notice gives no application deadline.
- The October 30 20:07 UTC postmortem says a compromised performance-monitoring script used some active sessions to sell positions and move funds. Polymarket says 95% of affected wallets had been fully refunded as of that dated update. It describes US$3.9 million being returned: US$2.7 million plus US$1.2 million for pause-related losses. This is not a claim that every wallet has been repaid. Identified eligible wallets need no claim or ticket; disputes should use the form linked from the official notice. The separate trading-pause and security notices track different components and time windows.
What you can do Review orders and account activity through official support. Avoid unsolicited refund links.
Official sources: Polymarket · 1 · Polymarket · Postmortem · 2026-10-30
Unauthorized access and partial platform recovery
Allium systems and platform features; specific data types, affected countries and counts not disclosed in the cited notice
- Allium says it identified unauthorized access to certain systems, restricted access and notified affected customers directly. Its October 28 announcement describes an independent investigation and restored core services; detailed findings are still pending.
- Core Explorer/API returned, but Assistant/MCP and access to uploaded tables remain unavailable. Datashare delivery resumed; some verification and backfill remain incomplete, including Hyperliquid and affected BigQuery windows. Service recovery does not prove all data is current or copied information recovered.
- Allium now says Datashares on Snowflake, BigQuery and Databricks passed historical verification for all chains across all regions. This advances the earlier incomplete verification; it does not confirm restoration of Assistant/MCP, every platform feature, or recovery of copied information.
- At 15:38 UTC on November 2, Allium explicitly resolved its Datashare incident. At 16:22 UTC it reported Assistant restored for all users, while further feature recovery, including MCP, remained to be announced. These service updates do not establish that copied information was recovered or the security investigation finished.
What you can do Follow the official password-reset and replacement API-key instructions; wait if your Allium contact is issuing the key. Enable MFA as recommended and verify data completeness before dependent jobs. The notices do not establish compromise of named downstream companies or loss of funds.
Official sources: Security notice · Explorer/API · AI/MCP · Datashare
File Manager recovery and precautionary password resets
Affected service or information: Some mail and FTP/SFTP users; File Manager and webmail · data-exposure scope not established
- DreamHost began investigating File Manager and webmail disruption and precautionary credential resets.
- The KB says incoming mail continues and FTP/SFTP files remain stored on the server; affected users need owner-set passwords to regain access.
- File Manager returned at 22:35 UTC; monitoring and affected-user resets continue. This is not confirmation of full recovery or data theft.
- DreamHost formally closed the File Manager incident at 23:45 UTC. Password resets are still required for a subset of email and FTP/SFTP users. Closure does not establish the scope of any data exposure or recovery of copied data.
What you can do: Affected account owners: open the panel directly, reset affected credentials, review mail forwarding and update clients. Allow up to 15 minutes; deliver credentials through a secure channel outside affected email. Other users should contact their account owner.
Official sources: Incident status · Account-owner instructions
Individual notices and identity-protection support
Affected service or information: Data associated with Frontline Central and School Health Management
- Frontline identified a third-party software flaw; unauthorized activity ended on August 15.
- Greenville County Schools’ October 21 notice limits its own affected system to external Frontline School Health Management; district internal systems were not breached. For that district it lists Medicaid billing numbers, names, student IDs and/or birth dates. It reports initial individual notices planned from October 26 and offers notified individuals 24 months of TransUnion protection, with cyber monitoring for minors and enrollment by January 31, 2027. These local data categories and eligibility terms must not be generalized to every Frontline customer. Use your individual notice and the school’s established contact route; the notice date does not prove all recipients have received a letter.
- Individual notices began around this date for affected Central and School Health Management records.
Data categories vary by person and include U.S. Social Security numbers (SSNs), birth dates and government, Medicaid or student identifiers. Frontline says investigation and remediation are complete; this does not retrieve copied data.
What you can do: Verify the notice through your school’s established channel. Eligible U.S. adults are offered two years of credit monitoring. Eligible minors may receive dark-web monitoring where available. Follow the eligibility and enrollment terms in your personal notice.
Official sources: Incident information and support · October 26 notification announcement
Internal data copied; customer-specific review continues
Affected service or information: PingCAP internal records, support material and TiDB Cloud management keys
- PingCAP discovered the incident on October 7. Its report dates unauthorized access to September 9–October 7, with internal records and source code copied.
- Copied records include contacts, business/billing information and SQL editor text/errors; exposure varies by customer. Investigators found no evidence that data in customer TiDB databases was accessed.
- The CEO says identified compromised credentials were invalidated. Exported management API-key values were encrypted and their encryption key was not exposed; secrets shared with support require separate action. Customer-specific review continues.
What you can do Have your TiDB Cloud organization owner follow the official rotation steps: replace keys, update and test dependent applications, then revoke old keys. If misuse is suspected, revoke immediately and contact official support. Rotate secrets shared with support and verify unexpected requests through a known channel.
Official sources: Incident report · Customer actions · CEO follow-up
Compromised 1.107.0 release and follow-up investigation
Affected service or information: The 1.107.0 PyPI package and affected Docker/GHCR images from October 21
- LiteLLM reported a malicious 1.107.0 package and container artifacts, including the v1.107.0, latest, main-latest and main-stable tags. Affected artifacts were removed. The private enterprise registry was not affected, according to the company.
- Its canonical investigation supersedes conflicting early assumptions. The current reconstruction says an administrative key was exposed on May 27. A follow-up removed the file about three hours later, but the original commit remained public until October 22 and the key was not revoked for over four months. On October 10, access to the internal Agent Platform exposed an organization-owner GitHub CLI OAuth token. The attacker later used owner privileges to override branch protection and alter the release workflow. Removing a file or package does not revoke a key or clean an exposed host. The report still carries its October 23 publication date; a new revision date is not asserted.
- An October 30 update documents the October 23 cosign signing-key replacement and the first releases using it on October 24: v1.103.8, v1.104.6, v1.105.4 and v1.106.3. The compromised v1.107.0 images also have valid signatures from the old key. Administrators should use the official key fingerprint and affected-image digests together; a valid old signature alone does not establish safety. This is a verification follow-up, not a newly confirmed attack.
What you can do If your team ran an affected artifact, involve its incident responders. Avoid starting Python or pip in that environment. Preserve evidence and follow the official rebuild and credential-revocation guidance from a clean system; this is not a warning that every AI user was affected.
Official sources: Affected artifacts and response · Canonical investigation
Employee mailboxes and company files accessed
Affected service or information: Two employee email accounts and some company files; affected countries not specified
- In a statement dated October 22 in New Zealand, the company reported unauthorized access to two employee email accounts and some files containing personal information. It was notifying affected people. It found no evidence that its patient-data system was compromised, reported no product, manufacturing or supply-chain disruption, and believed the incident contained. Two accounts is not a count of affected people.
What you can do If you receive a notice, follow the instructions for your own information and verify the sender through a contact you already trust. The statement does not list affected data fields or countries; do not assume all patients or all countries are affected.
Official sources: Company statement on NZX
Quanum LSM access and patient-record investigation
Affected service or information: Quanum LSM, used by some clients for test orders and results; full data scope under investigation
- Quest says it learned of unauthorized access to Quanum LSM and began its incident response, with outside experts and federal law enforcement.
- Its Form 8-K says the company believes certain patient records were accessed. The full scope was still under investigation, and business operations and patient services were not materially disrupted. The filing does not identify a patient count, specific record fields or affected countries.
What you can do Use your usual clinic or Quest contact to confirm any notice about your own records. Verify unexpected requests before sharing health information or credentials. This filing does not establish that every patient was affected, that all data was stolen, or that compensation or an enrollment deadline has been announced.
Official sources: Company Form 8-K on SEC EDGAR
ATS/CRM incident and partial feature recovery
Affected service or information: Bullhorn ATS/CRM; BBO access and integrations · customer-data impact still under investigation
- Bullhorn’s FAQ confirms a cyber incident affecting ATS/CRM. Its investigation has not determined whether customer data was taken; affected customers will be notified directly. The company says separate shutdowns to address PHP vulnerabilities were unrelated to this incident.
- The status update says products are available, but Canvas reporting within Bullhorn ATS is unavailable and some login or ATS-to-BBO SSO issues remain. BBO access is restored; affected SSO users should contact support for a targeted fix. Monitoring continues. Bullhorn’s Canvas is separate from Instructure Canvas.
- The October 25 updates at 20:00 UTC reiterate that products and BBO access are available, while ATS Canvas reporting and some login/SSO functions remain affected. Existing BBO credentials still work for time entry without a password change. Affected SSO users should request the targeted support fix.
- The October 26 status posts retain the remaining ATS Canvas and login/SSO restrictions and continue monitoring. This is not confirmation of full feature recovery.
- The October 27 update retains ATS Canvas and login/SSO restrictions and adds that the QuickBooks Desktop connector is offline for BBO customers who use it. Existing credentials still work for BBO time entry without a password change; affected SSO users should contact support. Monitoring continues.
- The October 29 notices repeat the existing Canvas, login/SSO and QuickBooks Desktop restrictions; no additional functional recovery is confirmed. Their prose labels the time EST while structured timestamps use -04:00. The precise new source time remains unconfirmed. This page retains its previous overall review clock pending consistent source timing.
- A later October 29 product notice restores Canvas access and running existing reports for all customers. Create/Copy Report remains unavailable for all customers, while Modify Report remains unavailable for some US customers. Some users may encounter a CAPTCHA; Canvas login errors should be reported to support. The QuickBooks Desktop connector remains offline, and existing BBO credentials still work for time entry without a password change. The removal of the earlier SSO sentence does not explicitly confirm full SSO recovery. Monitoring continues. The newer product header says 10:30 AM EST, but its structured post time is 10:28 EDT; the exact new source time remains unconfirmed, so this page retains its previous overall review clock.
- A further product update explicitly says all Canvas functionality is fully restored. BBO login problems still require a support case, and the QuickBooks Desktop connector remains unavailable for affected BBO customers. Existing credentials continue to work for BBO time entry without a password change. The overall incident remains under monitoring; this is not confirmation that the security investigation or customer-data assessment is complete. The new EST labels still conflict with structured EDT timestamps, so the precise source time and this page’s overall review clock remain unchanged.
- The October 30 update reiterates that Canvas is fully restored, while the QuickBooks Desktop connector remains unavailable for affected BBO customers. BBO login problems still require a support case. Its EST labels and structured EDT times remain inconsistent, so the exact update time and this page’s overall review clock remain unconfirmed.
- The October 30 notice now says adding or editing Bullhorn Canvas reports is unavailable; running, copying and deleting reports are unaffected. BBO login issues still go to support, the QuickBooks Desktop connector remains unavailable, and existing BBO time-entry credentials do not require a password change. The updated FAQ directs support cases through Bullhorn Hub or Help in Bullhorn ATS. EST labels still conflict with EDT metadata; the precise confirmation clock remains held. This is a feature restriction, not confirmation of a new breach.
- The November 2 refresh at 07:00 EST (12:00 UTC) continues to list Canvas report creation/editing restrictions, BBO login support and the offline QuickBooks Desktop connector. Running, copying and deleting Canvas reports remain unaffected, and existing BBO time-entry credentials need no password change. The current labels and UTC−05:00 offsets agree; the older October EST/EDT conflict is not retroactively resolved. This is limited feature recovery, not a statement that every feature or copied data has been restored.
What you can do Match instructions to your product and login method. BBO time entry using existing credentials does not require a password change under this notice. Follow official account-specific API or login instructions rather than rotating every integration secret. Check time-entry/payroll outcomes before retrying. SLA credits are subject to later review, not guaranteed.
Official sources: Product status · BBO status · Incident FAQ
October exposure, service closure and claim deadlines
Affected service or information: Shared clusters, some dedicated servers, stored secrets and account/project data · scope varies by system
- Zeabur announced a phased service closure from December 1 through December 31. December 31 is the final stop, not a guarantee that each server runs until then.
- The preliminary report describes an October 14–15 intrusion. It confirms reads of 3,218,965 environment-variable records and data relating to 321,810 accounts; these are different counts. Shared clusters and 101 GCP dedicated servers were involved. Variables already moved off the platform database were outside that database read, but a compromised host may still expose them. The proposed link to August remains a hypothesis; investigation continues.
- The later notice recommends migration by November 30 and sets November 30 as the security-incident claim deadline. Balance refunds are separate: apply by support ticket by that date, or by email afterward, subject to the stated conditions. The notice says service data will be deleted by the final December 31 closure; dedicated-server data can be deleted earlier at that server’s expiry. This updates dates left open in the October 17 notice.
What you can do If you use Zeabur, follow its system-specific notice to replace exposed credentials, revoke old keys and review access and charges. An August rotation alone does not address this October event; credentials already replaced after October containment need not be repeated solely because of this page. Test backups and migration before your own expiry. Submit loss claims separately through official support, using masked evidence; compensation is not guaranteed.
Official sources: Preliminary report · Service closure · Migration, refunds & claims
Stored-secret exposure and precautionary key revocations
Affected service or information: Environment variables and registry credentials
- Railway says some stored variables may have been decrypted, potentially exposing API keys and database/registry credentials.
- The preliminary report, dated October 22, estimates potentially compromised variables in at most 1.85% of workspaces (about 100,000 workspaces). This is not a user count or a final assessment; which keys were decrypted and possible source-code access remain under investigation.
- The 19:18 UTC notice says notifications to workspaces meeting the current higher-risk criteria finished at 18:57:54 UTC; other workspaces are not confirmed safe. At 22:06 UTC Railway formally resolved the platform outage: builds, deployments, API and dashboard were normal. Signups remained paused and the support/community site unavailable under a separate notice. This does not close the security investigation.
- At 13:57 UTC, Railway clarified that provider revocations can include newer replacement keys accidentally included in a precautionary batch. It says this is not a new attack and those revocations do not prove the replacement keys were compromised.
- Railway closed the precautionary API-key clarification notice at 06:26 UTC as having no impact. This closes that notice; it does not reverse the October 21 data exposure or remove the need to replace credentials that were actually revoked. The separate support notice, rechecked October 25, now says station.railway.com is restored; new signups remain paused and some nonessential features are disabled. It does not specify a restoration time.
- Railway reports services fully restored for existing users while new signups remain paused. Reopening this week is a plan. Railway cannot refund fraudulent spend on other AI platforms; contact that provider first, then request support escalation with evidence. No reimbursement is guaranteed.
- At 03:20 UTC Railway closed the support notice as having no impact. This does not establish that new registrations reopened or that copied secrets were recovered.
What you can do Have the application owner replace incident-exposed credentials that have not already been rotated, revoke old keys, update variables, redeploy dependent services and review provider logs. Replace a newer key if the provider actually revoked it or gives other account-specific instructions; working keys do not need repeat rotation solely because of the October 24 notice. Service recovery does not recover stolen copies.
Official sources: Railway disclosure · Railway preliminary report · Railway status · Key revocation clarification · Support and signups notice
Brand-by-brand recovery; data investigation still open
Affected service or information: Retail websites, apps and e-commerce · Europe and United States
- Ahold Delhaize disclosed a network security issue and took some systems offline as a precaution. Stores remained open.
- The October 19 update confirmed malicious activity and uneven recovery by brand and country. Belgian e-commerce was operational; Albert Heijn’s website/app were back, but home delivery was only expected from October 23, not confirmed by this source. US e-commerce recovery was still expected. The company then had no evidence of sensitive customer, associate or partner data being taken, while investigation continued.
What you can do Check the current notice from your local brand and the actual order/payment status before retrying. Do not treat a forecast recovery date or the absence of theft evidence as a guarantee. Verify unexpected messages through a known official channel.
Official sources: Ahold Delhaize · 12 October · Ahold Delhaize · 19 October
Weak intermediate keys; browser protection and customer transition
Affected service or information: Eight TLS intermediates · affected certificate chains, not every eMudhra service
- Mozilla received a report of eight compromised intermediate keys and blocked them via OneCRL. Standard Firefox configurations received that block by 22:59 UTC on October 17; this does not prove every browser or custom setup was protected.
- Mozilla’s October 21 addendum records Firefox for Android 158.0.2 for a startup blocklist problem, after its October 20 Firefox/ESR releases. In its October 21 statement, eMudhra said the eight weak intermediates had issued no end-entity certificates and the related ECC-root distrust affected one US customer ecosystem; its investigation remained open. These are company findings, not proof of worldwide customer-data theft.
- eMudhra offered Sectigo-issued certificates as an alternative, while saying G1 roots remained active. This is an alternative offer, not a statement that all TLS certificates or all eMudhra products are affected. In a separate October 22 announcement, its board decided to leave the global SSL/TLS business. It says G1 RSA roots will serve customers during the transition, partner replacements will be offered free, and revocation/status services will continue until issued certificates expire or are replaced. This is not an immediate shutdown of every eMudhra product.
- eMudhra’s October 26 update attributes the eight weak intermediate keys to a script error. It reports revocation within 14 hours and no infrastructure or customer-data compromise in its investigation to date. A CCADB root-cause report and independent expert review are planned, not completed.
- Google scheduled G3 root-store removal for October 27 morning PDT; completion is not confirmed here.
- In its October 28 update, eMudhra says roughly 30,800 certificates under the affected G3 hierarchies belong to one US client ecosystem, which is now using an alternate G1 RSA issuance path. It has requested time from browser/root programs for an orderly move to other providers; this is not approval or a completed migration. G1 TLS issuance will stop after that transition. The wider hierarchy count does not establish 30,800 fraudulent certificates or data-theft victims, and is distinct from the earlier claim about the eight weak intermediates. eSignature and enterprise products remain unaffected according to the company.
- Cisco’s October 29 Webex notice plans enforcement from November 2, possibly in stages, for affected Webex Meetings Edge Audio and CMR secure SIP integrations. This is not confirmation that enforcement has reached every connection. It lists emSign Root TLS CA – G3, emSign ECC Root CA – G3, emSign Root CS CA – G3 and AAA Certificate Services paths. AAA itself was not compromised; some Sectigo chains use an AAA-cross-signed path. G1 is excluded. Operators should inspect both primary and redundant CUBE, Expressway-E or SBC chains, coordinate a validated replacement with the issuer, and test Edge Audio dial-in/dial-out and CMR SIP joins. Where supported, retaining the identity certificate and replacing only the intermediate chain may suffice. Never remove the old chain before installing and validating its replacement, bypass TLS checks or disclose private keys. Other meeting access methods do not use the same customer SIP path.
- eMudhra announced KPMG as its independent external reviewer. This is an appointment to examine the incident, not publication of a completed review or confirmation that the investigation is closed.
What you can do Keep your browser and managed trust components on current supported releases. Never bypass certificate warnings. Affected site operators should check their certificate chain and coordinate replacement with their issuer; other eMudhra products are not automatically affected.
Official sources: eMudhra statement · Mozilla security update · TLS business transition · Google browser trust notice
Internal videos copied; investigation continues
Affected service or information: Internal video platform
- Videos were copied; users’ names/emails were accessed. Supercell says its investigation has found no player-data impact so far.
What you can do Verify unexpected requests through trusted channels. Use the official notice for affected-person contact details.
Official sources: Supercell notice
Phased Cloud Backup recovery requires tenant re-authorization
Affected service or information: Cloud Backup, formerly SkyKick; affected Microsoft 365 integrations
- Investigation announced after unauthorized access involving application credentials.
- At 14:00 UTC, ConnectWise said infrastructure recovery and certificate rotation were continuing. It targets Monday, October 26 for backup-restore access first, subject to testing and security validation; phased partner re-enrollment will follow. This is a target, not confirmed availability or permission to reconnect.
- At 14:00 UTC, ConnectWise reiterated the target of phased partner onboarding on Monday, October 26, subject to successful testing and security validation. Backup-restoration access comes first, then service re-enrollment. It says infrastructure restoration does not mean every partner capability is available; keep affected connections disabled until applicable instructions arrive. The next daily update is due by October 26 at 14:00 UTC.
- At 14:00 UTC on October 26, ConnectWise said restoration, testing and validation continued. It was still preparing phased onboarding and would announce when partners could begin restoring existing backups. Availability was not confirmed. Keep affected application connections disabled until service-specific instructions arrive; the next update is due by October 27 at 14:00 UTC.
- At 14:30 UTC, ConnectWise said preparations were complete but required third-party validation was still pending. Phased backup-restoration access will begin only after validation; availability has not been announced. Keep affected connections disabled until service-specific instructions arrive. Existing backup archives remain encrypted, isolated and preserved, with no indication of compromise. The next daily update is due by October 28 at 14:00 UTC.
- At this review after 14:00 UTC on October 28, the published notice still ended with the October 27 14:30 UTC update. Its promised October 28 checkpoint has passed; a new availability or validation result was not confirmed in the reviewed original. Continue to follow service-specific instructions rather than assuming access has reopened.
- At 16:00 UTC, ConnectWise announced phased restoration, starting with Microsoft 365 backups and restores through the new “ConnectWise Cloud Backup for M365” application. Partners must reset the portal password, complete MFA setup if needed, and re-authorize each tenant using the instructions for its authentication method. Other features return in later phases. Re-authorization alone does not confirm backups resumed: verify successful new snapshots once the service is enabled for the tenant. Continue the separate tenant investigation. Do not re-enable old applications without explicit service-specific instructions.
- At 20:45 UTC, ConnectWise reiterated phased Microsoft 365 restoration through the new application. Partners seeing a password-reset “Server error”/500 should return to the official Cloud Services portal and retry; if it persists after several attempts, contact Cloud Backup support. Reset the portal password, complete MFA if needed and re-authorize each tenant through ConnectWise Cloud Backup for M365. Do not re-enable old applications without explicit instructions. Re-authorization alone is insufficient: verify successful new backup snapshots and continue the separate tenant investigation.
- At 21:00 UTC on October 30, ConnectWise said phases 1 and 2 were complete: backups/restores for re-authorized Microsoft 365 tenants, the End-Customer Self-Service Portal and Backup Monitoring dashboards are available. Phase 3 is in progress; Backup Health reporting, export jobs and billing remain in restoration. Notifications follow in phase 4. Re-authorization is not proof that backups resumed: verify new successful snapshots and retain the interruption gap. Keep old applications disabled unless explicitly instructed otherwise. Investigation and enhanced monitoring continue; preserved archives are not the same as recovered copied information.
What you can do Have the authorized tenant administrator use the current Trust Center instructions and new application, verify new snapshots, and retain the interruption gap in backup history. Keep previously disabled applications off unless explicitly instructed otherwise. This is separate from the Axcient PHP-related portal interruption.
Official sources: ConnectWise Trust Center
Intrusion contained; internal-data review continues
Affected service or information: Internal learning and customer-relationship systems
- Genesys became aware of unauthorized access.
- It confirmed access or downloads involving business contacts and account information. It said its Cloud/Engage platforms and their customer recordings were unaffected; investigation continues.
- Genesys says it fully contained the intrusion and completed immediate remediation. It suspended use of the affected learning management system and continues reviewing accessed internal information. Cloud/Engage platforms and their customer data remain unaffected according to the company; containment does not establish recovery of copied data.
What you can doVerify unexpected Genesys-themed requests through a known contact. Ask your account team whether your business information was affected; do not send passwords in response to unsolicited messages.
Official sources: Genesys security update
Patient notifications follow the completed data review
Affected service or information: Patient contact details, account/device identifiers, insurance number, service date and birth date
- Unauthorized access was detected around this date; the investigation identified data downloads between June 3 and June 8.
- Notifications began after the forensic and data review. The company reported no identified impact to its medical-device systems or patient safety.
What you can doUse the dedicated response channel in the official notice to check your notification. Review unfamiliar medical or insurance activity with the relevant provider; available fraud-protection procedures depend on your country.
Official sources: iRhythm individual notice · iRhythm investigation update
Canvas review completed; institutions receive affected data
Affected service or information: Usernames, email, course/enrollment information and messages; fields vary
- After detecting the initial intrusion on April 29, Instructure detected a second attack on May 7 and temporarily took Canvas offline. It says no additional data was accessed or extracted in that second attack.
- Forensic data review was completed. Remaining affected institutions will receive information through designated security contacts; later updates go directly to them.
What you can doStudents and families should use their institution's official notification channel. Administrators should verify the designated contact and delivered data before deciding who needs notice; do not contact the attacker.
Official sources: Instructure incident updates and FAQ
Earlier incidents: what happened afterwards
Later notice confirms stolen customer data was released
Affected service or information: Contact/profile information; Qantas says passwords, card details and identity documents were not accessed
- Unusual activity was detected on a third-party contact-centre platform.
- Qantas confirmed a data release and continued investigating its contents. Earlier assurances that no release had been found must not replace this later notice.
What you can doRead your individual notification using the official site. Verify callers independently and use the incident-support channel listed there; accurate personal details do not prove a message is genuine.
Official sources: Qantas customer notice and previous updates
Customer-data theft and service recovery are different outcomes
Affected service or information: Contacts, birth dates, order history and masked card details; not usable payment details or passwords
- M&S notified customers that personal data had been taken after the April incident.
- It reported summer recovery of customer-facing systems and recovery of practically all operational systems. The 2026 results describe the subsequent business recovery, not retrieval of leaked information.
What you can doOpen the official app or website to follow account prompts and contact support. Be cautious of impersonation; restoring online shopping does not make previously copied personal information private again.
Official sources: M&S customer FAQ · M&S: 13 May 2025 announcement · M&S recovery report · M&S 2026 results
Production recovered after a later data-impact finding
Affected service or information: Retail, production and affected data; individual exposure is determined by notification
- JLR said some data was affected and it was informing regulators. The statement did not specify all affected data categories or individuals; the forensic investigation was continuing.
- It reported production back at normal levels after the phased restart. Operational recovery does not establish that every data investigation or notification is complete.
What you can doUse JLR or your retailer's official contact for your order or individual notice. Verify unexpected payment or bank-account-change requests independently before acting.
Official sources: JLR data-impact update · JLR production-recovery report · JLR 2026 annual report
School notices and later extortion concern the same stolen data
Affected service or information: Students, former students and staff; data categories differ by school board
- School boards were notified of the December 2024 SIS breach. Some district notices include identity, contact and medical information.
- Further notices described extortion directed at some customers using the earlier stolen data, not proof of a newly separate breach.
What you can doCheck your own school board's notice for affected years and fields. Ask the official school contact about current support; do not assume a 2025 protection-enrollment deadline is still open.
Official sources: TDSB: incident and notifications · Northwest Territories: later extortion notice
Regulator found failures protecting genetic and family information
Affected service or information: 155,592 UK residents in the ICO finding; not a worldwide victim total
- Credential-stuffing activity began and continued into September, using credentials from unrelated breaches.
- The ICO announced a £2.31 million penalty. Exposed information varied, including family, ancestry and health-related details. A regulatory fine is not a customer compensation award.
What you can doReview your notification and account-sharing settings. Secure any reused credentials elsewhere; changing a password cannot change genetic or family information that has already been exposed.
Official sources: ICO: 23andMe findings
Copied backups and later regulatory findings require different checks
Affected service or information: 2022 incident; encrypted vault data and other customer information
- LastPass explained how two linked 2022 incidents led to access to cloud backups containing encrypted and unencrypted customer data.
- The ICO announced a £1.2 million penalty over the 2022 breach, which affected up to 1.6 million UK users. It found no evidence that the attacker decrypted encrypted passwords; this is not proof that copied data was recovered.
What you can doUse LastPass's current account-specific guidance to assess passwords, saved secrets and integrations. Do not assume changing only the master password retroactively protects an already copied backup.
Official sources: LastPass: investigation and recommended actions · LastPass: December 2022 notice · ICO: LastPass findings
The cited ICO notice could not be reconfirmed during this recheck. Its findings retain their original dates; follow current account-specific LastPass guidance for urgent decisions.
What affected users can do now
Match the service, account, date range and data fields in the official individual notice. A company’s worldwide incident does not establish that every account or every field was affected.
If credentials or sessions may be affected, follow the provider’s current instructions from a trusted device. Replace reused passwords on other services, enable multi-factor authentication and review recovery methods and connected apps.
Save your official notice and case reference securely. Contact the relevant bank, insurer, school or provider through a known channel. Check current eligibility and deadlines before enrolling in any protection service.
For advice about your rights or a complaint, contact the relevant consumer or data-protection authority in your country. A UK regulatory decision does not automatically set the rules, compensation or eligibility elsewhere. Never search for your details in leaked datasets or send them to an unverified “breach checker.”
Service recovery does not erase a data breach
A service may restart while the investigation, affected-person notifications or regulatory process continues. A statement that no ongoing access has been found does not prove that previously copied data was deleted. An attacker’s claim or a payment is not independent verification that all copies were recovered.
We distinguish the incident date, the company’s announcement and later findings above. A case is not marked resolved merely because it disappears from a status feed. For ordinary availability, check the status monitor; for errors after an update, use app and operating-system update issues.