Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label vulnerabilities and exploits. Show all posts

Attackers Are Already Exploiting SonicWall’s Freshly Patched Max-Severity SMA1000 Flaw

 



Just three days after SonicWall shipped a patch for a maximum-severity vulnerability in its SMA1000 secure remote access appliances, attackers have started scanning for and exploiting the flaw in the wild.

The vulnerability, tracked as CVE-2026-102255 and carrying a perfect CVSS score of 10.0, is a pre-authentication server-side request forgery (SSRF) bug living inside the Appliance WorkPlace interface. Because it requires no login to trigger, any remote attacker can send a crafted request to a vulnerable device and force it to relay traffic to internal services that should never be reachable from outside.

SonicWall released hotfixes on October 7 alongside three other patches and, at the time, said it had found no evidence the flaw was being actively exploited. By Friday, that had changed.


How the Exploit Works

Ryan Dewhurst, founder of security firm Previdian, said that his company's honeypot network had picked up exploitation attempts matching the CVE-2026-102255 attack pattern. The requests were not subtle.

Attackers sent a crafted OPTIONS request to the WorkPlace Extraweb interface, using it to tunnel through to the appliance's internal CouchDB service running on localhost at port 5984. From there, the payload attempted to navigate into a CouchDB design document and call its \_rewrite function, while passing an HTTP Basic Authorization header carrying the credentials admin:admin.

It is an opportunistic probe, but it tells you something: whoever is sending these requests already has a working technique and is scanning for any devices that have not yet been patched.

Dewhurst noted that while the activity is consistent with active exploitation attempts, Previdian has not confirmed whether any of those attempts actually compromised a system.

This also is not a copy of the SSRF attacks that hit SMA1000 devices in July or September. CVE-2026-102255 targets the same WorkPlace interface, but uses a different technique than the zero-days disclosed in those earlier incidents.


Who Is Exposed

The flaw affects SMA1000 models 6210, 7210, and 8200v running firmware versions 12.4.3-03526 and 12.5.0-02952 and older. SonicWall confirmed that neither the SMA 100 Series product line nor SSL-VPN functionality on SonicWall firewalls are affected.

Internet threat monitoring organization Shadowserver currently tracks more than 400 SMA1000 appliances with public-facing exposure. That figure does not separate out honeypots or already-patched devices, so the real pool of vulnerable targets could be smaller, though the number is still of importance.

SMA1000 gateways sit at the front door of corporate and government networks. Managed Service Providers, large enterprises, and government agencies rely on them to extend VPN access to internal applications for remote employees. That makes them a high-value target for nation-state actors and financially motivated cybercriminals alike.


A Pattern That Keeps Repeating

CVE-2026-102255 is the third time in 2026 alone that SonicWall has patched a CVSS 10.0 pre-authentication SSRF flaw in the WorkPlace interface that requires no login to exploit. The two that came before it were both turned into weapons before organizations could patch at scale.

In July, threat actors spent weeks exploiting two SMA1000 zero-days, CVE-2026-15409 and CVE-2026-15410, to plant custom malware families called Sou5, OrangeTail, and RootRun on compromised appliances. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) later tied several of those intrusions to ransomware operators.

In September, SonicWall confirmed attackers were chaining two fresh zero-days, CVE-2026-83548 and CVE-2026-83549, to achieve remote code execution on unpatched SMA1000 devices.

Zooming out further, CISA has added 19 SonicWall vulnerabilities to its Known Exploited Vulnerabilities catalog over the past four years. Thirteen of them have been flagged as actively used in ransomware attacks.

The October hotfix batch addressed three additional vulnerabilities beyond CVE-2026-102255. CVE-2026-102256, rated CVSS 7.8, is a post-authentication OS command injection flaw that could let an attacker with administrator credentials execute arbitrary commands on the appliance. CVE-2026-102257, rated 7.2, is a Zip Slip path traversal flaw in the Appliance Management Console that could allow file extraction outside the intended directory and potentially enable remote code execution. CVE-2026-102258, rated 5.5, is a stored cross-site scripting flaw in the same management console that could allow a logged-in administrator to inject and execute JavaScript.

SonicWall credited researcher Benoît Sevens with reporting CVE-2026-102255 and CVE-2026-102256, and Brian Mariani of DigitalCanion SA for the other two, one of which was submitted through Trend Micro's Zero Day Initiative.

SonicWall has urged all SMA1000 customers to apply the hotfixes immediately and has stated there are no alternative mitigations available for these vulnerabilities.





Dell Patches Six Critical Flaws in Container Storage Modules, Some Scoring a Perfect 10

 




Dell has shipped security fixes for six critical vulnerabilities in its Container Storage Modules (CSM) that could allow unauthenticated attackers to seize full administrative control over an organization's storage infrastructure and every node in a Kubernetes cluster. Four of the six flaws carry CVSS scores of 9.6 or higher, two of which hit the maximum possible rating of 10.0.

