A critical vulnerability in a popular WooCommerce plugin is being actively exploited to upload malware and possibly take over entire websites, security experts have warned.
The plugin in question is called Wholesale Lead Capture Plugin for WooCommerce. It adds a dedicated registration and onboarding system for wholesale and B2B customers, letting businesses collect company and other custom information, review applications, assign wholesale user roles, and automate registration and onboarding emails.
It is a premium plugin that costs between $99 and $600 and which, according to the Wordpress store page, has more than 20,000 active installations.
The plugin was vulnerable to an unauthenticated arbitrary file-upload flaw which, as the name suggests, allows unauthenticated parties to upload arbitrary files, including PHP webshells and executable code that can result in full site takeover. It is tracked as CVE-2026-27540 and carries a severity score of 9.0/10 (critical).
Versions 2.0.3.1 and older were said to be affected. Version 2.0.3.2, released on February 20, was said to have addressed the bug, meaning the patch has been available for almost half a year. However, WordPress security outfit Defiant said its Wordfence web application firewall blocked more than 100,000 attacks, and Wordfence added that it observed two attack spikes - one between June 4 and 17, and another one between July 1 and August 30.
In these incidents, the attackers were mostly uploading reconnaissance webshells, possibly mapping out the landscape before deploying more serious malware.
“The uploaded shell.php is a PHP webshell that reports host details and provides a browser-based upload form for writing additional malicious files to the site,” the researchers said.
If you are running the plugin, it is advised you update it to the newest version as soon as possible, and check upload directories for unexpected, or recently created, PHP files.
Via BleepingComputer
Security researchers from Elastic Security Labs have discovered a new Brazilian banking malware campaign that uses browser extensions to compromise users and steal sensitive information.
In an in-depth report published earlier this week, the researchers said the campaign has been active since at least May 2025. Dubbed REF9334, the campaign uses fake banking, invoice, and business documents, to trick victims into installing malware which, in turn, deploys a malicious extension in Chrome and Edge browsers.
The researchers named the malware “Kremlin”, and say it can steal browser credentials, cookies, session information, monitor browser activity, grab screenshots, and steal information from websites that the victims visit. But the goal of the campaign is primarily to target Brazilian bank users.
The malware really makes an effort to hide and persist in the target environment. For example, it first checks to see if it’s in a sandbox and if so - it simply won’t run. If instead it determines that it’s running on a real user’s computer, it will deploy an extension with the name “AVSync System Inc.” in an attempt to trick the victim into thinking they have an antivirus addon running in the browser.
It also doesn’t use a fixed C2 server, but rather stores the information on the Ethereum blockchain, since it’s a lot harder to disrupt the communication between the operators and the infected machines that way.
During their investigation, Elastic researchers were able to take control of a domain that the malware used and discovered that it had infected 1,515 systems. Almost all of them (98%) were located in Brazil. They were also able to register the network canary domain and point it to their webhost, which resulted in the loader assuming it was in a sandbox. This also meant “the infections have not moved past the initial access”, Elastic explained.
The full list of indicators of compromise can be found on this link.
Via The Hacker News
One of the first questions I ask devops organizations is to walk me through their development and operations standards. What are the non-negotiable devops practices? What are the data governance first principles? What observability standards are in place? How is security embedded in devops? This is the starting point. From there, we might review standards on how functional requirements are written. For businesses developing AI agents, I’ll ask about their non-functional requirements (NFRs) and how testing is performed.
Now that many devops organizations are using AI code generators, vibe coding, and applying spec-driven development practices, the questions increase. How does the AI know your organization’s standards? What processes monitor and enforce these standards? What are the developer responsibilities for owning the outcomes?
“Generative AI will happily hand you the movie set of an app with looks of a house from the street. The doors and windows open, and the demo runs clean,” says Mike Toole, director of security and IT at Blumira. “Behind the facade, there’s no plumbing and no wiring: no input validation, no auth boundaries, nothing actually holding it up. If your only gate is ‘does it run and look right,’ you’re shipping a set, not a building.”
One report shows that 92% of developers use AI coding tools daily in 2026 and that 41% of all global code is now AI-generated. Will all that code deliver value, operational issues, or mounting AI debt? I spoke to several experts about how to keep AI-generated code aligned with organizational standards and how to define an AI code generator’s context beyond just functional requirements.
A general contractor in the construction industry will review building information models that provide a view of what they are developing. But many of the details are in the construction specifications, including component stipulations and performance requirements. Devops teams without equivalent documentation for their organization, architectures, and applications may have gotten away with this omission in the pre-AI era. But institutional knowledge and compliance requirements are the context AI code generators need before you share the first functional prompts with them.
“AI-generated code stays aligned with engineering standards only when those standards are explicit, available, and difficult to bypass,” says Eddie Zhou, founding engineer at Glean. “Put architecture, approved libraries, data-handling rules, security controls, naming conventions, observability, test expectations, and non-functional requirements into specs and automated checks. Then, ensure you give the model that context but treat its output as untrusted until it passes the same reviews, tests, scans, and production monitoring as human-written code.”
Overcoming tribal knowledge was always challenging as devops teams had too much pressure to push features and little incentive to maintain documentation. Two of my top AI leadership skills are change management and agile collaborative leadership, because devops teams need practice alignment while introducing AI capabilities.
Zhou adds, “AI amplifies ambiguity and weak governance as efficiently as good engineering. If standards live only in tribal knowledge, AI will expose that problem, not solve it.”
The problem with requirement documents and reference architectures is they aren’t directly enforceable with human or AI developers. Once a devops team agrees on standards and documents them, the next step is to develop approaches to encode them as automated acceptance criteria in CI/CD pipelines.
“AI code generators and human developers optimize for functional correctness—making the feature work—and quietly skip the non-functional requirements where most of your real standards live, including performance, security posture, error handling, observability, and auditability,” says Michael Bevilacqua, vice president of AI product management at Adeptia. “Encode your NFRs as executable acceptance criteria that generated code must pass before it merges, so ‘aligned with our standards’ becomes a gate the pipeline enforces on every change.”
An example: Performance requirements stating that all web pages should have a total page weight under 2MB can be validated during the pull request, and requiring the time to first byte (TTFB) to be under 800ms can be automated in CI/CD in a staging environment.
Architecture and automated non-functional requirements covering performance, security, and other organization-level compliance requirements should become the base-level context standards shared with AI-code generators. The next set of considerations for setting accurate contexts starts with application- and agent-specific requirements, their intended use cases, and specific compliance guardrails.
“CIOs are mandating AI to build apps faster, but many are realizing speed isn’t the bottleneck because more code doesn’t automatically create business value,” says Matt Healy, senior director of product strategy and marketing at Pegasystems. “Before developers write any code, organizations must understand customer needs, assess legacy systems, stay current with regulations and best practices, map enterprise architectures and integrations, and align business and IT.”
Consider three stages of understanding requirements. Once stakeholders set business value and intent, developers must first align on an implementation strategy and discuss performance, cost, and other trade-offs. Then, developers should reconvene with stakeholders and review implementation trade-offs. Healy adds, “On large projects, defining the solution and success metrics can take as much time as building it. Leaders aren’t just using AI to accelerate development, but to help executives, business analysts, product owners, and IT teams collaborate more effectively.”
The third stage is gathering the goals, user requirements, and implementation approach into a development-specific context. But we’re not done yet, because data requirements and operations considerations must also be included in the context fed to AI code generators.
How the application or AI agent being developed can use the data it has access to requires clear specifications. Data governance programs should have standards based on data sets, defined roles, entitlements, and usage specifications.
Kash Mehdi, vice president and field CTO at Reltio, says the teams that are pulling ahead treat data governance as an input to AI, not an audit after it. “They ground their tools in trusted, semantically consistent data models, approved specs, and security policies, so the AI inherits the organization’s standards instead of inventing its own. Without that governed context layer, you don’t scale from a handful of AI-assisted workflows to thousands; you just accumulate inconsistent code faster,” Mehdi says.
Here are two options to consider in creating standards: First, establish repurposable data sets as data products with defined integrations and usage rules. Organizations with many data sets and integration points should consider data fabrics. The second (and key requirement) is to standardize the format of data contracts, using human- and machine-readable formats so that data owners, users, and AI code generators operate from a consistent set of principles.
“AI writes code that compiles and passes tests but quietly ignores your data contracts, so the failures show up in production as corrupted state, not build errors,” says Ed Huang, cofounder and CEO of TiDB. “The fix is to make governance machine-checkable, including schema constraints, access policies, and data-quality rules enforced at the database layer where the AI can’t route around them, not documented in a wiki the model never reads. Treat the database as the enforcement point for your standards, and it stops mattering whether a human or an agent wrote the query.”
When AI generates the code, a best practice is to use static application security testing (SAST) and other code analysis tools to perform automated code reviews. Another best practice is to put applications through penetration testing and other application security validations. But many of these tools are outside in view of what the AI developed. To get an inside view, observability and testing requirements must be included as a standard, with specific requirements around the key transactions you’re asking the AI to develop.
Sanjay Gidwani, CEO and founder at Kosmos, says, “More code volume just means more time spent investigating, and the fix isn’t reading the code more carefully before it ships. It’s connecting the observability signal, the thing that broke, back to the specific change that caused it. Without that link, you’re doing the same manual investigation as before, just with a bigger haystack.”
Testing requirements must go beyond generating automated tests, using synthetic data to expand the test patterns, and implementing continuous testing. “Instead of testing one input against one output, test whether an invariant holds across a wide range of generated inputs, which is a good fit for AI’s unbounded input space and non-deterministic outputs,” says Lior Gavish, cofounder and CTO at Monte Carlo. “I treat it as one layer in a stack with evals mapping the input space, property-based testing stress-testing it for edge cases and brittleness, and observability on live traffic checking whether production is drifting from the properties you defined as non-negotiable.”
Ed Frederici, CTO at Appfire, recommends codifying standards as machine-readable rules, including linters, formatters, and type checks. Merge the organizational and application standards into one context shared with the AI code-generating tool. His other recommendations:
LoginCLAUDE.md, style guides, and architecture docs.It’s also important to remember that as code must be extended and maintained, so must the underlying development standards. “AI-generated code only stays aligned with your standards when it’s powered by a context engine that keeps learning, not a static snapshot of your rules,” says Itamar Friedman, CEO and cofounder at Qodo. “That means an engine that continuously adapts to your codebase’s evolving standards, your team’s PR history, and the prior decisions your engineers have already made, so the AI isn’t just following instructions but actually understands how your team works.”
As more devops organizations rely on AI code-generating tools, developers have an important opportunity to develop the standards and automated validations required to ensure what is built meets engineering and compliance requirements.
A swarm of hundreds of OpenAI agents uploaded “malicious packages” to RubyGems and tried to steal API keys, the Ruby community gem hosting service revealed Friday.
OpenAI confirmed part of the disclosure, saying, “our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. We’ll continue to investigate as part of our broader review of agent activity during training and evaluation.”
The agents’ goals were unclear, as was whether they engaged in the swarming activity for research, and even whether they were explicitly sent by OpenAI staffers, but an analysis published by RubyGems strongly suggests malicious intent.
“Once the AIs got arbitrary RCE on the build environment, they would sometimes use the build environment to attempt to steal other users’ API keys, though we are unsure if they succeeded or not,” the RubyGems post said. “The agents clearly regarded what they were doing as hacking. Agents used file names like hack[.]rb, evil[.]rb, inject[.]rb, exploit[.]rb, and ssrf[.]rb. SSRF stands for ‘Server-Side Request Forgery,’ a type of security vulnerability. They also dubbed packages conspicuous titles like pwnp999, exfiltestwand3, hacksvn1778554764 and lambproxyhackabcxyz. Comments such as “# malicious probe” or “#hack” are littered across the campaign.”
The post also said that the agents attempted to trick defensive systems.
“At some points, the agents attempted to be covert. We found multiple packages that would disarm themselves to hide their payload in the next version,” the post said. “They uploaded one package with the comment ‘# disable evil in the next version and bump version,’ which after execution would modify the package to remove the malicious code initially inserted.”
Analysts and consultants said the attack was concerning because if such efforts happen often enough, it could slow down security operations center (SOC) responses.
Nader Henein, a Gartner VP analyst, said he was highly concerned about an upcoming bot swarm trend.
“What we know is that this is the kind of standard attack, now AI-augmented, that will become commonplace over the coming months,” Henein said. “It’s less so a rogue agent, more so an attacker, potentially using compromised credentials, weaponizing an agent swarm, in the same way that attackers used compromised endpoints to mount DDoS attacks for the better part of the last decade. The difference here is the fact that these are not individually compromised bots. OpenAI’s guardrails should have not allowed this to happen.”
Frank Dickson, principal analyst at Dickson Research, added, “OpenAI needs to be held accountable. They seem to want to create ‘Dr. Frankenstein’s monster,’ but don’t seem to want to accept blame for the outcomes. OpenAI hasn’t denied its agents used RubyGems. It has disputed the word ‘malicious’ and called the activity ‘benign,’ while separately acknowledging that, in that same stretch of weeks, its agents escalated to cluster-admin access at Hugging Face and compromised accounts at four other third-party services. Those two characterizations are hard to square. The behavior is still unacceptable.”
However Erik Avakian, technical counselor at Info-Tech Research Group, stressed that it’s not necessarily the case that OpenAI launched these agents with explicit instructions. The agents might have easily charted this destructive path all on their own.
The OpenAI agents “absolutely could have acted autonomously. We’ve already seen that capable agents can pursue various unexpected paths to accomplish a task when they have enough autonomy and access,” he said. “A human may have authorized the evaluation or given the agents access to tools, but that doesn’t mean a human approved every action they subsequently took.”
Dickson added that he fears the ultimate cybersecurity risk is that SOC staffers see so many of these attacks that they start to experience alert fatigue.
“If the vendor whose agents did this is the one downgrading the language, a SOC analyst reading headlines instead of the underlying report has every reason to underreact,” Dickson said. “Security operations aren’t fit for purpose if they run on the assumption that an AI agent label makes an intrusion less real. A stolen API key or a remote code execution path behaves identically whether the actor is a ransomware crew or an unsupervised model chasing a reward signal.”
Mike Wilkes, enterprise CISO at Aikido Security, also noted that the fact that the agents self-identified as OpenAI should mean nothing, as all agents can persuasively pretend to be representing anyone, especially if they think it will slow down a response, even for a brief period.
“A User-Agent string is a nametag written by the visitor, not a passport,” he said. “If SOC tooling begins suppressing alerts because traffic claims to be an OpenAI, Anthropic, Google or other AI agent, attackers will adopt those identities immediately if they haven’t already.”
Thus, he said, “if a human researcher or employee delegates authority to an autonomous agent, there should be a verifiable chain showing who delegated that authority, which organization they represent, what agent was authorized, what scope it was given, and for what period of time.”
Consultant Brian Levine, executive director of FormerGov, encouraged CISOs to anticipate more such attacks and plan accordingly.
“Organizations that depend on open source, which is nearly all of them, should assume registries are an active battleground [and should] rotate and scope API keys tightly, monitor for anomalous package publishing and credential access, and pin and verify dependencies rather than trusting a name,” he said. “The economics have shifted. Automation lets an attacker try thousands of variations cheaply, so defenders have to make the payoff of any single success as small as possible.”
Justin Greis, CEO of consulting firm Acceligence, agreed.
“If legitimate AI research activity increasingly generates behavior that looks like hostile scanning, exploitation, credential access or persistence, SOC teams can become conditioned to treat those signals as noise,” Greis said. “Attackers will understand that very quickly. The dangerous phrase becomes ‘that is probably just an AI agent.’”
This article originally appeared on CSOonline.
Spot false claims and impersonators in AI search, then match each brand protection problem to the right correction, report, or preventive action.
The post Brand Protection In AI Search: How To Audit And Defend Your Brand’s Identity appeared first on Search Engine Journal.
