Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label Cyber Security. Show all posts

DoppelCart Fake-Shop Network Found Operating Across 119,000 Domains

 

A newly published investigation has uncovered what may be the largest documented fake-shop network to date, spanning roughly 119,000 domains and dubbed "DoppelCart" by researchers at nebty. The cluster's .shop domains alone account for 2.72 percent of the entire .shop domain population captured in a September 2026 snapshot — roughly one in every 37 domains registered under that extension. 

The investigation, led by Benedikt Scheungraber and published September 7, began not as a large-scale probe but as routine work handling individual customer complaints. Researchers found fake shops targeting several clients and arranged for their removal, but noticed the same infrastructure patterns recurring across unrelated takedowns and monitoring cases. Using publicly accessible website scans from urlscan, the team began connecting domains and quickly realized the scale far exceeded a handful of isolated scam sites — eventually tracing around 119,000 associated domains back to a single technical foundation dressed up as countless different brand identities. 

To put the discovery in context, researchers compared it to other publicly documented fake-shop networks. BogusBazaar, reported by SRLabs in 2024, spanned more than 75,000 domains over several years, with about 22,500 active at any one time. FraudWear, documented by CTM360 in 2026, involved over 30,000 domains with roughly 8,000 simultaneously active. Malwarebytes identified a cluster of more than 20,000 domains in March 2026, while Netcraft's Fibergrid investigation found 16,700 active fake shops on connected hosting infrastructure in April 2026. 

DoppelCart's scale surpasses all of these prior cases. What makes the fake shops convincing, according to the investigation, is their use of genuine material lifted from real businesses. Examined storefronts featured product descriptions copied word for word from legitimate online stores, including detailed explanations of product features and construction. In some cases, the fake sites even embedded images directly from the legitimate brand's own image servers, pairing authentic-looking product photos with advertised discounts of 65 percent to create a convincing illusion of a genuine sale. 

The fallout lands squarely on the copied businesses. Because many fake shops list the legitimate store's real support address, customers who never receive their orders end up contacting the authentic company, forcing its support staff to untangle orders they never placed or received payment for — all while trust in the real brand suffers. 

To help affected companies respond, the researchers are publishing the full investigation database, allowing businesses to search for their own brand name or domain and review classifications and evidence for each entry. Journalists and security researchers can request the underlying raw data, including archived HTML pages, by contacting the team directly. While takedowns pursued so far have kept removed stores offline, the majority of the DoppelCart cluster reportedly remains active.

LG Targets Residential Proxies in New Smart TV Security Move



Several webOS apps using residential proxy technology are being suspended by LG Electronics for routing third-party traffic through smart TVs. The company is working with developers to remove proxy functionality, and apps that fail to do so will be suspended. According to research conducted by security firm Spur, residential proxy software is embedded in a significant number of LG and Samsung smart TV apps. 

A proxy SDK was identified in 2,058 of 6,038 examined applications, raising concerns about how television owners' internet connections may be exploited without clear awareness of the activity. As a result of the study, more than 42% of LG webOS apps examined contained residential proxy functionality, while 26.5% of Samsung Tizen apps did not. As a result of such software, a device's connection to the internet and public IP address can be used as part of residential proxy networks. 

Web data collection, advertisement verification, optimization monitoring and market research are some of the legitimate business uses of residential proxies. However, the same infrastructure can also be misused for the purpose of concealing malicious activity. Recent takedowns of large residential proxy networks have demonstrated the dangers associated with the use of compromised consumer devices as proxy nodes. 

A particular concern is associated with smart TVs because proxy software can continue to operate while connected to the internet. According to Spur researchers, unclear consent mechanisms can lead users to be unaware that their connection has been shared with other parties or that their IP address may be exposed to third parties. 

In a statement provided by LG Senior Vice President John Taylor, the company is working with developers to eliminate the residential proxy option from webOS applications. While the company has not provided a specific deadline for developers, apps that retain the functionality will be suspended. In Spur's research, some SDKs remain active after the associated TV app has been closed, making the concern even more serious when the proxy is running in the background. 

Some applications are presented as alternatives to advertisements using the TV's internet connection. This model allows apps to remain ad-free and utilize the internet connection to perform activities such as web indexing while using the television's internet connection as an alternative to advertisements. This model poses a security risk that goes beyond exposing the household IP address. 

