CVE-2026-111357 (CVSS score of 8.8) – A missing authentication check for a critical function that could allow an authenticated local attacker to gain higher privileges.
CVE-2026-118527 (CVSS score of 4.3) – A predictable identifier vulnerability that could allow an authenticated remote attacker to upload files containing malicious content to a known location on the system.
The vulnerabilities are part of an exploit chain that cybersecurity firm Volexity first documented in mid-October.
“Volexity has identified active in-the-wild exploitation of a vulnerability chain allowing unauthenticated remote code execution in Ivanti Connect Secure VPN devices. Ivanti has published an advisory providing upgrade instructions to customers.” states Volexity. “Systems exhibiting signs of compromise, such as attempts to move laterally originating from the ICS VPN device, should be forensically investigated to ensure no breach has occurred.“
The attacks combined these vulnerabilities with an authentication bypass vulnerability, tracked as CVE-2026-104935 (CVSS score of 8.6).
In early October 2026, Volexity discovered that a threat actor tracked as UTA0576 was exploiting a zero-day vulnerability chain to compromise fully patched Ivanti Connect Secure VPN appliances. The attack combined authentication bypass, remote code execution, and privilege escalation flaws, allowing attackers to gain root access without logging in. The authentication bypass and RCE flaws are tracked as CVE-2026-104935.
After gaining access, the attackers targeted Active Directory credentials and sensitive information, including LAPS passwords and BitLocker recovery keys. Volexity worked with Ivanti as soon as it suspected the vulnerabilities were being exploited.
CISA added CVE-2026-104935 to the Known Exploited Vulnerabilities (KEV) catalog on October 13, 2026.
Ivanti released security updates to address both CVE-2026-111357 and CVE-2026-118527:
Version 25.1.1.2 and earlier: upgrade to 25.1.1.3.
Version 22.8R2.5 and earlier: upgrade to 22.8R2.6.
Ivanti said it disclosed CVE-2026-104935 first because a fix was already available and ready for testing. When researchers discovered the additional privilege escalation flaws, the company decided not to delay the release of the first patch, which addressed the main attack method. Ivanti also worked with Volexity to share information about the attackers’ techniques, including how they chained the vulnerabilities.
Ivanti had already fixed part of the issue in its July 25.1.3.0 release and was preparing updates for other supported versions. Patches are now available for all the vulnerabilities used in the attacks.
“At the time of discovery of exploitation, Ivanti had a fix developed for CVE-2026-104935 which was already in QA for supported versions, and we made the decision to not delay getting a fix to customers that resolved the primary exploitation path when the LPE was discovered. Because of this, our focus was initially centered on the disclosure of CVE-2026-104935 and providing protection for our customers as quickly as possible.” states Ivanti. “Additionally, Ivanti collaborated with Volexity on their blog post which provided information to arm defenders on known threat actor behavior, including chaining the local privilege escalation vulnerability. These additional CVE disclosures have now been added to this Security Advisory and a fix is available now.”
Drupal warns that attackers are exploiting a critical authorization flaw in Commerce Core, putting vulnerable online stores at risk.
Drupal warns that threat actors are exploiting a highly critical security flaw, tracked as CVE-2026-118539, in its Commerce Core module. The vulnerability is caused by missing authorization checks.
“This module enables you to sell goods and services to customers through an included shopping cart and checkout form or through decoupled applications via APIs. The module doesn’t sufficiently protect certain routes and entity fields, leading to an access bypass that may financially impact the vendor.” reads the advisory. This vulnerability is being actively exploited in the wild.”
The module allows websites to sell products and services through shopping carts, checkout forms, and APIs.
“Missing Authorization vulnerability in Drupal Commerce Core allows Forceful Browsing. This issue affects Commerce Core versions: from 0.0.0 to 2.41, from 3.0.0 to 3.3.13.” reads the advisory.
Researchers Dan Puccetti (dpuccetti), Marcus Johansson (marcus_johansson), and Robert Snyder (rsnyd) reported the vulnerability.
The maintainers at the open-source project confirmed that the vulnerability is being actively exploited in the wild.
Drupal recommends that users update their installations to the latest available release. Those running the 3.x branch should upgrade to version 3.3.13, while users on earlier releases should move to Commerce Core 8.x-2.41.
In May, Drupal warned that attackers were exploiting an SQL injection flaw, tracked as CVE-2026-9082, in its database abstraction API. The vulnerability could allow attackers to gain higher privileges, access sensitive information, and execute malicious code remotely.
The US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities (KEV) Catalog.
Yoba malware uses fake ChatGPT and Claude apps to sideload malware through signed installers and deploy a cryptocurrency miner.
Check Point Research has spent two months tracking a campaign it calls Yoba, which uses the popularity of AI tools to spread a custom malware chain. The attackers build fake GitHub projects that pose as AI desktop applications such as GPT-5.6 Sol, GPT-6 Astra and Claude Opus. The projects look convincing and run on real GitHub infrastructure, which helps them seem legitimate to potential victims.
“These projects look convincing and use real GitHub infrastructure, which helps them appear legitimate to potential victims. The website exhibits search-targeted content and suspicious installer-delivery tactics consistent with an SEO-poisoning lure.
Inside the installers, there is a malicious component we refer to as the YobaDropper. This dropper includes another component, the YobaLoader, which is responsible for contacting attacker-controlled infrastructure and fetching the final payload.” reads the report. “In this report, we describe how victims are lured to these fake projects, how the YobaDropper and YobaLoader work together, and how the attackers ultimately use this chain to run unwanted software on infected systems.”
The lure is simple. Each project has a repository, a GitHub.io page describing the software, and a ZIP release with the malware. The repositories show no fake stars or forks, yet they still rank among the top Google results, most likely through SEO poisoning that optimizes titles, descriptions and hosting domains.
The first repository appeared around July 2026, but the first malicious releases landed only on August 30 and 31, and a third followed about five days later on September 4. Each repository uses a different Outlook address, and commit times point to UTC+4, UTC-4 and UTC+3, which Check Point reads as a deliberate attempt to hide the actor’s real time zone.
Here’s the trick that gives the report its title. Each ZIP holds a legitimate signed executable from OpenAI or Anthropic, named Setup.exe, next to a malicious winmm.dll. The signed program loads the DLL on its own, a technique known as DLL sideloading, which is often used to bypass security protections.
The ZIP files were not even password-protected. Attackers often use passwords to prevent security tools from automatically unpacking and scanning files. However, these binaries already had very low detection rates because they used anti-sandbox and other techniques to avoid analysis. The DLL’s compilation date is another clue: it was built on the same day it was added to the archive, unlike the legitimate files around it.
The dropper, called YobaDropper, checks the environment before running. It calculates a hash of the name of the program that launched it and continues only if the name is Setup.exe. This means that sandboxes that run the DLL on its own will fail this check. When that happens, the process does not exit. Instead, it sleeps 200,000 times for 5.5 seconds each, a total of about 12.73 days.
The malware also avoids victims in CIS countries by checking the keyboard layout. It excludes Russian, Belarusian, Tajik, Armenian, Azerbaijani, Georgian, Kazakh, Kyrgyz, Turkmen, Uzbek, and Tatar. Interestingly, Ukraine, which has often appeared in similar exclusion lists, is not included.
Next, the malware requests administrator privileges. If the user does not have them, it displays the message “Please run this program as Administrator.” and exits. The victim must then restart it with administrator rights.
Once it has the required privileges, the malware creates a folder called WMProcess under ProgramData. It copies the legitimate WMPDMC.exe file from System32 into this folder and places the second-stage payload there under the name wmpdui.dll.
The malicious code achieves persistence by using a scheduled task dressed up as Microsoft. The author is set to Microsoft Corporation, the description says it collects device metadata for Windows Media Player, and it starts three minutes after boot as Local System. The task launches the legitimate program, which sideloads the malicious DLL.
The second stage, YobaLoader, shares code with the dropper, which points to the same developer. It only runs under WMPDMC.exe and uses a different seed for its hashing than the dropper does, which separates the stages and weakens hash-based detection. Its job is to find its payload without a classic command server.
It goes to a Telegram channel, t[.]me/yoba_fanclub, and downloads the channel’s profile picture. The last 50 bytes of the image seed a domain generator that builds names from word lists in the form adjective-noun-verb-number on dedyn[.]io. Change the picture and the operator gets a new domain.
Then it asks Google’s DNS-over-HTTPS service for a TXT record on that domain. The reply is signed, and the loader checks the signature before decrypting it, which gives a link to a payload on Catbox. Check Point says this reliance on DoH and common hosting aims to bypass passive DNS monitoring and some gateway protections, and the campaign avoids dedicated command-and-control infrastructure, using Telegram, Tor, Catbox and DoH instead.
The operator can choose how the payload runs. It can inject it into svchost.exe, save it as an executable after removing the Zone.Identifier mark, or run it as a hidden PowerShell script while bypassing execution policies.
“Finally, the injected payload into svchost.exe is an XMRig 6.26.0 miner with a hidden command line targeting a TLS-enabled onion mining endpoint through a local Tor SOCKS5 proxy. It can unpack and start Tor 0.4.9.12 plus lyrebird 0.8.1, monitor user-input activity to pause mining, and conditionally load the WinRing0 driver service for MSR-based mining optimization.” continnues the report.
The miner uses Tor to connect to an encrypted mining server. It can start its own Tor components, use about 85% of CPU threads, and pause mining when the user is active. It resumes after 240 seconds of inactivity and can load the WinRing0 driver to optimize mining performance.
However, YobaLoader is not limited to cryptocurrency mining. Its DNS tasking system allows operators to deliver any PE executable or PowerShell payload, meaning future attacks could distribute other malware families.
Earlier versions appeared in June 2026. They used Cursor.exe for sideloading, a startup shortcut for persistence, and excluded only Russia. They also used .aber[.]ir instead of dedyn[.]io and included anti-debugging and anti-VM checks that later versions dropped.
Check Point believes the attackers may have Russian origins and mainly operate in the UTC-4 time zone, but this is an assessment, not a confirmed attribution.
Defenders should look for suspicious WMPDMC.exe copies under ProgramData, fake Microsoft scheduled tasks, Telegram-related traffic, DNS lookups for dedyn[.]io through dns.google, and unexplained high CPU usage.
“The Yoba campaign shows how attackers can use trusted platforms and the current interest in AI tools to distribute malware in a way that looks believable and harmless at first glance. By packaging their code together with well-known software names and hosting it on GitHub, they lower the chances that users or basic security checks will immediately flag the files as suspicious.” concludes the report. “Organizations should be cautious about installing “AI helpers” or similar tools from unverified repositories and should enforce policies that restrict running software from unknown sources. Combining user awareness with basic technical controls.”
CVE-2026-97229 (CVSS score of 10.0) GitLab Community Edition and Enterprise Edition Integer Overflow or Wraparound vulnerability
CVE-2026-76418 (CVSS score of 8.6) Cisco Secure Firewall ASA Software and Cisco Secure FTD Software Unchecked Return Value to NULL Pointer Dereference Vulnerability
CVE-2026-97229 is a critical security flaw that could let attackers run code on its servers without logging in.
The flaw affects Community Edition (CE) and Enterprise Edition (EE), it is an integer overflow bug caused by weak validation of regular expressions in CI/CD configurations. The issue affects GitLab versions 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. Users should upgrade to a patched version to protect their systems. GitLab advisory
“GitLab has remediated an issue that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration, due to insufficient regular expression validation.” reads the advisory.
The researchers joaxcar reported this vulnerability through the company’s HackerOne bug bounty program.
Alpine Linux recently reported that an unknown attacker tried to exploit the vulnerability against Alpine Linux on October 20 and 21, 2026, but the attempts failed.
CVE-2026-76418 is a NULL pointer dereference vulnerability affecting Cisco Secure Firewall ASA and FTD Software. It could allow an unauthenticated remote attacker to force a device to reload, causing a denial-of-service (DoS) condition.
Cisco said it became aware of active exploitation earlier this month. The company has not disclosed who is behind the attacks, how many organizations have been targeted, or what attackers may have done after gaining access.
Binance links a $6.3 billion crypto theft to a compromised DevOps laptop, with North Korean hackers blamed by blockchain analysts.
Binance was investigating suspicious transfers that early estimates put at up to $5.8 billion. A day later, multiple media outlets reported that the largest cryptocurrency exchange had linked the theft of about $6.3 billion to a DevOps engineer’s compromised laptop. Billions had moved out of wallets linked to the exchange.
According to The Block, blockchain analyst Spreek identified approximately $3.55 billion in incoming transfers to an initially unidentified wallet.
“Onchain data flagged by analyst Spreek shows about $3.55 billion in incoming transfers to the unlabeled wallet, with nearly $900 million subsequently moved across other wallets.” The Block reports. “Conor Grogan, a senior director and product leader at Coinbase, says the amount is up to $5.8 billion.”
Coinbase executive Conor Grogan initially estimated that the total value of the movements could reach $5.8 billion.
Those figures came from blockchain tracking and differing estimates, so they didn’t necessarily show the amount stolen.
Binance pointed out that customer funds were safe, while co-founder Changpeng Zhao, widely known as CZ, said the activity appeared to be a hack. Zhao no longer manages Binance’s platform, but said he expected customers’ funds to be fully covered.
The company said its user funds were “completely safe.”
“Our teams are aware of reports of a potential security issue and are actively investigating. User funds are completely safe. Our security teams are reviewing all relevant information with urgency, and we will provide updates through official Binance channels as soon as we have verified information.” the company states. “Users should remain cautious of scams and should not trust unofficial links, messages, or requests for account information.”
That assurance is important, but it doesn’t replace a technical explanation of how the transfers occurred or independent confirmation of the final impact.
“Our initial investigation suggests this security incident may have started with a compromised DevOps engineer’s laptop. That gave an attacker access to a service container, where they submitted unauthorized withdrawal transactions.” Binance Co-CEO Richard Teng explained.
“To be clear: the attacker did not simply use one engineer’s permissions, and this was not a single “one-click” action. It involved a more complex attack process. Our investigation has not attributed responsibility to any individual.”
I want to speak to you directly about what happened.
Bottom line – your money is safe, and we’re covering every loss.
Our initial investigation suggests this security incident may have started with a compromised DevOps engineer’s laptop. That gave an attacker access to a…
Attackers used access from an engineer’s laptop to reach a service container and send unauthorized withdrawal requests. Binance says it has found no evidence that attackers stole any wallet private keys.
Binance also said it had found “additional points of breach” and was still investigating. Co-CEO Richard Teng said the investigation had not identified anyone responsible. After the attack, Binance suspended deposits and withdrawals to carry out security checks, cancelled the permissions linked to the affected address, and began working with blockchain analysis firms and law enforcement to track the stolen funds.
Binance says it will cover all losses using its SAFU fund and its own money, and that customer funds are safe. The company also plans to publish an updated Proof of Reserves once it has completed the recovery work. This commitment does not replace a detailed technical explanation or independent confirmation of the full impact of the attack.
Binance hasn’t named a culprit, but the blockchain analysis firm TRM has. It attributes the attack to TraderTraitor, a North Korean state-backed unit also tracked as Lazarus Group and APT38, and Chainalysis says it’s highly confident in that finding.
Our investigators observed funds stolen by DPRK in last month’s Bitget exploit commingling with funds stolen from Binance.
We have a high degree of confidence that DPRK is responsible for the $6.4 billion hack of Binance. https://t.co/xj9dQYcbKr
TRM says the attacker moved about $6.36 billion out of Binance wallets on ten blockchains on October 29, most of it in roughly 20 minutes starting at 20:05 UTC. That makes it the largest crypto theft on record, about four times the $1.5 billion Bybit hack of February 2025.
“On October 29, 2026, an attacker moved approximately USD 6.36 billion out of Binance wallets on ten blockchains, most of it in about 20 minutes starting at 20:05 UTC. That makes this the largest crypto theft on record, about four times the USD 1.5 billion Bybit hack of February 2025. Binance has confirmed a security incident and suspended withdrawals on several networks.” TRM said. “TRM attributes the attack to TraderTraitor, North Korea’s elite hacking unit, based on robust on and off-chain intelligence. We make this judgment with high confidence. TRM is tracking the funds and alerting partners through the Beacon Network.”
Freezing the money only went partway. Tether, Circle, Ripple and World Liberty Financial froze about $2.67 billion in stablecoins, and Arbitrum’s Security Council froze 8,426 ETH and 74.6 million ARB, for roughly $2.7 billion in all. But the attacker raced the freezes by selling USDT to market makers and borrowing ETH against USDT on Aave. It now holds more than 420,000 ETH and 18,270 BTC, about $2.4 billion beyond any issuer’s reach.
The early freeze numbers were messy too, Tether and Circle froze approximately $1.79 billion in stablecoins associated with the suspicious transfers in the initial reports. Those amounts describe different moments, and you shouldn’t add them without checking whether they cover distinct assets. A freeze works on tokens that have an issuer to call, and Ether and Bitcoin don’t.
Hot wallets help explain how this type of theft can happen. They store cryptocurrency in systems connected to the internet, allowing exchanges to process withdrawals quickly. But this also makes strong security controls essential. Investigators still need to determine who initiated the transfers, whether they were authorized, whether attackers gained control of the wallets, and whose funds were stolen.
Binance co-founder Changpeng Zhao, who no longer runs the company, said the activity looked like a hack and expected customers to be fully compensated. Large transfers alone do not prove a cyberattack, but the findings that emerged later provided strong evidence of a breach.
Customers also need to be careful. Attackers often exploit the confusion after a major incident by spreading fake announcements, pretending to be support staff, and directing users to fraudulent websites. Use only Binance’s official channels, avoid unexpected links, and never share passwords, authentication codes, or wallet recovery phrases in response to unsolicited messages. Security teams should also watch for phishing emails that use the incident to pressure employees into verifying their accounts.
The lesson goes beyond Binance. A public blockchain records every transaction, but it cannot show who authorized it or how attackers gained access. Blockchain transparency does not guarantee operational security.
A practical pentest workflow combines CVSS, EPSS and business impact to validate findings, prioritize fixes and document remediation decisions.
Remediation prioritization after a pentest is the process of ranking and ordering security findings based on their risk, exploitability, and business impact. A penetration test can produce any number of findings, ranging from the very low (zero) to the very high (hundreds).
The security of the tested organization depends on the findings management processes addressing the most important results first.
CVSS alone misranks risk. Accurate prioritization relies on combining CVSS, EPSS, and business context.
68.4% of practitioners say a 500+ candidate finding set would strain the team or be unmanageable, so it’s important to validate first.
81.7% of practitioners see AI-generated findings that need significant manual validation, so validation with concrete proof remains essential.
Document every deprioritization, because that record counts as audit evidence.
Why aren’t CVSS scores alone enough to inform remediation?
When prioritizing pentest results, some practitioners rely solely on frameworks like the Common Vulnerability Scoring System (CVSS). The logic is sound: the higher a vulnerability’s CVSS score is, the more risk it poses, and the sooner you should fix it, right?
Unfortunately, the reality is much more complicated. Boiling down a complex ecosystem of risk into a one-dimensional number means ignoring the wider business context. In the end, that means you fix vulnerabilities that pose serious theoretical risk first, while genuine exposures get pushed to the back of the queue.
Lets use two hypothetical vulnerabilities as an example.
Vulnerability A is an RCE flaw, CVSS 9.8, on an isolated intranet site.
Vulnerability B is a BOLA flaw, CVSS 6.5, on a public facing production payment API.
Now think about which one you would fix first.
Would you prioritize the“critical” flaw on an intranet site, containing no sensitive data that attackers could only reach if they’d already compromised your internal network? Or would you prioritize the “medium” flaw on an API that processes live credit card transactions, and that any script kiddie could manipulate?
Across an entire organization, or multiple organizations if you’re a consultant or MSP, those critical flaws can really pile up. In one AI pentesting survey of 158 base practitioners by Pentest-Tools.com, conducted in June 2026, 68.4% of respondents said a 500+ candidate finding set would strain the team or be unmanageable.
Approaching risk prioritization by trying to fix every “Critical” finding is going to exhaust you and your team. That’s when people make mistakes, and you end up with a major incident on your hands.
What separates a validated finding from a candidate?
That same distinction, in part, separates a candidate finding from a validated one. For example, vulnerability with a high CVSS score but near-zero exploitability should remain a candidate. To graduate a vulnerability from a candidate to a legally and technically validated finding, it must pass through a strict filter that involves three processes.
The first step is to eliminate as much administrative noise as possible. That means deduplicating findings and removing any that are obviously non-exploitable.
Then, you need to confirm exploitability. That typically means executing a safe, controlled attack path against the target environment to prove that a state change, data exposure, or privilege escalation can actually occur.
Finally, you need concrete evidence. A validated finding cannot rely on a generic tool’s “confidence score.” It must include comprehensive proof that a developer or auditor can immediately follow:
Technical proof tends to include HTTP request/response traces or specific error payloads.
Proof of impact includes things like screenshots or server-side telemetry demonstrating unauthorized data access.
Now, many vendors are going to claim that AI-generated findings ease the strain of exploit validation. In many cases, they’re telling the truth. But as with any AI technology, a healthy level of skepticism is important. According to the same study, 81.7% of respondents encounter AI-generated findings that need significant manual exploit validation at least sometimes.
How do CVSS, EPSS and business context combine into a ranking?
Together, CVSS, Exploit Prediction Scoring System (EPSS) scores, and business context create a single risk ranking that reflects real-world danger to the tested organization.
CVSS, as mentioned earlier, measures theoretical severity. It tells you how bad a flaw is in a vacuum, but is entirely blind to context. EPSS measures probability. It tells you how likely an attacker is to exploit a flaw in the wild over the next 30 days, but doesn’t measure the potential impact of an exploitation.
Business context measures operational impact. It tells you the value of the affected asset, how easily an attacker can reach a flaw, and what they can steal. It tells you nothing, however, about the threat itself. Ultimately, business context is expressed as residual risk, the danger left over after you factor in your existing defenses. Calculating it relies on measuring four factors:
Exposure: Whether a server is open to the public internet.
User count: How many people use a system.
Data sensitivity: Whether the system holds sensitive information.
Compensating controls: Whether you have firewalls or antivirus tools actively blocking the attack path.
By checking these boxes, you won’t waste time fixing a “Critical” bug locked in an empty, disconnected server. Instead, you’ll prioritize the “Medium” bug on your public checkout page that hackers are actively trying to breach.
What goes first when dev time is limited?
Sometimes, you’re not going to have much time for remediation. That’s natural. In those situations, prioritize validated findings with high threat activity (EPSS score) and critical business exposure. They’re the findings that pose the most threat to your organization.
Prioritization done well is itself evidence. A ranked, validated list, with a written reason for what was deprioritized, is what a team can defend later.
You’ll need to record the owner (the specific individual accepting the risk), the date of the decision, the technical operational basis for deprioritization (such as an active compensating control), and a hard review date for re-evaluation.
Why does the ranked list count as audit evidence?
A prioritized ranking list counts as valid audit evidence because it proves compliance alignment with several major security frameworks. For example:
ISO 27001 A.8.8 demands that organizations evaluate real-world exposure, take targeted corrective actions, and retain objective evidence that the remediation loop has successfully closed.
PCI DSS 11.4 mandates that penetration testing actively validates and exploits findings, with formal retesting conducted after significant organizational changes.
SOC 2 CC7.1 relies on this documentation to confirm that an organization maintains systemic operational consistency and rigorous vulnerability triage over time.
A ranked, validated list also gives MSPs and MSSPs a clear, auditable record of truth that clients can either accept or challenge with their own evidence. This transparency ensures both sides agree on which real-world risks need to be addressed first.
What does a defensible ranking record contain?
A defensible ranking record contains the validated asset identification, its technical CVSS severity, its real-world EPSS probability, the active compensating controls defining its residual list, the formal sign-off from the risk owner, and the targeted review schedule.
About the Author: Josh Breaker-Rolfe is a Content writer atBora. He graduated with a degree in Journalism in 2021 and has a background in cybersecurity PR. He’s written on a wide range of topics, from AI to Zero Trust, and is particularly interested in the impacts of cybersecurity on the wider economy.
Binance probes suspicious crypto transfers worth up to $5.8 billion as Tether and Circle freeze $1.79 billion in stablecoins linked to the activity.
Binance is investigating a potential security incident after billions of dollars in cryptocurrency moved from wallets linked to the exchange on October 29. The transfers raised concerns about a possible hack, while Tether and Circle moved to freeze stablecoins linked to the suspicious activity. The full scope of the incident remains unclear, and the reported outflows shouldn’t automatically be treated as confirmed losses.
According to The Block, blockchain analyst Spreek identified approximately $3.55 billion in incoming transfers to an initially unidentified wallet.
“Onchain data flagged by analyst Spreek shows about $3.55 billion in incoming transfers to the unlabeled wallet, with nearly $900 million subsequently moved across other wallets.” The Block reports. “Conor Grogan, a senior director and product leader at Coinbase, says the amount is up to $5.8 billion.”
Coinbase executive Conor Grogan estimated that the total value of the movements could reach $5.8 billion.
Binance acknowledged the reports and said its security team was investigating. The company had not publicly confirmed a breach in the initial reports, making it important to distinguish between suspicious transactions and a verified compromise.
“We are aware of reports of a potential security issue and we are actively investigating.” He wrote in a post on X. “Our security teams are reviewing all relevant information with urgency, and we will provide updates through official Binance channels as soon as we have verified information. Users should remain cautious of scams and should not trust unofficial links, messages, or requests for account information.”
We are aware of reports of a potential security issue and we are actively investigating. Our security teams are reviewing all relevant information with urgency, and we will provide updates through official Binance channels as soon as we have verified information. Users should…
This statement, reported by The Block, reflects the company’s position at the time. Binance also urged users to be cautious of unofficial messages and links, a relevant warning whenever a major security incident attracts public attention.
Blockchain records showed large transfers from Binance-linked hot wallets to a wallet that wasn’t previously identified as belonging to the exchange. Hot wallets hold cryptocurrency in systems connected to the internet, allowing exchanges to process withdrawals and other transactions quickly. Their online availability also makes their security controls particularly important.
The transfers involved Ethereum, stablecoins and other cryptocurrencies. Some funds were later moved to additional wallets, making it harder to track all the transactions.
Investigators must determine who initiated the transfers, whether they were authorized and whether an attacker gained control of the wallets. They also need to establish whether the funds belonged to customers or Binance itself.
Large transfers alone don’t prove a hack. However, unusual movements involving large amounts of cryptocurrency require immediate investigation.
One of the most significant developments was the response from the companies behind two major stablecoins, USDT and USDC. According to The Block and Forbes, Tether and Circle froze approximately $1.79 billion in stablecoins associated with the suspicious transfers in the initial reports.
The figures subsequently changed as the investigation developed. Tether CEO Paolo Ardoino later said the company had frozen more than $1.567 billion in USDT linked to a potential Binance exchange hack. These amounts reflect reported actions at different points in time and shouldn’t be combined without checking whether they refer to distinct assets and addresses.
Tether froze more than 1.567B USDT related to a potential Binance exchange hack.
Protecting the industry and our partners is our main priority.
The freezes demonstrate an important feature of centralized stablecoins: their issuers can restrict transfers from addresses they control through their token contracts. This can help contain suspected theft, but it doesn’t provide the same control over assets such as Ether or Bitcoin. Nor does freezing a balance guarantee that every transferred asset can be recovered.
The incident also highlights a practical tension in crypto security. Stablecoins offer the convenience of blockchain transfers, but their centralized issuers retain powers that can make a difference during an investigation.
Binance maintained that customer funds were safe, while co-founder Changpeng Zhao, widely known as CZ, said the activity appeared to be a hack. Zhao no longer manages Binance’s platform, but said he expected customers’ funds to be fully covered.
The company said its user funds were “completely safe.”
“Our teams are aware of reports of a potential security issue and are actively investigating. User funds are completely safe. Our security teams are reviewing all relevant information with urgency, and we will provide updates through official Binance channels as soon as we have verified information.” the company states. “Users should remain cautious of scams and should not trust unofficial links, messages, or requests for account information.”
That assurance is important, but it doesn’t replace a technical explanation of how the transfers occurred or independent confirmation of the final impact.
A security investigation must establish more than whether an exchange can cover a potential loss. It should determine how the activity was authorized, whether credentials or signing mechanisms were compromised, which systems were involved and whether the attacker retained any access.
For customers, the immediate priority is to avoid becoming a secondary victim. Attackers often exploit uncertainty around a major incident to distribute fake announcements, impersonate support staff and direct users to fraudulent websites. Users should rely on official Binance communication channels, avoid unexpected links and never disclose passwords, authentication codes or wallet recovery phrases in response to unsolicited messages.
Security teams should also watch for phishing emails that use the incident to demand urgent account verification. Attackers may exploit the situation to launch a separate scam.
The key lesson is that blockchain transparency does not guarantee operational security. Public ledgers show transactions, but they don’t reveal who authorized them, how attackers may have gained access or whether an exchange’s internal security controls failed.
As the investigation continues, it’s important to distinguish between reported transfers, confirmed theft and funds that can be recovered. The figures may change as analysts trace more wallets and stablecoin issuers take further action.
The Pentagon treats August freezer failures at US military bases as a suspected hack and is working with French investigators after a supermarket attack.
The Pentagon is investigating freezer failures that spoiled food at US military bases in August as a suspected cyberattack, according to four officials who spoke to Reuters. One official said US investigators are also in contact with French authorities about a similar attack on commercial freezers that disrupted supermarkets in France earlier this month. This is the first time Reuters has reported that the US incident is being treated as a suspected cyberattack.
“The Pentagon is treating the spate of mysterious freezer malfunctions that spoiled food at military bases across the United States in August as a suspected hack, according to four officials familiar with the matter.” Reuters reports.
“One of the officials said the military investigators were in touch with their French counterparts about a similar cyberattack on commercial freezers that disrupted supermarkets there earlier this month.”
It is still unclear who is behind the attacks. Reuters could not determine how far the investigation has progressed or whether investigators have identified the cause or those responsible. The Pentagon said a unit of US Cyber Command is working closely with other government agencies and law enforcement. The Army’s Criminal Investigation Division confirmed that its Cyber Field Office is involved and is working with French law enforcement to investigate the freezer outages in Europe.
The incidents hit commissaries, the on-base stores where military personnel buy food. At least six were affected in late August, according to Reuters’ review of the bases’ Facebook posts and website updates. Stars and Stripes named Fort Irwin, F.E. Warren, Naval Station Newport, Columbus and Travis among the confirmed stores, and some outlets count up to 14 sites in 11 states, though not all are confirmed.
In at least one case the freezers didn’t just stop. Their temperatures were cranked up overnight, which left mounds of wilted or melted food in the morning. Fort Huachuca in Arizona said on August 26 that its freezer went into defrost mode and heated up all the food, adding that trust us when we say it was spoiled.
The Pentagon wasn’t the first to speak. A recently created blog called Signal and Silence reported the freezer failures and the possibility of sabotage on August 28, while Stars and Stripes reported the involvement of military investigators and Britain’s Daily Telegraph reported the contacts with the French. The French Embassy in Washington had no comment. Frozen food is the one asset where damage takes hours and evidence takes the form of puddles.
The French attack is the clearest example. Hackers took control of the cooling units in more than 350 stores and raised the temperatures. Frozen food aisles were emptied, and some units got so hot they caught fire. One supermarket owner said the total cost could reach tens of millions of euros.
The same thing happened in Arizona: attackers made the units hotter instead of just turning them off.
Reuters could not tell which brand was used at the US bases, and Danfoss, which is the manufacturer targeted in French supermarket attacks, did not reply. A public research report on Danfoss controllers came out before the incidents, but nothing shows a link to the bases.
There is a history of attacks on refrigeration systems. Danfoss reports that hackers targeted supermarkets in Russia and Israel in 2022 by exploiting outdated cooling controllers. In December 2025, US prosecutors accused a Ukrainian woman of belonging to a hacking group that disrupted refrigeration at a meat plant in 2024, ruining more than 2,000 pounds of meat.
Earlier this year, the Global Food Safety Initiative urged food safety experts and IT leaders to work together to protect refrigeration systems.
42 publicly listable cloud buckets containing 18 billion files, including exposed credentials, database dumps and backups.
The Ransomnews research team counted 484,142 publicly listable cloud storage buckets in October 2026, holding 18.05 billion files. They built the count from the search engines that index open cloud storage and published it as the Ransomnews Cloud Exposure Index, written by Mantas Sasnauskas.
“No file was opened for this index. Every number below comes from bucket names, file extensions, file counts and last-modified timestamps. That is a deliberate limit. It keeps the research on the right side of the line, and it turns out to be enough to see where the sensitive material concentrates.” Ransomnews states. “We are calling it the Ransomnews Cloud Exposure Index, and we will rerun it quarterly so the numbers can be compared over time.”
The researchers used bucket names, file types, file counts and last-modified dates to collect their data. They did not open any files, allowing them to identify where sensitive information might be stored without accessing the content. They plan to repeat the research every three months to track changes over time.
Amazon S3 accounts for 72% of the exposed buckets, roughly in line with its share of the market. This does not mean S3 has weaker security than other providers. Azure Blob, however, appears 2.5 to 3.6 times more often than expected among buckets named for backups, data exports and payroll records. The researchers also found 321,058 files related to credentials and keys. Of the exposed .env files, 67% were last modified in 2026.
Below is the split by provider, from a snapshot taken on October 7:
Provider
Open buckets
Share
Amazon S3
347,984
71.9%
Azure Blob
68,532
14.2%
Google Cloud Storage
53,131
11.0%
DigitalOcean Spaces
11,069
2.3%
Alibaba OSS
3,426
0.7%
Total
484,142
100%
A lot of these buckets are public on purpose, holding website assets, CDN mirrors, open datasets and podcast archives. So the index isn’t 484,142 breaches. It’s the pool where breaches hide, and the rest of the report narrows it down to the stores that should never have been listable.
“Azure, by a wide margin relative to its size. Azure Blob holds 14.2% of open buckets, but 37% of the 1,459 buckets with “backup” in the name, 42% of the 399 named for exports, and 51% of the 505 carrying HR or payroll terms.” continues the report. “Buckets named for logs, customers and databases sit at 35% to 36%, all around two and a half times Azure’s baseline.”
The skew only shows up for operational data. Buckets named “dev” sit at Azure’s baseline of 15 percent, and “test” and “staging” fall below it, at 9 and 7 percent. The authors suspect Azure storage accounts more often hold line-of-business data such as backups, exports and HR systems that enterprises run on Microsoft, while S3 and Google Cloud carry more application assets. They call it a hypothesis the counts suggest and don’t prove, and it’s the first thing they want to test next time.
By sector, retail and e-commerce names lead with 5,666 buckets, mostly storefront assets. The more worrying number is that names tied to regulated sectors (finance, healthcare, education, government, legal and HR) appear on 10,891 unique open buckets. Those are the places where a stray file most likely holds personal, health or financial records, and where regulators expect to hear about it.
Sector (by bucket name)
Open buckets
Files in them
Retail and e-commerce
5,666
269.9M
Finance and insurance
3,508
58.0M
Healthcare
2,709
47.9M
Media and entertainment
2,696
136.2M
Education
2,393
60.6M
Gaming
2,296
79.0M
Travel and hospitality
1,714
118.7M
Real estate
1,137
60.7M
Government and public sector
1,000
36.2M
Legal
978
11.3M
Crypto
630
11.9M
HR and payroll
505
8.4M
Healthcare-related names appear in 2,709 buckets containing 47.9 million files. The researchers identified them using terms such as “hospital” (135 buckets), “patient” (135), “clinic” (277) and “dental” (331). HR and payroll is the smallest sector, with 505 buckets, 259 of which are hosted on Azure.
These figures are based on names, not proof of ownership. The search matches parts of words, so “store” can refer to object storage as well as shops. A single bucket can also appear in two sectors.
The exposed buckets also list about 4.7 million database and dump files, 15,130 mailbox archives, and tens of millions of spreadsheets and documents. Credential files are particularly concerning because they can turn a cloud misconfiguration into a real intrusion.
File type
What it is
Files listed
.pem
Certificates and private keys
113,285
.env
App secrets and API keys
80,495
.p12
Certificate bundles with keys
33,268
.keystore
Java and Android keystores
27,229
.ppk
PuTTY SSH private keys
24,302
.pfx
Windows certificate bundles
23,352
.ovpn
OpenVPN client configs
15,079
.jks
Java keystores
2,421
.htpasswd
Web server password files
695
.tfstate
Terraform infrastructure state
475
.kdbx
KeePass password vaults
457
Each of these exists to grant access. A .env file is where developers keep database passwords and API keys. A .tfstate file is Terraform’s record of a whole cloud setup, often with secrets in plain text, and a .kdbx vault is encrypted but now open to anyone who wants to guess passwords offline. Some .pem files are public certificates and some files are test fixtures, so the counts are a ceiling on live secrets and not a measure of them. It’s still a big ceiling.
Database files make up most of the sensitive material by volume:
File type
What it usually holds
Files listed
.sqlite
Embedded app databases
2,561,807
.bak
Database and server backups
752,055
.sql
Database dumps
687,446
.sqlite3
Embedded app databases
488,176
.dump
Database dumps
176,603
.mdb / .accdb
Microsoft Access databases
36,467
.dmp
Memory and crash dumps
12,809
.pst / .ost / .mbox
Mailbox archives
15,130
.eml
Saved emails
4,549,665
.csv
Data exports and records
at least 69,580,112
.xlsx / .xls
Spreadsheets
42,544,997
.docx
Word documents
24,936,788
.pdf
Documents, invoices, scans
at least 106,191,393
.log
Application and server logs
at least 61,310,809
The exposed buckets contain thousands of virtual disk images, including VMware, Hyper-V and QEMU files. A single disk image can contain an entire server, including credentials.
Some exposures involve active systems. Of 80,495 .env files, 67% were last modified in 2026. Certificates and SQLite databases include both recent and older files. Backups appear older, with 89% of the 752,055 .bak files last modified before 2025. Almost all PuTTY key files date from 2024.
Recent leaks need urgent attention, while long-standing exposures point to poor security management. The problem is ongoing: at least 113.6 million files were added to publicly listable buckets in the seven days before September 9. Over the previous 30 days, these included more than 21,000 SQL dumps, nearly 21,000 backup files, 4,477 .pem files and 1,298 .env files.
Public .env files can expose database passwords that ransomware affiliates and initial access brokers look for. Similar credentials appear in stolen-data logs, but in this case, attackers do not need to infect a device. They only need to search for exposed files.
Cloud providers already offer settings to prevent public access. Organizations should enable S3 Block Public Access, disable anonymous access to Azure Blob storage, and enable public access prevention in Google Cloud. These controls should apply at account or organization level to prevent new storage buckets from becoming public.
Organizations should also scan their storage for sensitive files such as .env, .sql, .bak, .pem, .ppk, .tfstate and .kdbx. Terraform state files and virtual disk images should be treated as secrets, stored privately, encrypted and monitored. Backups should never be publicly accessible, and recovery procedures must be tested.
One exposed bucket may be a mistake, but many often indicate a wider process failure. Organizations need to fix the underlying security controls, not just individual buckets.
The research has some limitations. The team queried search engines on October 25, while the bucket list was current to October 7 and the newest indexed file dated September 9. File-level data may therefore be about a month old. Counts are also capped at one million per query, so researchers split larger categories into date ranges and added the results.
Some limits apply. The team queried the search engines on October 25. The bucket list was current to October 7 and the newest indexed file was dated September 9, so file-level figures lag by about a month. The index caps any single count at one million, so larger types were split into date windows and summed.
A last-modified date shows when a file was written, not when it was exposed, and a listed file isn’t proof that its contents can be read. No bucket is named in the report. Exposures with a known owner in regulated sectors are going through responsible disclosure, with national CERTs copied where the owner is public sector or doesn’t respond.
“Rotate any secret that has ever sat in a public bucket. Closing the bucket does not un-leak the key. Assume anything that was listable was copied.” conlcudes the report.
U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds Linux Kernel and Broadcom VMWare ESX flaws to its Known Exploited Vulnerabilities catalog.
CVE-2026-46300 (CVSS score of 2.7) Linux Kernel Missing Initialization of a Variable Vulnerability
In July, Broadcom released patches to address five vulnerabilities affecting VMware ESXi, vCenter, Workstation, and Fusion, including CVE-2026-41709. The vulnerability in VMware ESX is caused by insufficient logging. A malicious user with administrator privileges could perform certain operations on the affected system without those actions being recorded in the logs.
This could allow an attacker to hide specific activities and make it harder for security teams to detect suspicious behavior, investigate incidents, and determine what happened. The flaw does not itself grant administrator privileges; the attacker must already have them.
According to CrowdStrike’s 2026 Legal Threat Landscape Report, which said the China-linked threat actor Warp Panda (aka Armory Castle, UNC5221, Clay Typhoon and VerdantBamboo) exploited CVE-2026-41709 as a zero-day in early 2026 to reduce the visibility of its activities in audit logs.
Warp Panda targets internet-facing edge devices by exploiting zero-day vulnerabilities and deploying custom malware to maintain persistent, covert access. The group also attempts to evade detection by bypassing audit logging, stealing cloud session tokens and registering unauthorized multi-factor authentication (MFA) devices.
The second flaw added to the catalog is CVE-2026-46300, also known as Fragnesia, could let local attackers gain root access through page cache corruption.
The flaw affects the XFRM ESP-in-TCP subsystem and could allow local attackers to gain full root access by corrupting the kernel page cache.
Security experts warn that the issue is dangerous because attackers with low privileges can modify read-only files in memory and take complete control of vulnerable systems. The vulnerability was discovered by William Bowling of the V12 security team, while Wiz published a detailed technical analysis.
“The vulnerability allows unprivileged local attackers to modify read-only file contents in the kernel page cache.” reads the report published by Wiz. “Attackers can then achieve root privileges through deterministic page-cache corruption.”
Fragnesia shares similarities with earlier Linux privilege escalation flaws, such as Dirty Frag and Copy Fail. According to researchers, the bug can reliably provide root access on major Linux distributions without requiring race conditions or complicated timing attacks.
(@paoloardoino) 
