Meta plans to test exclusive features that will be incorporated in paid versions of Facebook, Instagram, and WhatsApp. It confirmed these plans to TechCrunch.

But these plans are not to be confused with the ad-free subscription options that Meta introduced for Facebook and Instagram in the EU, the European Economic Area, and Switzerland in late 2023 and framed as a way to comply with General Data Protection Regulation (GDPR) and Digital Markets Act requirements.

From November 2023, users in those regions could either keep using the services for free with personalized ads or pay a monthly fee for an ad‑free experience. European rules require Meta to get users’ consent in order to show them targeted ads, so this was an obvious attempt to recoup advertising revenue when users declined to give that consent.

This year, users in the UK were given the same choice: use Meta’s products for free or subscribe to use them without ads. But only grudgingly, judging by the tone in the offer… “As part of laws in your region, you have a choice.”

That ad-free option, however, is not what Meta is talking about now.

The newly announced plans are not about ads, and they are also separate from Meta Verified, which starts at around $15 a month and focuses on creators and businesses, offering a verification badge, better support, and anti‑impersonation protection.

Instead, these new subscriptions are likely to focus on additional features—more control over how users share and connect, and possibly tools such as expanded AI capabilities, unlimited audience lists, seeing who you follow that doesn’t follow you back, or viewing stories without the poster knowing it was you.

These examples are unconfirmed. All we know for sure is that Meta plans to test new paid features to see which ones users are willing to pay for and how much they can charge.

Meta has said these features will focus on productivity, creativity, and expanded AI.

My opinion

Unfortunately, this feels like another refusal to listen.

Most of us aren’t asking for more AI in our feeds. We’re asking for a basic sense of control: control over who sees us, what’s tracked about us, and how our data is used to feed an algorithm designed to keep us scrolling.

Users shouldn’t have to choose between being mined for behavioral data or paying a monthly fee just to be left alone. The message baked into “pay or be profiled” is that privacy is now a luxury good, not a default right. But while regulators keep saying the model is unlawful, the experience on the ground still nudges people toward the path of least resistance: accept the tracking and move on.

Even then, this level of choice is only available to users in Europe.

Why not offer the same option to users in the US? Or will it take stronger US privacy regulation to make that happen?

---

We don’t just report on threats – we help protect your social media

Cybersecurity risks should never spread beyond a headline. Protect your social media accounts by using Malwarebytes Identity Theft Protection.

A new joint investigation by SentinelOne SentinelLABS, and Censys has revealed that the open-source artificial intelligence (AI) deployment has created a vast "unmanaged, publicly accessible layer of AI compute infrastructure" that spans 175,000 unique Ollama hosts across 130 countries. These systems, which span both cloud and residential networks across the world, operate outside the

The Chocolate Factory strikes again, targeting the infrastructure attackers use to stay anonymous

Crims love to make it look like their traffic is actually coming from legit homes and businesses, and they do so by using residential proxy networks. Now, Google says it has "significantly degraded" what it believes is one of the world's largest residential proxy networks.…

eScan lawyers up after Morphisec claimed 'critical supply-chain compromise'

A spat has erupted between antivirus vendor eScan and threat intelligence outfit Morphisec over who spotted an update server incident that disrupted some eScan customers earlier this month.…

The right habits change everything

Sponsored Post  Security teams are under pressure from every direction: supply chain threats are rising, regulatory expectations are tightening, and development cycles aren’t getting any slower. Yet for many organizations, the practical work of improving software security still comes down to the same challenge — how do you reduce exposure without constantly battling developers, delaying releases, or piling on process?

That’s where a more consistent set of habits can make a measurable difference.
Rather than treating software supply chain security as a one-off initiative, many teams are shifting toward repeatable practices they can build into everyday workflows. The goal isn’t perfection; it’s improving baseline security in ways that actually stick, across teams and tool chains.

Chainguard is hosting an upcoming webinar-style event designed to help security and engineering leaders identify the habits that matter most. The session explores seven practical approaches for building more secure software pipelines, with a focus on reducing risk while keeping delivery moving.…

