Thinware SimpleVM: A Practical Free-Forever KVM Hypervisor for VMware Administrators Seeking a Smarter Path Forward

The virtualization market has shifted dramatically in recent years and continue to do so. Many enterprises or small businesses face challenging decisions: absorb significant cost increases for VMware, accept unwanted product bundles, or begin the journey toward alternative solutions. Many SMBs has already moved on, now the mid-size and enterprises. For those looking to reclaim control over their infrastructure budgets and operational freedom, Thinware SimpleVM emerges as a compelling option. This lean, KVM-based Type-1 hypervisor combines enterprise-grade capabilities with genuine simplicity and a free-forever licensing model.

Having followed various KVM-based platforms over time, SimpleVM stands out for its focused design philosophy. It avoids unnecessary complexity while delivering the features most teams need for reliable production environments.

Understanding SimpleVM’s Foundation and Design Goals

SimpleVM is built directly on KVM with a hardened operating system base that maintains strong compatibility with RHEL ecosystems. This choice provides excellent driver support, security features (including SELinux), and long-term stability. The platform is engineered as a purpose-built hypervisor rather than a general-purpose Linux distribution with virtualization layered on top.

The development team emphasizes zero vendor lock-in. Everything runs on open, trusted components, meaning you retain full sovereignty over your environment. There is no telemetry collection, no forced cloud connectivity, and no artificial restrictions on scaling. You can deploy on standalone hosts or grow into clusters without licensing penalties.

Key Features in Detail

Deployment and Initial Setup – One of the biggest advantages is speed. The guided installer takes you from bare metal to a functional host in minutes. Hardware support is broad thanks to the Linux kernel foundation, accommodating everything from older server hardware still running in many datacenters to brand-new deployments. This flexibility removes one of the common barriers when planning migrations.

If you’re familiar with Rocky Linux, you’ll find exactly that as SimpleVM uses Rocky Linux as its foundations. The deployment of a single host takes few minutes and it is comparable to other platforms including VMware ESXi.

 

Login screen of Thinware SimpleVM

 

Web-Based Management Console – The integrated dashboard serves as your central control point.

Administrators can:

• Monitor host resources and VM performance in real time
• Create, clone, snapshot, start, stop, and migrate virtual machines
• Manage storage pools and individual volumes with thin provisioning support
• Configure virtual networks, bridges, VLANs, and firewall rules
• Access a web-based terminal and file browser for host maintenance

 

The UI is simple but effective

 

The interface is clean and responsive, making daily tasks efficient without requiring deep command-line expertise for routine operations.

Clustering, Live Migration, and High Availability – For production environments, SimpleVM supports host clustering (starting from simple 2-node setups up to larger configurations). Live VM migration allows you to move running workloads between hosts with minimal or no interruption — the equivalent of vMotion. When combined with shared storage (NFS, iSCSI, or Fibre Channel), you gain automated failover capabilities for higher resilience.

Resource pooling across clustered hosts improves overall utilization. While it may not include fully automated load balancing like some high-end DRS implementations, manual and policy-driven migration tools cover the majority of maintenance and optimization scenarios effectively.

Light UI is also available.

 

Light UI showing the default overview

 

Security and Compliance Features – Hardened SELinux policies, granular firewall controls, and secure boot options provide strong defaults. Role-based access in the web console helps enforce proper administrative boundaries. For organizations with compliance requirements, the ability to run everything on-premises with no external data sharing is a significant advantage.

Support, Patching, and Long-Term Maintainability

A common concern with alternative platforms is “What happens when we need help or updates?” SimpleVM addresses this thoughtfully.

Patching and Updates: The platform follows a 10-year Long Term Support (LTS) philosophy. Security patches and maintenance updates are delivered regularly and can be applied directly through the web console with minimal disruption. This approach provides stability similar to enterprise Linux distributions while keeping the hypervisor layer focused and lightweight.

 

Patching is via the web UI – simple

 

Professional Support Options: Thinware offers dedicated support services for organizations that require it. You can reach out via sales@thinware.net or support@thinware.net for assistance with deployment planning, performance tuning, troubleshooting, or priority handling of issues.

Support is available as an add-on rather than a mandatory subscription tied to the core product. This flexible model works well for teams that want self-sufficiency for standard operations but need expert backup for critical environments.

This combination – free core software with optional professional support gives organizations predictable budgeting while ensuring they are not left without recourse when needed.

Backup and Data Protection: The Veeam Question

No virtualization platform evaluation is complete without addressing backup and recovery. SimpleVM deliberately does not include a built-in backup engine, giving you the freedom to choose tools you already trust. I have interviewed Jeremy Brown, the CEO of Thinware, in my detailed post about SimpleVM. You can get the whole picture why SimpleVM exists. As concerning backups, here is what he said.

Quote:

For backup we want our customers to use whatever tool they prefer. Most of the well know/used packages out there already support KVM so there is no issue there. We chose not to include backup into SimpleVM for this reason.

We still have quite a few customers using Thinware vBackup so we will be retooling vBackup to support KVM as well.

Veeam Compatibility Clarified: Veeam Backup & Replication does not have direct, first-class support for SimpleVM at this time. Because SimpleVM is a relatively new KVM-based platform, it is not listed among Veeam’s officially supported hypervisors (such as VMware, Hyper-V, Proxmox VE, or oVirt/RHV).

That said, practical compatibility is often achievable because it uses standard KVM technology. Many organizations successfully protect generic KVM/libvirt environments using:

• Guest-level agents (Veeam Agent for Windows/Linux)
• Application-aware processing inside the VMs
• File-level or volume-level backups

Recommendations:

• Thoroughly test your intended backup method (agent-based is the most reliable path currently) in a proof-of-concept.
• Monitor future Veeam releases – support for additional KVM platforms has expanded over time.
• Consider complementary solutions such as Thinware’s own vBackup (being updated for KVM) or other open-source options.

The lack of direct integration is important to note for production planning. While not a deal-breaker for many teams (especially those comfortable with agent-based protection), it requires validation during evaluation.

Migration Strategies from VMware

Moving workloads requires careful planning, but SimpleVM provides helpful documentation for the process. Common approaches include:

• Exporting VMs from vSphere and importing them into SimpleVM.
• Using standard conversion utilities (V2V) compatible with KVM as a destination.
• Phased migrations starting with development, test, and less critical production systems.

Because the underlying technology is KVM, virtual hardware compatibility is generally good. Take time to test performance and driver behavior (especially paravirtualized drivers for disk and network) after migration. Storage and networking reconfiguration may be necessary but is usually straightforward.

Start small, document everything, and leverage Thinware support if you want guidance during the initial phases.

Who Should Evaluate SimpleVM?

SimpleVM is particularly well-suited for:

• Mid-sized enterprises and SMBs facing VMware licensing pressure
• Organizations prioritizing cost predictability and operational simplicity
• Teams already comfortable with Linux-based infrastructure
• Environments where 80-90% of workloads are standard server VMs rather than highly specialized use cases

It may not be the perfect fit if you rely heavily on advanced software-defined networking, container orchestration integration, or specific VMware-exclusive features. However, for the broad majority of server virtualization needs, it delivers excellent value.

While writing the article, I quickly spun a new VM in the lab.

 

Example of Windows Server 2022 VM running

 

Potential Considerations and Limitations

As with any platform, transparency is important. SimpleVM is relatively new in its current form, so the ecosystem of third-party tools and community knowledge is still growing compared to more established alternatives. Hardware certification is less rigid (a benefit for flexibility but requires your own validation). Some advanced automation features found in premium enterprise suites may require custom scripting or additional tools.

That said, the rapid deployment, clean management layer, and free licensing often outweigh these factors for many organizations.

Real-World Operational Benefits

Admins who adopt solutions like SimpleVM frequently report:

• Lower total cost of ownership
• Faster provisioning of new environments
• Reduced time spent on licensing compliance
• Greater flexibility in hardware refresh cycles

When combined with existing monitoring tools and your preferred backup solution (such as Veeam), you can build a modern, cost-effective stack tailored to your needs.