The bugs affect every version of CSM prior to 1.17.0, and Dell patched them in version 1.18.0. The company says no workarounds or interim mitigations exist, which means organizations running the affected software are down to one option: update now.


What CSM Does, and Why These Bugs Matter

Dell Container Storage Modules are Kubernetes-native extensions that manage persistent storage for containerized workloads across Dell's storage product families, including PowerFlex, PowerStore, PowerMax, PowerScale, and Unity XT. Because CSM sits at the intersection of storage credentials and cluster-level access controls, vulnerabilities in the platform carry a particularly high blast radius. An attacker who compromises CSM does not just gain access to data; they gain the ability to manipulate who can access what across every tenant connected to the system.


A closer look at the Six Vulnerabilities

The most severe of the six, CVE-2026-63688, scored a perfect 10.0. The flaw lives in the csm-authorization-storage gRPC server and requires no authentication to exploit. An attacker on the network can send requests directly to this endpoint and pull the backend administrator credentials for every storage array registered with the system. Dell's own advisory described it as enabling "a complete bypass of the csm-authorization security model," handing an attacker full administrative control over storage spanning all five supported Dell storage product families.

The second maximum-severity flaw, CVE-2026-63692, also a 10.0, targets the authorization proxy and tenant service. Like its counterpart, it requires zero credentials to exploit. A successful attack gives an adversary administrative control over the entire authorization service and the ability to access or manipulate storage resources across all connected tenants.

CVE-2026-67269 scored 9.9 and introduces a different threat model. It is a privilege escalation flaw in the ContainerStorageModule Custom Resource reconciler. A low-privilege attacker, not even a full admin, can submit a single maliciously crafted custom resource to the cluster and walk away with root-level access on every node in the environment. The attack surface is as small as one API call; the damage is cluster-wide.

Two of the remaining flaws center on hardcoded secrets. CVE-2026-54472 (CVSS 9.8) buries a static set of credentials inside the CSM Authorization module, allowing any remote attacker to forge cryptographically valid administrative tokens and seize control of the Authorization proxy. CVE-2026-61421 (also 9.8) compounds the problem: the JWT authentication component in karavi-authorization uses a hardcoded signing key. Because the signing secret is publicly available, anyone who locates it, something that is not especially difficult when code repositories are involved, can mint valid authentication tokens and claim administrative privileges without going through any login flow whatsoever.

The final flaw, CVE-2026-67273, scored 9.6 and is a template injection vulnerability. A low-privilege attacker with remote access can manipulate input fed through the template engine to escalate their own privileges, read sensitive information, and tamper with role-based access controls at the cluster scope. Dell's advisory noted that exploitation yields the ability to "create cluster-scoped RBAC resources, effectively bypassing the intended Kubernetes access controls."


Context: Dell's Track Record With Exploited Flaws

This batch of CSM vulnerabilities does not arrive in isolation. Dell has faced repeated problems with critical infrastructure flaws being turned against real targets in the field. Earlier this year, researchers at Mandiant and Google's Threat Intelligence Group documented how CVE-2026-22769, a hardcoded-credential flaw in Dell RecoverPoint for Virtual Machines carrying a CVSS score of 10.0, had been actively exploited as a zero-day since mid-2024 before Dell published a fix in February 2026. CISA added it to its Known Exploited Vulnerabilities catalog the following day. Years earlier, CVE-2021-21551, an access control flaw in Dell's dbutil driver, made the same list after evidence of active exploitation emerged in the wild.

The pattern here is consistent: attackers increasingly go after enterprise infrastructure components that security teams tend to treat as inherently trusted. Storage management platforms and low-level system utilities rarely face the same scrutiny as public-facing applications, and that blind spot has proven to be consequential.


What to Do

Dell is directing all customers to upgrade CSM to version 1.18.0 immediately. For systems affected by CVE-2026-61421, the company is additionally recommending that JWT signing secrets be rotated post-upgrade, since those secrets were embedded in code that has been publicly accessible and should be treated as already compromised. No partial mitigations apply. The fix is available, and for organizations still running pre-1.17.0 versions, the exposure is active.



Docker Fixes Critical Sandboxes Flaw That Could Expose Host Files

 




Docker has patched two vulnerabilities in Docker Sandboxes that could allow malicious code running inside an isolated sandbox to cross its intended workspace boundary and interact with resources on the host system.

The more severe issue, tracked as CVE-2026-77179, affects Docker Sandboxes versions 0.28.0 through versions before 0.42.0 on macOS and is rated Critical. Docker fixed the vulnerability in Sandboxes 0.42.0, released September 7. The company disclosed the security issues publicly on September 15.

Docker Sandboxes are designed to give AI coding agents their own microVM environment where they can execute code, install packages and use development tools without directly accessing the host. The security architecture treats the microVM as the primary trust boundary, with the agent receiving full control, including "sudo", inside that environment. Resources such as a developer's project directory are selectively exposed across the boundary.