UPD 30.01.2026: Added technical details about the attack chain and more IoCs.

On January 20, a supply chain attack has occurred, with the infected software being the eScan antivirus developed by the Indian company MicroWorld Technologies. The previously unknown malware was distributed through the eScan update server. The same day, our security solutions detected and prevented cyberattacks involving this malware. On January 21, having been informed by Morphisec, the developers of eScan contained the security incident related to the attack.

Malicious software used in the attack

Users of the eScan security product received a malicious Reload.exe file, which initiated a multi-stage infection chain. According to colleagues at Morphisec who were the first to investigate the attack, Reload.exe prevented further antivirus product updates by modifying the HOSTS file, thereby blocking the ability of security solution developers to automatically fix the problem, which, among other things, led to the update service error.

The malware also ensured its persistence in the system, communicated with command-and-control servers, and downloaded additional malicious payloads. Persistence was achieved by creating scheduled tasks; one example of such a malicious task is named “CorelDefrag”. Additionally, the consctlx.exe malicious file was written to the disk during the infection.

How the attackers managed to pull off this attack

At the request of the BleepingComputer information portal, eScan developers explained that the attackers managed to gain access to one of the regional update servers and deploy a malicious file, which was automatically delivered to customers. They emphasize that this is not a vulnerability — the incident is classified as unauthorized access to infrastructure. The malicious file was distributed with a fake, invalid digital signature.

According to the developers, the infrastructure affected by the incident was quickly isolated, and all access credentials were reset.

Having checked our telemetry, we identified hundreds of machines belonging to both individuals and organizations, which encountered infection attempts with payloads related to the eScan supply chain attack. These machines were mostly located in South Asia, primarily in India, Bangladesh, Sri Lanka, and the Philippines. Having examined them, we identified that to orchestrate the infection, attackers were able to replace a legitimate component of the eScan antivirus, located under the path C:\Program Files (x86)\escan\reload.exe, with a malicious executable. This reload.exe file is launched at runtime by components of the eScan antivirus. It has a fake, invalid digital signature (certificate serial number: 68525dadf70c773d41609ff7ca499fb5). We found this implant to be heavily obfuscated with constant unfolding and indirect branching, which made its analysis quite tedious.

When started, this reload.exe file checks whether it is launched from the Program Files folder, and exits if not. It further initializes the CLR (Common Language Runtime) environment inside its process, which it uses to load a small .NET executable into memory (SHA1: eec1a5e3bb415d12302e087a24c3f4051fca040e). This executable is based on the UnmanagedPowerShell tool, which allows executing PowerShell code in any process. Attackers modified the source code of this project by adding an AMSI bypass capability to it, and used it to execute a malicious PowerShell script inside the reload.exe process. This script has three lines, and looks as follows:

Each of these lines is responsible for decoding and launching a Base64-encoded PowerShell payload. These three payloads, which we will further analyze, are used for the infection on the target machine.

eScan antivirus tampering payload

The first executed payload is deployed to tamper with the installed eScan solution, in an attempt to prevent it from receiving updates and detecting the installed malicious components. To do that, it performs several actions, including the following ones:

• Deletes multiple files of the eScan antivirus, including the Remote Support Utility located at C:\Program Files (x86)\Common Files\MicroWorld\WGWIN\tvqsapp.exe. Notably, before deletion, the payload creates ZIP-archived backups of removed files inside the C:\ProgramData\esfsbk directory.
• Modifies the HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\MwMonitor registry key to add the C:\Windows, C:\Program Files and C:\Program Files (x86) folders to antivirus exceptions.
• Adds update servers of the eScan antivirus (such as update1.mwti.net) to the hosts file, associating them with the IP address 2.3.4.0.
• Modifies registry keys related to antivirus databases, for example by assigning 999 to the WTBases_new value of the HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\ODS registry key.

While tampering with eScan, this payload writes a debug log to the C:\ProgramData\euapp.log file, which can be used as an indicator of compromise.

