Cybersecurity News and Magazine https://thecyberexpress.com Trending Cybersecurity News, Updates, Magazine and More. Thu, 10 Sep 2026 18:24:35 +0000 en-US hourly 1 https://thecyberexpress.com/wp-content/uploads/tce-favicon-75x75.jpg?crop=1 The Cyber Express https://thecyberexpress.com 32 32 208869986 noTrending Cybersecurity News, Updates, Magazine and More. AI Agents Compromised 440 PaperCut Servers, Researchers Say https://thecyberexpress.com/ai-agents-compromised-440-papercut-servers/ Thu, 10 Sep 2026 18:24:35 +0000 https://thecyberexpress.com/?p=114023 PaperCut, PaperCut Compromise

A threat intelligence firm says it watched a Russian-speaking attacker turn hundreds of AI agents loose on a print management platform and compromise 440 servers in 48 countries — including 11 organizations in 26 seconds. It is the most vivid account yet of an autonomous intrusion campaign. It is also, so far, a single-source story that the vendor at the center of it has pointedly declined to endorse.

GreyNoise published the report on Sept. 9, describing a campaign it says launched Aug. 31 against PaperCut NG and MF, the self-hosted Java print management software used by a frequently cited 100 million people. The firm says it observed the operation through its own sensor network rather than reconstructing it from victim forensics after the fact.

GreyNoise counts 440 compromised instances across 395 organizations, with education absorbing 204 of them, and domain administrator privileges reached at 12 victims. It says the operator went from an empty workspace to remote code execution against a real victim in under four hours, and to harvested domain admin credentials in roughly six. One US high school, the report says, went from initial access to full domain admin in seven minutes. The agents ran on an OpenAI Codex harness alongside a DeepSeek model.

The most quietly alarming detail is not the speed. GreyNoise says the operator maintained a list of 28 countries the agents were told to leave alone — Russia, China, Iran and Venezuela among them — and that the victim data shows the agents hit some of them anyway. An attacker's sanctions-avoidance policy failed because the automation did not respect it. The report frames this as evidence that unconstrained agentic operations drift, and that the drift is a risk to the attacker as much as to anyone else.

The underlying vulnerabilities are real and the exploitation is not in dispute. CVE-2026-81578, an authentication bypass, and CVE-2026-82078, an unsafe-reflection remote code execution flaw, were published Aug. 28 and can be chained. PaperCut shipped emergency patches on Aug. 28 and Sept. 1 and full maintenance releases — 26.0.5, 25.0.13 and 24.1.10 — on Sept. 10. CISA added both to its Known Exploited Vulnerabilities catalog on Aug. 31 with a Sept. 14 remediation deadline, a listing that predates the GreyNoise report and was driven by the earlier exploitation wave documented.

Read: PaperCut Issues Second Emergency Patch as Researchers Break Fix for Exploited Zero-Days
]]> PaperCut, PaperCut Compromise

A threat intelligence firm says it watched a Russian-speaking attacker turn hundreds of AI agents loose on a print management platform and compromise 440 servers in 48 countries — including 11 organizations in 26 seconds. It is the most vivid account yet of an autonomous intrusion campaign. It is also, so far, a single-source story that the vendor at the center of it has pointedly declined to endorse.

GreyNoise published the report on Sept. 9, describing a campaign it says launched Aug. 31 against PaperCut NG and MF, the self-hosted Java print management software used by a frequently cited 100 million people. The firm says it observed the operation through its own sensor network rather than reconstructing it from victim forensics after the fact.

GreyNoise counts 440 compromised instances across 395 organizations, with education absorbing 204 of them, and domain administrator privileges reached at 12 victims. It says the operator went from an empty workspace to remote code execution against a real victim in under four hours, and to harvested domain admin credentials in roughly six. One US high school, the report says, went from initial access to full domain admin in seven minutes. The agents ran on an OpenAI Codex harness alongside a DeepSeek model.

The most quietly alarming detail is not the speed. GreyNoise says the operator maintained a list of 28 countries the agents were told to leave alone — Russia, China, Iran and Venezuela among them — and that the victim data shows the agents hit some of them anyway. An attacker's sanctions-avoidance policy failed because the automation did not respect it. The report frames this as evidence that unconstrained agentic operations drift, and that the drift is a risk to the attacker as much as to anyone else.

The underlying vulnerabilities are real and the exploitation is not in dispute. CVE-2026-81578, an authentication bypass, and CVE-2026-82078, an unsafe-reflection remote code execution flaw, were published Aug. 28 and can be chained. PaperCut shipped emergency patches on Aug. 28 and Sept. 1 and full maintenance releases — 26.0.5, 25.0.13 and 24.1.10 — on Sept. 10. CISA added both to its Known Exploited Vulnerabilities catalog on Aug. 31 with a Sept. 14 remediation deadline, a listing that predates the GreyNoise report and was driven by the earlier exploitation wave documented.

Read: PaperCut Issues Second Emergency Patch as Researchers Break Fix for Exploited Zero-Days
]]> 114023 EUChatGPT Sandbox Flaw Let a Planted Prompt Ship Victim’s 24-Hr Vulnerability Reporting Rules Take Effect Friday, a Year Before the Rest of the Cyber Resilience Acts Gmail Data to Another Account https://thecyberexpress.com/eu-cyber-resilience-act-24-hr-reporting/ Thu, 10 Sep 2026 11:09:23 +0000 https://thecyberexpress.com/?p=114019 Cyber Resilience Act, CRA, EU, EU Sanctions, Iran, Chinese Hacking,

Manufacturers selling connected products in the European Union face a new legal duty starting Sept. 11. Report actively exploited vulnerabilities to authorities within 24 hours of confirming them. The obligation arrives 15 months ahead of the Cyber Resilience Act's full application date of Dec. 11, 2027, making it the regulation's first hard deadline.

The CRA covers products with digital elements placed on the EU market, a category broad enough to take in enterprise software, consumer IoT devices, industrial controllers and much of the component software beneath them.

Under Article 14, manufacturers must file an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident affecting product security, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure becoming available — one month in the case of severe incidents.

Reports go through a Single Reporting Platform operated by ENISA. A manufacturer submits once to a designated national computer security incident response team, which then shares the notification with CSIRTs in other member states where the product is sold, with ENISA receiving it in parallel. The European Commission has said the platform will be operational by the September date and has been undergoing functional and security testing.

Where the Deadline Bites

