Tag Archive for: Sicherheitslücke

Security experts are observing a worrying trend: the time to exploit (TTE), i.e. the time between a security vulnerability becoming known and being exploited by malicious actors, has been falling dramatically in recent times.

At the same time, attackers are becoming increasingly skilled at concealing their presence in a successfully hacked network. Experts refer to the time it takes to establish a foothold and then gain unauthorized access to company resources before being detected (and removed) as “dwell time”. The shorter this time, the better for those under attack. Even the most talented hacker needs time and can cause more (permanent) damage the longer they remain undetected and unobserved.

The Enemy Is Listening – and May Already Be There

Alarmingly, dwell time is increasingly reaching months or even years, as was the case with Sony and the US Office for Personal Management. There, attackers were able to operate undisturbed for more than twelve months. As a result, more than 10 terabytes of data were stolen from the Japanese technology group.

The fear of hidden intruders is great; after all, no one can say with certainty whether a malicious listener is already on their own network. It happens. In the 2015 Bundestag hack, for example, it was not the Bundestag’s own monitoring system that informed the German authorities about strange activities by third parties (Russian APT hacker groups) on the Bundestag network, but a “friendly” intelligence service. How long and how many actors had already been active in the network at that point remained unclear. The only thing that was clear was that there was more than one, and that the friendly intelligence services had been watching for some time.

Detection, Prevention and Response Increasingly Critical

This makes it more important to ensure that attackers do not gain access to the system in the first place. But this is becoming increasingly difficult: as reported by experts at Google’s Mandiant, among others, the response time available to companies and software operators between the discovery of a vulnerability and its exploitation has fallen rapidly in recent years, from 63 days in 2018 to just over a month in recent years.

Less and Less Time to Respond

In 2023, administrators had an average of only five days to detect and close vulnerabilities. Today it is already less than three days.

But that’s not all. In the past, security vulnerabilities were often exploited after patches became available, i.e., after experienced administrators had already secured their systems and installed the latest patches. These so-called “N-day vulnerabilities” should not really be a problem, as fixes are available.

Improved Discipline with Side Effects: Attackers Learn

Unfortunately, in the past, discipline (and awareness) was not as strong in many companies, and the issue was neglected, inadvertently contributing to the spread of automated attack methods such as worms and viruses. But there is good news here too: in 2022, attacks via N-day vulnerabilities still accounted for 38% of all attacks, but by 2023 this figure will fall to just 30%.

At first glance, this sounds good because administrators can find and fix known vulnerabilities for which patches are available more quickly and effectively. After years of poor discipline and a lack of update and patch strategies, the major and successful ransomware incidents have certainly also helped to convey the scope and importance of proper vulnerability management to the majority of those responsible.

Two-thirds Are now Zero-days

But there is also a downside to these figures: more than two-thirds of all attacks are now based on zero-day vulnerabilities, i.e., security gaps for which there is no patch yet – in 2023, this figure was as high as 70%. Criminal groups and attackers have reacted, learned and professionalized, automated and greatly accelerated their activities.

Without automation and standardization of processes, without modern, well-maintained and controlled open-source software, administrators can hardly keep up with developments. Who can claim to be able to respond to a new threat within three days?

Powerless? Not with Greenbone

When attackers can respond faster to new, previously unknown vulnerabilities and have also learned to hide themselves better, there can only be one answer: the use of professional vulnerability management. Greenbone solutions allow you to test your network automatically. Reports on the success of measures give administrators a quick overview of the current security status of your company.

CVE-2025-34028 (CVSS 10) is a maximum severity flaw in Commvault Command Center, a popular admin console for managing IT security services such as data protection and backups across enterprise environments. As of April 28th, CVE-2025-34028 has been flagged as actively exploited. CVE-2025-34028 also presents heightened risk due to the existence of publicly available proof-of-concept (PoC) exploit code and the fact that Command Center manages the backups and other security configurations for many prominent organizations.

The flaw allows unauthenticated attackers to perform Remote Code Execution (RCE) and to take complete control of a Command Center environment. Given the sensitivity and criticality of IT tasks managed by Commvault, forfeiting complete control has a high potential for disastrous impacts. For example, if backups are disabled, an organization could lose their ability to recover from a ransomware attack. This makes CVE-2025-34028 an attractive target for ransomware operators and financially motivated attackers.

The vulnerability, discovered by Sonny Macdonald of watchTowr Labs, exploits a server-side request forgery (SSRF) [CWE-918] weakness in Command Center’s deployWebpackage.do endpoint. In a successful attack, an adversary uploads a poisoned ZIP archive to a publicly accessible path. The malicious ZIP file is automatically extracted allowing attackers to trigger execution via HTTP GET request to the extracted payload.

CVE-2025-34028 affects versions 11.38.0 to 11.38.19 on both Linux and Windows platforms. Greenbone is able to detect CVE-2025-34028 with an active check that sends a crafted HTTP POST request and checks if the target connects back to the scanner host indicating that it is vulnerable to exploitation. Users of affected versions are urged to apply patches immediately. Let’s further examine the risk posed by CVE-2025-34028.

What is Commvault Command Center?

Commvault Command Center is a web-based interface written in Java that enables organizations to manage data protection, backup, and recovery operations across enterprise environments. Commvault markets itself as a single platform with modular components such as Commvault Complete Backup & Recovery, Commvault HyperScale X and Commvault Disaster Recovery. Most of Commvault’s products rely on the Command Center as their primary management interface. As such, Command Center is used to configure backup jobs, monitor systems, restore data and administer user roles and access.