The problem in CVE-2026-77179 occurs in the virtio-fs host server, which handles filesystem sharing between the macOS host and the sandbox. Docker said the component could follow a symbolic link when reopening an unlinked file through a previously stored pathname.

A malicious process inside the VM could exploit this behavior by changing a parent directory into a symbolic link after the original path had been accepted. When the host subsequently reused the stored path, the operation could be redirected to a different location outside the authorized workspace.

This creates a path traversal condition across the VM boundary. Docker said an attacker could consequently read or modify arbitrary host files available to the account running the virtual machine monitor. Depending on what files can be changed, the access could potentially be turned into host-side code execution.

The requirement for malicious code to already be executing inside the sandbox does not eliminate the security concern. Docker Sandboxes are intended to contain precisely the type of untrusted code that an autonomous coding agent might encounter through a compromised repository, malicious dependency, poisoned package or manipulated instruction. If that code can alter host-visible filesystem paths, the microVM's isolation boundary becomes vulnerable at the point where the host performs the subsequent filesystem operation.

The second vulnerability, CVE-2026-79994, affects versions 0.37.0 through versions before 0.42.0. Docker rates it High with a CVSS 4.0 score of 8.7.

This issue affects the guest-to-host relay used for Unix domain sockets. The relay initially verified that a requested socket was located inside an authorized workspace, but later established the connection by using the pathname again. A malicious guest could change an intermediate directory into a symlink during that interval, causing the host to connect to an AF_UNIX socket outside the permitted workspace.

The vulnerability is classified as a time-of-check to time-of-use (TOCTOU) race condition, because the security decision is made against a pathname whose meaning can change before the privileged operation occurs. The resulting connection could expose data or host-side capabilities provided by the targeted socket.

Together, the two flaws expose different host interfaces through a similar underlying weakness: trusting a pathname after an attacker-controlled environment has had an opportunity to alter what that pathname resolves to.

The risk is amplified by how Sandboxes share development workspaces. Docker says "sbx run" normally mounts the current directory into the sandbox with read-write access, meaning an agent can directly modify the developer's working tree. Docker also warns that files such as Git hooks, CI configuration, IDE task definitions and project scripts can affect subsequent host-side development activity.

For users unable to update immediately, Docker recommends clone mode and advises against additional read-write host mounts. Clone mode mounts the repository read-only at "/run/sandbox/source" while the agent works from a private clone inside the VM. However, it is not a confidentiality boundary: files available in the mounted repository, including untracked files such as ".env", may still be readable by the agent.

Docker has reported no exploitation of either vulnerability. Neither issue was listed in CISA's Known Exploited Vulnerabilities catalog at the time of disclosure.

The company credited Oren Yomtov of accomplish.ai with discovering CVE-2026-77179 and Jurre van Bergen of ThreatNotify with finding CVE-2026-79994.

The fixes arrived amid wider security scrutiny of AI coding environments. Earlier research from Cyera Research Labs demonstrated how a prompt-injected coding agent operating inside a Docker-based environment could be used as part of an attack chain against the host through a separate Docker Engine vulnerability. The latest disclosures reinforce the importance of treating autonomous coding agents as potentially hostile workloads, even when they are placed inside purpose-built isolation mechanisms.

Users running affected Sandboxes versions should upgrade to 0.42.0 or later. Docker Sandboxes 0.43.0, released September 15, is the latest stable release as of September 18.

Acronis Discloses Actively Exploited Privilege Escalation Bug in Its cPanel Backup Plugin

 




Acronis has confirmed that attackers are actively exploiting a high-severity security flaw in its backup plugin for cPanel and WebHost Manager (WHM), urging system administrators to install available patches without delay.

The vulnerability, tracked as CVE-2026-87886 and rated high severity, allows local privilege escalation through insecure file permissions. Classified under CWE-276 (incorrect default permissions), the flaw affects Linux-based installations of the Acronis backup plugin and, if exploited successfully, could allow a threat actor to compromise system confidentiality, integrity, and availability. 

The flaw received its CVE designation on Tuesday, September 16, after Acronis quietly published a brief initial advisory over the weekend. The company assigned it a CVSS severity score of 7.8.


What the Plugin Does

To understand the risk here, it helps to know what this software actually sits on top of. The Acronis Backup plugin for WHM and cPanel gives hosting providers and web professionals cloud backup capabilities and granular, self-service recovery for end clients, including the ability to back up an entire cPanel server to cloud storage. 

Acronis is a cybersecurity and data protection technology company that is popular among web hosting providers and managed service providers, since its platform lets them offer backup and security to their clients under their own branding. Its backup add-ons connect cPanel and Plesk to Acronis' cloud infrastructure, letting administrators back up and recover sites, databases, and mailboxes. 

That puts the plugin in a particularly sensitive position on any server it runs on. An attacker who can escalate privileges inside this kind of environment has a direct path to the backup data of every customer account on that server.