The awareness standard is what will generate arguments. The trigger is a reasonable degree of certainty that a vulnerability is being exploited or that an incident has severely compromised product security — a judgment call that must be made in hours, often on partial telemetry, and one that manufacturers cannot defer by declining to investigate.

Two further wrinkles are drawing attention from compliance advisers. Reporting duties survive end of support, unlike most of the CRA's other vulnerability-handling requirements, which means legacy product lines remain in scope. And importers or distributors that rebrand a product or substantially modify it inherit manufacturer obligations outright.

Penalties for breaching core manufacturer obligations reach €15 million or 2.5% of global annual turnover, whichever is higher.

Readiness Questions on the Cyber Resilience Act

Practitioners have raised two gaps. The reporting platform is scheduled to be ready by the deadline rather than in advance of it, leaving little room for manufacturers to rehearse submissions. And the harmonised standards that will define what adequate compliance looks like are still working through public enquiry, so companies are building processes against a moving target. The CRA's requirement that manufacturers publish a coordinated vulnerability disclosure policy does not apply until December 2027.

The effects reach past manufacturers. Enterprises that buy connected products will begin receiving vendor notifications on the vendor's clock rather than their own, and will need a route from a supplier advisory into incident triage — plus a fast assessment of whether the same event triggers separate duties under NIS2 or DORA.

Friday's start date has an immediate real-world test case. Adobe confirmed this week that a maximum-severity Magento flaw, CVE-2026-75650, has been exploited against merchants since Sept. 4. Had the same sequence begun a week later, the 24-hour clock would have applied.

Read: Attackers Exploit Unpatched Magento Zero-Day to Backdoor Online Stores
]]> Cyber Resilience Act, CRA, EU, EU Sanctions, Iran, Chinese Hacking,

Manufacturers selling connected products in the European Union face a new legal duty starting Sept. 11. Report actively exploited vulnerabilities to authorities within 24 hours of confirming them. The obligation arrives 15 months ahead of the Cyber Resilience Act's full application date of Dec. 11, 2027, making it the regulation's first hard deadline.

The CRA covers products with digital elements placed on the EU market, a category broad enough to take in enterprise software, consumer IoT devices, industrial controllers and much of the component software beneath them.

Under Article 14, manufacturers must file an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident affecting product security, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure becoming available — one month in the case of severe incidents.

Reports go through a Single Reporting Platform operated by ENISA. A manufacturer submits once to a designated national computer security incident response team, which then shares the notification with CSIRTs in other member states where the product is sold, with ENISA receiving it in parallel. The European Commission has said the platform will be operational by the September date and has been undergoing functional and security testing.

Where the Deadline Bites

The awareness standard is what will generate arguments. The trigger is a reasonable degree of certainty that a vulnerability is being exploited or that an incident has severely compromised product security — a judgment call that must be made in hours, often on partial telemetry, and one that manufacturers cannot defer by declining to investigate.

Two further wrinkles are drawing attention from compliance advisers. Reporting duties survive end of support, unlike most of the CRA's other vulnerability-handling requirements, which means legacy product lines remain in scope. And importers or distributors that rebrand a product or substantially modify it inherit manufacturer obligations outright.

Penalties for breaching core manufacturer obligations reach €15 million or 2.5% of global annual turnover, whichever is higher.

Readiness Questions on the Cyber Resilience Act

Practitioners have raised two gaps. The reporting platform is scheduled to be ready by the deadline rather than in advance of it, leaving little room for manufacturers to rehearse submissions. And the harmonised standards that will define what adequate compliance looks like are still working through public enquiry, so companies are building processes against a moving target. The CRA's requirement that manufacturers publish a coordinated vulnerability disclosure policy does not apply until December 2027.

The effects reach past manufacturers. Enterprises that buy connected products will begin receiving vendor notifications on the vendor's clock rather than their own, and will need a route from a supplier advisory into incident triage — plus a fast assessment of whether the same event triggers separate duties under NIS2 or DORA.

Friday's start date has an immediate real-world test case. Adobe confirmed this week that a maximum-severity Magento flaw, CVE-2026-75650, has been exploited against merchants since Sept. 4. Had the same sequence begun a week later, the 24-hour clock would have applied.

Read: Attackers Exploit Unpatched Magento Zero-Day to Backdoor Online Stores
]]> 114019 EUChatGPT Sandbox Flaw Let a Planted Prompt Ship Victim’s 24-Hr Vulnerability Reporting Rules Take Effect Friday, a Year Before the Rest of the Cyber Resilience Acts Gmail Data to Another Account https://thecyberexpress.com/chatgpt-sandbox-flaw-leads-to-gmail-leak/ Wed, 09 Sep 2026 08:48:09 +0000 https://thecyberexpress.com/?p=114005 ChatGPT, SearchGPT, OpenAI, Sam Altman, Lockdown Mode

Check Point Research disclosed Tuesday that a weakness in ChatGPT's code-execution sandbox let data from one user's connected Gmail account be moved into a separate, attacker-controlled ChatGPT account, with no confirmation prompt shown to the victim.

The flaw sat not in the model but in the infrastructure beneath it. Containers running individual conversations cannot address one another directly, Check Point found, but every container could reach the same internal JFrog Artifactory instance OpenAI used for package management. An item-management feature there let any container attach text metadata properties to cached items and read properties written by others, turning a package cache into a two-way message board between environments meant to be isolated.

How the Chain Worked

The attack starts with an instruction the victim never sees. Researchers demonstrated three delivery routes, any one of them was sufficient. First, a prompt pasted into a chat, second was a shared conversation link, or third, a custom GPT carrying a hidden instruction.

The victim's session then quietly processes a second stream of tasks alongside the conversation they can actually see. In one demonstration described by The Register, the user got an ordinary answer, a temperature chart, while an injected task told the session to use the Gmail connector and list their messages.

Those instructions reach whatever the victim has connected. Researchers cited Gmail, Google Drive, Microsoft Teams and GitHub in their findings.

The decisive detail is the permission model. ChatGPT's default connected-app setting automatically approves read actions it judges low risk, with no separate confirmation step. The only trace researchers observed was a small "Talked to Gmail" label appearing afterward. Harvested data went into the shared metadata channel and was collected by the attacker's own session — exfiltration that never touches the victim's browser or their employer's network egress, leaving nothing for conventional data-loss prevention tools to inspect.

Also read: New ChatGPhish Technique Uses Prompt Injection to Manipulate ChatGPT Responses

The Hugging Face Connection