A smart TV is connected to a local network that includes routers, printers, cameras, and storage units. It is possible for the TV to provide a path to other systems on a network if proxy traffic is permitted to reach private network addresses or if filtering mechanisms are not effective. Spur's analysis also observed different implementations of proxy SDKs that enforce these boundaries. 

In the sample of Bright Data, restrictions were established for private and reserved IP ranges; however, comparable protections were not observed for the local versions of Massive and Honeygain/Oxylabs SDKs examined. It is therefore necessary to rely heavily on filtering on the provider's end, customer screening, and abuse controls to prevent this type of misuse. The wider platform policies add another level to this problem. 

While Amazon explicitly prohibits the use of proxy services for third parties, Roku has also been reported to restrict similar software. LG and Samsung previously did not institute a public restriction that would prevent proxy-enabled applications from using their TV platforms. Instead of relying solely on store descriptions or permission prompts, the research involved an analysis of actual LG webOS and Samsung Tizen application packages.

A team of researchers analyzed the applications to confirm fingerprints associated with residential proxy SDKs, such as Bright Data, Massive, and Honeygain/Oxylabs components, and has denied the suggestion that proxy networks are intrinsically unsafe. The data provider mentioned consent, customer vetting, and governance measures, whereas Massive stated that their network employs KYC checks, server-side controls, and consent checks. 

In addition, Oxylabs said it implements filtering and local-network restrictions using both infrastructure and SDK-level controls. However, LG's issue is now more complex than the removal of individual applications alone. Through its scheduled review of webOS apps, the company may determine whether residential proxy functionality is subjected to greater scrutiny during the approval process for the platform's apps. 

As a result of this change, smart TV applications are also required to disclose background network activity and obtain consent for services that continue to operate after an app is closed. It is LG's intention to take action on its planned plans that illustrates the need for clearer disclosures, stronger app review policies, and effective controls surrounding residential proxy services.

Ransomware Affiliate Pretends to be Recovery Service for Extortion


An alleged ransomware affiliate is pretending to be a ransomware recovery service named “Ransom Busters,” reaching out to victims before the attacks become public and claims it can delete stolen data and provide decryption keys for some fees.

Fake ransomware recovery service

The activity was discovered by GuidePoint Security’s Research and Intelligence Team (GRIT) after it responded to various cases where targets got emails apparently from Ransom Busters, contacting to provide help in recovering from the ransomware attack. 

This seems suspicious because cybersecurity firms usually contact ransomware victims to offer recovery services or consulting after the attack has happened and becomes public knowledge. But in this case, Ransom Busters’ knowledge about the attack that was not yet public raises questions.

GRIT believes Ransom Busters to be working across various ransomware operations, and have taken a new extortion approach. 

The group contacted victims via emails, requesting to get in touch with their CEO or IT leadership. 

According to GRIT, the email said “I am a representative of a project that assists victims of cyberattacks. We have been identifying vulnerabilities and infiltrating the servers of criminal groups for over three years. On the server we recently accessed, we discovered data stolen from your company [...] We can return your files to you and destroy all backups held by the group. Additionally, we have gained access to the encryption key storage and can help you regain access to your encrypted files.”

Extortion tactic

In the communications after this mail, Ransom Busters said they found the flaws in the admin panels of various ransomware-as-a-service (RaaS) operations. It offered to remove the stolen data from ransomware servers such as Settra, DragonForce, and Anubis, for a fee of $20,000 to $60,000.

But evidence from the two incidents has led GRIT to suspect that Ransom Busters is the group responsible for the attacks.

In both incidents, the threat actors used the same software such as s5cmd, Remotely remote monitoring tool, and SoftPerfect Network Scanner. The group also used the same approach to create a local backdoor account via the same threat actor-controlled hostname 'DESKTOP-BBETH6K' and password Numlock!123'. 

The attacker claimed this access gave them command over “almost all of their infrastructure,” according to GRIT. The aim of Ransom Busters seems to be financial, like other RaaS groups.

Impact on ransomware victims

Ransomware groups such as Ransom Busters cannot be trusted as they use deceptive tactics for extortion payments. In these incidents, it is observed that even payments to these gangs does not guarantee recovery of stolen data and if it will be deleted. If your organization receives such mails, it should be immediately reported to the response team.

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.

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.