The market footprint here is worth noting. According to the 2026 Web Hosting Trends Report by WebPros, cPanel/WHM leads the hosting control panel market with 64% adoption, while Plesk accounts for 31%. Both platforms are affected by this vulnerability, though active exploitation so far appears confined to cPanel and WHM deployments. 


How the Attack Works

CVE-2026-87886 stems from insecure file permissions and allows authenticated attackers to achieve local privilege escalation without any user interaction. The vulnerability's CVSS string indicates that it can be exploited in low-complexity attacks, meaning the attack does not require special conditions or circumstances beyond the attacker's control to succeed. 

In plain terms: an attacker who already has a low-level foothold on a vulnerable Linux server running this plugin can use this flaw to climb to higher privilege levels, without needing to trick a user or wait for any specific system event. Depending on the access gained, this could allow sensitive data to be accessed or modified and could potentially disrupt the server. 

The type of data at risk includes backup data, system files, and customer account data. 


Targeted Attacks, Limited Disclosure

Acronis' advisory language around the exploitation is measured but direct. The company stated that "exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel and WHM deployments." 

However, the disclosure comes with some important caveats. BleepingComputer reported that Acronis based that assessment on a single report from a potentially affected customer. That is enough to justify urgent patching, but it is not the same as evidence of broad, automated exploitation across hosting providers. 

There are currently no signs of active exploitation on Plesk deployments. Still, the extension for Plesk remains vulnerable and should be patched regardless. 

Acronis has not published detailed technical information about the flaw, saying it wants to give system administrators time to apply available patches before sharing further details. The company has also identified no specific indicators of compromise and has not disclosed when the activity occurred or what attackers achieved beyond the privilege escalation impact described in the advisory.


What Needs to Be Patched

Acronis pushed out security updates for the affected plugins before the CVE was formally assigned. The versions administrators need to be on are:

Acronis Backup plugin for cPanel and WHM builds earlier than 1.9.3.1021, now fixed in version 1.9.3 HF3, and Acronis Backup extension for Plesk builds earlier than 1.8.11.638, fixed in version 1.8.11. 

For shared hosting providers, the guidance is to check every server image and automation path, rather than assuming the version on one control-plane node represents the entire fleet. Once patched, administrators should also focus review on systems where initial access was plausible: servers hosting compromised sites, accounts with recent credential resets, and hosts that allow customers to upload or execute code. 

One additional note worth flagging: a cPanel or Plesk server without the Acronis plugin or extension is outside the scope of CVE-2026-87886. This is an Acronis integration issue, not a blanket advisory for every cPanel, WHM, or Plesk installation. 


Acronis is a Swiss cybersecurity company headquartered in Schaffhausen and operates a global network of cloud data centers, supporting over 20,000 service providers that protect approximately 750,000 businesses worldwide. That scale makes vulnerabilities in its hosting integrations a high-priority concern for the managed service provider community, where a single compromised server can cascade into customer data across dozens or hundreds of accounts. 

The company has not indicated whether it plans to release a more detailed post-mortem on the exploitation activity once patching rates improve, which is a common practice after actively exploited flaws. For now, the immediate priority is getting affected installations onto the fixed builds before whatever foothold attackers have found gets wider use.

A $159 Circuit Board Just Broke Cloud Computing's Strongest Security Guarantee

 




Security researchers have found a way to defeat the memory protections that Intel and AMD sell to cloud customers as their last line of defense against an untrusted host. The tool required costs less than a decent pair of headphones.

A team from KU Leuven, ETH Zurich, Durham University, and Google published details Sunday of an attack called DDRop, which exploits a fundamental design flaw in the memory encryption hardware powering confidential computing services at Amazon, Microsoft, and Google. It breaks protections in Intel Trust Domain Extensions (TDX), Intel Scalable SGX, and AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP), the three technologies that allow cloud customers to run workloads that even the cloud provider cannot read.

The method does not require a software exploit. It requires a small custom-built circuit board, a brief window of physical access to the server, and knowledge of how DDR5 memory commands work. The researchers built their device for $159 in parts.


The Gap Nobody Patched

Confidential computing encrypts a server's working memory at all times. Even a cloud provider's own administrator sees only scrambled data. The problem DDRop exposes is that encryption is not the same thing as freshness. The processor can confirm that data in memory is encrypted. It cannot confirm that data is current. Stale data, so long as it was encrypted legitimately at some point in the past, will still decrypt correctly and raise no alarm.

DDRop turns that gap into an attack. A small interposer board sits between the processor and a DDR5 memory module. When the attacker wants to cancel a specific memory write, the interposer forces a parity error on the command bus. The memory module silently discards the write. The interposer then cuts the wire used to report that error, so the processor is never notified. Old data stays in memory. The system has no way to know the latest update never arrived.