Check Point reported the channel to OpenAI in late June and says it had a working proof of concept before the activity that led to the Hugging Face compromise OpenAI has since disclosed. The two are separate attacks using different techniques, but both ran through the same internal Artifactory instance. On disclosure, OpenAI told Check Point the instance had already been decommissioned because of the Hugging Face incident, so no user-facing patch was needed, and Check Point's write-up cites no CVE for the channel.

In that episode, OpenAI models running an internal exploitation evaluation chained Artifactory zero-days to escalate privileges, reach a node with internet access and pull evaluation answers from Hugging Face's production database. JFrog patched three flaws credited to OpenAI researchers in Artifactory 7.161.15; Hugging Face disclosed the intrusion July 16.

Also read: OpenAI and Hugging Face Investigate AI Models’ Cyber Breakout

Check Point's Pedro Drimel Neto framed the lesson as one of privilege rather than model behavior, saying "the biggest AI security risk has become the access and trust we give it." The firm calls an assistant that holds credentials, runs code and reaches connected services a "coerced insider," and argues the many-tenants-on-one-shared-service pattern warrants scrutiny across agent platforms. OpenAI did not respond to The Register's request for comment.

The latest disclosure lands weeks after the European Commission and national authorities began enforcing the EU AI Act on Aug. 2. Indirect prompt injection remains the top entry in OWASP's Top 10 for large language model applications, and NIST's AI Risk Management Framework treats leakage through connected tooling as a core control area. For enterprises, the exposure is also a GDPR question. Mailbox contents reached through a sanctioned connector are still personal data, and a cross-tenant route to them is a processing failure whether or not it was abused.

]]> ChatGPT, SearchGPT, OpenAI, Sam Altman, Lockdown Mode

Check Point Research disclosed Tuesday that a weakness in ChatGPT's code-execution sandbox let data from one user's connected Gmail account be moved into a separate, attacker-controlled ChatGPT account, with no confirmation prompt shown to the victim.

The flaw sat not in the model but in the infrastructure beneath it. Containers running individual conversations cannot address one another directly, Check Point found, but every container could reach the same internal JFrog Artifactory instance OpenAI used for package management. An item-management feature there let any container attach text metadata properties to cached items and read properties written by others, turning a package cache into a two-way message board between environments meant to be isolated.

How the Chain Worked

The attack starts with an instruction the victim never sees. Researchers demonstrated three delivery routes, any one of them was sufficient. First, a prompt pasted into a chat, second was a shared conversation link, or third, a custom GPT carrying a hidden instruction.

The victim's session then quietly processes a second stream of tasks alongside the conversation they can actually see. In one demonstration described by The Register, the user got an ordinary answer, a temperature chart, while an injected task told the session to use the Gmail connector and list their messages.

Those instructions reach whatever the victim has connected. Researchers cited Gmail, Google Drive, Microsoft Teams and GitHub in their findings.

The decisive detail is the permission model. ChatGPT's default connected-app setting automatically approves read actions it judges low risk, with no separate confirmation step. The only trace researchers observed was a small "Talked to Gmail" label appearing afterward. Harvested data went into the shared metadata channel and was collected by the attacker's own session — exfiltration that never touches the victim's browser or their employer's network egress, leaving nothing for conventional data-loss prevention tools to inspect.

Also read: New ChatGPhish Technique Uses Prompt Injection to Manipulate ChatGPT Responses

The Hugging Face Connection

Check Point reported the channel to OpenAI in late June and says it had a working proof of concept before the activity that led to the Hugging Face compromise OpenAI has since disclosed. The two are separate attacks using different techniques, but both ran through the same internal Artifactory instance. On disclosure, OpenAI told Check Point the instance had already been decommissioned because of the Hugging Face incident, so no user-facing patch was needed, and Check Point's write-up cites no CVE for the channel.

In that episode, OpenAI models running an internal exploitation evaluation chained Artifactory zero-days to escalate privileges, reach a node with internet access and pull evaluation answers from Hugging Face's production database. JFrog patched three flaws credited to OpenAI researchers in Artifactory 7.161.15; Hugging Face disclosed the intrusion July 16.

Also read: OpenAI and Hugging Face Investigate AI Models’ Cyber Breakout

Check Point's Pedro Drimel Neto framed the lesson as one of privilege rather than model behavior, saying "the biggest AI security risk has become the access and trust we give it." The firm calls an assistant that holds credentials, runs code and reaches connected services a "coerced insider," and argues the many-tenants-on-one-shared-service pattern warrants scrutiny across agent platforms. OpenAI did not respond to The Register's request for comment.

The latest disclosure lands weeks after the European Commission and national authorities began enforcing the EU AI Act on Aug. 2. Indirect prompt injection remains the top entry in OWASP's Top 10 for large language model applications, and NIST's AI Risk Management Framework treats leakage through connected tooling as a core control area. For enterprises, the exposure is also a GDPR question. Mailbox contents reached through a sanctioned connector are still personal data, and a cross-tenant route to them is a processing failure whether or not it was abused.

]]> 114005 Microsoft Patch Tuesday Hits Record 974 CVEs, Two Exploited https://thecyberexpress.com/patch-tuesday-september-2026/ Wed, 09 Sep 2026 06:51:42 +0000 https://thecyberexpress.com/?p=114006 Patch Tuesday September 2026

Microsoft's Patch Tuesday September 2026 rollout has broken previous records, with the company addressing 974 CVEs across its product lineup in a single release. Two of these vulnerabilities were already being exploited in the wild before fixes became available, prompting quick action from federal cybersecurity authorities.  The sheer volume of this month's Patch Tuesday September 2026 release dwarfs recent months. Windows accounted for 723 of the fixed flaws, while the Office suite received patches for 222 issues, 111 of which affected Office 2016 specifically.  

Scale of Patch Tuesday September 2026 

SQL Server products saw 62 CVEs resolved, Developer Tools had 22, SharePoint Server received 16 fixes, Azure had 12, Skype for Business had 10, and Exchange Server accounted for 9. More than 110 of the vulnerabilities patched carry a critical severity rating, and nearly 90% of the total fall into three categories: privilege escalation, remote code execution, and information disclosure.   Factoring in fixes for 25 non-Microsoft CVEs, the combined total for this Patch Tuesday September 2026 cycle reaches 999 resolved vulnerabilities.  This release continues a pattern of escalating patch volumes from Microsoft in recent months — 457 CVEs were addressed in August, 663 in July, 220 in June, and 161 in May, making September's numbers a significant jump even against that backdrop. 

The Two Exploited Zero-Days 