Getting Started Today

Visit simplevm.com and download the latest version.

1. Deploy on a test server or a small cluster.
2. Configure storage and networking, then create sample VMs.
3. Test live migration, backup, and patching workflows.
4. Document performance and plan your production rollout timeline.
5. Engage with Thinware early if you anticipate needing support during migration.

Final Words

Couple of years back when the domination of VMware was reaching heights, SimpleVM would probably be forgotten quickly, but now with VMware pricing skyrocketed, this solution only makes sense and it is another viable and simple VMware alternative which runs at a fraction of the costs.

The days of single-vendor dominance in virtualization are definitely over. Solutions like SimpleVM demonstrate that teams can achieve high reliability, good performance, and essential enterprise features without ongoing licensing burdens. The combination of a free core platform, straightforward patching, optional professional support, and compatibility with established tools like Veeam creates a practical migration path for many organizations.

If you are an administrator evaluating options to modernize or right-size your virtualization strategy, SimpleVM deserves a place on your shortlist. A few days in the lab can provide clarity on whether it aligns with your technical and financial goals.

The move away from high-cost ecosystems is not just about saving money – it’s about regaining control and building infrastructure that serves your business rather than the other way around.

What are your biggest drivers for exploring alternatives right now? Cost savings, support flexibility, or something else? Feel free to share your thoughts and experiences in the comments section below. The community benefits when we exchange real-world insights during these transitions.

FAQ

Is Thinware SimpleVM free?

Yes. Thinware SimpleVM uses a free-forever licensing model for its core hypervisor. Professional support is available separately for organizations that need help with deployment, troubleshooting, performance tuning, or other production requirements.

What hypervisor technology does SimpleVM use?

SimpleVM is built on KVM and uses Rocky Linux as its foundation. It is positioned as a purpose-built Type-1 hypervisor with support for SELinux, standard Linux hardware drivers, and RHEL-compatible infrastructure.

Does SimpleVM support clustering and live migration?

Yes. SimpleVM supports host clustering, including configurations starting with two nodes. Administrators can migrate running virtual machines between hosts, and shared storage such as NFS, iSCSI, or Fibre Channel can be used for high-availability configurations.

Does SimpleVM include built-in backup?

No. SimpleVM does not include its own built-in backup engine. Thinware’s approach is to let administrators choose their preferred backup solution rather than bundling one with the hypervisor.

Does Veeam support Thinware SimpleVM?

Veeam Backup & Replication does not currently provide direct, first-class support for SimpleVM. Organizations can still evaluate agent-based protection with Veeam Agent for Windows or Linux, application-aware processing inside VMs, and file- or volume-level backup methods.

Can VMware virtual machines be migrated to SimpleVM?

Yes. VMware workloads can be moved by exporting VMs from vSphere and importing them into SimpleVM or by using V2V conversion tools compatible with KVM. A phased migration starting with development, test, or less critical systems can help validate storage, networking, drivers, and performance before a wider rollout.

Who should consider Thinware SimpleVM?

SimpleVM may suit SMBs and mid-sized enterprises looking for a lower-cost VMware alternative, teams already comfortable with Linux-based infrastructure, and environments where most workloads are standard server virtual machines.

What are the main limitations of SimpleVM?

SimpleVM has a smaller third-party ecosystem and knowledge base than long-established virtualization platforms. Some advanced automation or VMware-specific functionality may require extra tools or custom scripting, and hardware should be validated for the intended environment.

from StarWind Blog https://ift.tt/EfHnUBP
via IFTTT

Terraform provider for Google Cloud 8.0 now generally available

The Terraform provider for Google Cloud connects Terraform configurations to Google Cloud, giving teams a consistent way to provision and manage Google Cloud infrastructure as code. Today, we are announcing the general availability of version 8.0 of the Terraform provider for Google Cloud. 

This major release continues the evolution of the provider around how customers manage Google Cloud infrastructure today. It modernizes several provider defaults, removes resources and properties associated with retired or replaced Google Cloud services, and improves schema behavior to make Terraform plans more predictable. 

Version 8.0 also builds on capabilities introduced throughout the 7.x release cycle, including expanded support for discovering existing infrastructure and bringing it under Terraform management through features such as Search and List. 

What's new since 7.0 

The Google Cloud provider is continuously updated alongside Google Cloud services and Terraform itself. Since the release of version 7.0, several capabilities have expanded across the provider. 

Discover and import existing Google Cloud infrastructure 

During the 7.x release cycle, the Google Cloud provider introduced support for Terraform list resources, starting with service accounts and expanding across a growing set of Google Cloud resources.  

List resources provide a read-only mechanism for discovering existing infrastructure. Used with the terraform query workflow, they allow users to search for existing Google Cloud resources outside Terraform state and optionally generate Terraform resource and import configuration for the results.

Support has expanded across commonly used services including Compute Engine, IAM, BigQuery, Pub/Sub, Secret Manager, Migration Center, and Network Services.  

The provider also expanded Resource Identity support during the 7.x cycle. Resource identities provide a provider-defined representation of the remote object and can be used for operations such as import alongside traditional provider-specific IDs.  

Together, these capabilities make it easier to discover existing infrastructure and prepare it to be brought under Terraform management, particularly in environments where infrastructure already exists outside Terraform state. 

Continue reducing sensitive data in Terraform state 

The 7.x release cycle continued to expand support for Terraform write-only attributes, allowing sensitive values to be sent to APIs without storing those values in Terraform state. 

Write-only support expanded to additional sensitive fields, including certificate private keys, AlloyDB passwords, and IAP credentials. 

This gives teams more options for managing sensitive configuration while reducing the amount of credential material persisted in Terraform state. 

Expand coverage for evolving Google Cloud services 

The provider continued to add resources and capabilities as Google Cloud services evolved. This includes additional support across areas such as Vertex AI, Discovery Engine, GKE, networking, security, data services, and migration tooling. 

As with previous releases, these updates are delivered continuously through the provider's regular release cadence rather than being held for a major version. 

Highlights in Google Cloud provider 8.0 

Version 8.0 uses the major-version boundary to introduce several behavioral and schema changes that could not be made safely in a minor release. 

Modernized Application Load Balancer defaults 

The default load_balancing_scheme for google_compute_backend_service and google_compute_global_forwarding_rule has changed from EXTERNAL to EXTERNAL_MANAGED.  

Configurations that do not explicitly specify a load-balancing scheme will therefore use the modern external Application Load Balancer behavior. Users that need to retain Classic Application Load Balancer behavior should explicitly configure load_balancing_scheme = "EXTERNAL".  

For migration details, refer to the google_compute_backend_service and google_compute_global_forwarding_rule sections of the version 8.0 upgrade guide. 

Removal of retired and replaced Google Cloud services 

Google Cloud provider 8.0 removes a number of resources and data sources associated with services or APIs that have been retired, replaced, or superseded. 

Examples include: 

•  google_iap_brand and google_iap_client, following the shutdown of the IAP OAuth Admin APIs.  

• google_notebooks_environment, google_notebooks_instance, and google_notebooks_runtime, following the end of life of the associated Notebooks products. Users should migrate to google_workbench_instance.  

• google_ml_engine_model, with machine learning deployments moving to Vertex AI.  

• google_beyondcorp_app_connection, google_beyondcorp_app_connector, and google_beyondcorp_app_gateway, with Security Gateway resources providing the replacement path.  

• google_vertex_ai_schedule, which is replaced by google_colab_schedule. 

These are breaking removals, so configurations using these resources must be updated before upgrading. Refer to the version 8.0 upgrade guide for the migration path for each affected resource. 

More predictable Terraform plans 

Version 8.0 includes several schema, validation, and behavioral changes designed to better reflect Google Cloud API behavior. 

Several attributes where ordering is not significant have changed from lists to sets, including fields in Compute Service Attachments, GKE logging and monitoring configuration, and Cloud Security Compliance Frameworks. These changes help prevent perpetual diffs when APIs return values in an order different from the order represented in Terraform configuration or existing state. 