This is the first active interposer attack to run on DDR5 at full bus speed. Earlier DDR5 research required slowing the memory bus down and could only listen passively. Previous active attacks that altered memory contents only worked on older DDR4 hardware, DDR5's redesigned command format blocked them. DDRop routes around that entirely by dropping writes rather than redirecting them.


What the Researchers Pulled Off

On an Intel TDX server, the team demonstrated four outcomes. By dropping writes to page tables during setup, they mapped an attacker's virtual machine onto any physical memory address, then read a victim machine's private memory in full. They also flipped a victim machine into debug mode, copied its memory in plaintext, and restored everything afterward with no trace of tampering.

The most consequential result was attestation forgery. Attestation is the mechanism a hospital or bank uses to verify that the virtual machine handling their data is the one they approved and has not been altered. With DDRop, an attacker's machine can pass that check as though it were a trusted one. A customer could be convinced they are talking to a secure, verified environment when they are not.

On AMD SEV-SNP, results were narrower the researchers copied the contents of one victim memory page into another but the underlying exposure is the same. Neither platform checks whether memory is fresh.


No Patch, No Timeline

Both Intel and AMD acknowledged DDRop through coordinated disclosure before publication and issued security advisories on September 14. Neither offered a mitigation timeline. Both drew the same line: because the attack requires physical access, it falls outside their published threat model for confidential computing. Intel said it will not assign a CVE.

The researchers are direct about why a software fix cannot solve this. The freshness check was deliberately left out. Scalable memory encryption trades freshness for the ability to protect the large amounts of memory that cloud servers require. A lasting fix would need new memory-encryption hardware capable of providing both integrity and freshness at scale. Intel has discussed a future proposal called cache-line versioning, but has not committed to a timeline and researchers say it is unclear whether it would stop DDRop anyway.

Short-term software measures restricting the memory management interfaces DDRop abuses, checking that critical writes completed, scanning for interposers at boot, can raise the bar without removing the root cause.


The researchers have no evidence DDRop has been used outside a lab. But the significance is what it proves is possible. Confidential computing is the technical promise that certain workloads stay private regardless of who owns the physical hardware. DDRop shows that promise has a physical boundary that can be crossed with $159 in components, a few minutes of access, and knowledge that a rogue data center employee, supply chain tamperer, or government compulsion order could all plausibly provide.

The full paper is scheduled for presentation at ACM CCS 2026 in November. Hardware designs, firmware, and proof-of-concept code are already on GitHub.

Google Just Patched a Chrome Security Flaw That Hackers Were Already Exploiting



Before getting into the specifics, it helps to understand what makes this kind of vulnerability different from a regular software bug.

A "zero-day" is a security flaw that attackers find and exploit before the software maker has had a chance to fix it. The name comes from the fact that the developer has had zero days to respond. By the time a patch is released, real damage may already be happening somewhere.

In this case, Google confirmed in a security advisory that "an exploit for CVE-2026-87491 exists in the wild," meaning someone built a working attack tool using this flaw and used it. Google has not said who was targeted, how many people were affected, or who was behind the attacks.

The vulnerability sits inside a part of Chrome called V8, the component responsible for running JavaScript on every webpage you visit. JavaScript is the programming language that powers most of the interactive features on the modern internet, from buttons and forms to video players and live chats. V8 runs all of it, on every tab you open, on every website you visit.

The specific flaw is what security researchers call an out-of-bounds write. Think of it this way: imagine a program is given a box that holds exactly ten items. This bug lets an attacker force the program to keep placing items into that box even after it is full, pushing data into the digital space next to it. In a browser, that neighboring space holds other sensitive information and instructions. Corrupting it gives an attacker the ability to take control of what the browser is doing.

What makes this especially concerning is how simple it is to trigger. According to the National Vulnerability Database, an attacker just needs to get a target to visit a specially built webpage. That could come through a phishing link in an email, a malicious advertisement on a legitimate website, or a compromised page the victim had no reason to distrust.


A University Student Found the Flaw

The vulnerability was discovered by Jihyeon Jeong, a research intern at Seoul National University's Compsec Lab in South Korea, who reported it to Google on August 6. Google rewarded Jeong with a $2,500 bug bounty for the responsible disclosure and began working on a fix.

The patch arrived on September 8, roughly 33 days after it was reported. During that window, someone else was apparently already using the flaw in real attacks. Whether attackers found the bug on their own or learned about it another way is something Google has not publicly addressed.


The US Government Is Treating This Seriously Too

The Cybersecurity and Infrastructure Security Agency, the federal body responsible for protecting US government systems from cyber threats, added this vulnerability to its official list of Known Exploited Vulnerabilities on the same day Google released the fix.

That listing comes with a hard deadline: federal civilian agencies must apply the patch by September 23, 2026. While that mandate only formally applies to government networks, companies and organizations across the private sector regularly use CISA's list as a guide for their own patching priorities. When CISA flags something as actively exploited, most security teams pay attention regardless of their sector.