Central to this month's Patch Tuesday September 2026 update are two CVEs that Microsoft confirmed had been exploited before patches were issued.  The first, CVE-2026-85880 (CVSS 7.8), is a heap-based buffer overflow in the Windows Advanced Local Procedure Call (ALPC) component. It allows an attacker with local access to escalate privileges and obtain SYSTEM-level control. Microsoft's advisory states that an attacker who can execute code in a low-privilege AppContainer could exploit this vulnerability locally to escape the sandbox and elevate privileges on the affected system, with no additional user interaction required.  The second actively exploited flaw, CVE-2026-81963 (CVSS 7.8), stems from improper link resolution within the Windows Update Stack. Like the ALPC bug, it enables a local, authorized attacker to escalate privileges and gain SYSTEM access.  Both CVEs have since been added to the Known Exploited Vulnerabilities (KEV) catalog maintained by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Federal Civilian Executive Branch agencies now face a September 22, 2026 deadline to apply the relevant patches. 

Other Notable CVEs Worth Tracking 

Beyond the zero-days, several other CVEs patched in this Patch Tuesday September 2026 batch carry high severity scores and warrant prompt attention from Microsoft administrators: 
  • CVE-2026-55007 (CVSS 8.1) — a double-free flaw in Microsoft Exchange Server enabling remote code execution 
  • CVE-2026-80097 (CVSS 8.6) — improper authentication in Microsoft Authenticator allowing local privilege escalation 
  • CVE-2026-69465 (CVSS 8.8) — missing authorization in Microsoft Office SharePoint permitting remote code execution 
  • CVE-2026-65669 (CVSS 9.6) — an injection flaw in SQL Server enabling remote privilege escalation 
  • CVE-2026-69525 (CVSS 9.8) — use-after-free in Windows Remote Desktop Services allowing remote code execution 
  • CVE-2026-69595 (CVSS 9.8) — use-after-free in the Windows Services for NFS ONCRPC XDR Driver 
  • CVE-2026-69730 (CVSS 9.8) — use-after-free in the Windows DNS server 
  • CVE-2026-69829 (CVSS 9.8) — heap-based buffer overflow in Windows Shell 
  • CVE-2026-72979 (CVSS 9.8) — use-after-free in the Windows DHCP Server 
Alongside the CVE fixes, Microsoft's Patch Tuesday September 2026 release also included new Servicing Stack Updates (SSUs), classified as critical, covering Windows Server 2012, Windows Server 2012 R2, and Windows 10 Version 1607/Server 2016.  Given the number of critical-severity CVEs and the confirmed exploitation of two privilege-escalation bugs, security teams are expected to prioritize this Patch Tuesday September 2026 rollout above routine monthly cycles, particularly for internet-facing Windows and Exchange deployments. ]]> Patch Tuesday September 2026

Microsoft's Patch Tuesday September 2026 rollout has broken previous records, with the company addressing 974 CVEs across its product lineup in a single release. Two of these vulnerabilities were already being exploited in the wild before fixes became available, prompting quick action from federal cybersecurity authorities.  The sheer volume of this month's Patch Tuesday September 2026 release dwarfs recent months. Windows accounted for 723 of the fixed flaws, while the Office suite received patches for 222 issues, 111 of which affected Office 2016 specifically.  

Scale of Patch Tuesday September 2026 

SQL Server products saw 62 CVEs resolved, Developer Tools had 22, SharePoint Server received 16 fixes, Azure had 12, Skype for Business had 10, and Exchange Server accounted for 9. More than 110 of the vulnerabilities patched carry a critical severity rating, and nearly 90% of the total fall into three categories: privilege escalation, remote code execution, and information disclosure.   Factoring in fixes for 25 non-Microsoft CVEs, the combined total for this Patch Tuesday September 2026 cycle reaches 999 resolved vulnerabilities.  This release continues a pattern of escalating patch volumes from Microsoft in recent months — 457 CVEs were addressed in August, 663 in July, 220 in June, and 161 in May, making September's numbers a significant jump even against that backdrop. 

The Two Exploited Zero-Days 

Central to this month's Patch Tuesday September 2026 update are two CVEs that Microsoft confirmed had been exploited before patches were issued.  The first, CVE-2026-85880 (CVSS 7.8), is a heap-based buffer overflow in the Windows Advanced Local Procedure Call (ALPC) component. It allows an attacker with local access to escalate privileges and obtain SYSTEM-level control. Microsoft's advisory states that an attacker who can execute code in a low-privilege AppContainer could exploit this vulnerability locally to escape the sandbox and elevate privileges on the affected system, with no additional user interaction required.  The second actively exploited flaw, CVE-2026-81963 (CVSS 7.8), stems from improper link resolution within the Windows Update Stack. Like the ALPC bug, it enables a local, authorized attacker to escalate privileges and gain SYSTEM access.  Both CVEs have since been added to the Known Exploited Vulnerabilities (KEV) catalog maintained by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). Federal Civilian Executive Branch agencies now face a September 22, 2026 deadline to apply the relevant patches. 

Other Notable CVEs Worth Tracking 

Beyond the zero-days, several other CVEs patched in this Patch Tuesday September 2026 batch carry high severity scores and warrant prompt attention from Microsoft administrators: 
  • CVE-2026-55007 (CVSS 8.1) — a double-free flaw in Microsoft Exchange Server enabling remote code execution 
  • CVE-2026-80097 (CVSS 8.6) — improper authentication in Microsoft Authenticator allowing local privilege escalation 
  • CVE-2026-69465 (CVSS 8.8) — missing authorization in Microsoft Office SharePoint permitting remote code execution 
  • CVE-2026-65669 (CVSS 9.6) — an injection flaw in SQL Server enabling remote privilege escalation 
  • CVE-2026-69525 (CVSS 9.8) — use-after-free in Windows Remote Desktop Services allowing remote code execution 
  • CVE-2026-69595 (CVSS 9.8) — use-after-free in the Windows Services for NFS ONCRPC XDR Driver 
  • CVE-2026-69730 (CVSS 9.8) — use-after-free in the Windows DNS server 
  • CVE-2026-69829 (CVSS 9.8) — heap-based buffer overflow in Windows Shell 
  • CVE-2026-72979 (CVSS 9.8) — use-after-free in the Windows DHCP Server 