Validation has also been tightened where Google Cloud APIs already require particular values. For example, source_contents is now required for google_workflows_workflow, and claim_mapping is required when creating Workforce Identity Pool Provider SCIM tenants. 

These changes allow Terraform to catch more configuration issues during planning and reduce differences caused by how API responses are represented in state. 

Migrating to Google Cloud provider 8.0 

Google Cloud provider 8.0 is a major release, so users should review their configurations before upgrading. 

The Terraform provider for Google Cloud 8.0 Upgrade Guide documents removed resources and data sources, field changes, validation updates, state migrations, and other breaking changes. 

When planning an upgrade, we recommend that users: 

• Upgrade to the latest 7.x provider release first and resolve existing deprecation warnings. 

• Review configurations for resources and fields removed in version 8.0. 

• Explicitly configure load_balancing_scheme = "EXTERNAL" where Classic Application Load Balancer behavior is still required. 

• Review configurations affected by schema and validation changes, including attributes converted from lists to sets and write-only fields whose version attributes have changed type or are now required. 

Test the upgrade in a non-production environment and carefully review the resulting terraform plan before rollout, paying particular attention to resources that Terraform plans to destroy or replace. 

Some state changes, including certain integer-to-string conversions, are migrated automatically by the provider, while other changes require updates to Terraform configuration. Refer to the upgrade guide for the requirements of each affected resource. 

Getting started 

Terraform provider for Google Cloud 8.0 is now available in the Terraform Registry. 

For detailed migration guidance, review the Terraform provider for Google Cloud 8.0 Upgrade Guide. For the complete list of changes included in the release, refer to the provider changelog on GitHub. 

The Google Cloud provider is developed through the continued collaboration of the Google Cloud engineering team, our HashiCorp team, and the Terraform community. Thank you to the maintainers, contributors, and users whose feedback and contributions continue to improve the provider. 

from HashiCorp Blog https://ift.tt/jvUXzaQ
via IFTTT

Exploit Released for Unpatched Ubuntu Linux Flaw Enabling Host-Root Container Escape

A use-after-free in the Linux kernel's AF_UNIX socket subsystem can be used to escape a container and gain root on the host, security firm DepthFirst said in research published September 22.

The flaw, tracked as CVE-2026-80521 (CVSS score: 7.8), was fixed upstream on August 6, but Ubuntu has not shipped the patch for its 26.04, 24.04, or 22.04 LTS releases. DepthFirst released exploit code targeting Ubuntu 26.04.

Ubuntu's security tracker lists the Linux package on 26.04 as "vulnerable, work in progress." The 24.04 and 22.04 releases are also affected through newer kernel packages, including those for AWS, Azure, and GCP workloads. No fix has shipped on any affected release.

The flaw is not in CISA's Known Exploited Vulnerabilities catalog, and there are no confirmed reports of attacks using it.

The vulnerability sits in the kernel's garbage collector for AF_UNIX sockets. That collector cleans up file descriptors passed between processes through SCM_RIGHTS messages. AF_UNIX sockets handle local communication between processes and are allowed by default in Docker and Kubernetes seccomp profiles, which is why the flaw can be reached from inside a container.

A race condition in the garbage collector lets it see new references before the data carrying them has been queued. If the collector runs during that window, it can free part of a group of linked sockets without removing a pointer from a persistent internal list. The next collection pass follows that pointer into freed memory.

Because the exploit reaches the kernel through ordinary system calls that containers are allowed to make, it bypasses namespace isolation, cgroup limits, and seccomp filtering.

The upstream fix landed on August 6 in mainline kernel 7.2 and stable branch 7.1.10. The vulnerable code was introduced in kernel 6.10 and also backported to stable branches 6.1 and 6.6. Organizations running an affected kernel can apply the upstream patch directly. Ubuntu's tracker shows "work in progress" with no published date for the distribution update.

Neither DepthFirst nor Ubuntu has published a temporary workaround. DepthFirst recommends moving untrusted workloads to microVM isolation, such as Firecracker or Kata Containers, which give each workload its own kernel rather than sharing the host's.

How the Flaw Was Found

DepthFirst said its AI model, dfs-large1, trained for vulnerability detection, found the flaw alongside a human-operated testing harness. The company won a Google kernelCTF slot with the exploit on July 24 and reported the bug to the kernel security team on August 5.

The kernel maintainers replied that a researcher at OpenAI had independently reported the same bug, according to DepthFirst's timeline. The CVE commit credits kernel-exploitation researcher Kyle Zeng as the reporter.

The disclosure is the latest in a series of 2026 kernel flaws that allow attackers to escape containers. A futex vulnerability disclosed in July and a flaw in the kernel's cryptographic subsystem in April also allowed an unprivileged user to escalate to root on the host. Both discoveries involved AI-assisted research.

DepthFirst argues that AI-accelerated vulnerability discovery has lowered the barrier to container escapes to the point that organizations should not treat containers as a security boundary.

"The barrier to escaping containers by attacking the kernel has fallen so significantly that we must assume attackers can do so at will," the company said.

Nearly 5,700 Linux kernel CVEs have been published in 2026, the highest annual total on record, according to LinuxCVETracker. The demonstrated exploit and the rising volume are the basis for the company's assessment.

from The Hacker News https://ift.tt/qFpw9tH
via IFTTT

Chinese Hackers Exploit Chrome-Windows Zero-Day Chain to Deploy CLEANGULP Malware

A Chinese threat actor codenamed UTA0565 has been observed exploiting the recently disclosed Google Chrome-Microsoft Windows exploit chain as zero-days through fake websites.

The attacks, detected on September 3 and 4, 2026, involved the chaining of two vulnerabilities in Chrome (CVE-2026-85046, CVE-2026-87491) and one impacting Windows Advanced Local Procedure Call (CVE-2026-85880) to break out of the browser's sandbox and achieve remote code execution.

"UTA0565 masqueraded as various entities including media organizations and a non-governmental organization (NGO)," Volexity researchers Damien Cash and Tom Lancaster said in an analysis published this week. "Notably, this threat actor's campaigns differed from previously documented attacks by using multiple fake websites to deceive victims."

One such campaign targeted Asian government entities with Chinese- and English-language phishing emails that urged recipients to support Hong Kong activist Chow Hang-tung and masqueraded as the Center for American Progress (CAP). Chow was sentenced to seven years and three months in prison earlier this month.

These messages contained spoofed links pointing to "chinadigitaltimes[.]top" and "americanprgoress[.]top," which replicated the look of China Digital Times and CAP, while loading an additional HTML element via a hidden iframe.

The HTML element ("config.html") is said to have used the same BlueMoon exploit kit combining CVE-2026-85046, CVE-2026-87491, and CVE-2026-85880, with the final "pp" shellcode downloading an executable named "chrome_cleanup.exe" from the bogus domain. The payload is a malware family dubbed CLEANGULP, which is built using the Microsoft Visual C Compiler.

It supports the following capabilities -

• shell, to run a command
• ps, to list running processes
• upload, to upload a file
• download, to download a file
• bof, to execute a Execution of a beacon object file (BOF)

Interestingly, CLEANGULP has been found to use a hard-coded domain named "thecovnresation[.]com" for command-and-control (C2) over HTTP, indicating an attempt to mimic "theconversation[.]com," a non-profit media outlet known for publishing academic research, analysis, and commentary.

"This seemingly widespread adoption across multiple threat actors suggests a coordinated effort within the Chinese CNE community, where the core kit was likely shared, customized, and weaponized by multiple groups," Volexity said. "The activity reported so far reflects only two organizations' observations; the full scope and impact are likely far broader."

from The Hacker News https://ift.tt/R9lMBFJ
via IFTTT

Critical Next.js ImageResponse Flaw Can Lead to Server Code Execution via Crafted SVG Input

A new security vulnerability in Next.js could allow attackers to run code on a server via ImageResponse, the feature that generates Open Graph and other social preview images, Vercel said.