1 Folder Was All It Took: Security Researchers Find AI Coding Agents Can Be Hijacked Before a Single Prompt Is Typed




Opening a folder should not be a security event. For users of at least seven popular AI coding agents, until recently, it could be one. A newly documented set of vulnerabilities, tracked under the name GitSpawn, shows that pointing an AI coding assistant at a project folder was enough to hand an attacker code execution on the developer's own machine. No prompt had to be typed. No permission dialog had to be clicked. In some cases, the user had not even logged in yet.

The affected tools include Anthropic's Claude Code, OpenAI's Codex, Cursor, Block's Goose, Nous Research's Hermes Agent, Alibaba's Qwen Code, and xAI's Grok Build. These products sit on an enormous number of developer machines. Claude Code's npm package sees more than 77 million downloads a month. The tools examined most closely in the disclosure carry a combined GitHub following approaching half a million stars. This flaw reached deep into the software supply chain.


What actually happens when you open a folder

An AI coding agent needs context the moment it launches inside a project: what branch is checked out, which files changed, what the codebase looks like. The fastest way to get that information is to ask git, the version control system nearly every software project runs on. So these agents run background commands like `git status` or `git diff` as soon as a folder opens, often before the assistant has said anything to the user.

That part is normal. The danger sits in a git feature called `core.fsmonitor`, a performance setting built to let large repositories speed up status checks by handing file-change detection to an external helper program instead of scanning every file each time. Git learns which helper to run by reading the repository's own configuration file, `.git/config`. That file ships with the project. It does not live on the user's machine.

Anyone who builds a repository controls that file, which means anyone who builds a repository can set `core.fsmonitor` to run whatever command they want. Nearly every git command that touches a project's working files triggers something called an index refresh, and that refresh is what reads the setting and runs it. So the moment an AI coding agent runs an ordinary git command inside a booby-trapped folder, git executes the attacker's command on the developer's machine, under the developer's own account. Because the agent's own code is making that subprocess call rather than something routed through its interface, none of the approval prompts or sandboxing built into these tools ever sees it happen.

There is a limit worth knowing. A standard `git clone`, `fetch`, or `pull` will not trigger this, because those operations do not carry the repository's local configuration along with them. The malicious repository has to reach a victim as a set of files with its `.git` directory already inside: a zipped folder sent over email, a shared drive, a synced folder, a USB stick passed at a meeting. Developers, contractors, and consultants hand off projects this way constantly, which is what makes the delivery method plausible.


Which vendors fixed it, and which did not

Eight distinct findings were reported privately across the seven agents before this went public. Four of them were still unpatched at the time of publication.

Goose, maintained by Block, shipped a fix in version 1.44.0. The issue was catalogued as CVE-2026-72718, with a severity score of 7.0. Cursor and OpenAI's Codex both carried variants of the same flaw and have since patched them, though in both cases the vulnerability had already reached the vendors through other researchers' independent reports. Anthropic fixed the core.fsmonitor path in Claude Code with version 2.1.196. A second issue in the same product, tied to the `claude ultrareview` command and a different git configuration key, was still working as of version 2.1.252 at publication time. That configuration key has not been made public while the issue stays open, so as not to hand out a working template.

Two vendors had shipped nothing. Alibaba's security response center accepted the report on Qwen Code but had not resolved it by publication. xAI's Grok Build remained vulnerable through version 1.0.13; an earlier, related report had been closed by the company as merely informative before this disclosure connected it to the same bug. Hermes Agent's maintainers never triaged the report despite six separate contact attempts across five channels. The flaw was eventually assigned CVE-2026-71963 by VulnCheck, an independent numbering authority that can step in when a vendor stays silent.


This bug has been seen before

The shape of GitSpawn is not new to anyone who has followed git security for a while. Independent researcher Justin Steven documented abuse of the fsmonitor hook back in 2022. Visual Studio Code built its workspace trust model in 2021 to stop untrusted folders from running code the second they were opened in an editor. AI coding agents brought a version of that same exposure back by running git commands in the background before any of those trust protections had a chance to apply.

That is the part worth sitting with. Nothing about how these models reason or respond caused this. The exploit runs entirely in ordinary software plumbing, the subprocess call an agent makes to figure out where it is, firing before any of the safeguards a user assumes are in place actually engage.


What to do about it