Alongside the CVE fixes, Microsoft's Patch Tuesday September 2026 release also included new Servicing Stack Updates (SSUs), classified as critical, covering Windows Server 2012, Windows Server 2012 R2, and Windows 10 Version 1607/Server 2016.  Given the number of critical-severity CVEs and the confirmed exploitation of two privilege-escalation bugs, security teams are expected to prioritize this Patch Tuesday September 2026 rollout above routine monthly cycles, particularly for internet-facing Windows and Exchange deployments. ]]> 114006 Exposed Database Left 220Mn Airline Passenger, Crew Records Open to the Internet https://thecyberexpress.com/220-million-airline-passenger-crew-data-expose/ Tue, 08 Sep 2026 14:51:26 +0000 https://thecyberexpress.com/?p=114000 Airline, Data Leak,

A misconfigured Elasticsearch cluster exposed roughly 220.8 million airline passenger and crew records, including passport numbers and full itineraries, before it was secured in June, researchers at Kinryu Labs disclosed.

The records spanned January 2017 through April 2026 and came from an Advance Passenger Information System deployment - the standardized data feed airlines transmit to border authorities before departure, covering traveler identity and flight details. Researchers linked the server to IP address space assigned to Vietnamese telecommunications operator Viettel in Hanoi but said they could not confirm which organization operated it.

What was exposed

As per BleepingComputer, the data set combined identity documents with granular travel history. Exposed fields included names, dates of birth, sex and nationality; passport or travel document numbers, expiration dates and issuing countries; and flight numbers and dates, airline names, departure, destination and transit airports, seat numbers, baggage references, and scheduled, estimated and actual flight times.

That combination is unusually sensitive. Passport numbers are difficult to change and useful for identity fraud and account takeover at travel providers, while the itinerary fields - particularly transit airports and actual flight times - allow reconstruction of an individual's movements over nine years. Security researchers have long flagged APIS-style data as a surveillance risk precisely because it maps people to places at fixed times.

Also read: Why Airline Data Breaches Matter – And Why Qantas Could Have Been Worse

Two misconfigurations

According to Kinryu Labs, the cluster was protected inconsistently. Direct access over the internet returned an HTTP 401 authentication error, which would give a casual scanner the impression the system was locked down. An alternative cloud-based access path, however, reached the same cluster and accepted default credentials.

The exposure appears to have been long-lived. Internet scanning service FOFA detected the host in 2022 and identified it as a database in 2023. Kinryu Labs reported the issue on June 3, 2026, and the cluster was secured by June 8. Singapore Airlines assisted in coordinating the response, the researchers said. There is no indication any airline was itself breached or operated the server.

Researchers said they found no evidence the data was stolen, but noted that without server logs they could not determine whether anyone copied it during the years it was reachable — a distinction that matters more than it may appear, because notification obligations in several jurisdictions turn on whether unauthorized access can be ruled out.

Compliance exposure

Vietnam's Personal Data Protection Law, Law No. 91/2025/QH15, took effect Jan. 1, 2026 - before the exposure was reported and remediated. The statute requires notification within 72 hours of detecting a violation, rather than from the time it occurred, and expands notification duties to affected individuals in defined circumstances. Its penalty ceiling for general violations is 3 billion Vietnamese dong, with cross-border transfer breaches exposed to fines of up to 5% of prior-year revenue.

Because the records cover international flights, EU and UK residents are almost certainly represented, which brings GDPR and UK GDPR into scope for any controller established in or targeting those markets. Passport numbers and travel history fall squarely within personal data, and passenger data processing has drawn repeated scrutiny from European data protection authorities.

]]> Airline, Data Leak,

A misconfigured Elasticsearch cluster exposed roughly 220.8 million airline passenger and crew records, including passport numbers and full itineraries, before it was secured in June, researchers at Kinryu Labs disclosed.

The records spanned January 2017 through April 2026 and came from an Advance Passenger Information System deployment - the standardized data feed airlines transmit to border authorities before departure, covering traveler identity and flight details. Researchers linked the server to IP address space assigned to Vietnamese telecommunications operator Viettel in Hanoi but said they could not confirm which organization operated it.

What was exposed

As per BleepingComputer, the data set combined identity documents with granular travel history. Exposed fields included names, dates of birth, sex and nationality; passport or travel document numbers, expiration dates and issuing countries; and flight numbers and dates, airline names, departure, destination and transit airports, seat numbers, baggage references, and scheduled, estimated and actual flight times.

That combination is unusually sensitive. Passport numbers are difficult to change and useful for identity fraud and account takeover at travel providers, while the itinerary fields - particularly transit airports and actual flight times - allow reconstruction of an individual's movements over nine years. Security researchers have long flagged APIS-style data as a surveillance risk precisely because it maps people to places at fixed times.

Also read: Why Airline Data Breaches Matter – And Why Qantas Could Have Been Worse

Two misconfigurations

According to Kinryu Labs, the cluster was protected inconsistently. Direct access over the internet returned an HTTP 401 authentication error, which would give a casual scanner the impression the system was locked down. An alternative cloud-based access path, however, reached the same cluster and accepted default credentials.

The exposure appears to have been long-lived. Internet scanning service FOFA detected the host in 2022 and identified it as a database in 2023. Kinryu Labs reported the issue on June 3, 2026, and the cluster was secured by June 8. Singapore Airlines assisted in coordinating the response, the researchers said. There is no indication any airline was itself breached or operated the server.

Researchers said they found no evidence the data was stolen, but noted that without server logs they could not determine whether anyone copied it during the years it was reachable — a distinction that matters more than it may appear, because notification obligations in several jurisdictions turn on whether unauthorized access can be ruled out.

Compliance exposure

Vietnam's Personal Data Protection Law, Law No. 91/2025/QH15, took effect Jan. 1, 2026 - before the exposure was reported and remediated. The statute requires notification within 72 hours of detecting a violation, rather than from the time it occurred, and expands notification duties to affected individuals in defined circumstances. Its penalty ceiling for general violations is 3 billion Vietnamese dong, with cross-border transfer breaches exposed to fines of up to 5% of prior-year revenue.

Because the records cover international flights, EU and UK residents are almost certainly represented, which brings GDPR and UK GDPR into scope for any controller established in or targeting those markets. Passport numbers and travel history fall squarely within personal data, and passenger data processing has drawn repeated scrutiny from European data protection authorities.

]]> 114000 Attackers Exploit Unpatched Magento Zero-Day to Backdoor Online Stores https://thecyberexpress.com/attackers-exploit-unpatched-magento-zero-day/ Mon, 07 Sep 2026 12:32:45 +0000 https://thecyberexpress.com/?p=113992 Magento, Magento Vulnerability