The risk applies when an app puts values an attacker controls, such as text read from the request URL, into the image. Vercel, which develops Next.js, fixed the flaw on September 22 in version 16.3.6.

The flaw, tracked as CVE-2026-94545, affects Next.js 16.2.0 through 16.3.5 when ImageResponse runs on the Node.js runtime, which Next.js uses by default. Vercel's advisory rates it critical, with a CVSS score of 9.5. The Edge version of ImageResponse is not affected, and neither is Next.js 15.

ImageResponse uses Satori, a Vercel library, to convert the image layout into SVG code before the final PNG is generated. Affected apps are those that "pass attacker-controlled values into SVG content, attributes, or styles during image generation", according to the advisory.

The advisory's example takes a value from the request URL and places it inside an SVG title element. It does not say whether text in ordinary elements, such as a heading inside a div, also counts.

To find where an app uses the feature, look for ImageResponse imported from next/og, for example in route handlers and in opengraph-image files. Route handlers make the image when a request arrives. An opengraph-image file can make it at build time or when a request arrives.

As of September 23, The Hacker News found no public reports of attacks using the flaw and no public exploit code.

The fix is Next.js 16.3.6, the only patched version, installed with npm install next@16.3.6. As of September 23, the npm registry listed no fixed release for the 16.2 line, so apps on 16.2 need to move to 16.3.6. Next.js 15.5.26 adds extra security hardening for next/og on the 15.5 line.

If upgrading has to wait, the advisory's workaround is to keep attacker-controlled values out of the SVG content, attributes, and styles that the Node.js ImageResponse renders. The advisory does not suggest switching to the unaffected Edge version, and the Next.js documentation marks the Edge runtime as deprecated.

In checks by The Hacker News on September 23, npm audit did not flag Next.js 16.3.5, an affected version. The advisory was also not yet listed in the GitHub Advisory Database, and no CVE record for CVE-2026-94545 had been published.

Check the Next.js version directly. Satori is bundled inside the Next.js package, so a lockfile does not list it as a dependency of Next.js.

Vercel's advisory and announcement do not say whether apps hosted on Vercel are protected. For two critical Next.js flaws fixed in August, the company said hosted apps were protected and needed no upgrade.

Vercel's advisory and announcement also provide no way to check whether an affected route was abused before the patch. Affected versions have been available since Next.js 16.2 was released on March 18.

The bug itself is in Satori. Satori's own advisory, published the same day, says certain values reached its SVG output without being properly escaped. A specially made value could then be read as SVG code instead of plain text.

In Next.js, such values could reach vulnerabilities in other libraries that Next.js depends on and lead to code execution, Vercel said. It has not named those libraries.

Satori's advisory rates the same CVE as moderate, with a score of 5.3, and says the impact depends on how the SVG output is used. Developers who use Satori directly should update it to version 0.33.5, which has the fix.

from The Hacker News https://ift.tt/Lr5KhOX
via IFTTT

ShinyHunters Claims FBI Breach, Says It Stole Data on Agents and Job Applicants

The cyber extortion group known as ShinyHunters on Tuesday claimed it had breached the U.S. Federal Bureau of Investigation and stolen data belonging to current and former employees at the agency.

"We have compromised the FBI. We hold very sensitive data on almost ALL FBI Agents and individuals who filed an application with the FBI for a job," the group said in a statement posted on their dark web site. "Whether it be a Special Agent or any other role within your agency. The following FBI services were compromised: Criminal Justice (CJ), HR, Medlink, and more."

The development was first reported by 404 Media. ShinyHunters said the FBI was targeted in response to a May 2026 public service announcement (PSA) that detailed the threat actor's targeting of Canvas, an online Learning Management System (LMS), while urging victims not to pay.

The attackers, in their own counter PSA, described them as "substantial false allegations," adding, "we were very disappointed to see an agency of your standing would resort to such circulation of disinformation in an attempt to 'disrupt' our operations, an effort that ultimately proved unsuccessful."

The group has also rejected claims that it's part of The Com decentralized collective, calling it a "propaganda started by the Information Security Industry which has brainwashed past FBI and DOJ officials into formalizing this nonsense."

A ShinyHunters spokesperson told The Register that the group exploited a new Oracle PeopleSoft zero-day vulnerability to gain remote code execution and deface the FBI's jobs site with a "This site has been seized by ShinyHunters" banner. Visiting the site now reads: "Scheduled Maintenance Underway. We're Sniffing Out Site Updates for You!"

There are currently no details of a PeopleSoft pre-authenticated RCE zero-day. However, ShinyHunters weaponized a similar flaw (CVE-2026-35273) in June 2026 to break into enterprise networks and extort victims.

In a statement shared with Reuters, the FBI said it's "aware of claims regarding unauthorized activity affecting FBIjobs.gov and is currently investigating."

The disclosure comes after the high-profile hacking group hijacked the dark web leak site of the Clop (aka Cl0p) ransomware crew.

"IF YOU WANT TO SAVE YOUR BRAND AND NOT DIE BY MY HANDS: [...] let's see how rich you really are," the notice read. "2.333% of my net worth is a 8 figure amount, I hope you can pay that much because that is the demand, negotiable. Get your bosses in front of the white board in the war room. Clock is ticking moron. Kindly excuse our unprofessionalism."

"ShinyHunters; claim of an FBI breach is an unusually provocative move in the ongoing contest between law enforcement and cybercrime groups and should absolutely be taken seriously," Etay Maor, VP of threat intelligence at Cato Networks, said.

"We have seen threat actors target businesses countless times, and nation states or nation-state-connected groups have compromised law-enforcement organizations before—the 2015 OPM breach remains the most notable example—but a cybercrime brand publicly claiming an FBI compromise is different."

"One small operational clue is the September 23 timestamp on the group's post, while the news emerged on September 22 in the U.S. If that timestamp reflects the group's real operating environment, it points toward activity in Asia. It is not a definitive attribution, but it is a detail investigators will examine alongside the technical evidence."

Maor also described ShinyHunters as a resilient criminal brand that has managed to outlast takedowns, arrests, and forum seizures by evolving its methods and attracting new operators, suggesting it's more than a "fixed set of people or infrastructure."

"Its recent playbook has emphasized abusing trusted identity paths through help-desk social engineering, malicious OAuth applications, and stolen SaaS integration tokens, rather than simply breaking through a technical perimeter. That is the larger lesson here: organizations, including public-sector agencies, need to protect the identity and third-party trust relationships that attackers increasingly exploit."

from The Hacker News https://ift.tt/RbMyp0a
via IFTTT

SharePoint Flaw Initially Listed as Spoofing by Microsoft Enables Authenticated RCE

A SharePoint Server vulnerability that Microsoft initially classified as a spoofing flaw with a CVSS score of 6.5 actually enables authenticated remote code execution, according to full technical details published today by Viettel Cyber Security researcher Dinh Ho Anh Khoa.

The flaw, CVE-2026-65660, affects SharePoint Server 2016, 2019, and Subscription Edition. Patches have been available since the August 11 security updates, and the National Vulnerability Database scores it 8.8.

Microsoft's advisory describes CVE-2026-65660 as allowing an authorized attacker to perform spoofing and assigns no impact to integrity or availability. The CVE record that Microsoft publishes separately, updated on September 11, titles the same flaw a remote code execution vulnerability and says it allows an authorized attacker to execute code.

Both records assign CWE-94, a code-injection weakness. Defenders who triaged CVE-2026-65660 based on the advisory saw a moderate spoofing flaw, not a code-execution vulnerability with a near-maximum score.

Khoa is the researcher who demonstrated the original ToolShell exploit chain against SharePoint at Pwn2Own Berlin in May 2025. That chain was later exploited by Chinese state-backed groups and triggered emergency patches from Microsoft.

The researcher has since disclosed several other SharePoint flaws, including CVE-2026-55040, an authentication bypass that attackers exploited shortly after its details became public in August.

