A city-based businessman lost close to Rs 20 lakh after fraudsters hijacked his correspondence with a Dubai supplier and rerouted a paymen...
The Secure Shell (SSH) remote-access service of MikroTik routers is actively being used by attackers to access internet-exposed MikroTik routers, exploiting vulnerabilities that can grant complete administrative control without requiring authentication. A CERT Polska advisory published on September 5, stating that successful exploitation has been observed since at least September 2. The advisory also noted successful exploitation of the ongoing attacks.
In the advisory, the attackers were not identified or an estimate of how many devices had been compromised was not provided. In addition to warning of active exploitation, Costin Raiu also reported that MikroTik routers with SSH exposed may already be compromised. Known as MikroTrick, this attack chain is comprised of two vulnerabilities found in MikroTik RouterOS.
A CVSS rating of 9.2 has been assigned to CVE-2026-67276, an SSH authentication bypass vulnerability. A second vulnerability, CVE-2026-86060, allows privilege escalation within an SSH session. When combined, these flaws allow an attacker with no credentials to gain complete control of RouterOS devices that are affected by these flaws. RSA public key validation is the cause of CVE-2026-67276.
Using a legitimate username and public key, an attacker can construct a fake key that is accepted without possessing the associated private key. Once access has been gained, a privilege-escalation flaw can be used to elevate the session to administrative level control. The CERT Polska website stated that six RouterOS vulnerabilities have been identified and coordinated for disclosure, with two of these vulnerabilities involving MikroTrick.
Organizational members have observed the attack on RouterOS devices accessible directly from the Internet. MikroTik has released fixed RouterOS versions that address these vulnerabilities. CERT Polska recommends installing the appropriate security updates immediately, and reviewing router configurations for unauthorized modifications following that.
As stated in the vendor's documentation, home devices' default firewall rules normally prevent external access to management services as long as those rules are not altered. Evidence of exploitation emerged before the security fixes were widely announced. The successful attacks, including the creation of highly privileged accounts known as "ops," are believed to have begun at least at the beginning of September, CERT Polska stated.
A security researcher, Costin Raiu, noted that MikroTik released fixes on September 3, posing questions regarding whether attackers were aware of the patches before they were made public. The timeline does not conclusively establish the flaws as zero-days. In the case of the attacks, the IP address associated with Leaseweb 82.192.72.4 has been primarily linked. There was also an observation of a second address, 103.102.31.18, exploiting MikroTrick. The confirmed successful attacks originating from this address, according to CERT Polska.
A number of traces have been left in RouterOS logs. Failed exploitation attempts appear under the username “-2”, while successful activity may appear as a configuration change and SSH session. It has been confirmed that the creation of the “ops” account is related to the observed attacks. Any changes involving users, SSH keys, scripts, scheduled tasks, firewall rules, proxy servers, or tunnels should be investigated immediately. It remains difficult to determine the extent of the exposure.
Approximately 122,500 MikroTik devices exposed to the Internet over SSH were reported by ShadowServer Foundation on September 5, however this number does not reflect how many devices are vulnerable to specific MikroTik vulnerabilities. MikroTik has not disclosed the number of compromised or exploitable routers. The new RouterOS versions include a Flagged mechanism which detects signs of unauthorized configuration changes during startup of the operating system.
The system can be configured to disable suspicious entries and record a critical warning, but according to CERT Polska, the detection mechanism only detects known traces, so a router without a Flagged warning cannot be regarded as automatically clean.
Administrators unable to patch immediately should disable externally accessible SSH, WWW/WWW-SSL, and bandwidth test services or restrict access to trusted management networks. Additionally, CERT Polska recommends that unpatched devices do not make outbound TLS connections or use the built-in RouterOS SSH clients, particularly across untrusted networks. These measures are intended only to reduce exposure until the security update can be installed.
When a router shows signs of compromise, CERT Polska suggests isolating it and conserving its logs and configuration before performing a reset. When the router has been restored to factory settings, it should be rebuilt using a trusted configuration, while passwords, SSH keys, and other credentials should be rotated.
Restoring a potentially compromised backup without verifying it should never be done. It is important to note that the six vulnerabilities identified by CERT Polska extend beyond the SSH flaws, affecting areas such as bandwidth testing, certificate handling, and WebFig functionality. Among the high severity bandwidth-test flaws identified by the agency are CVE-2026-67277, which can expose kernel memory or cause a remote system crash.
The active exploitation highlights the risks of exposing router management services to the internet. RouterOS security updates should be applied by administrators, configurations should be reviewed for unauthorized changes, and affected devices should be examined for signs of compromise.
Dutch e-commerce security firm Sansec found the vulnerability, called “StyleSmuggler,” which lets threat actors run malicious code on compromised servers without needing verification. According to Sansec, it found active attacks starting on September 4,2026 and posted the information after discovering that online stores were already being targeted.
StyeSmuggler is a severe remote code execution (RCE) vulnerability impacting present Magento variants. According to Sansec, the flaw successfully reproduced the attack on Magento Open Source variants 2.4.7, 2.4.8 and 2.4.9. This includes the latest 2.4.9 release.
For people who are not using Sansec Shield, they can temporarily stop Graphql until Adobe has issued an official patch. “The next Adobe security release is scheduled for Sept 8th, but it is yet unknown if that covers this bug,” Sansec said.
The flaw is notedly troubling as threat actors don’t require any password, admin account, or a username to exploit it. A successful compromise could give attackers the power to run code directly on the server hosting an online store.
Malicious code is injected into Magento's template system by StyleSmuggler. It can get around present safety precautions by utilizing the styles features. It operates in two phases:
Threat actors exploit GraphQL and Magento’s template functionality to install malicious code, The attack can then prompt the installed code via Magento’s internal processes, in the end letting them download and run malware on the infected server.
The attack is not limited to stores running old software, which is a troubling finding.
“The first victim ran 2.4.6-p15 with the July and August 2026 patches applied and security:patch-status clean,” Sansec said. In other words, even having the latest available security updates for the released could not stop the exploit of the new zero-day.
Another group, Disrex found the exploit, a Magento hosting and development company. “One of the Magento servers managed by Disrex was compromised only 50 minutes after the first confirmed StyleSmuggler attack worldwide,” it said.
No official patch has been released at the time of writing this article.
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.