Attackers are exploiting an unpatched remote code execution flaw in Adobe Commerce and Magento Open Source to install persistent backdoors on e-commerce sites, Dutch security firm Sansec reported, with the first intrusions observed Sept. 4 and no vendor fix available as of Sept. 6.

Sansec's forensics team, in an advisory, named the flaw StyleSmuggler. No CVE identifier has been assigned. As of Sept. 7, Adobe's Magento security bulletin index listed no September advisory, and the flaw does not appear in CISA's Known Exploited Vulnerabilities catalog, leaving an unknown number of merchants exposed during a window in which working exploit traffic is already circulating.

Magento underpins a large share of mid-market online retail, and Adobe has sold it as Adobe Commerce since acquiring the platform in 2018. The codebase has been a durable target for payment-skimming crews: Sansec has tracked Magecart-style card theft against Magento storefronts for close to a decade, and the platform's checkout position makes any unauthenticated code execution flaw unusually valuable.

According to Sansec's analysis, StyleSmuggler is a two-stage chain that abuses the platform's GraphQL interface. Attackers first inject PHP code into files Magento writes on its own, such as failure reports, then trigger execution through the platform's "Payment Transaction Failed Reminder" email routine. Because the trigger fires when the reminder is generated, no recipient has to open the message for the payload to run.

The vulnerability was confirmed on Magento Open Source 2.4.7, 2.4.8 and 2.4.9. The detail likely to unsettle merchants most is the first known victim: a store running 2.4.6-p15 with all available patches applied. Being current on Adobe's release cycle did not prevent compromise.

The implant Sansec documented is built to survive routine inspection. It runs under a process name mimicking a Linux kernel thread, [kworker/u:8:0], with the binary written to ~/.local/share/.gvfsd/gvfsd-user and a cron entry relaunching it every five minutes. Sansec also listed the domain 247.cdnflare.xyz among its indicators of compromise.

Sansec advised merchants to disable GraphQL where the storefront can tolerate it, disable the PHP proc_open function, and mount /tmp, /var/tmp and /dev/shm with the noexec option. Unofficial community patches have been published by Disrex Group, ProxiBlue and Graycore. Disrex said it independently identified two compromised stores and a third that was attacked without being breached.

Adobe's most recent scheduled Commerce bulletin, APSB26-92, was published Aug. 11 and addressed critical and important flaws across the 2.4.4 through 2.4.9 branches. The company's next scheduled security release is Sept. 8. Adobe did not appear to have commented publicly on StyleSmuggler.

Also read: Adobe Issues Urgent Patch for ‘SessionReaper’ Vulnerability in Commerce and Magento
]]> Magento, Magento Vulnerability

Attackers are exploiting an unpatched remote code execution flaw in Adobe Commerce and Magento Open Source to install persistent backdoors on e-commerce sites, Dutch security firm Sansec reported, with the first intrusions observed Sept. 4 and no vendor fix available as of Sept. 6.

Sansec's forensics team, in an advisory, named the flaw StyleSmuggler. No CVE identifier has been assigned. As of Sept. 7, Adobe's Magento security bulletin index listed no September advisory, and the flaw does not appear in CISA's Known Exploited Vulnerabilities catalog, leaving an unknown number of merchants exposed during a window in which working exploit traffic is already circulating.

Magento underpins a large share of mid-market online retail, and Adobe has sold it as Adobe Commerce since acquiring the platform in 2018. The codebase has been a durable target for payment-skimming crews: Sansec has tracked Magecart-style card theft against Magento storefronts for close to a decade, and the platform's checkout position makes any unauthenticated code execution flaw unusually valuable.

According to Sansec's analysis, StyleSmuggler is a two-stage chain that abuses the platform's GraphQL interface. Attackers first inject PHP code into files Magento writes on its own, such as failure reports, then trigger execution through the platform's "Payment Transaction Failed Reminder" email routine. Because the trigger fires when the reminder is generated, no recipient has to open the message for the payload to run.

The vulnerability was confirmed on Magento Open Source 2.4.7, 2.4.8 and 2.4.9. The detail likely to unsettle merchants most is the first known victim: a store running 2.4.6-p15 with all available patches applied. Being current on Adobe's release cycle did not prevent compromise.

The implant Sansec documented is built to survive routine inspection. It runs under a process name mimicking a Linux kernel thread, [kworker/u:8:0], with the binary written to ~/.local/share/.gvfsd/gvfsd-user and a cron entry relaunching it every five minutes. Sansec also listed the domain 247.cdnflare.xyz among its indicators of compromise.

Sansec advised merchants to disable GraphQL where the storefront can tolerate it, disable the PHP proc_open function, and mount /tmp, /var/tmp and /dev/shm with the noexec option. Unofficial community patches have been published by Disrex Group, ProxiBlue and Graycore. Disrex said it independently identified two compromised stores and a third that was attacked without being breached.

Adobe's most recent scheduled Commerce bulletin, APSB26-92, was published Aug. 11 and addressed critical and important flaws across the 2.4.4 through 2.4.9 branches. The company's next scheduled security release is Sept. 8. Adobe did not appear to have commented publicly on StyleSmuggler.

Also read: Adobe Issues Urgent Patch for ‘SessionReaper’ Vulnerability in Commerce and Magento
]]> 113992 Attackers Exploited MikroTik RouterOS Flaws a Day Before Patches Shipped https://thecyberexpress.com/mikrotik-routeros-exploited-before-patch/ Mon, 07 Sep 2026 11:39:45 +0000 https://thecyberexpress.com/?p=113986 World map showing 122,500 internet-exposed MikroTik routers concentrated in Brazil, the United States, Indonesia, the Czech Republic and Ukraine

Attackers began compromising internet-exposed MikroTik routers on Sept. 2, a day before the Latvian vendor released fixes and three days before national authorities published the technical detail defenders needed to detect the intrusions.

What is the MikroTrick vulnerability chain?

CERT Polska disclosed six RouterOS vulnerabilities Sept. 5 and gave the two-flaw chain seen in the wild a common name, "MikroTrick." CVE-2026-67276, rated 9.2, is an SSH authentication bypass. RouterOS verified the type and modulus of a public key during authentication but omitted the exponent, letting an attacker who knows a username and the RSA modulus forge a matching key and authenticate without ever holding the private one.

CVE-2026-86060, also rated 9.2, is an argument injection flaw in which an SSH username beginning with a disallowed character escalates the session to full administrative rights. Chained, the two give an unauthenticated attacker complete control of any device with SSH reachable from the internet.