If you receive a project as raw files rather than through a direct git clone, whether by email, shared drive, or a USB stick, check `.git/config` before opening it in an AI coding agent or any development tool. Anything in that file that names an external program to run deserves a second look.

If you build one of these tools, the fix is narrow: disable risky configuration keys like `core.fsmonitor` on every background git call, for example by running commands with the flag `-c core.fsmonitor=false` instead of trusting whatever the repository hands you.

AI coding agents keep taking on components they did not write and did not choose: plugins, extensions, connections to outside services, most of which arrive as files carrying their own settings and get trusted the moment they load. GitSpawn shows what happens when that trust runs ahead of the checks meant to govern it. The next version of this bug probably will not look like a git command at all.

5 Million WordPress Sites Exposed to SQL Injection Vulnerability


A severe security flaw in a famous WordPress migration plugin and backup could allow threat actors to take command of over millions of sites, experts have warned.

About the security flaw

The security flaw is tracked as CVE-2026-19949, it impacts the Backup plugin and All-in-One WP Migration, which is utilized by over five million active wordpress installations. The plugin lets site owners to migrate, import, export, and backup sites, this consists of media files, themes, plugins, and databases.

As per Bleeping Computer, the flaw is a second-order SQL injection vulnerability that could permit an unauthorized threat actor to run malicious code on a compromised site. The flaw impacts variants 7.109 and earlier and has been given high severity, with a 8.8 CVSS score.

Reporting of the flaw

The vulnerability was found by security expert Jack Taylor, who reported the incident to cybersecurity company Wordfence, which investigated and disclosed the flaw. On August 15, 2026, Wordfence informed the plugin’s developer, Servmask, which released variant 7.220 on August 20 to patch the flaw. 

“On August 14th, 2026, we received a submission for an Unauthenticated Second-Order SQL Injection vulnerability in All-in-One WP Migration and Backup, a WordPress plugin with more than 5 million active installations,” Wordfence reported.

Attack tactic

Contrary to flaws that can be abused immediately, this vulnerability consists of an extra step. Threat actors first place specially tailored data on a compromised website. 

The malicious information remains latent until a website admin does a backup restoration of the archive. “This vulnerability makes it possible for unauthenticated attackers to inject SQL that is later executed when a site administrator performs an archive restore, which can be used to leak the plugin’s secret key and ultimately achieve remote code execution, leading to complete site takeover,” Wordfence said.

Misuse of malicious data

In the restoration stage, the stored malicious data can be used as SQL commands which allows threat actors to take out sensitive data from the website’s database.

An important target is the plugin’s secret ai1wm_secret_key.. If a threat actor accesses this key, it can possibly be used to move from database access to remote code execution (RCE), allowing the threat actor more control over the compromised website.

Through RCE, threat actors could install malicious code, change website files, and create backdoors.

Addressing the flaw

ServMask addressed the CVE-2026-19949 in variant 7.110 of the plugin. Users are advised to update their websites to the latest patched versions of Backup and All-in-One WP Migration.

On August 20, ServMask addressed the CVE-2026-19949 vulnerability in version 7.110 of the plugin.

Four Cybersecurity Habits That Can Do More Harm Than Good When Misused



Cybersecurity advice is often reduced to simple rules: change passwords regularly, avoid public Wi-Fi, install antivirus software and enable two-factor authentication. These recommendations were created for good reasons, but the threat landscape and the technology protecting users has changed.

The problem is not that these safeguards have become useless. Instead, rigidly following outdated versions of the advice can create false confidence, encourage risky behaviour or distract users from more effective protections.

Here are four familiar cybersecurity habits that need to be reconsidered.

1. Changing Every Password on a Fixed Schedule

For years, organizations required employees to change their passwords every 30, 60 or 90 days. The intention was to limit the amount of time a stolen password could remain useful.

In practice, frequent forced changes can encourage people to select predictable passwords or make minor alterations, such as replacing “Password1” with “Password2.” This provides much less protection than organizations may assume.

The current NIST Digital Identity Guidelines advise service providers not to demand periodic password changes unless there is evidence that a password has been compromised. NIST instead emphasizes longer passwords, blocking commonly used or compromised credentials and permitting the use of password managers.

A better approach is to give every account a long, unique password generated and stored by a reputable password manager. A password should be changed immediately if it appears in a breach, is entered on a suspicious website or may have been exposed through malware.