It is worth noting that while running this payload, we did not observe all these actions to succeed on our test machine with eScan installed. For example, the self-defense component of eScan was able to prevent malicious entries from being written into the hosts file. Nevertheless, after the payload had finished execution, we were unable to further update eScan, as we were getting this error message:

Finally, the first payload replaces the C:\Program Files (x86)\eScan\CONSCTLX.exe component of eScan with a next-stage persistent payload, which we will describe in further sections of this article.

AMSI bypass payload

The second payload launched is designed to bypass AMSI. The payload implements typical code for doing that – it determines the address of the AmsiScanBuffer function and then patches it to always return an error.

Victim validation payload

The goal of the third payload, which is the last to be executed, is to validate whether the victim machine should be further infected, and if yes, to deliver a further payload to it. When started, it examines the list of installed software, running processes and services against a blocklist. Entries in this blocklist are related to analysis tools and security solutions. Notably, Kaspersky security solutions are included into this blocklist. This means that this stage will refuse to deliver the embedded payload if Kaspersky products are installed on the victim machine.

If validation is successful, the payload proceeds with deploying a PowerShell-based persistent payload on the infected machine. To do that, it:

• Writes the persistent payload to the Corel value of the HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E registry key.
• Creates a scheduled task named Microsoft\Windows\Defrag\CorelDefrag, designed to execute the following PowerShell script every day at a random time:
  
  

  PowerShell script executed by the CorelDefrag scheduled task (beautified version)

  This script retrieves the persistent payload from the HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E registry key, Base64-decodes and then executes it.

When the payload execution finishes, either because validation failed or the persistent component was deployed successfully, it sends a heartbeat to the C2 infrastructure. This is done by sending a GET request, which contains a status code and optionally an error message, to the following URLs:

• https://vhs.delrosal[.]net/i
• https://tumama.hns[.]to
• https://blackice.sol-domain[.]org
• https://codegiant.io/dd/dd/dd.git/download/main/middleware[.]ts

The response to the GET request is not processed.

As such, during installation, the infected machine receives two persistent payloads:

• The CONSCTLX.exe payload, designed to be launched by the eScan antivirus
• The PowerShell-based payload, designed to be launched via a scheduled task

The CONSCTLX.exe persistent payload

This payload is obfuscated in the same way as the Reload.exe malicious executable. In the same way as this executable, CONSCTLX.exe initializes the CLR environment to execute a PowerShell script inside its own process. The goal of this script is to retrieve the other (PowerShell-based) persistent payload from the HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E registry key, and execute it. However, this script contains another interesting feature: it changes the last update time of the eScan product to the current time, by writing the current date to the C:\Program Files (x86)\eScan\Eupdate.ini file. This is needed to make the eScan solution GUI display a recent update date, so that the user does not notice that antivirus updates are actually blocked.

Apart from launching the PowerShell script, the payload also attempts to retrieve a fallback payload from the C2 infrastructure, by sending GET requests to the following URLs:

• https://csc.biologii[.]net/sooc
• https://airanks.hns[.]to

If there is a need to deliver this payload, the server responds with an RC4-encrypted blob, which is decrypted by the component and launched as shellcode.

The PowerShell-based persistent payload

The second deployed payload is entirely PowerShell-based. When started, it performs an AMSI bypass and conducts the same validation procedures as the victim validation payload. It further sends a GET request to the C2 infrastructure, using the same URLs as the validation payload. In this request, the cookie value named “s” contains RC4-encrypted and Base64-encoded system information, such as the victim ID, user name and current process name. In response to this request, the C2 server may optionally send the victim a PowerShell script, to be launched by the victim machine.

A rarely observed attack vector

Notably, it is quite unique to see malware being deployed through a security solution update. Supply chain attacks are a rare occurrence in general, let alone ones orchestrated through antivirus products. Based on the analysis of the identified implants, we can conclude that this attack was prepared thoroughly, as to orchestrate it, attackers had to:

• Get access to the security solution update server.
• Study the internals of the eScan product to learn how its update mechanism works, as well as how to potentially tamper with this product.
• Develop unique implants, tailored to the supply chain attack.