A third flaw, CVE-2026-67277 at 8.8, permits unauthenticated access to privileged state through the bandwidth-test service. CERT Polska credited the discoveries to its own team, which said it used OpenAI's GPT-5.5-cyber and GPT-5.6-sol models under the vendor's Government and Trust Agency Collaboration program to automate version comparison, RFC analysis and binary review, with researchers independently verifying every finding.

The exposed population is large. Shadowserver counts more than 122,500 MikroTik devices with SSH reachable on the open internet, concentrated in Brazil with 11,300, the United States and Indonesia with 7,100 each, the Czech Republic with 6,300 and Ukraine with 5,100. CERT.LV said it has confirmed 12 compromised devices in Latvia out of several thousand exposed, notified critical infrastructure operators Sept. 3, and recorded intensifying attacks in an update published Sept. 6.

How to check whether your MikroTik router is compromised

Both agencies published the same indicators. Failed logins for a user named -2, system history entries reading ssh:-2@, creation of a privileged account named ops, and a "Flagged" marker RouterOS sets at startup. Attack traffic traced to 82.192.72.4 for successful compromises and 103.102.31.18 for attempts.

MikroTik shipped 6.49.21, 7.23.4, 7.24.2 and 7.25beta3 on Sept. 3 and pushed alerts through its mobile app, but declined to publish specifics, saying it was withholding detail to give users time to update. The embargo held about a day.

Network engineer Nick Pratley published a binary diff of RouterOS 7.23.3 against 7.24.2 on Sept. 4, reconstructing three of the fixes and releasing working proof-of-concept code. Shipping patched binaries worldwide, he argued, makes the diff itself the disclosure. A separate lab proof-of-concept for CVE-2026-67276 has since been posted to GitHub.

Why MikroTik's silent patch drew criticism

The sequencing is what draws criticism. Because exploitation preceded the patch, the withheld detail was not being kept from an attacker who lacked it. It was being kept from administrators who had no way to know they were already being targeted.

There is a regulatory dimension approaching. MikroTik is headquartered in Riga, and from Sept. 11 the EU Cyber Resilience Act requires manufacturers to file an early warning within 24 hours of learning a product is under active exploitation, routed through a platform operated by ENISA. A repeat of this week's sequence after that date would start a regulatory clock rather than leaving disclosure timing to vendor discretion.

Also read: EU, UK Attribute Russia Cyberattack to FSB, Announce Sanctions
]]> World map showing 122,500 internet-exposed MikroTik routers concentrated in Brazil, the United States, Indonesia, the Czech Republic and Ukraine

Attackers began compromising internet-exposed MikroTik routers on Sept. 2, a day before the Latvian vendor released fixes and three days before national authorities published the technical detail defenders needed to detect the intrusions.

What is the MikroTrick vulnerability chain?

CERT Polska disclosed six RouterOS vulnerabilities Sept. 5 and gave the two-flaw chain seen in the wild a common name, "MikroTrick." CVE-2026-67276, rated 9.2, is an SSH authentication bypass. RouterOS verified the type and modulus of a public key during authentication but omitted the exponent, letting an attacker who knows a username and the RSA modulus forge a matching key and authenticate without ever holding the private one.

CVE-2026-86060, also rated 9.2, is an argument injection flaw in which an SSH username beginning with a disallowed character escalates the session to full administrative rights. Chained, the two give an unauthenticated attacker complete control of any device with SSH reachable from the internet.

A third flaw, CVE-2026-67277 at 8.8, permits unauthenticated access to privileged state through the bandwidth-test service. CERT Polska credited the discoveries to its own team, which said it used OpenAI's GPT-5.5-cyber and GPT-5.6-sol models under the vendor's Government and Trust Agency Collaboration program to automate version comparison, RFC analysis and binary review, with researchers independently verifying every finding.

The exposed population is large. Shadowserver counts more than 122,500 MikroTik devices with SSH reachable on the open internet, concentrated in Brazil with 11,300, the United States and Indonesia with 7,100 each, the Czech Republic with 6,300 and Ukraine with 5,100. CERT.LV said it has confirmed 12 compromised devices in Latvia out of several thousand exposed, notified critical infrastructure operators Sept. 3, and recorded intensifying attacks in an update published Sept. 6.

How to check whether your MikroTik router is compromised

Both agencies published the same indicators. Failed logins for a user named -2, system history entries reading ssh:-2@, creation of a privileged account named ops, and a "Flagged" marker RouterOS sets at startup. Attack traffic traced to 82.192.72.4 for successful compromises and 103.102.31.18 for attempts.

MikroTik shipped 6.49.21, 7.23.4, 7.24.2 and 7.25beta3 on Sept. 3 and pushed alerts through its mobile app, but declined to publish specifics, saying it was withholding detail to give users time to update. The embargo held about a day.

Network engineer Nick Pratley published a binary diff of RouterOS 7.23.3 against 7.24.2 on Sept. 4, reconstructing three of the fixes and releasing working proof-of-concept code. Shipping patched binaries worldwide, he argued, makes the diff itself the disclosure. A separate lab proof-of-concept for CVE-2026-67276 has since been posted to GitHub.

Why MikroTik's silent patch drew criticism

The sequencing is what draws criticism. Because exploitation preceded the patch, the withheld detail was not being kept from an attacker who lacked it. It was being kept from administrators who had no way to know they were already being targeted.

There is a regulatory dimension approaching. MikroTik is headquartered in Riga, and from Sept. 11 the EU Cyber Resilience Act requires manufacturers to file an early warning within 24 hours of learning a product is under active exploitation, routed through a platform operated by ENISA. A repeat of this week's sequence after that date would start a regulatory clock rather than leaving disclosure timing to vendor discretion.

Also read: EU, UK Attribute Russia Cyberattack to FSB, Announce Sanctions
]]> 113986 Liquid Network Hackers Demand Bug Fix Before Returning $320M BTC https://thecyberexpress.com/liquid-network-security-incident/ Mon, 07 Sep 2026 08:28:11 +0000 https://thecyberexpress.com/?p=113978 Liquid Network security incident

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. ]]> Liquid Network security incident

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. ]]> 113978 Mathspace Breach Impacts More Than 1 Million Users in Australia, NZ https://thecyberexpress.com/mathspace-data-breach/ Mon, 07 Sep 2026 07:14:26 +0000 https://thecyberexpress.com/?p=113972 Mathspace data breach

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. ]]> Mathspace data breach

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. ]]> 113972 G7, CISA Urge Urgent Shift to Post-Quantum Cryptography https://thecyberexpress.com/post-quantum-cryptography/ Mon, 07 Sep 2026 06:51:40 +0000 https://thecyberexpress.com/?p=113966 post-quantum cryptography