As of 2025, Commvault maintains roughly 6.2% of the Backup And Recovery market share category, serving over 10,000 organizations globally, across various industries such as banking, healthcare, government and technology. Most of its customers are large enterprises, with 42% having more than 1,000 employees. With Commvault’s adoption among critical sectors including healthcare, government and Fortune 500 companies, the potential impact of this vulnerability is widespread and significant.

A Technical Description of CVE-2025-34028

The discovery and disclosure of CVE-2025-34028 was accompanied by a full technical description and PoC code. Here is a brief summary of the root cause and attack vector for CVE-2025-34028:

The root cause of CVE-2025-34028 is classified as Server-Side Request Forgery (SSRF) [CWE-918]. SSRF vulnerabilities arise when an application is tricked into accessing a remote resource without properly validating it. By exploiting SSRF flaws, an attacker can potentially bypass access controls [CWE-284] such as firewalls that prevent the attackers from accessing the URLs directly. You can think of it as “bouncing” a request off the target in order to bypass security measures. In the case of CVE-2025-34028, the SSRF flaw allows an Unrestricted Upload of File with Dangerous Type [CWE-434].

Here is how the exploit process for CVE-2025-34028 works:

Mixed among the Command Center application endpoints, the researcher found 58 that do not require any form of authentication. Inspecting these unrestricted APIs, researchers discovered the deployWebpackage.do endpoint included a parameter named commcellName, which was used to define the hostname of a URL and which was not filtered for scope. Another parameter, servicePack, defines the local path where the HTTP response to that URL should be stored.

Using a simple directory traversal technique, i.e. prepending the servicePack parameter with “../../” the researcher was able to achieve arbitrary file upload to a custom destination. The Command Center application used a hardcoded filename dist-cc.zip, indicating that the program was expecting a ZIP archive.

When supplying a ZIP archived Java executable (.jsp file), and specifying an unauthenticated route via the servicePack param, a malicious .jsp payload was uploaded, automatically extracted, where it could be accessed directly via an HTTP GET request. This results in execution of the .jsp file by Command Center’s Apache Tomcat web server and unauthenticated, arbitrary RCE on behalf of the attacker.

Mitigating CVE-2025-34028

CVE-2025-34028 affects Commvault Command Center versions 11.38.0 through 11.38.19 on both Linux and Windows platforms and has been resolved in versions 11.38.20 and 11.38.25, with patches released on April 10, 2025. For those unable to update immediately, Commvault recommends isolating the Command Center installation from external network access as a temporary mitigation.

Commvault’s Innovation releases, which are frequent, feature-rich update tracks, are typically updated automatically by the system on a predefined schedule without requiring user action. This is in contrast to Long Term Support (LTS) versions which require manual updates.

Summary

CVE-2025-34028 is a critical severity unauthenticated RCE flaw in Commvault Command Center that doesn’t require user interaction. The vulnerability has been flagged as actively exploited by CISA as of April 2025. CVE-2025-34028 affects Command Center versions 11.38.0–11.38.19 and enables attackers to take full control of backup systems. Commvault is relied upon by many large companies globally for key backup and restoration capabilities making CVE-2025-34028 a hot target for ransomware threat actors. Greenbone is able to detect affected Command Center instances with an active test that uses an HTTP POST request to verify vulnerability.

Vulnerabilities in IT environments appear in different forms. The most common ones are likely software vulnerabilities that have not been patched. Then there are weak passwords, misconfigurations or network switches that have been EOL for five years. However, another type of security gap sometimes causes significant confusion during the scans: hardware vulnerabilities.

We have become accustomed to the continuous emergence of software vulnerabilities, and hopefully, it is now standard practice for every company to regularly scan its network for vulnerabilities and apply patches. Unfortunately, mistakes are not limited to software developers – CPU developers are not immune either. CPU vulnerabilities often arise from design flaws, allowing malicious actors to exploit unintended side effects to access sensitive data. Unlike software vulnerabilities, which can often be resolved through patches or updates, hardware vulnerabilities require either microcode updates or fundamental architectural changes in future processor designs.

Microcode Updates

The only way to mitigate CPU vulnerabilities is by applying microcode updates, which are typically distributed through the operating system or sometimes even through firmware (UEFI/BIOS). Microcode is a low-level software layer within the processor that translates higher-level machine instructions into specific internal operations.

While end users do not traditionally update microcode themselves, manufacturers like Intel provide relevant updates to patch certain vulnerabilities without requiring a full hardware replacement. However, these updates often introduce performance loss, as they disable or modify certain CPU optimizations to prevent exploitation. In some cases, this can even lead to performance reductions of up to 50%.

Flaws on different levels

Since these vulnerabilities exist at the CPU level, tools like the Greenbone Enterprise Appliance detect and report them. However, this can lead to misconceptions, as users might mistakenly believe that the reported vulnerabilities originate from the operating system. It is crucial to understand that these are not OS vulnerabilities; rather, they are architectural flaws in the processor itself. The vulnerabilities are detected by checking for the absence of appropriate microcode patches when an affected CPU is identified. For example, if a scan detects a system that lacks Intel’s microcode update for Downfall, it will be reported as vulnerable. However, this does not mean that the OS itself is insecure or compromised.

Performance or safety?

In the end, mitigating CPU vulnerabilities always involves trade-offs, and users must decide which approach best suits their needs. In principle, there are three options to choose from:

  • Apply microcode updates and accept significant performance degradation in compute-heavy workloads.
  • Forego certain microcode updates and accept the risks if the probability of exploitation is low in their environment.
  • Replace the affected hardware with CPUs that are not vulnerable to these issues.

Ultimately, the decision depends on the specific use case and risk tolerance of the organization or individual responsibles.