Where available, users should also consider passkeys, which remove the need to remember a password and provide stronger resistance to phishing. Organizations reviewing password policies should combine these protections with measures designed to secure single sign-on systems against credential attacks.

2. Treating Every Public Wi-Fi Network as Equally Dangerous

“Never use public Wi-Fi” was once common security advice. However, widespread adoption of HTTPS means that most websites now encrypt information travelling between a device and the website.

The US Federal Trade Commission says that connecting through public Wi-Fi is usually safe because most websites use encryption. Users should still check for HTTPS and remember that an encrypted connection does not prove that the website itself is legitimate. A phishing website can also use HTTPS.

Public networks continue to present risks. Attackers may create convincing lookalike networks, manipulate captive-portal login pages or target devices with outdated software and exposed sharing settings.

Instead of avoiding every public network, users should:

  • Confirm the network name with the venue before connecting.

  • Disable automatic Wi-Fi connections and unnecessary file sharing.

  • Keep the operating system, browser and security software updated.

  • Avoid proceeding past browser certificate warnings.

  • Use cellular data or a personal hotspot for especially sensitive work.

  • Follow an employer’s approved VPN requirements when accessing company systems.

A trusted VPN can provide another encrypted layer, particularly for work traffic or applications that do not protect their own connections. However, a VPN transfers trust from the local network to the VPN provider and does not prevent phishing, malware or account compromise.

3. Assuming Antivirus Software Is a Complete Security System

Antivirus software remains an important protection and should not be disabled. The outdated habit is assuming that installing it is the only step needed to secure a device.

Traditional antivirus products relied heavily on signatures that identified previously discovered malicious files. Modern security tools also use reputation checks, behavioural analysis, cloud intelligence and other methods to identify suspicious activity.

Attackers nevertheless use techniques intended to evade detection, including frequently changing malware, malicious scripts, abuse of legitimate system tools and attacks that leave few conventional files behind. Artificial intelligence may help criminals modify malicious code more quickly, but malware evasion existed long before generative AI.

CISA’s ransomware guidance recommends keeping antivirus and antimalware tools updated while also using protections such as application allowlisting and endpoint detection and response. This reinforces an important point: antivirus should be one part of a layered defence.

For individual users, that means enabling the device’s built-in or another reputable security product, installing software updates promptly, downloading applications from trusted sources and maintaining backups. Businesses should add centralized monitoring, restricted administrative privileges, application controls and tested recovery procedures.

Running multiple antivirus products at the same time is not necessarily safer. They may conflict, reduce performance or interfere with each other’s detection capabilities.

4. Believing Any Form of Two-Factor Authentication Is Unbreakable

Two-factor authentication remains one of the most effective ways to prevent account takeover, and users should enable it wherever possible. The mistake is believing that every form of two-factor authentication provides the same protection—or that it makes an account impossible to compromise.

Text-message codes and one-time passwords can be captured through phishing. Attackers may also send repeated login approval requests in the hope that a user eventually accepts one.

Another threat is session theft. After a successful login, a website generally creates a session token or cookie that allows the user to remain signed in. Malware or adversary-in-the-middle phishing infrastructure can steal this token and reuse it without repeating the original authentication process.

Microsoft explains that stolen browser cookies can bypass authentication controls. This is why infostealers that collect browser data and authentication tokens remain dangerous, as demonstrated by the growing capabilities of threats such as the REMUS infostealer.

Passkeys and physical security keys provide stronger protection against phishing because authentication is tied to the legitimate website. CISA recommends moving toward phishing-resistant MFA, especially for important or privileged accounts.

However, even passkeys cannot make an infected device completely safe. Users and organizations must also protect endpoints, monitor active sessions, revoke suspicious sessions and require fresh authentication before particularly sensitive actions.

Security Controls Must Evolve With the Threats

The lesson is not to abandon passwords, public Wi-Fi precautions, antivirus software or two-factor authentication. Each remains useful when applied correctly.

The safer approach is to replace scheduled password resets with unique credentials or passkeys, assess public networks based on the connection and activity, treat antivirus as one security layer and choose phishing-resistant authentication whenever possible.

Cybersecurity habits should evolve as attacks and defensive technologies change. A safeguard becomes dangerous when users stop examining what it protects against—and assume that it can protect them from everything.