The latest vulnerability sits in how SharePoint checks whether server-side controls are on the SafeControls list, a filter that prevents dangerous classes from loading. When the ToolPane component processes web-part markup, it reconstructs Register directives by writing attribute values between double quotes without escaping quotes inside them.

An attacker can inject additional directives through the unescaped quotes, registering arbitrary .NET classes after the type check runs but before the control is loaded.

With arbitrary class loading, the attacker uses XamlServices.Parse() to trigger code execution through deserialization. The writeup includes a working in-memory webshell payload that avoids the registry permission failures other deserialization methods encounter, Khoa said.

The researcher also demonstrated that the flaw can be chained with a separate, already-patched authentication bypass to reach pre-authentication remote code execution on servers configured to allow anonymous page access. Khoa says the bypass was fixed in a June 9 patch, and servers that applied the fix are not exposed to the pre-authentication path.

No exploitation of CVE-2026-65660 has been reported in the wild, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog. Microsoft's advisory rates exploitation as unlikely, though the full exploit markup is now public. Khoa says he has used the exploit in penetration testing engagements.

The August 11 patch fixes the flaw and turns off the vulnerable function by default, according to the researcher.

Khoa says the flaw also affects SharePoint 2013, though Microsoft's advisory lists only 2016, 2019, and Subscription Edition. SharePoint 2013 has been out of support since April 2023 and receives no security updates.

from The Hacker News https://ift.tt/eLZfgyO
via IFTTT

Introducing CAIRN: Frontier tracking for AI-integrated malware

A cairn is a marker left behind on a trail, a deliberately placed stack of stones that helps hikers find their way when the path is unclear. Attackers building AI-integrated malware unintentionally (and inevitably) leave behind markers of their own: prompt templates, provider endpoints, API keys, jailbreak terms, and other artifacts embedded throughout their tooling. 

When we consider these strings as cognitive artifacts, or vestiges left behind from AI integration, we can enable a new, metadata-first hunting methodology for AI-integrated malware that is fast and scalable. These artifacts can be extracted, related, and classified without ever touching the underlying binary. 

Today, Cisco Talos is releasing this methodology in the form of CAIRN (Cognitive Artifact Intelligence Research Network), a research toolkit for hunting, classifying, and tracking emerging AI-integrated malware. Over time, we will share the full contents of our initial findings, starting today with CLOSEDQUORUM.

Figure 1. CAIRN explorer connects malware binaries by metadata attributes like submitter, import hash, domain or AI provider. Run cairn explorer to launch the graph.

CAIRN contains functionality for identifying AI-integrated malware; in our definition, that is malware that functionally operationalizes, explicitly targets, or exploits AI systems and their ecosystems — spanning functional integration into attack chains, credential and infrastructure compromise, and ecosystem-level abuse. These binaries are classified based on pre-defined AI-usage archetypes, and reporting findings in a structured way.

CAIRN has an explorer layer, which creates a structured graph of cognitive artifact relationships to help defenders identify related malware families, infrastructure, and threat actors. 

Figure 2. The CAIRN processing pipeline extracts AI-integration artifacts from metadata, classifies and constructs unique representations for all samples, and clusters and graphs the sample relationships.

Metadata-first architecture 

CAIRN operates entirely from metadata — no binary downloads or execution required. It combines rule-based detection, semantic clustering, and relationship graph traversal to identify AI-integrated malware through cognitive artifacts such as embedded prompts, provider endpoints, orchestration logic, API key prefixes, and AI-analysis evasion strings. 

CAIRN discovers candidate samples through up to 24 acquisition filters, each targeting a different type of AI-related artifact. Instead of relying solely on filenames or hashes, these filters search across metadata including extracted strings, sandbox behavior, and antivirus (AV) detection labels. 

• provider-api-integration searches for LLM provider endpoint strings in file metadata. For example: 
  • api.openai.com  
  • api.anthropic.com 
  • api.deepseek.com
  • Generativelanguage.googleapis.com
    
    Any file whose binary content, URL extraction, or sandbox behavior surfaces one of these domains becomes a candidate. 
• python-ai-scripts targets Python files matching AI framework import patterns. For example: 
  • langchain 
  • litellm 
  • openai 
    
    This pulls in scripts that interact with the AI ecosystem at the code level, not just the network level. 
• ai-analysis-evasion searches for text strings explicitly addressed to AI analysis systems — the kind of comment an actor might embed when trying to tell an LLM sandbox "there's nothing to see here."
• local-llm-runtime searches for strings indicating local model inference (ollama, llama.cpp, vllm, gguf, safetensors). This surfaces files that may be running inference on the endpoint rather than calling a hosted API.
• agentic-tooling looks for tool-call syntax (tool_call, tool_calls, function_call) co-occurring with offensive capability terms. 

Results from the acquisition filters are stored in a SQLite corpus with YARA run automatically on import, using a three-layer ontology:  

• Tier 1 (T1) Primitive AI Artifacts (e.g., API endpoints, tool calling syntax) establishes that AI-related artifacts are present. 
• Tier 2 (T2) Behavioral Context (e.g., AI analysis evasion, known C2 methods) adds behavioral context by identifying combinations of artifacts that suggest operational use of AI. 
• Tier 3 (T3) Operational Families (named AI-enabled malware family) performs family attribution using confirmed operational fingerprints.

Analysis methods with CAIRN 

CAIRN is set up with a detailed CLI and works well for an analyst or as an agent-driven workflow. The skills published support a standardized reporting structure when using an agent. 

CAIRN uses four distinct analysis strategies; each suited to a different phase of investigation. In practice, a hunt session combines several of them: surface expansion to find unknowns, pivoting to map what's related, and corpus analysis to find structure in what's been collected. 

1. Acquisition filters for sample corpus expansion 

Discover previously unseen samples using acquisition filters. This type of hunt produces candidate samples that are introduced into the CAIRN database. 

Figure 3. Acquisition filters can be viewed and edited from within the CAIRN explorer.

2. Relationship-based pivoting 

Once a sample of interest has been identified, CAIRN expands outward through metadata relationship graphs to identify related malware, shared infrastructure, and other artifacts connected to the same campaign. 

These relationships help analysts answer questions such as: 

• Are there additional variants of this malware family?  
• What infrastructure (e.g., domains, IPs, certificates, C2 servers) does this malware share with other samples?  
• What loaders, companion payloads, or adjacent malware are part of the same campaign? 

By following these connections, analysts can move beyond a single malware sample and begin reconstructing the broader operational ecosystem behind it. 

3. YARA-based triage and classification 

CAIRN's YARA rules operate on scan text derived from sample metadata in a three-tier structure (T1 artifacts, T2 behaviors, T3 confirmed families). The same text document that feeds the embedding pipeline in the next method, Semantic Discovery, is used for YARA matching.  

Traditional YARA rules are written after reverse engineering (RE). They anchor on the artifacts reverse engineering surfaces, particularly the low-level implementation details that most precisely fingerprint a family. Those are the best classifiers you can write, but they presume you hold the binary. A CAIRN rule must fire on what VirusTotal already exposes as metadata: printable strings, import names, resource and version-info fields, and certificate identities — so the discriminator must survive the trip from disassembly up to the surface of the file. The RE finding tells you what makes the family unique; the metadata rule is the projection of that finding onto the subset of it that's observable without a download. 

Tier 3 rules are used to assign logic to identify known operational families. This produces a YARA rule for confirmed attribution of a family of samples. 

Figure 4. YARA rules serve to identify which specific artifacts and behaviors a given sample exhibits.

This is the constant tension in a T3 rule: The sharpest signal from low-level RE is exactly the signal you can't hunt on. As a result, the discipline is to pin down the family by RE, then ask which string- or metadata-accessible trait travels alongside that mechanism. Build the rule from those, treating the deep implementation detail as the thing the rule is a proxy for rather than the thing the rule matches. 

 After any rule change, cairn rescan re-applies all three tiers offline against the full corpus without any API calls or re-downloading. This means a new T3 rule for a confirmed family will immediately surface any previously-acquired samples that match, retroactively attributing earlier hits to the new family. 

4. Semantic discovery 