Some of the world's leading democracies are pushing governments and companies to start preparing for post-quantum cryptography before quantum computers become powerful enough to break the encryption systems that protect global digital infrastructure today.

In a joint advisory released Thursday, the G7 Cybersecurity Working Group and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) said organizations should begin their transition to post-quantum cryptography now, rather than waiting until cryptographically relevant quantum computers (CRQCs) are available to threat actors.

Why the Post-Quantum Cryptography Shift Cannot Wait

The publication, titled "Preparing for the Post-Quantum Era: A Call to Action," warns that the quantum computing threat is no longer a distant concern. While the exact timeline for CRQC development remains uncertain, the working group said recent technological advances suggest such machines could emerge sooner than expected, putting widely used public-key cryptography mechanisms at risk.

One of the most immediate dangers is a tactic known as "harvest now, decrypt later," where malicious actors intercept and store encrypted data today with the intention of decrypting it once a CRQC becomes available. This poses a serious risk to governmental records, sensitive personal data, and trade or business secrets that require long-term confidentiality.

The advisory also cautions that CRQCs could eventually be used to target authentication mechanisms, allowing bad actors to impersonate trusted entities, forge data, or compromise equipment. Because supply chain vulnerabilities can cascade, a single organization's delay in adopting post-quantum cryptography could expose entire sectors to compromise.

According to the report, organizations that fail to act may also face business consequences beyond security risk, including exclusion from public procurement contracts and loss of competitive advantage.

Five Priorities for the PQC Transition

The G7 Cybersecurity Working Group outlined five priority areas to guide the global shift toward post-quantum cryptography:

  1. Raising awareness — Many organizations still view the quantum threat as a distant or purely technical issue. The group called for awareness campaigns, technical guidance, and workforce upskilling to reframe it as an economic and business risk.
  2. Developing national strategies — Countries are encouraged to build strategies that ensure an adequate supply of quantum-safe hardware and software while encouraging adoption, integrating the effort into broader digital privacy and security policies.
  3. Advancing research and development — Governments should fund research programs and support pilot projects and testbeds to help organizations test and refine their transition to post-quantum cryptography.
  4. Building public-private partnerships — Collaboration between government, industry, and academia is seen as key to developing domestic expertise, lowering transition costs, and sharing playbooks and case studies across sectors.
  5. Integrating PQC into cybersecurity requirements — The group recommends treating post-quantum cryptography adoption as a natural evolution of cryptographic best practice, and embedding requirements into public procurement to push both vendors and organizations toward quantum-safe systems.

The advisory emphasizes that the shift to post-quantum cryptography cannot be solved by individual organizations in isolation. Instead, it calls for early engagement, coordinated planning, and informed decision-making across public and private sectors worldwide.

Tackling the risks that the impending quantum computing era poses to current cryptographic systems... requires a coordinated global effort to transition to PQC," the report states, adding that public and private organizations must act now to safeguard confidential data, supply chains, and critical systems.

The document was jointly published by cybersecurity authorities from Canada, Germany, Italy, Japan, the United Kingdom, the United States, and France's ANSSI, with participation from the European Commission and support from the EU Agency for Cybersecurity (ENISA).

]]> post-quantum cryptography

Some of the world's leading democracies are pushing governments and companies to start preparing for post-quantum cryptography before quantum computers become powerful enough to break the encryption systems that protect global digital infrastructure today.

In a joint advisory released Thursday, the G7 Cybersecurity Working Group and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) said organizations should begin their transition to post-quantum cryptography now, rather than waiting until cryptographically relevant quantum computers (CRQCs) are available to threat actors.

Why the Post-Quantum Cryptography Shift Cannot Wait

The publication, titled "Preparing for the Post-Quantum Era: A Call to Action," warns that the quantum computing threat is no longer a distant concern. While the exact timeline for CRQC development remains uncertain, the working group said recent technological advances suggest such machines could emerge sooner than expected, putting widely used public-key cryptography mechanisms at risk.

One of the most immediate dangers is a tactic known as "harvest now, decrypt later," where malicious actors intercept and store encrypted data today with the intention of decrypting it once a CRQC becomes available. This poses a serious risk to governmental records, sensitive personal data, and trade or business secrets that require long-term confidentiality.

The advisory also cautions that CRQCs could eventually be used to target authentication mechanisms, allowing bad actors to impersonate trusted entities, forge data, or compromise equipment. Because supply chain vulnerabilities can cascade, a single organization's delay in adopting post-quantum cryptography could expose entire sectors to compromise.

According to the report, organizations that fail to act may also face business consequences beyond security risk, including exclusion from public procurement contracts and loss of competitive advantage.

Five Priorities for the PQC Transition

The G7 Cybersecurity Working Group outlined five priority areas to guide the global shift toward post-quantum cryptography:

  1. Raising awareness — Many organizations still view the quantum threat as a distant or purely technical issue. The group called for awareness campaigns, technical guidance, and workforce upskilling to reframe it as an economic and business risk.
  2. Developing national strategies — Countries are encouraged to build strategies that ensure an adequate supply of quantum-safe hardware and software while encouraging adoption, integrating the effort into broader digital privacy and security policies.
  3. Advancing research and development — Governments should fund research programs and support pilot projects and testbeds to help organizations test and refine their transition to post-quantum cryptography.
  4. Building public-private partnerships — Collaboration between government, industry, and academia is seen as key to developing domestic expertise, lowering transition costs, and sharing playbooks and case studies across sectors.
  5. Integrating PQC into cybersecurity requirements — The group recommends treating post-quantum cryptography adoption as a natural evolution of cryptographic best practice, and embedding requirements into public procurement to push both vendors and organizations toward quantum-safe systems.

The advisory emphasizes that the shift to post-quantum cryptography cannot be solved by individual organizations in isolation. Instead, it calls for early engagement, coordinated planning, and informed decision-making across public and private sectors worldwide.

Tackling the risks that the impending quantum computing era poses to current cryptographic systems... requires a coordinated global effort to transition to PQC," the report states, adding that public and private organizations must act now to safeguard confidential data, supply chains, and critical systems.

The document was jointly published by cybersecurity authorities from Canada, Germany, Italy, Japan, the United Kingdom, the United States, and France's ANSSI, with participation from the European Commission and support from the EU Agency for Cybersecurity (ENISA).

]]> 113966