An interesting fact about the implants deployed is that they implement fallback methods of performing malicious operations. For example, if the scheduled task that launches the PowerShell payload is deleted, it will still be launched by the CONSCTLX.exe file. In addition, if the C2 servers used by the PowerShell payload are identified and blocked, attackers will be still able to deploy shellcodes to the infected machine through CONSCTLX.exe.

One lucky thing about this attack is that it was contained in a quite a short period of time. As security solutions have a high level of trust within the operating system, attackers can use a variety of creative ways to orchestrate the infection, for example by using kernel-mode implants. However, in the attack we saw, they relied on user-mode components and commonly observed infection techniques, such as using scheduled tasks for persistence. This factor, in our opinion, made this supply chain attack easy to detect.

How to stay safe?

To detect infection, it is recommended to review scheduled tasks for traces of malware, check the %WinDir%\System32\drivers\etc\hosts file for blocked eScan domains, and review the eScan update logs for January 20.

The developers of eScan have created a utility for their users that removes the malware, rolls back the modifications it has made, and restores the normal functionality of the antivirus. The utility is sent to customers upon request to technical support.

Users of the solution are also advised to block known malware command-and-control server addresses.

Kaspersky’s security solutions, such as Kaspersky Next, successfully detect all malware used by the attackers with its Behavior Detection component.

Indicators of compromise

Network indicators
https://vhs.delrosal[.]net/i
https://tumama.hns[.]to
https://blackice.sol-domain[.]org
https://codegiant.io/dd/dd/dd.git/download/main/middleware[.]ts
https://csc.biologii[.]net/sooc
https://airanks.hns[.]to

Malicious Reload.exe component hashes
1617949c0c9daa2d2a5a80f1028aeb95ce1c0dee
a928bddfaa536c11c28c8d2c5d16e27cbeaf6357
ebaf9715d7f34a77a6e1fd455fe0702274958e20
96cdd8476faa7c6a7d2ad285658d3559855b168d

Malicious CONSCTLX.exe component hash
2d2d58700a40642e189f3f1ccea41337486947f5

Files and folders
C:\ProgramData\esfsbk
C:\ProgramData\euapp.log

Scheduled task name
Microsoft\Windows\Defrag\CorelDefrag

Registry keys
HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E
HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\ODS – value WTBases_new set to 999

Extortion crew says it's found love in someone else's info as Match Group plays down the impact

ShinyHunters has added a fresh notch to its breach belt, claiming it has pinched more than 10 million records from Match Group, a US firm that owns some of the world's most widely used swipe-based dating platforms.…

An LLMjacking operation has been targeting exposed LLMs and MCPs at scale, for commercial monetization.

The post LLMs Hijacked, Monetized in ‘Operation Bizarre Bazaar’ appeared first on SecurityWeek.

Microsoft issued an emergency patch for a high-severity zero-day vulnerability in Office that allows attackers to bypass document security checks and is being exploited in the wild via malicious files.

Microsoft pushed the emergency patch for the zero‑day, tracked as CVE-2026-21509, and classified it as a “Microsoft Office Security Feature Bypass Vulnerability” with a CVSS score of 7.8 out of 10.

The flaw allows attackers to bypass Object Linking and Embedding (OLE) mitigations that are designed to block unsafe COM/OLE controls inside Office documents. This means a malicious attachment could infect a PC despite built-in protections.

In a real-life scenario, an attacker creates a fake Word, Excel, or PowerPoint file containing hidden “mini‑programs” or special objects. They can run code and do other things on the affected computer. Normally, Office has safety checks that would block those mini-programs because they’re risky.

However, the vulnerability allows the attacker to tweak the file’s structure and hidden information in a way that tricks Office into thinking the dangerous mini‑program inside the document is harmless. As a result, Office skips the usual security checks and allows the hidden code to run.

As code to test the bypass is publicly available, increasing the risk of exploitation, users are under urgent advice to apply the patch.

How to protect your system

What you need to do depends on which version of Office you’re using.