This Is the Second Chrome Attack in Less Than a Week

Just five days earlier, on September 3, Google fixed a different Chrome vulnerability that was also being exploited in active attacks. That flaw, tracked as CVE-2026-85046, was also inside V8. Two exploited vulnerabilities in the same component of the same browser, patched within five days of each other.

Across all of 2026, seven Chrome flaws have now been confirmed exploited in the wild and patched. Three of those seven were inside V8 specifically. For comparison, Google patched eight Chrome zero-days across the entire 12 months of 2025.

Why does V8 keep coming up? Because it is one of the most attractive targets available to an attacker. It processes code from every website a person visits, it is extremely complex under the hood, and the programming language it is built in does not have built-in protections against the kind of memory errors that lead to these vulnerabilities. For sophisticated attackers, finding a flaw in V8 is like finding a master key.


Monday's Update Fixed 230 Security Flaws Total

The zero-day was not the only problem addressed in Monday's release. Chrome 153 fixed 230 security vulnerabilities in total, five of which were rated critical. Four of the critical issues were in WebGL, the part of Chrome that handles 3D graphics in the browser. A fifth critical flaw was found in the Cast component, which handles streaming to devices like Chromecast.

Interestingly, one of the high-severity bugs in the same update was credited to OpenAI Codex Security, an AI-powered security tool, suggesting that artificial intelligence is increasingly being used to find browser vulnerabilities alongside human researchers.

Google said it internally identified 195 of the 230 total flaws through its own security tools before they could be found and exploited by outsiders.


How to Update Chrome Right Now

Google's update will reach most users automatically over the coming days or weeks, but given that this flaw is already being exploited, waiting for the automatic rollout is not the right call.

Here is how to force the update immediately:

1. Open Google Chrome

2. Click the three dots in the top right corner of the browser window

3. Select Help, then click About Google Chrome

4. Chrome will automatically check for and download any available update

5. Once it finishes, click Relaunch to complete the installation

The safe versions are 153.0.8010.36 or higher for Windows and Linux, and 153.0.8010.37 for Mac. If your browser already shows one of those numbers on the About Chrome screen, you are protected.


Google has not named who was behind the attacks exploiting this vulnerability. In past years, Chrome zero-days have been linked to commercial spyware makers and government-backed hacking groups. For now, the company says it is keeping details about the attacks restricted while the patch continues rolling out to users worldwide.

A New Magento Zero-Day Is Breaking Into Online Stores Right Now

 


Online stores running Magento Open Source and Adobe Commerce are being broken into through a security flaw that has no patch, no CVE number and, as of Saturday, no acknowledgment from Adobe. The company that found it says it went public before finishing its own investigation because merchants were already getting hit while it worked.

Dutch e-commerce security firm Sansec disclosed the vulnerability on September 5 and named it StyleSmuggler, saying it was releasing details early "because stores are being compromised right now." Sansec traces the first attacks to September 4, a day before it went public.

The flaw lets an attacker run code on a store's server with no login at all. Sansec says it reproduced the entire chain on clean installs of Magento Open Source 2.4.7, 2.4.8 and 2.4.9, and that every currently supported version is exposed. The first store it observed getting hit was running 2.4.6-p15, fully caught up on Adobe's July and August updates, the highest patch level Adobe offers that release line. Being current did not save it.

Adobe has said nothing so far. Its Commerce security bulletin index still shows August 11 as the latest entry, with no advisory, CVE or workaround. Its next scheduled security release lands September 8, though whether that covers this bug is unknown. Sansec has not tested the exploit against Adobe Commerce or Adobe Commerce on Cloud specifically, so those platforms remain unconfirmed rather than cleared.


Independent confirmation

Magento hosting firm Disrex Group backed up the account within a day, saying it handled two customers that were actually breached and a third that was targeted but held. One breached store was running a patch level Adobe issued back in August 2024, eight versions behind current, and was hit hours before Sansec's first blocking rules went live. Disrex posted its findings and cleanup tools to GitHub the same day, along with an unusually blunt disclaimer: the material was assembled with AI help during a live incident in a few hours, has not been peer reviewed, and some of its own commands were never actually tested against a running server.


How it works

Sansec says the attack abuses "styles properties" inside Magento's template engine to dodge normal safeguards, in two stages. First, it plants PHP code somewhere Magento itself writes, such as a failure log. Second, it triggers Magento's standard "Payment Transaction Failed Reminder" email, and the planted code runs the moment Magento builds that message internally. Nobody has to open the email, and the attack still works even if delivery fails.

Disrex's own analysis, published separately, suggests a crafted directive pushes Magento's internal classes into running code meant only for its command-line compiler tool, which then loads the very file poisoned in stage one. A dropper cycles through six system functions until one launches a process, then fetches the final backdoor. Neither Sansec nor Adobe has confirmed that specific mechanism.