YARA finds what you already know to search for. Embedding models can identify samples that are semantically similar even when they share no obvious string overlap. CAIRN therefore treats semantic clustering as a complementary discovery mechanism rather than a replacement for YARA. 

For each sample, CAIRN assembles a scan text document from: 

• All AV engine detection label strings 
• URL and domain objects extracted by VirusTotal's PE static analysis engine 
• Content-search hex-dump snippets (VirusTotal's preview of matched content at a file offset) 
• ExifTool PE resource strings (CompanyName, FileDescription, OriginalFilename) 
• Behavioral string patterns from VirusTotal sandbox execution (memory-scanned domains, contacted URLs, sigma rule hits)

Figure 5. UMAP in the CAIRN explorer shows groups of samples based on the similarity of their metadata fingerprint, facilitating hunting of a known malware’s nearest neighbors, or distinct clusters of uncategorized samples.

This approach produces candidate families and reveals outliers and novel clusters. This view is exposed in the CAIRN explorer through the UMAP toggle, which presents an unsupervised pass over the full existing corpus using HDBSCAN and UMAP. Cluster co-membership is a weak similarity signal, not a strong attribution signal. It generates leads, not conclusions. Every interesting cluster still requires per-sample inspection to confirm the AI angle is real and not a false neighbor. 

Findings summary 

Talos' initial hunts with CAIRN have targeted active malware development since July 2025, when the first AI-integrated samples were reported in the wild (LAMEHUG, CERT-UA). Looking across our collection of samples and relationships, we can make a few interesting initial observations: 

• There is an autonomy escalation arc, and it is changing fast. The progression from "LLM as optional feature" to "fully autonomous multi-model consensus orchestrator with no human operator" filled in within a single calendar year. 
   
• AI-specific tradecraft is being taught and spread. An AI-analysis evasion technique, embedding natural-language suppression text addressed to LLM sandboxes was traced to a named red team instructor and appeared in independent actor samples, within 12 months of its first confirmed in-the-wild use.  This suggests the technique is circulating broadly enough to reach actors with no connection to the original course or malware sample and has crossed from interpreted scripts into compiled malware. 
   
• Mandatory “No free lunch,” “Not a silver bullet” statement. T1/T2 hits without genuine AI integration are common. For example, PyInstaller bundles expose the developer's entire virtual environment as YARA-visible strings regardless of what the application imports; Tauri-framework apps and certain Go PE structures accumulate detection signatures from structural similarity alone. Analysts running AI artifact hunts should expect elevated noise from these patterns specifically. 
   
• We may be in a fleeting window to observe AI transition. AI integration is becoming commonplace in all software. As this integration increases, our filters will need to shift from an emphasis on presence of AI strings, toward purpose of their integration. The current approach emphasizes T2 YARA to sharpen behavior classification over the presence of AI indicators alone. Final verdicts for all findings still need validation through reverse engineering. 

Conclusions 

It’s too soon to tell whether AI-integrated malware will conclude as an experimental era, or usher in new paradigms for modern attack operations. Adversaries are increasingly incorporating LLMs into operational tooling, and researchers need methodologies and frameworks that scale beyond manual reverse engineering to keep pace with the changes. Metadata-first hunting provides a scalable complement to traditional reverse engineering, and by open-sourcing CAIRN, Talos hopes to refine filters, rules, and reporting via community-driven improvements. 

CAIRN is a research effort, not a pure active threat signal. However, for the security community, the insights gleaned from studying this landscape and its progression form a valuable signal to inform our detection, intelligence, and operational strategies. 

Take a brief tour of CAIRN with our demo video:

from Cisco Talos Blog https://ift.tt/7vUJK0u
via IFTTT

Malicious npm Package indexed-btree Hid Its Loader in Runtime Code Before Removal

A malicious npm package named "indexed-btree" has been observed hiding its malicious behavior within application code rather than using lifecycle scripts, indicating that threat actors are likely shifting tactics in response to recent security controls.

"Indexed-btree is a malicious npm package mimicking the legit sorted-btree package, an ordinary B-tree/indexing utility," Checkmarx said. "Unlike the common attacks we've seen in the supply chain space, this package does not rely on preinstall / postinstall at all. Instead, it runs entirely from application code at runtime."

The package and the associated GitHub repository are no longer available for download from npm. However, statistics show the package was first uploaded to the registry on June 18, 2026, by an npm user named "charlessadler25," amassing millions of downloads in a short span of time.

To make matters worse, the campaign may have generated illicit profits for the threat actor, earning them around €230,933.57 in cryptocurrency (i.e., 109 ETH).

The development comes as npm version 12 introduced a security change to prevent automatic execution of lifecycle scripts such as preinstall or postinstall, which is one of the most common ways malware is executed through packages distributed through the repository.

"Legitimately, these are often used for compiling necessary code, seeding data, or setting up essential configurations," Checkmarx said. "For threat actors, however, this is frequently exploited to automatically execute malicious code without user consent during the installation of a malicious package."

The latest findings from the software supply chain security company show that bad actors are shifting tactics in response to the change, eschewing install hooks in favor of incorporating the malicious code directly within the library.

In this case, the malware loader is concealed inside a "BTree.prototype.set()" method, which then triggers "sharedLoad.min.js," a JavaScript payload that embeds the obfuscated first stage of the malware.

The malware is designed to fingerprint the host, beacon the details to a hard-coded Slack channel and Telegram bot, uses the EtherHiding technique to pull next-stage, encrypted blobs from a smart contract deployed on Sepolia testnet, and finally merge them to form the second-stage payload.

The final step involves deleting the malicious artifacts and removing the trigger from the package code to cover up the tracks.

Checkmarx said indexed-btree is one of the many npm packages tied to the same operation, all of which have since been removed from npm -

• ordered-kv-index
• btree-leaderboard
• priority-slot-queue
• btree-range-store
• btree-core
• btree-time-index
• btree-lru-cache
• neighbor-key-map
• sliding-score-window
• mutex-forge

To counter the threat, developers are recommended not to stick only to install-time scanning and blocking lifecycle scripts alone, but also employ runtime behavior analysis.

"What makes this campaign particularly important is that it shows attackers adapting almost immediately to stronger software supply chain defenses," Ensar Seker, CISO at SOCRadar, said in a statement shared with The Hacker News. "Npm has improved install time security by restricting dependency lifecycle scripts, but this campaign demonstrates that attackers can simply move malicious execution into legitimate-looking runtime functionality instead."

"The broader lesson is that security controls change attacker behavior rather than eliminate the underlying threat. Blocking lifecycle scripts is an important improvement, but attackers will continue searching for alternative execution paths. Defenders, therefore, need layered controls capable of detecting malicious behavior before installation, during execution, and after deployment."

PolinRider Resurfaces on Packagist

The disclosure comes as Socket said it deleted malicious code in the "dev-main" version of "visanduma/nova-two-factor," a Packagist package with over 700,000 cumulative downloads, as part of an ongoing North Korea-linked malicious cyber campaign dubbed PolinRider.

A defining trait of PolinRider is the threat actor's pattern of compromising developer accounts to inject malicious content into source code repositories and employ routine developer actions, such as cloning a repository or opening it in an integrated development environment (IDE), as triggers to activate the infection chain.

This often entails rewriting Git history, concealing payloads within configuration or font files, setting up malicious VS Code auto-run tasks, and relying on takedown-resistant techniques like EtherHiding and its stealth-focused successor, NullReceiver, for staged-payload delivery via the blockchain.

"Analysis of the Visanduma GitHub organization indicates that its repositories have been compromised since mid-June 2026," Socket security researcher Karlo Zanki said. "The malicious changes were introduced through the LaHiRu developer account."

One notable shift observed in the latest iteration is the direct insertion of heavily obfuscated JavaScript into "index.php" and its execution through PHP's "shell_exec()" function. This approach, besides allowing a PHP entry point to invoke the JavaScript infection chain, suggests the threat actors are adapting their execution methods based on the compromised project instead of using a fixed delivery path.

"The activity reinforces a defining characteristic of PolinRider: package-registry compromise is often a consequence of a broader Git-based intrusion rather than the campaign's primary objective," Socket said. "The operators use ordinary source-code collaboration to reach developer environments, spread into additional repositories, and maintain access over time."

"Compromised source repositories give the operators opportunities to infect contributors, access private projects, and propagate through normal development workflows. Package publication becomes an additional distribution path when a compromised repository produces a new release."

from The Hacker News https://ift.tt/MqiLb4K
via IFTTT

SideCopy Broadens India Targeting to Academia With ReverseRAT Spear-Phishing

The threat actor known as SideCopy has been observed using spear-phishing lures to target academic institutions in India, expanding their strategic focus beyond government entities.

"SideCopy campaign operations typically initiate through spear-phishing campaigns that leverage the abuse of mshta.exe to execute malicious scripts and circumvent standard security protocols," Trellix researchers Boggavarapu R S S Srinivas Gupta and Ravishankar N C said in a technical report.

"This delivery mechanism facilitates the deployment of a remote access trojan (RAT), which serves as the central pillar of their offensive infrastructure."

Active since at least 2019, SideCopy (aka TAG-140) is an advanced persistent threat (APT) group that originates from Pakistan, and shares overlaps with the Transparent Tribe cluster. Historically, the threat actor has primarily targeted Indian defense forces and government officials.

In a report published in June 2026, Seqrite Labs attributed SideCopy to a spear-phishing campaign targeting Afghanistan's Ministry of Finance with an open-source remote access trojan called Xeno RAT.

The latest attack chain documented by Trellix uses spear-phishing to deliver a weaponized ZIP archive, within which exists a Windows shortcut (LNK) with a spoofed PDF icon and a .DOCX extension ("commskll.docx.lnk") to make the malicious file look legitimate.

The LNK file is used to fetch an obfuscated HTML Application (HTA) from a remote server ("docsportal[.]in") and execute it using "mshta.exe," which then proceeds to reflectively load a DLL payload. The malware makes use of an anti-forensic self-deletion routine that deletes the HTA file once the subsequent stage is initialized.

The DLL serves as a dropper for three embedded components -

• appT.bat, a batch script that's launched by means of a Windows Registry Run Key to execute "startT.hta" using "mshta.exe" without requiring user interaction
• startT.hta, a secondary exploit stage that contains the obfuscated final payload
• commskl.docx, a decoy document

"The obfuscated code within startT.hta executes a multi-stage deobfuscation routine to reconstruct a two-part XAML payload directly in memory," Trellix explained, adding it's responsible for reflectively loading an embedded DLL ("ioluegnt.dll").

"To evade disk-based detection, the malware decodes its core payload into volatile memory space, transitioning from a Base64-encoded string to an active, in-memory process via .NET Deserialization."

The DLL is a remote access trojan named ReverseRAT, which has been put to use by SideCopy since early 2021 to facilitate data exfiltration, remote execution, and persistence. It's equipped to gather system metadata, a list of installed software, screenshots, passwords, and clipboard content; perform file operations; run commands; set up persistence via Registry; upload files; and spawn a shell session.

The command-and-control (C2) traffic is encrypted using a hard-coded cryptographic key ("NMXIKS09?:709,!~lnsYUS"). The harvested data is exfiltrated via port 5863 to "dns.educationportals[.]biz," which resolves to the IP address "45.61.157[.]22."

"The current activities of SideCopy underscore a disciplined and highly strategic approach to intelligence collection," Trellix concluded. "While their historical focus has been on Indian government entities, their recent pivot toward academic institutions highlights an expanding set of strategic priorities."

"By continuously refining their infection stages, most notably through the heavy abuse of mshta.exe and complex, multilayered obfuscation, they remain a formidable and adaptive adversary for regional security."

from The Hacker News https://ift.tt/ykzXD2R
via IFTTT

One Hidden Meta Muse Setting Could Let Attackers Turn the AI Assistant Into a Backdoor

Malware already running on a Mac can quietly take over Meta's Muse assistant and use the broad access its owner granted the app, security researcher Patrick Wardle has shown in a proof-of-concept released on September 21.

It works by changing a hidden setting so that when the user taps the microphone and dictates a prompt, the words go to the attacker instead of Meta.

The flaw is in the Mac version of Muse, and it only works if an attacker can already run code as the logged-in user. It is not a way to remotely break into a Mac.

Muse is the personal AI agent Meta launched this month in the United States. Once a user turns it on, it can work across their files, email, messages, calendar, shopping and smart-home apps, using whatever access the person chooses to give it.

That access is the point, Wardle says. He urged people not to install Muse, calling it "trivial to turn Muse into the ultimate backdoor."

macOS normally prevents one app from accessing another app's files, microphone, camera, or saved logins, so ordinary malware is limited in what it can access. An attacker who can quietly steer Muse instead gets everything the user allowed the app to do.

Wardle also warns that security software may not notice, because the commands come from Muse, a normal signed app, rather than from something that looks like malware.

The setting he found is undocumented and decides where Muse sends dictation. It is stored in the Mac app's preferences under the name endo_voyager_dictation_endpoint, and any program running as the logged-in user can point it at an address the attacker controls, without needing extra permissions.

After that, the dictation no longer goes to Meta. When the user speaks a prompt, the audio and the text go to a small program the attacker is running on the same Mac.

From there, Wardle showed three things an attacker can do: read what the user dictated, add extra instructions that Muse trusts and acts on, and take the token that identifies the user's Muse session and use it to control the assistant directly.

Because a Muse account can be signed in on multiple devices, the attack does not stop at the Mac. Using a stolen session, Wardle directed the Muse app on his own iPhone to report its exact location, run a Bluetooth scan of nearby devices, and list the smart-home commands it could send. In his tests, the assistant only drafted messages rather than sending them on its own.

Wardle also pointed to what the attack does not do. It does not defeat the part of macOS that stops one app from reading another app's saved passwords. Instead of stealing Muse's stored login tokens, it makes Muse itself act, using access the app already has. And it does not show that Meta's cloud system, which the company built to keep each user's agent walled off, was broken.

What Mac Users Can Do Now

With no patch available, a Mac user can only limit the exposure:

• Quit Muse, or remove it, until Meta fixes the problem.
• Review the apps and permissions Muse holds, and revoke any it does not need, so there is less for an attacker to access.
• If the Mac may already be compromised, treat the connected accounts as exposed and change their passwords.
• Because the attack needs the user to dictate, avoid Muse's voice input, which closes the exact path shown.

Meta has put a lot of weight on Muse's security. It built the agent to run in a separate cloud system that keeps each user's data apart from others, with a checking layer meant to approve the actions Muse takes. This flaw sits in the Mac app instead, not in that cloud design.

Wardle argues Meta created the weak point itself by building its own way to handle dictation that sends the audio off the device, rather than using Apple's dictation, which runs on the Mac.

from The Hacker News https://ift.tt/1LXHa5m
via IFTTT

Zyxel and Veeam Flaws Under Active Exploitation With Command and SYSTEM Access

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday added a now-patched security flaw impacting Zyxel GS1900 series switches to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation.

The vulnerability, tracked as CVE-2026-7273 (CVSS score: 8.8), is a stack-based buffer overflow vulnerability that could result in arbitrary operating system (OS) command execution.

"A stack-based buffer overflow vulnerability in the CGI program of the Zyxel GS1900 series switch firmware could allow a LAN-based, unauthenticated attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request," Zyxel said in an advisory released in June 2026.

The issue has been addressed in the following versions -

• GS1900-8 2.90(AAHH.1)C0 and earlier - Fixed in 2.90(AAHH.2)C0
• GS1900-8HP 2.90(AAHI.1)C0 and earlier - Fixed in 2.90(AAHI.2)C0
• GS1900-10HP 2.90(AAZI.1)C0 and earlier - Fixed in 2.90(AAZI.2)C0
• GS1900-16 2.90(AAHJ.1)C0 and earlier - Fixed in 2.90(AAHJ.2)C0
• GS1900-24 2.90(AAHL.1)C0 and earlier - Fixed in 2.90(AAHL.2)C0
• GS1900-24E 2.90(AAHK.1)C0 and earlier - Fixed in 2.90(AAHK.2)C0
• GS1900-24EP 2.90(ABTO.1)C0 and earlier - Fixed in 2.90(ABTO.2)C0
• GS1900-24HPv2 2.90(ABTP.1)C0 and earlier - Fixed in 2.90(ABTP.2)C0
• GS1900-48 2.90(AAHN.1)C0 and earlier - Fixed in 2.90(AAHN.2)C0
• GS1900-48HPv2 2.90(ABTQ.1)C0 and earlier - Fixed in 2.90(ABTQ.2)C0

CISA hasn't disclosed who was behind the exploitation efforts, when they started, how many organizations have been targeted, how many of them have been successful, and what attackers did once inside the vulnerable service.

Zyxel credited Lei Gu, Jun Cao, Zhiqing Rui, Jingzheng Wu, and Tianyue Luo from ISCAS for discovering and reporting the vulnerability. As of writing, the company has yet to revise the alert to confirm active exploitation.

In light of active exploitation, Federal Civilian Executive Branch (FCEB) agencies are required to apply the fixes by September 24, 2026, for optimal protection.

Active Exploitation of Veeam Agent for Windows Flaw

This disclosure comes as Arctic Wolf warned of active exploitation of CVE-2026-32996 (CVSS score: 7.3), a local privilege escalation vulnerability in Veeam Agent for Microsoft Windows that allows an attacker with local access to obtain SYSTEM-level control of affected endpoints.

"The issue stems from the Veeam Endpoint Backup service's handling of elevated client sessions over the local gRPC named pipe \\.\pipe\Veeam\VAW\ServiceConnectionPipe," the company said. "The service caches an elevated administrator principal against a client-controlled session UID that is not bound to the requesting user or connection."

"Because elevated session UIDs are written to C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log, which standard users can read, an attacker can obtain a valid UID and abuse it to execute commands as SYSTEM. The public GitHub PoC demonstrates this by running whoami and writing the output to a file."

from The Hacker News https://ift.tt/BGIQse4
via IFTTT

Fake LastPass Authenticator Installer Abuses Microsoft-Signed Driver to Kill Antivirus and EDR

A fake LastPass Authenticator installer offered on GitHub installs a Windows kernel driver that shuts off antivirus and other security software before a password stealer runs if a victim downloads and runs it, researchers at LastPass and Delphos Labs said on September 17.

Microsoft's own hardware-compatibility program signs the driver, scored zero detections on VirusTotal when researchers checked it in August, and was not on Microsoft's list of blocked drivers. LastPass says none of its own systems, services, or customer vaults were touched, and that the attackers only borrowed its name.

The lure is a fake GitHub page (github.com/LastPass-Authenticator) that ranks in search results for terms like "LastPass Authenticator download" and looks like a real LastPass product page.

Clicking the download button sends the visitor through several GitHub pages to an attacker server, which serves a large ZIP file. The real LastPass Authenticator comes from lastpass.com and the official app stores, not GitHub.

Inside the ZIP is a renamed copy of a real Microsoft debugging tool, vsdbg.exe, placed next to a malicious file named vsdbg.dll. When the fake installer runs, Windows loads the attacker's DLL from the same folder, a trick called DLL side-loading. The loader then tries three ways to gain administrator rights, reaches SYSTEM, the highest level on a Windows machine, and installs the kernel driver as a service.

The archives seen were 148 MB and 127.9 MB, padded with junk files so that scanners with size limits skip them.

What the driver does, and why Windows trusts it

A kernel driver runs below the level where antivirus and endpoint detection and response (EDR) tools operate. This one, which the researchers named Alinubx.sys, carries a list of 145 antivirus and security process names and terminates each one it finds running.

It does this from the kernel, below the level where security software runs, so those user-mode tools cannot block or see the kill. Loading a legitimately signed but abusable driver to gain that access is a known technique called bring your own vulnerable driver, or BYOVD, which The Hacker News has covered before.

The driver is signed through the Microsoft Windows Hardware Compatibility Publisher chain, with a signing date of March 2023, years before this campaign. As the researchers put it, "Microsoft attestation proves a driver passed through a trust pipeline. It does not prove the driver is safe."

The kill list is the only part of the driver that ran here. Its code can also hide files, inject into other programs, and reroute web traffic, but those need a configuration file the attackers did not include, so they stayed off.

What it did do is enough. With security software down, the stealer collected saved passwords from more than two dozen browsers, cryptocurrency wallet files, and login sessions for Discord, Steam, and Telegram, along with the contents of Windows Credential Manager and files named like "password," "seed," or "recovery."

For Chrome and Edge, which use Google's app-bound encryption to stop exactly this, the stealer injects code into the browser and asks the browser's own service to decrypt the passwords. The data is packed into a ZIP and sent to an attacker server.

Why nothing caught it

The driver is a renamed copy of CcProtect.sys, a driver from the Chinese disk-encryption product CnCrypt that is already listed on the LOLDrivers catalog as a process killer, with public proof-of-concept code. The two share the same product name, version, and submitter; only the file name and description changed.

That change dropped the file's antivirus detections: the known original showed 7 of about 70 engines flagging it in August, while the renamed driver showed zero.

The blocklist is a different matter. Microsoft's vulnerable driver blocklist, on by default since the Windows 11 2022 update, stops listed drivers from loading. Delphos checked it on August 20 and found neither the renamed driver nor the known original on it. The rename did not slip past the blocklist, because the original was never on it either.

The blocklist matches known file hashes, and a renamed or recompiled driver produces a new hash that the list does not carry. At the September 17 report, Alinubx.sys was still not on the blocklist.

Delphos reported the driver to Microsoft on August 19. Microsoft responded that the behavior does not meet its definition of a security vulnerability, because the driver is not a Microsoft component, and pointed the researchers to the separate channel that considers drivers for the blocklist. Delphos resubmitted there the same day.

If you ran the fake installer

Treat every password saved in the browser on that machine as stolen, along with any cryptocurrency wallet files, Discord, Steam, and Telegram sessions, and anything in Windows Credential Manager. The stealer copies these out before the driver work begins.

Change those passwords from a separate, clean device, not the affected one, and review account activity for anything you did not do. The driver stays loaded, re-kills security tools, and re-runs the stealer on every reboot, defeating the tools that would normally clean it up.

A machine that ran this payload should be treated as a kernel-level compromise and, where possible, given a kernel-level forensic check or rebuilt.

What defenders can hunt for

The researchers say to hunt for the driver's lineage and behavior rather than one file name, because the operators can change the name again as they did here. Signs to watch for:

• Service: a service created as NvFsFilter
• File: a driver written to C:\Windows\System32\drivers\nvfsflt64.sys
• Signer: a driver whose signing details name Henan Dafeng Software or contain "CnCrypt"
• Device: the path \\.\Alinubx
• Behavior: a driver load followed by security processes being killed

A community detection for the exact driver is published on LOLDrivers, though it matches by hash and so shares the same weakness once the file changes. Full indicators are in the joint report.

Where it came from

The LastPass page was one of many lures. The attacker server was serving impersonation pages for at least 40 brands, LastPass said, and a near-identical second fake page for a "macOS LastPass" product was taken down before the team could examine it.

Fake GitHub repositories delivering this family of stealer are not new: Trend Micro documented the BoryptGrab stealer spread this way in March, and Arctic Wolf reported a separate wave of nearly 300 such repositories in July.

Delphos assesses with high confidence that the loader was built with the Cruciferra crypter, a paid tool whose default kill list also holds 145 names and whose driver is interchangeable, and with moderate confidence that the stealer, which LastPass calls Rapuncel, is a relative of BoryptGrab rather than the same build. How many people were infected is unknown; the report provides no victim count.

from The Hacker News https://ift.tt/1vDB8TF
via IFTTT