The affected products include Microsoft Office 2016, 2019, LTSC 2021, LTSC 2024, and Microsoft 365 Apps (both 32‑bit and 64‑bit).

Office 2021 and later are protected via a server‑side change once Office is restarted. To apply it, close all Office apps and restart them.

Office 2016 and 2019 require a manual update. Run Windows Update with the option to update other Microsoft products turned on.

If you’re running build 16.0.10417.20095 or higher, no action is required. You can check your build number by opening any Office app, going to your account page, and selecting About for whichever application you have open. Make sure the build number at the top reads 16.0.10417.20095 or higher.

What always helps:

• Don’t open unsolicited attachments without verifying them with a trusted sender.
• Treat all unexpected documents, especially those asking to “enable content” or “enable editing,” as suspicious.
• Keep macros disabled by default and only allow signed macros from trusted publishers.
• Use an up-to-date real-time anti-malware solution.
• Keep your operating system and software fully up to date.

---

We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

The two bugs impacted n8n’s sandbox mechanism and could be exploited via weaknesses in the AST sanitization logic.

The post N8n Vulnerabilities Could Lead to Remote Code Execution appeared first on SecurityWeek.

After the viral AI assistant Clawdbot was forced to rename to Moltbot due to a trademark dispute, opportunists moved quickly. Within days, typosquat domains and a cloned GitHub repository appeared—impersonating the project’s creator and positioning infrastructure for a potential supply-chain attack.

The code is clean. The infrastructure is not. With the GitHub downloads and star rating rapidly rising, we took a deep dive into how fake domains target viral open source projects.

The background: Why was Clawdbot renamed?

In early 2026, Peter Steinberger’s Clawdbot became one of the fastest-growing open source projects on GitHub. The self-hosted assistant—described as “Claude with hands”—allowed users to control their computer through WhatsApp, Telegram, Discord, and similar platforms.

Anthropic later objected to the name. Steinberger complied and rebranded the project to Moltbot (“molt” being what lobsters do when they shed their shell).

During the rename, both the GitHub organization and X (formerly Twitter) handle were briefly released before being reclaimed. Attackers monitoring the transition grabbed them within seconds.

“Had to rename our accounts for trademark stuff and messed up the GitHub rename and the X rename got snatched by crypto shills.” — Peter Steinberger

That brief gap was enough.

Impersonation infrastructure emerged

While investigating a suspicious repository, I uncovered a coordinated set of assets designed to impersonate Moltbot.

Domains

• moltbot[.]you
• clawbot[.]ai
• clawdbot[.]you

Repository

• github[.]com/gstarwd/clawbot — a cloned repository using a typosquatted variant of the former Clawdbot project name

Website

A polished marketing site featuring:

• professional design closely matching the real project
• SEO optimization and structured metadata
• download buttons, tutorials, and FAQs
• claims of 61,500+ GitHub stars lifted from the real repository

Evidence of impersonation

False attribution: The site’s schema.org metadata falsely claims authorship by Peter Steinberger, linking directly to his real GitHub and X profiles. This is explicit identity misrepresentation.

Misdirection to an unauthorized repository: “View on GitHub” links send users to gstarwd/clawbot, not the official moltbot/moltbot repository.

Stolen credibility:The site prominently advertises tens of thousands of stars that belong to the real project. The clone has virtually none (although at the time of writing, that number is steadily rising).

Mixing legitimate and fraudulent links: Some links point to real assets, such as official documentation or legitimate binaries. Others redirect to impersonation infrastructure. This selective legitimacy defeats casual verification and appears deliberate.

Full SEO optimization: Canonical tags, Open Graph metadata, Twitter cards, and analytics are all present—clearly intended to rank the impersonation site ahead of legitimate project resources.

The ironic security warning: The impersonation site even warns users about scams involving fake cryptocurrency tokens—while itself impersonating the project.

---

Code analysis: Clean by design

I performed a static audit of the gstarwd/clawbot repository:

• no malicious npm scripts
• no credential exfiltration
• no obfuscation or payload staging
• no cryptomining
• no suspicious network activity