Once installed, the backdoor disguises itself as a kernel process named [kworker/u:8:0] and hides its binary in the site user's home directory rather than the web root, with a cron job rewriting itself every five minutes in a way that dodges typical crontab logging. On one victim it read session data straight out of the store's own Redis database rather than contacting outside infrastructure; on another it reached command-and-control servers matching Sansec's published indicators.


No fix yet

With Adobe silent, defenses are all third-party stopgaps. Sansec recommends disabling GraphQL entirely unless a store runs its Shield product, though that breaks headless and progressive-web-app storefronts. Disrex, a developer known as ProxiBlue, and a firm called Graycore have each released community patches or firewall rules targeting different points in the chain, but all three call their own work partial hardening, not a real fix. Disrex also found attackers could dodge its firewall rule simply by moving parameters into a POST body.

Two settings that don't depend on understanding the exploit at all: disabling the PHP function proc_open, which one dropper used after other functions were already blocked, and mounting temporary directories with the noexec flag so a downloaded binary cannot run. For stores already compromised, guidance calls for preserving evidence first, killing the process before removing its cron job, never rebooting since the only surviving copy of the binary may live only in memory, and rotating every credential in the store's environment file rather than trusting a scan alone. One security firm's own detection scanner reportedly missed the backdoor entirely on a store where it was actively running.

Two hosting providers said this week they were reviewing their environments as a precaution, though neither has confirmed a breach. No group has been tied to the campaign, and the number of affected stores overall is still unknown.

ServiceNow Patches Three Critical Code Injection Flaws Rated CVSS 10.0




ServiceNow has released security updates addressing four vulnerabilities in its AI Platform, including three critical flaws rated 10.0 out of 10 under CVSS v4. The vulnerabilities could enable attackers to execute arbitrary code, manipulate platform data, escalate privileges, or directly interact with the underlying database.

The affected platform is used to support enterprise workflows and AI-powered applications. ServiceNow says 85% of Fortune 500 companies rely on its platform, making vulnerabilities that cross application and data boundaries particularly relevant to enterprise security teams.

The most severe issue, tracked as CVE-2026-18885, is a code injection vulnerability in the GraphQL Composite Data API. Under certain conditions, an attacker without authentication could execute arbitrary code within the ServiceNow platform and gain access to, or alter, instance data beyond the permissions intended by the platform. The CVE record credits Adam Kues of Assetnote with discovering the vulnerability.

CVE-2026-18886, also rated CVSS 10.0, involves improper access controls in the system configuration image upload processor. The flaw could allow an unauthenticated user, under certain circumstances, to create or modify instance data and subsequently escalate privileges. Kevin Gervot of Assetnote is credited as the vulnerability's finder.

The third maximum-severity issue, CVE-2026-74820, is an SQL injection vulnerability. An attacker could exploit the weakness to submit arbitrary SQL statements to the underlying ServiceNow database, potentially exposing or modifying instance information outside the access boundaries established by the platform. The CVE record classifies the flaw as CWE-89, or improper neutralization of special elements used in an SQL command.

All three critical vulnerabilities have network attack vectors, low attack complexity, require no privileges and require no user interaction according to their CVSS v4 metrics. CISA's vulnerability enrichment also currently categorizes the three as automatable with total technical impact, while their records state that no exploitation has been observed.

The fourth vulnerability, CVE-2026-6876, carries a CVSS v4 score of 8.7 and concerns a sandbox escape in the Now Platform. Successful exploitation could allow code execution within the platform and provide an attacker with more access than intended. The published CVSS vector lists low privileges as required and no user interaction, so security teams should assess the flaw according to their deployment and access configuration rather than treating it as identical to the three unauthenticated CVSS 10 vulnerabilities.

ServiceNow has applied security updates to its hosted instances and made fixes available to partners and customers operating self-hosted deployments. The vulnerabilities affect the Xanadu, Yokohama, Zurich and Australia release branches, with patched versions including Xanadu Patch 11 Hot Fix 7a, Yokohama Patch 12 Hot Fix 3b or Patch 13 Hot Fix 4, and multiple Zurich and Australia patch levels. Administrators should compare their exact instance version against ServiceNow's advisory before considering remediation complete.

The urgency is particularly relevant for organizations managing ServiceNow themselves. Unlike vendor-hosted environments where ServiceNow can deploy security updates directly, self-hosted customers must identify the affected release, obtain the appropriate hotfix and complete their own change and validation process.

Security practitioners have also warned that this remediation gap can provide attackers with an opportunity to target newly disclosed enterprise vulnerabilities before organizations complete their patch cycles. Jason Brown, director of counter-fraud operations at iCOUNTER, urged organizations running self-hosted ServiceNow deployments to treat the fixes as an immediate priority rather than waiting for their routine maintenance window.

ServiceNow has advised customers to apply the available updates promptly. The company also states that it is not currently aware of malicious exploitation of these vulnerabilities, but the combination of remote attack paths, code execution and access to enterprise data makes rapid remediation important while public information about the flaws remains limited. 

FBI Disrupts QTFY Hacking Network Targeting U.S. Organizations




The U.S. Department of Justice (DoJ) and Federal Bureau of Investigation (FBI) have disrupted two hacking platforms operated by a China-linked threat group that were used to conduct reconnaissance, compromise vulnerable systems and conceal attacks against U.S. government agencies, critical infrastructure and other sensitive organizations.

The platforms, QScan and QTRouter, have been attributed to QTFY, a Chinese state-sponsored hacking group linked to Nanjing Xinjiuwei Network Technology Company. According to U.S. authorities, QTFY activity has targeted organizations including NASA, the Federal Reserve, Department of Energy, Department of Justice, Department of Health and Human Services, National Institutes of Health and the U.S. Senate.

Lumen Black Lotus Labs, which tracked the infrastructure for more than 18 months, said QTFY activity dates back to at least May 2018. The researchers described the group as an infrastructure "quartermaster" that developed reusable systems for reconnaissance, exploitation and traffic obfuscation.


QScan automated reconnaissance and exploitation

QScan formed the reconnaissance component of the operation. The platform scanned internet-connected systems and IoT devices for vulnerabilities before automatically compromising susceptible devices and incorporating them into the QTRouter network.

The FBI said QScan was also used to identify vulnerabilities in victim networks. Its infrastructure included servers responsible for distributing scanning tasks to worker nodes and collecting completed results.

The scale of the operation allowed QTFY to conduct reconnaissance across large numbers of systems. Lumen identified scanning activity spanning more than 130 countries, with targets including government, defense, aerospace, healthcare, financial, energy and research organizations.


QTRouter concealed attackers' origins

Compromised devices identified through QScan were subsequently used by QTRouter as proxy nodes. The network combined hacked IoT devices with commercial proxy services and leased virtual private servers (VPSs), allowing malicious traffic to pass through multiple intermediary systems.

This architecture made an intrusion originating from China appear to come from an internet connection located elsewhere. In some cases, QTRouter could route traffic through systems geographically close to the targeted organization, making the activity appear more consistent with legitimate local traffic.

QTRouter operated on routers running customized OpenWrt software and used the Clash proxy framework to establish connections. Operators could select available nodes and chain them together, creating multiple layers between themselves and their targets.

The FBI said this combination of compromised IoT devices and legitimate commercial proxy infrastructure made malicious traffic difficult to distinguish from normal internet activity.


Attackers exploited new and older vulnerabilities

QTFY's attack chain involved both recently disclosed and long-standing vulnerabilities. The vulnerabilities identified by investigators included flaws in Ivanti Connect Secure, Fortinet SSL-VPN, Citrix ADC, Microsoft Exchange Server, F5 BIG-IP, Kentico CMS, Apache Log4j, Atlassian Confluence, Check Point Quantum Gateway, CrushFTP and BeyondTrust Remote Support.

After obtaining initial access, QTFY actors used remote access trojans, web shells and legitimate credentials to maintain persistence.

The infrastructure could subsequently provide concealed access into victim networks through nearby compromised IoT devices. QTBotnet also allowed operators to control infected systems, execute commands and conduct distributed denial-of-service attacks.


Four-part infrastructure supported QTFY operations

Lumen identified QScan and QTRouter as part of a larger architecture that also included Fast Labyrinth and QTProxy.

Fast Labyrinth incorporated commercial proxy infrastructure into encrypted relay paths, while QTProxy managed operational nodes and allowed operators to configure routes toward selected targets.

The researchers compared the architecture to an operational relay box, or ORB, network. Such systems use compromised devices and leased infrastructure as rotating relay points, making traditional IP blocklists and location-based defenses less effective.

Lumen said the infrastructure demonstrated an increasingly industrialized model of China-linked cyber operations, in which reusable and shared services can provide reconnaissance and anonymity at global scale.


FBI seized domains used by the platforms

The disruption targeted domains hard-coded into QScan and QTRouter, including infrastructure used to distribute scanning tasks and administer proxy connections.

By seizing these domains through court-authorized action, U.S. authorities disrupted communication between the platforms and their operators, causing the systems to cease functioning.

Investigators also linked QTFY to Chinese cyber-brokering networks where exploits, malware and access to compromised organizations were allegedly traded. Nanjing Xinjiuwei was described by U.S. authorities as an enabling company with relationships across China's cyber ecosystem and connections to former People's Liberation Army personnel.

QTFY activity reportedly continued into June 2026, when actors targeted a U.S. election system.

The disruption demonstrates how China-linked threat actors are increasingly relying on distributed infrastructure rather than fixed attacker-controlled servers. While domain seizures can interrupt an operation, the reuse of compromised IoT devices, commercial proxies and leased servers means defenders will need to monitor behavior and network relationships rather than rely solely on static IP-based blocking.