The code is functionally identical to the legitimate project, which is not reassuring.

The threat model

The absence of malware is the strategy. Nothing here suggests an opportunistic malware campaign. Instead, the setup points to early preparation for a supply-chain attack.

The likely chain of events:

A user searches for “clawbot GitHub” or “moltbot download” and finds moltbot[.]you or gstarwd/clawbot.

The code looks legitimate and passes a security audit.

The user installs the project and configures it, adding API keys and messaging tokens. Trust is established.

At a later point, a routine update is pulled through npm update or git pull. A malicious payload is delivered into an installation the user already trusts.

An attacker can then harvest:

• Anthropic API keys
• OpenAI API keys
• WhatsApp session credentials
• Telegram bot tokens
• Discord OAuth tokens
• Slack credentials
• Signal identity keys
• full conversation histories
• command execution access on the compromised machine

What’s malicious, and what isn’t

Clearly malicious

• false attribution to a real individual
• misrepresentation of popularity metrics
• deliberate redirection to an unauthorized repository

Deceptive but not yet malware

• typosquat domains
• SEO manipulation
• cloned repositories with clean code

Not present (yet)

• active malware
• data exfiltration
• cryptomining

Clean code today lowers suspicion tomorrow.

A familiar pattern

This follows a well-known pattern in open source supply-chain attacks.

A user searches for a popular project and lands on a convincing-looking site or cloned repository. The code appears legitimate and passes a security audit.

They install the project and configure it, adding API keys or messaging tokens so it can work as intended. Trust is established.

Later, a routine update arrives through a standard npm update or git pull. That update introduces a malicious payload into an installation the user already trusts.

From there, an attacker can harvest credentials, conversation data, and potentially execute commands on the compromised system.

No exploit is required. The entire chain relies on trust rather than technical vulnerabilities.

How to stay safe

Impersonation infrastructure like this is designed to look legitimate long before anything malicious appears. By the time a harmful update arrives—if it arrives at all—the software may already be widely installed and trusted.

That’s why basic source verification still matters, especially when popular projects rename or move quickly.

Advice for users

• Verify GitHub organization ownership
• Bookmark official repositories directly
• Treat renamed projects as higher risk during transitions

Advice for maintainers

• Pre-register likely typosquat domains before public renames
• Coordinate renames and handle changes carefully
• Monitor for cloned repositories and impersonation sites

Pro tip: Malwarebytes customers are protected. Malwarebytes is actively blocking all known indicators of compromise (IOCs) associated with this impersonation infrastructure, preventing users from accessing the fraudulent domains and related assets identified in this investigation.

---

We don’t just report on threats—we remove them

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

Apply fixes within a few hours or face the music, say the pros

What good is a fix if you don't use it? Experts are urging security teams to patch promptly as vulnerability exploits now account for the majority of intrusions, according to the latest figures.…

The four critical flaws could be exploited without authentication for remote code execution or authentication bypass.

The post SolarWinds Patches Critical Web Help Desk Vulnerabilities appeared first on SecurityWeek.

This week’s updates show how small changes can create real problems. Not loud incidents, but quiet shifts that are easy to miss until they add up. The kind that affects systems people rely on every day. Many of the stories point to the same trend: familiar tools being used in unexpected ways. Security controls are being worked on. Trusted platforms turning into weak spots. What looks routine on

Close call after an apparently deliberate attempt to starve a country of energy at the worst time

Cybersecurity experts involved in the cleanup of the cyberattacks on Poland's power network say the consequences could have been lethal.…

Zero Trust is not a thing; it is an idea. It is not a product; it is a concept – it is a destination that has no precise route and may never be reached.

The post Cyber Insights 2026: Zero Trust and Following the Path appeared first on SecurityWeek.

A study by OMICRON has revealed widespread cybersecurity gaps in the operational technology (OT) networks of substations, power plants, and control centers worldwide. Drawing on data from more than 100 installations, the analysis highlights recurring technical, organizational, and functional issues that leave critical energy infrastructure vulnerable to cyber threats. The findings are based on