Record damage from cyberattacks on Germany

Cyberattacks on Germany inflicted record losses of 202.4 billion euros on the economy over the past twelve months. The Bitkom Wirtschaftsschutz 2025 study puts total damage from data theft, industrial espionage and sabotage at 289.2 billion euros, with around 70 percent attributable to cybercrime. The previous year’s figure stood at 178.6 billion euros, marking a 13 percent increase. Of the 1,002 companies surveyed, 87 percent reported being affected by data theft, espionage or sabotage in the past twelve months, while another 10 percent suspect they were targeted. Bitkom President Ralf Wintergerst stated at the presentation that Germany ranks among the top targets of cybercriminals worldwide. The figures position cyberattacks on Germany not merely as an IT issue, but as a first-order economic risk.

BSI Situation Report 2025 confirms tense security landscape

The Federal Office for Information Security published its Report on the State of IT Security in Germany 2025 on 11 November 2025. During the reporting period from July 2024 to June 2025, the agency registered an average of 119 new vulnerabilities per day, an increase of 24 percent compared to the previous year. BSI President Claudia Plattner described the overall situation as still tense. Federal Interior Minister Alexander Dobrindt emphasized that digital security is a core question of state sovereignty. The report identifies inadequately protected attack surfaces as the central weakness, particularly in web applications and perimeter systems within authorities, SMEs and political organizations.

Ransomware remains the dominant threat for companies

The Federal Criminal Police Office documents 950 reported ransomware attacks during the reporting period. Around 80 percent of the registered incidents targeted small and medium-sized enterprises. According to the BSI, the attacks resulted in data exfiltration or threats of publication of sensitive information in most cases. The Bitkom Wirtschaftsschutz study shows that 34 percent of surveyed companies were affected by ransomware, almost three times as many as in 2022 with 12 percent. 15 percent of those affected paid a ransom. Among the payers, 34 percent of cases involved demands between 100,000 and 500,000 euros, and 12 percent between 500,000 euros and one million. Ransomware-as-a-Service continues to lower the entry barriers for attackers, according to the BSI assessment.

DDoS campaigns accompany political events

Cyberattacks on Germany using DDoS techniques peaked sharply in February 2025, according to the BSI. The number of known attacks was 52 percent above the long-term average. The Federal Election and the Munich Security Conference took place during the same period. Pro-Russian hacktivist groups repeatedly targeted state portals and political institutions. Average bandwidth of the attacks declined year-on-year. Exploitation incidents rose by 38 percent during the reporting period, while blocked accesses to malicious websites increased by 23 percent. The Badbox IoT botnet also remains a significant threat to networked devices in households and businesses, the BSI states.

State-sponsored actors pressure critical infrastructure

The BSI Situation Report lists 28 APT groups relevant to Germany, corresponding to around 25 percent of state-sponsored attacker groups observed worldwide. Germany ranks fourth among target countries, behind the United States, India and Japan. According to Bitkom, 46 percent of identified cyberattacks can be traced to China and Russia. Energy providers, cloud operators, the automotive industry, research institutions and technology-focused companies are particularly affected. The Federal Office for the Protection of the Constitution assesses hybrid warfare by foreign states as a daily reality in German cyberspace. Russian actors primarily aim at disruption and disinformation, while Chinese groups focus on industrial espionage and technology transfer, according to the BSI.

Recommendations against cyberattacks on Germany

BSI and Bitkom call for consistent attack surface management as a central lever. The agency recommends structured vulnerability management, security by design, established emergency plans and targeted preventive measures against ransomware. For SMEs, the BSI points to the CyberRisikoCheck according to DIN SPEC 27076 and state funding programs. Bitkom advises spending at least 20 percent of the IT budget on security. The current average stands at 18 percent. 39 percent of companies still have no emergency management in place for serious incidents. Regular employee training, network segmentation and supply chain security are considered minimum standards. Given the ongoing escalation, these measures will gain further importance in 2026, as cyberattacks on Germany remain at record levels.

Der Beitrag Cyberattacks on Germany 2025 cause record damage of 202 billion euros erschien zuerst auf Ilja Schlak InfoSec Blog.

What the BSI C5 2026 delivers

The Cloud Computing Compliance Criteria Catalogue has been Germany’s most important security standard for cloud providers and cloud users since 2016. It translates complex security requirements into auditable criteria and creates comparability between providers. C5 audits are carried out by certified public auditors who, after a successful examination, attest that a cloud provider meets the defined security criteria.

With the publication of the BSI C5 2026, the agency takes the technological developments of recent years into account. In terms of content and structure, the catalogue is closely aligned with the work on the European certification scheme EUCS and can in parts be read as its German interpretation. The current versions of the CSA Cloud Controls Matrix v4, ISO/IEC 27001:2022, and the NIS2 Directive were also taken into consideration.

New topics in the criteria catalogue

Three subject areas are addressed explicitly for the first time in the BSI C5 2026. Container management receives significantly more detailed requirements than in the previous version, reflecting a technology that has long become standard in modern cloud architectures. Confidential computing is anchored as an independent subject area, closing a gap that previous audit catalogues had barely been able to capture.

Particular attention should be paid to the inclusion of post-quantum cryptography. Chapter 5.8 contains comprehensive requirements for effective encryption, including the use of hybrid procedures intended to harden algorithms that are foreseeably becoming too weak. With this, the BSI is responding to a development that will only become operationally relevant for many cloud providers in the coming years, but whose preparation must already begin today.

Existing topics have been sharpened. Multi-tenancy separation and supply chain management are addressed more specifically than before. Classic areas such as the protection of customer data and incident management also remain a fixed component of the catalogue.

Structural changes and machine readability

Structurally, the catalogue has been significantly revised. C5 criteria now consist of distinct sub-criteria. Additional criteria are classified according to whether they sharpen existing basic criteria with stricter requirements or complement them with new requirements. This differentiation is intended to make auditing, mapping, and evaluation easier.

An important innovation will follow shortly: the catalogue will be made available in a machine-readable format for the first time, with YAML, XLSX, and PDF planned in both German and English. This will simplify its use within governance, risk, and compliance processes and create a common language for how cloud security is described, audited, and assessed. For the automation of audit processes and the integration into existing compliance platforms, this is a central step.

Relevance for regulated industries

For many sectors, a C5 attestation is hardly a voluntary distinction but rather a de facto market access requirement. In the digital healthcare sector, a Type 2 attestation has been mandatory since July 2025 whenever patient data is processed in a cloud environment. The C5 also serves as a key standard in the banking sector, in digital financial services, and for government bodies.

The effort required for a formal attestation remains high. The audit is extensive and cost-intensive, making it primarily feasible for established providers. For smaller and mid-sized cloud providers, the hurdle remains, even though the machine-readable provision of the catalogue may help reduce manual effort in the long run.

In addition to the security criteria described in the C5, the BSI plans to publish general sovereignty criteria for cloud computing solutions in the near future. This will create a second framework that addresses not only security questions but also aspects of digital sovereignty.

Recommendations for cloud providers and users

Cloud providers should carry out a gap analysis between their current setup and the requirements of the BSI C5 2026 at an early stage. Particular attention should be paid to the new subject areas of container management, post-quantum cryptography, and confidential computing, as these are where the largest gaps in existing environments are to be expected. Supply chain processes should also be reviewed, since the sharpened criteria call for stricter evidence regarding the security of subcontractors.

Cloud users should examine, in ongoing procurement procedures, whether existing C5:2020 attestations from their providers include a credible roadmap for the transition to the new catalogue. Information security officers should incorporate the catalogue into internal risk assessments at an early stage, particularly where regulatory requirements such as NIS2, DORA, or healthcare-sector obligations apply.

Der Beitrag BSI C5 2026: New Criteria Catalogue for Cloud Security erschien zuerst auf Ilja Schlak InfoSec Blog.

Cybersecurity Market Q1 2026 Reaches $6.3 Billion in Total Strategic Activity

The Q1 2026 Cybersecurity Market Review by Momentum Cyber documents a quarter of historic proportions. Across 211 financing rounds, a total of $3.8 billion flowed into cybersecurity companies – a 33% increase year-over-year. In parallel, M&A activity reached 108 transactions with $2.6 billion in disclosed deal value, the second-highest quarterly deal count in the sector’s 65-quarter tracking history. Combined, strategic activity in the cybersecurity market Q1 2026 totaled $6.3 billion.

The fact that financing volume outpaced M&A is a rare occurrence. According to Momentum Cyber, this has happened only four times since 2018. Analysts interpret this as evidence that the “Capital Super Cycle” thesis, first introduced in their annual Cybersecurity Almanac in January, is now playing out in real time. Three converging forces are driving this momentum: AI-powered innovation, a strengthening financial environment, and mounting consolidation pressure.

AI Security Dominates the Cybersecurity Market Q1 2026

The most striking signal of the quarter comes from the AI security segment. With 37 financing rounds and a 46% share of all capital deployed, AI security has established itself as the dominant investment theme. On the M&A side, the segment recorded 12 transactions – more than it saw in all of 2025. AI governance is emerging as a standalone investment theme, driven by growing requirements around AI risk management, autonomous agent oversight, and regulatory compliance.

The capital allocation follows a clear logic: enterprises are deploying AI faster than their security architectures can keep pace. Legacy solutions lack adequate visibility into the behavior of LLMs or agentic AI systems. Specialized vendors with purpose-built, AI-native platforms are moving into this gap.

Four New Unicorns and the Principle of Fewer but Larger Bets

The quarter produced at least four new cybersecurity unicorns: Tenex.AI, Aikido, Torq, and XBOW. Tenex.AI, backed by a16z, closed a $250 million Series B at a $1 billion valuation. The platform pursues an AI-native approach to managed detection and response. In total, ten financing rounds exceeded the $100 million mark, amounting to $1.8 billion combined – well above the 2025 quarterly average of six such rounds totaling $1.5 billion. The median valuation for these mega-rounds reached $1.85 billion.

On the final day of the quarter alone, March 31, at least $380 million was deployed across three significant Series B rounds. Momentum Cyber CEO Eric McAlpine commented that the gap between well-capitalized market leaders and the rest of the field is growing “sharper.” Companies that did not participate in the early Seed-to-C wave are now raising at a scale that reflects genuine investor conviction.

Strategic Buyers Drive M&A Dynamics

Strategic acquirers dominated M&A activity, accounting for 87% of disclosed transaction value in the cybersecurity market Q1 2026. The largest single contribution came from CrowdStrike with two acquisitions: the identity security platform SGNL for $740 million and browser security vendor Seraphic Security for an undisclosed amount that analysts estimate at approximately $400 million. Both acquisitions extend the Falcon platform with browser runtime protection and continuous identity authorization – capabilities that are becoming strategically critical as AI agents proliferate across enterprise environments.

Private equity firms were also active, accounting for 45% of deal flow across 49 transactions. Security services remained the highest-volume M&A sector with 44 deals. Annualized, 2026 is on pace for 437 transactions – well above last year’s record of 400.

Outlook

The cybersecurity market Q1 2026 confirms a trend that has been building since 2025: capital is increasingly concentrating on platform-capable companies with scalable, AI-native architectures. Strategic exits continue to outpace IPOs, with Momentum Cyber expecting a landmark exit within the next 12 to 18 months that could exceed the scale of the Wiz acquisition. Identity platforms continue to command premium valuations, and hyperscaler gravity is pulling security capabilities ever deeper into their ecosystems.

For CISOs, security leaders, and enterprise decision-makers, these figures carry concrete implications. The vendor ecosystem is simultaneously fragmenting and consolidating, requiring careful evaluation of product roadmaps and integration strategies. The dominance of AI security as an investment theme signals that organizations must fundamentally rethink their security architectures for AI workloads. Those who fail to secure AI agents, models, and data flows risk gaps that conventional tools cannot close. At the same time, the capital influx is intensifying competition for specialized talent – particularly in cloud security, identity management, and AI security governance.

Der Beitrag Cybersecurity Market Q1 2026 – Record Momentum in Funding and M&A erschien zuerst auf Ilja Schlak InfoSec Blog.

LiteLLM supply chain attack originated from the Trivy compromise

LiteLLM is a Python library that serves as a unified interface to over 100 AI model providers. It is downloaded approximately 3.4 million times per day from PyPI, with the majority being automated CI/CD runs. Circulating victim counts in the hundreds of thousands are unsubstantiated and should be treated with caution.

An LiteLLM supply chain attack report with all verified IOCs, detection commands and a four-phase incident response playbook is available for download.wiwiki

The attack path led through the Trivy CI/CD integration that had been compromised days earlier, which was covered in detail in a previous post. LiteLLM’s build pipeline used Trivy as a security scanner and installed it without version pinning. The compromised Trivy version exfiltrated a PyPI publish token from the GitHub Actions runner environment. Using this token, the threat actor TeamPCP uploaded two malicious versions directly to PyPI, bypassing the regular GitHub release process. Two-factor authentication was active on the maintainer accounts but was circumvented through the stolen API token. LiteLLM’s CEO confirmed this sequence publicly.

How the malicious code in the compromised versions works

Version 1.82.7, published on March 24 at 10:39 UTC, contained twelve lines of obfuscated Base64 code in the file proxy_server.py, executed upon importing the LiteLLM proxy module. Thirteen minutes later, version 1.82.8 followed with an additional, significantly more aggressive vector: a .pth file in the wheel root that Python automatically processes at every interpreter startup. This meant that not just importing the library, but any Python process in the affected environment triggered the malicious code — including pip, pytest or an IDE’s language server. A bug in this implementation caused uncontrolled process multiplication leading to RAM exhaustion, which is what led a developer at FutureSearch to discover the compromise.

The payload operated in three stages: First, it systematically collected credentials from the host, including SSH keys, AWS, GCP and Azure credentials, Kubernetes configurations, database passwords, Git credentials, shell histories and cryptocurrency wallets. It then encrypted the collected data with AES-256-CBC and RSA-4096 and transmitted it to the C2 domain models.litellm[.]cloud, which had been registered the day before. In a third stage, the malicious code installed a persistent backdoor at ~/.config/sysmon/sysmon.py with an accompanying systemd service and attempted to deploy privileged pods on every node in Kubernetes environments.

Who may be affected by the LiteLLM supply chain attack

PyPI quarantined the package at approximately 13:38 UTC, with final deletion of the compromised versions taking place in the afternoon. The conservative exposure window therefore extends from 10:39 to approximately 15:00 UTC. According to the official statement, users of the LiteLLM Docker image, the cloud variant or installations directly from the GitHub repository were not affected. However, any environment that performed an unpinned pip installation of LiteLLM during this window is potentially affected. This explicitly includes transitive installations: the initial discoverer at FutureSearch had never consciously installed LiteLLM — it was pulled in as a dependency by a Cursor MCP plugin.

All documented IOCs and persistence mechanisms to date relate to Linux systems. Whether and how the malicious code affects Windows or macOS is not documented at the time of publication, although the .pth mechanism itself is cross-platform.

What organisations should do now

To check whether systems are affected, run pip show litellm on all machines, CI/CD runners and Docker images, and search for the file litellm_init.pth in site-packages directories. If versions 1.82.7 or 1.82.8 are found, all credentials accessible on the affected system must be treated as compromised and rotated. This applies equally to SSH keys, cloud provider credentials, Kubernetes secrets, LLM API keys, database passwords and CI/CD tokens.

This incident is part of an ongoing campaign that, according to Endor Labs, Snyk and Wiz, has now traversed five ecosystems. The operational takeaway therefore extends beyond this individual case: pin dependencies, replace publish tokens with trusted publishing, introduce egress monitoring for development environments and stop treating CI/CD runners as trusted infrastructure — instead, treat them for what they are: potentially exposed systems.

LiteLLM supply chain attack originated from the Trivy compromise

The LiteLLM supply chain attack on March 24, 2026 compromised two PyPI versions of the popular Python library with a three-stage credential stealer. The malicious code collected SSH keys, cloud credentials, Kubernetes secrets and LLM API keys, encrypted them and transmitted them to an attacker-controlled domain. According to multiple security vendors, the attack is attributed to the same group that had compromised the Trivy scanner just days earlier.

LiteLLM is a Python library that serves as a unified interface to over 100 AI model providers. It is downloaded approximately 3.4 million times per day from PyPI, with the majority being automated CI/CD runs. Circulating victim counts in the hundreds of thousands are unsubstantiated and should be treated with caution.

An LiteLLM supply chain attack report with all verified IOCs, detection commands and a four-phase incident response playbook is available for download.

The attack path led through the Trivy CI/CD integration that had been compromised days earlier, which was covered in detail in a previous post. LiteLLM’s build pipeline used Trivy as a security scanner and installed it without version pinning. The compromised Trivy version exfiltrated a PyPI publish token from the GitHub Actions runner environment. Using this token, the threat actor TeamPCP uploaded two malicious versions directly to PyPI, bypassing the regular GitHub release process. Two-factor authentication was active on the maintainer accounts but was circumvented through the stolen API token. LiteLLM’s CEO confirmed this sequence publicly.

How the malicious code in the compromised versions works

Version 1.82.7, published on March 24 at 10:39 UTC, contained twelve lines of obfuscated Base64 code in the file proxy_server.py, executed upon importing the LiteLLM proxy module. Thirteen minutes later, version 1.82.8 followed with an additional, significantly more aggressive vector: a .pth file in the wheel root that Python automatically processes at every interpreter startup. This meant that not just importing the library, but any Python process in the affected environment triggered the malicious code — including pip, pytest or an IDE’s language server. A bug in this implementation caused uncontrolled process multiplication leading to RAM exhaustion, which is what led a developer at FutureSearch to discover the compromise.

The payload operated in three stages: First, it systematically collected credentials from the host, including SSH keys, AWS, GCP and Azure credentials, Kubernetes configurations, database passwords, Git credentials, shell histories and cryptocurrency wallets. It then encrypted the collected data with AES-256-CBC and RSA-4096 and transmitted it to the C2 domain models.litellm[.]cloud, which had been registered the day before. In a third stage, the malicious code installed a persistent backdoor at ~/.config/sysmon/sysmon.py with an accompanying systemd service and attempted to deploy privileged pods on every node in Kubernetes environments.

Who may be affected by the LiteLLM supply chain attack

PyPI quarantined the package at approximately 13:38 UTC, with final deletion of the compromised versions taking place in the afternoon. The conservative exposure window therefore extends from 10:39 to approximately 15:00 UTC. According to the official statement, users of the LiteLLM Docker image, the cloud variant or installations directly from the GitHub repository were not affected. However, any environment that performed an unpinned pip installation of LiteLLM during this window is potentially affected. This explicitly includes transitive installations: the initial discoverer at FutureSearch had never consciously installed LiteLLM — it was pulled in as a dependency by a Cursor MCP plugin.

All documented IOCs and persistence mechanisms to date relate to Linux systems. Whether and how the malicious code affects Windows or macOS is not documented at the time of publication, although the .pth mechanism itself is cross-platform.

What organisations should do now

To check whether systems are affected, run pip show litellm on all machines, CI/CD runners and Docker images, and search for the file litellm_init.pth in site-packages directories. If versions 1.82.7 or 1.82.8 are found, all credentials accessible on the affected system must be treated as compromised and rotated. This applies equally to SSH keys, cloud provider credentials, Kubernetes secrets, LLM API keys, database passwords and CI/CD tokens.

This incident is part of an ongoing campaign that, according to Endor Labs, Snyk and Wiz, has now traversed five ecosystems. The operational takeaway therefore extends beyond this individual case: pin dependencies, replace publish tokens with trusted publishing, introduce egress monitoring for development environments and stop treating CI/CD runners as trusted infrastructure — instead, treat them for what they are: potentially exposed systems.

Der Beitrag LiteLLM Supply Chain Attack – PyPI Packages Compromised with Credential Stealer erschien zuerst auf Ilja Schlak InfoSec Blog.

Trivy Supply Chain Attack Hits Releases, Actions, and the Chain of Trust

The Trivy supply chain attack was not caused by an ordinary vulnerability, but by the compromise of the official software supply chain. The incident affected not just isolated artifacts, but the trivy v0.69.4 release as well as the two GitHub Actions aquasecurity/trivy-action and aquasecurity/setup-trivy. The risk was severe: teams that had integrated Trivy into automated build and scan workflows could trust unchanged version references on paper while still executing malicious code behind the scenes.

According to Aqua’s security advisory on GitHub, an attacker used compromised credentials on March 19, 2026, to publish the official trivy v0.69.4 release, repoint 76 out of 77 version tags in trivy-action to malicious commits, and replace all seven tags in setup-trivy. The most sensitive aspect is that this was not just the insertion of a suspicious new version. The attackers rewrote existing tags that were already known and widely used in pipelines. Workflows that trusted @0.x.y instead of a fixed commit SHA could therefore pull compromised code on the next run without any visible change in the workflow definition itself.

How the Trivy Supply Chain Attack Became Possible

The most important new finding is that the March 19 incident did not emerge out of nowhere. According to Aqua’s current incident update, the attack chain began as early as late February 2026. At that stage, attackers exploited a misconfiguration in Trivy’s GitHub Actions environment, stole a privileged access token, and gained access to automation and release processes. Aqua has so far deliberately described the root cause in general terms as a misconfiguration. Community and incident-response analyses describe the initial entry path more technically as a risky pull_request_target scenario, in which public repositories can run externally triggered workflows with elevated privileges.

The later impact was made possible by the incomplete cleanup after the first incident on March 1. Aqua states openly that secrets and tokens were rotated, but that the process was not atomic. That created a multi-day window in which the already embedded attacker could capture newly issued credentials or credentials that had not yet been revoked at the same time.

How the Second Phase of the Trivy Supply Chain Attack Unfolded

On March 19, the attackers used this residual access to abuse the official chain of trust directly. The suspicious activity began at around 18:43 (GMT+1) with the manipulated Actions tags. According to Aqua, the compromised trivy v0.69.4 release was publicly available roughly between 19:22 and 22:42. For setup-trivy, the exposure window ended that same evening at around 22:44, while trivy-action remained affected until March 20 at about 06:40. These precise time windows matter operationally because they allow GitHub workflow runs, artifacts, and runner logs to be narrowed down very precisely.

Technically, the attack unfolded in several stages. In the trivy v0.69.4 release, a manipulated commit was prepared so that, instead of legitimate code, a malicious component could be fetched from a typosquatted domain; according to the advisory, validation in the release chain was also bypassed. Even more dangerous was the tag manipulation in the GitHub Actions. There, write access alone was enough to repoint tags to different commits via force-push. This exact mechanism is also described in CrowdStrike’s technical analysis: Git tags are convenient, but mutable. That makes them practical as CI/CD version anchors, yet inherently vulnerable from a supply chain security perspective.

Why Developers and Pipelines Barely Noticed the Attack

The injected malware was positioned so that it executed before the actual Trivy scan. That is why many affected workflows could still appear normal on the surface. The job continued to produce what looked like a legitimate scan result while sensitive data was being collected from runner memory and the local file system in the background. Aqua lists SSH keys, AWS, GCP, and Azure credentials, Kubernetes tokens, Docker configurations, .env files, Git credentials, and database credentials among the targeted data. Anyone affected during this window should therefore not treat a green pipeline run as a sign of safety.

There was also a fallback path for exfiltration. If direct data exfiltration failed and a suitable GitHub token was present, the malware was designed, according to Aqua, to create a public repository named tpcp-docs in the victim’s account and store the collected data there as a release asset.

As part of incident response, teams should therefore investigate GitHub audit logs, newly created repositories, release artifacts, and bot activity across organizational accounts.

The Trivy Supply Chain Attack Did Not End with Secret Theft

The Trivy incident did not stop at the theft of CI/CD secrets. According to current analyses, the compromised attack chain established additional persistence on affected developer systems and runners, meaning the risk extended well beyond the pipeline run itself. CrowdStrike describes how the malware ran before the legitimate Trivy scan and could harvest credentials without raising immediate suspicion, while Aqua classifies the incident as a multi-stage campaign whose origins go back to a compromise of the GitHub Actions environment in late February.

The second escalation stage is especially serious: according to the available analyses, the downstream infrastructure relied on an ICP-based dead-drop mechanism that allowed compromised systems to retrieve additional payloads. At the same time, the campaign spread into the npm ecosystem. As The Hacker News reported based on technical analyses, at least 47 npm packages were compromised as part of the so-called CanisterWorm campaign; their postinstall hooks searched for tokens, downloaded additional malicious components, and used compromised publisher privileges for further propagation. As a result, the Trivy incident evolved from a supply chain compromise into a much broader, self-propagating ecosystem threat.

Which Versions Were Affected and What Is Considered Safe Now

The compromised versions include trivy v0.69.4, all trivy-action tags from 0.0.1 through 0.34.2, and all setup-trivy tags from v0.2.0 through v0.2.6. Aqua lists trivy v0.69.3, trivy-action 0.35.0, and setup-trivy 0.2.6 as safe target versions. Environments that pulled containers by digest rather than by tag, or that had already pinned GitHub Actions to full commit SHAs, were not affected.

Trivy Supply Chain Attack Lessons Learned

The immediate operational takeaway is clear: every pipeline that executed an affected version during the known exposure windows should be treated as potentially compromised. That means rotating all secrets without exception, including cloud keys, registry tokens, deployment keys, GitHub tokens, and any other credentials available on runners. In self-hosted runner environments, simply updating to a clean version is not enough, because additional local files and credentials may already have been accessed.

Strategically, the case is as uncomfortable as it is instructive. A security tool itself became the distribution channel for an infostealer because a previously stolen token, incomplete remediation, and trust in mutable tags came together. The Trivy supply chain attack shows that modern software supply chains must not only be scanned for vulnerabilities, but also hardened against the abuse of their own automation privileges. Anyone whose only lesson is “upgrade to the next clean version” is missing the point. The real consequence is this: pin GitHub Actions to commit SHAs, sharply reduce token privileges, carry out rotations completely and simultaneously, and monitor CI/CD runners as if they were critical production systems.

The frequently cited attribution to TeamPCP remains secondary. From a defensive standpoint, what matters more right now is that the cause, the attack flow, and the affected versions are now described with growing confidence. The case is especially notable because it shows how quickly an attack on the build and release layer of a security tool can become a direct risk to developers, organizations, and downstream software supply chains.

Der Beitrag Trivy Supply Chain Attack Explained: Cause, Timeline, and CI/CD Impact erschien zuerst auf Ilja Schlak InfoSec Blog.

The latest figures from Australia and the most recent reliable benchmark for Germany do not primarily show two markets competing with one another, but rather the same development across two different economic regions: cybersecurity and information security are becoming visibly more important for businesses. Gartner expects information security spending in Australia to reach AU$7.5 billion in 2026, representing growth of 9.5% compared with 2025. For Germany, the latest publicly available forecast from Bitkom based on PAC data puts the market at €12.2 billion in 2026, equivalent to an increase of 9.9%.

Gartner not only confirms rising budgets, but also a shift in investment logic. Security services remain the largest spending category, while security software is growing the fastest. This is a typical signal of a market in which security is no longer seen as a selective product purchase, but as a permanent operational capability. Companies are investing simultaneously in technology, operational support, and additional resilience. The Bitkom forecast shows almost identical growth dynamics, indicating that the same development can also be observed in Germany.

The IT security market in 2026 signals a maturation process

The IT security market in 2026 is not growing simply because demand for more security products is increasing. It is growing because companies are going through a process of maturity. Cyber risks are increasingly no longer understood as an isolated IT problem, but as a business risk. Those who view cybersecurity as a technical discipline discuss tools, architectures, and measures. Those who interpret it strategically, and therefore correctly, speak about business continuity, trust protection, regulatory resilience, reputation, competitiveness, operational capability, and an organization’s ability to act in an emergency or crisis situation.

That this understanding is increasing is not just an abstract impression; it can be seen in the structure of spending. In Australia, security software is growing at an above-average rate because AI, data and application protection, and infrastructure security require additional investment. At the same time, security services remain dominant because implementation is becoming more complex and internal teams often cannot handle the growing operational burden on their own. Germany shows a very similar pattern of strong software growth and a high share of services. This constellation is typical of a market in which security is becoming embedded in the operational reality of companies.

The threat landscape is decisive and directional

The most important reason for this development remains the threat landscape. Over the past few years, companies have learned that cyber incidents are no longer limited to technical disruptions. They affect processes, supply chains, service availability, communication, liability issues, and in many cases the basis of trust with customers and partners. For this very reason, the way management evaluates security is also changing. Cybersecurity is taken more seriously where incidents are no longer viewed as exceptional cases, but as a realistic burden on day-to-day operations.

This view is also supported institutionally. In its Top Cybersecurity Trends for 2026, Gartner points to the combination of an accelerating threat landscape, regulatory volatility, geopolitical tensions, and the strong influence of AI. Germany’s BSI, in turn, states in its situation assessment that the IT security situation in Germany remains tense. Any organization operating digital processes, cloud platforms, identities, data flows, and AI-related applications in a state of critical dependency can no longer ensure business resilience without addressing these factors.

Regulation increases binding force

Regulatory pressure is an important catalyst here, but not the sole cause of the development. Above all, it makes security issues more binding, more documentable, and more comprehensible to boards, supervisors, and auditors. Security measures therefore no longer compete only with other IT projects, but become part of governance, risk, and compliance architectures. As a result, the status of cybersecurity shifts toward a matter of corporate governance.

Where demonstrable compliance, resilience, and organizational responsiveness become more important, demand automatically rises for services, consulting, managed services, and structured security programs. Companies are therefore investing not only in more protection, but in more resilient security organizations.

AI and the skills shortage are increasing the pressure to act

A second structural, and arguably disruptive, driver is AI. On the one hand, it creates new productivity potential; on the other, it also creates new attack surfaces, new governance requirements, and additional demands for data protection, access control, and monitoring. The IT security market in 2026 is therefore also growing because companies must secure AI, while security providers themselves are integrating AI into detection, analysis, and response. Security is becoming more technical, faster, and at the same time more demanding to manage. One interesting trend: AWS is replacing AI with senior engineers.

The skills shortage further reinforces this effect. Many companies now know that they must take cybersecurity more seriously at a strategic level. At the same time, they often lack the personnel depth required to fully meet new security requirements internally. That is precisely why the share of services remains high. External expertise becomes almost indispensable wherever security architectures, monitoring, incident response, and governance must be professionalized in parallel.

A new understanding of cyber threats?

The current figures from Australia and Germany should therefore primarily be read as indicators. They show that the understanding of the importance of cybersecurity is broadening and deepening. What is becoming apparent is a clear shift in priorities. Companies are increasingly treating information security as a prerequisite for stability, compliance, reputation as a competitive advantage, and robust digital transformation.

Security in the corporate reality must now be understood differently than it was only a few years ago. The threat landscape has become more concrete, regulatory expectations have increased, AI is adding complexity, and the economic consequences of insufficient protection have become more visible.

Der Beitrag The IT Security Market in 2026 Shows Why Cybersecurity Matters More erschien zuerst auf Ilja Schlak InfoSec Blog.

Amazon AWS AI Outages Show the Limits of Pure Automation

The discussion around AI in engineering is now being approached much more soberly at Amazon and AWS. It is no longer about the simple question of whether AI helps developers. That has long been clear. What should be clarified, however, is where AI reaches its limits in highly critical environments. It is precisely where production systems, access rights, internal documentation, and complex dependencies intersect that it becomes clear why companies, despite growing automation, are once again placing greater emphasis on human experience.

Several incidents that attracted attention both internally and publicly form the starting point of this debate. In December 2025, AWS experienced problems involving Cost Explorer. As Reuters reported, citing the Financial Times, an internal AI tool was connected to a prolonged disruption. Amazon later publicly disputed that characterization and said in a correction that this was not a large-scale AWS outage, but rather an issue affecting a single service in one region. The cause, it said, was misconfigured access, not simply an “AI error.” For the broader assessment, however, the communications line matters less than the underlying pattern: an AI-assisted process encountered insufficiently restricted permissions and weak safeguards.

A second incident intensified this debate in early March 2026. Amazon.com suffered an outage that affected product pages, checkout, and account data, among other things. Amazon told Reuters that the issue was related to a software code deployment. Downdetector recorded a peak of around 22,000 reports in the United States. In a later correction, Amazon then said that only one of the recent incidents had involved AI tooling at all. In that case, an engineer had followed inaccurate guidance that an AI system derived from an outdated internal wiki. That, too, is revealing. It shows that the problem did not necessarily lie in AI independently generating harmful code. Rather, the critical issue was the combination of an error-prone knowledge base, operational proximity to production, and a lack of human oversight at the right point in the process, in other words, the absence of a proper human-in-the-loop.

Why Amazon AWS AI Outages Are Making Senior Engineers More Important Again

In complex platform environments, it is not enough for a change to look reasonable on paper. What matters is the assessment of the so-called blast radius, meaning the question of what downstream effects an intervention can trigger across adjacent systems, permissions, deployments, dependencies, and rollback processes. This capability does not arise from technical knowledge alone, but above all from experience with real production systems, historical incidents, and organizational weaknesses.

That helps explain why companies like Amazon are once again relying more heavily on senior sign-off, peer review, humans-in-the-loop, and additional approval layers for critical paths. AI works quickly, but it does not automatically weigh risks the way an experienced engineer can in a live cloud environment, drawing on both professional and practical experience. AI can recognize patterns, formulate suggestions, and accelerate routine tasks. What it lacks is sound judgment in situations where incomplete information, contradictory documentation, or unusual system states collide.

Since October 2025, the announced job cuts at AWS have reportedly added up to around 30,000 corporate jobs, according to Reuters, or nearly ten percent of the corporate workforce. At the same time, AI-assisted tools and agentic systems have been integrated more aggressively into development and operational processes. While this combination increases speed, it can also thin out institutional memory. Senior engineers in particular fill that gap because they do not just evaluate the current proposed change, but also keep the platform’s history, known weaknesses, and recurring failure patterns in view.

Why Pure AI Automation Is Not Enough at AWS

The lessons learned are that pure AI automation is not sufficient in security-critical environments. A system can generate suggestions, modify files, execute commands, and accelerate workflows. But as soon as context becomes outdated, permissions are too broad, or security boundaries are poorly defined, the risk rises sharply. AI may be useful, fast, and in some cases cheaper, but it remains “just” a tool.

An AI tool with extensive permissions may not only recommend bad decisions, but in some cases operationalize them directly. If a model accesses outdated internal documentation or derives faulty conclusions from knowledge sources, an entirely new class of operational information security risks emerges. These include misconfigurations, improper privilege assignments, problematic infrastructure changes, and in the worst case, security vulnerabilities that can spread through CI/CD processes or internal administrative tools.

AWS itself has long described principles such as peer review, separation of duties, and controlled approvals for production-adjacent changes in its DevOps Guidance. These mechanisms now seem like a return to the basics. And those basics will remain essential for a long time to come: least privilege, the four-eyes principle, traceable approvals, and clear chains of responsibility

Der Beitrag Amazon AWS AI Outages Show Why Senior Engineers Still Matter erschien zuerst auf Ilja Schlak InfoSec Blog.

ENFORCERS project aims to make Europe’s industrial software more resilient

With ENFORCERS, a European research and innovation project has been launched to address an issue that concerns many manufacturers and operators of industrial systems: the lifecycle of industrial software. The lifecycle of automation software should not end with rollout. Instead, a structured lifecycle must be established for maintenance, optimization, and patch and update cycles. In addition, crisis scenarios also need to be taken into account. In OT environments that are segmented, heterogeneous, or only partially connected, this is often a balancing act for operators. This is exactly where the project is intended to help. According to the official project announcement from WIBU-SYSTEMS, the goal over the next three years is to expand cooperation between industry, cybersecurity providers, and research organizations so that security incidents, vulnerability management, certification, and secure software distribution are no longer handled in silos.

ENFORCERS project and its relevance for OT environments, critical infrastructure, and industry

The real strength of the ENFORCERS project lies in its focus on industrial software and automation. In traditional IT environments, patches, telemetry, and incident response can often be deployed centrally. In manufacturing, industrial networking, and OT, the reality is often very different. OT and ICS systems have very long lifecycles, cannot simply be stopped for maintenance, and are connected to networks that are intentionally isolated or only partially accessible. The ENFORCERS project is designed to close the gap between incident detection, coordinated response, trusted protection, and the secure redistribution of software in industrial environments.

ENFORCERS project combines incident response, certification, and secure updates

The initiators describe the initiative as a cybersecurity system platform that brings together multiple trusted entities into a secured system network. These include private Security Operations Centers that collect, correlate, and classify incident and vulnerability data, secure elements as trust anchors at OT edges and gateways, automated playbooks for vulnerability remediation, certification, and secure software updates, as well as mechanisms for cross-border data exchange while preserving data sovereignty.

This is a positive development, because supply chain security today is no longer just about the origin of components. It is also about the secure distribution of updates, the trustworthiness of build and signing processes, the traceability of vulnerabilities, and how quickly an incident in a partner network can be translated into coordinated countermeasures. ENFORCERS attempts to bring these issues together in a common framework instead of distributing them across individual products, teams, or national borders.

It is also important that the project involves not only cybersecurity providers, but also industrial companies. The project is coordinated by WIBU-SYSTEMS. According to the published information, the consortium includes Balluff, Schneider Electric, TTTech Computertechnik, Technology Nexus Secured Business Solutions, Infineon Technologies, Langlauf Security Automation, DYNAMIKI, AITAD, and ResilTech. Fraunhofer SIT supports the initiative as a research partner, while VDMA contributes industrial networking and policy expertise. This suggests that ENFORCERS is not intended to remain a lab exercise, but to be aligned with real-world requirements from automation, manufacturing, and industrial networking.

New EU requirements add pressure to the ENFORCERS project

The initiative becomes even more relevant in light of the EU’s regulatory framework. The project leaders explicitly place ENFORCERS in the context of NIS2 and the Cyber Resilience Act. The EU’s NIS2 framework requires member states and affected organizations to reach a higher level of maturity in risk management, reporting significant incidents, cooperation, and supply chain security.

At the same time, the Cyber Resilience Act increases the pressure on manufacturers of digital products to prove security not only at market entry, but throughout the entire lifecycle. This marks a major shift, especially for industrial software and connected automation components. Future requirements for secure default settings, vulnerability management, update processes, and reporting obligations will reach much deeper into development and operational workflows than many market participants have been used to.

The timeline

According to the published project information, the operational starting point was the kick-off meeting held on February 10 and 11, 2026, in Karlsruhe. The press release announcing the official launch followed on March 11, 2026. In the early phase of the project, the focus is on legal and technical requirements, the system architecture, and initial SOC and platform components. Demonstrators and validation are planned for later stages. That is a typical progression for a three-year EU project, but it also shows that anyone expecting market-ready results today will need to be patient.

Nevertheless, the launch of the project is notable from an industry perspective. While many debates around industrial cybersecurity still move between product compliance, incident response, supply chain risks, and digital sovereignty, ENFORCERS attempts to bring these lines together. Whether this will ultimately result in a transferable model for different sectors will only become clear once the announced demonstrators and best practices are delivered. What is already clear, however, is that the project addresses a topic that is only likely to grow in importance under the EU’s new rules.

Der Beitrag ENFORCERS Project Strengthens Cybersecurity for Industrial Software in Europe erschien zuerst auf Ilja Schlak InfoSec Blog.

Veeam Backup vulnerabilities in versions 12 and 13 in detail

Veeam has fixed several serious vulnerabilities in Backup & Replication that can be clearly broken down by the affected major versions 12 and 13. What makes this especially critical is that this is not just about classic remote code execution on the backup server, but also about a case involving the Backup Viewer role, manipulated files in repositories, exposed SSH credentials, and local privilege escalation on Windows-based systems. According to Veeam for version 12, Veeam for version 13, and the BSI warning, the issue is already considered critical; the current Veeam build overview has listed the fixed releases as the current builds since March 13, 2026.

The affected builds are version 12.3.2.4165 and older version 12 builds in the 12.x branch, and version 13.0.1.1071 and older version 13 builds in the 13.x branch. According to the vendor, the fixes are available starting with 12.3.2.4465 and 13.0.1.2067 respectively. One distinction is especially important for readers: some vulnerabilities require an authenticated domain user, others require an existing role-based account within the backup environment, and others require local access to Windows systems. That is what makes the overall situation so concerning, because these layered privilege profiles are often already present in real-world networks or can be reached quickly after an initial breach.

Veeam Backup vulnerabilities in version 12

In version 12, the focus is on several critical attack paths targeting the backup server itself, as well as one particularly problematic case involving repositories and a local privilege escalation issue on Windows-based servers.

• CVE-2026-21666 – CVSS 9.9
  This vulnerability allows an authenticated domain user to achieve remote code execution on the backup server. What makes it so critical is that no local access is required, and an existing domain account may be enough to directly target the central backup node. Once the backup server is in scope, the risk no longer concerns just individual jobs, but potentially the entire backup and recovery logic.
• CVE-2026-21667 – CVSS 9.9
  This issue also enables remote code execution by an authenticated domain user on the backup server. From an operational perspective, it is just as serious as CVE-2026-21666: attackers do not need full administrative privileges, only a suitable authenticated account in the domain context. For defenders, that means traditional network boundaries alone are not enough to reduce the risk.
• CVE-2026-21668 – CVSS 8.8
  This vulnerability allows an authenticated domain user to bypass restrictions and manipulate arbitrary files on a backup repository. That is exactly what makes this bug so dangerous: it is not primarily about immediate code execution, but about the integrity of the backups. Anyone who can tamper with files in a repository is attacking the trust foundation of recovery itself.
• CVE-2026-21672 – CVSS 8.8
  This is a local privilege escalation vulnerability on Windows-based Veeam servers. At first glance, bugs like this may seem less dramatic than a network-based RCE, but in partially compromised environments they are extremely valuable. Anyone who already has a limited foothold on a system can use it to gain elevated privileges and prepare the next step toward full compromise.
• CVE-2026-21708 – CVSS 9.9
  This vulnerability allows a Backup Viewer to achieve remote code execution as the postgres user. That point stands out in particular: the entry point is not a classic administrator role, but a seemingly smaller one. That is the real core of the issue, because many organizations assign viewer roles for control, reporting, or audit purposes and may therefore underestimate their risk.

Veeam Backup vulnerabilities in version 13

The situation in version 13 is similarly critical, but somewhat broader. In addition to RCE on the backup server, it also includes theft of stored SSH credentials and a separate case affecting HA deployments of the Veeam Software Appliance.

• CVE-2026-21669 – CVSS 9.9
  An authenticated domain user can achieve remote code execution on the backup server. This is the direct parallel to the most critical cases in version 12. What makes it especially severe is that the attack targets the central orchestration point of data protection, putting not only data but also recovery processes at risk.
• CVE-2026-21670 – CVSS 7.7
  This vulnerability allows a low-privileged user to extract stored SSH credentials. While the score is lower than the 9.x issues, the practical value for attackers remains high. Credentials are often the lever for lateral movement, repository access, or pivoting into other infrastructure segments in backup environments.
• CVE-2026-21671 – CVSS 9.1
  Here, an authenticated user with the Backup Administrator role can execute code in high-availability deployments of the Veeam Software Appliance. What makes this issue special is that it does not affect every installation equally, but specifically targets HA scenarios. Anyone using this operating model should therefore treat it not just as a generic patch, but as a potentially business-critical configuration issue.
• CVE-2026-21672 – CVSS 8.8
  As in version 12, this is a local privilege escalation issue on Windows-based Veeam servers. In chained attacks, a flaw like this is especially valuable because it can turn a limited presence on the system into a more privileged position very quickly.
• CVE-2026-21708 – CVSS 9.9
  Version 13 is also affected by a flaw that allows a Backup Viewer to trigger remote code execution as the postgres user. From a prioritization standpoint, this is one of the most important points. The vulnerability shows that not only classic admin roles need to be reassessed, but also roles that many environments routinely assign with far less scrutiny.

Criticality of these vulnerabilities

In version 12, the immediate RCE and repository risks dominate, while version 13 adds a stronger appliance and credential angle. For patch and change teams, this separation is useful because it allows them to derive immediate actions: prioritize Windows-based backup servers, review HA appliance deployments separately, reassess roles such as Backup Viewer and Backup Administrator, and rotate stored SSH credentials after the update wherever possible.

Anyone running Veeam Backup & Replication version 12 or 13 should not only patch, but also review role assignments, network access to the backup server, and protection of the repositories. That is where the difference is made between a critical security bulletin becoming just an administrative task or a genuine resilience incident.

Der Beitrag Veeam Backup vulnerabilities in versions 12 and 13 require immediate patching erschien zuerst auf Ilja Schlak InfoSec Blog.

Detecting 5G attacks with AI in O-RAN networks

The University of Surrey presented a research project on an AI-based defense approach for 5G networks on March 10, 2026. According to the university, the TwinGuard framework detected and blocked complex attacks in two test environments in under 100 milliseconds. The focus is on Handover Flooding and E2 Subscription Flooding, meaning attacks against control and signaling processes in open mobile network architectures. For the security assessment, the key point is that the announcement does not describe a new vulnerability with a CVE identifier, but rather a defense mechanism that was evaluated in research environments.

TwinGuard combines a digital twin of the network with reinforcement learning. According to the current sources, the digital twin continuously mirrors the state of the infrastructure and is updated at very short intervals. On that basis, the system is intended to distinguish normal behavior from suspicious behavior and trigger countermeasures before an attack can cause greater disruption to network operations. The approach addresses a problem that is becoming more important with O-RAN and virtualized cores: the more open and modular 5G architectures become, the larger the attack surface grows across interfaces, controllers, and software-defined components.

Detecting 5G attacks with AI in two test environments

The researchers tested TwinGuard in two different 5G scenarios. The first was a simulated multi-cell O-RAN setup with several radio cells. The second was a fully virtualized 5G core based on OpenAirInterface and controlled through FlexRIC. In both environments, the system reportedly detected and blocked attacks in less than 100 milliseconds. In Handover Flooding, mobility management is burdened by a large number of manipulated or induced handover events. In E2 Subscription Flooding, the controller is overloaded with requests in order to disrupt normal control functions. According to the university, the focus is explicitly on attacks against the control plane rather than classic vulnerability reports involving end devices or base station firmware.

This point matters for proper classification, because current headlines can quickly create the impression of an immediately deployable protection product. At present, however, TwinGuard is still a scientifically published defense approach that has been validated in realistic 5G test environments. The current sources also do not indicate any ongoing exploitation of these two attack scenarios in public mobile networks. The exploit status therefore remains limited to the research scenario described.

When could the technology be ready for deployment?

The current sources do not provide metrics for continuous use in production carrier environments. There is no robust data on false positives, resource requirements, throughput under load, integration into existing O-RAN deployments, or interoperability with vendor-specific implementations. The recent publications also leave open questions about regulatory and operational requirements for the safe use of a digital twin in a live environment.

Implications for 5G and 6G security

The security value of the research lies primarily in reaction time and its behavior-based approach. Traditional systems often rely on signatures or rules and only respond reliably once an attack pattern is already known. TwinGuard, by contrast, is designed to detect deviations from normal conditions while they are unfolding. In open 5G networks with many software-based components, that is fundamentally plausible because attacks there do not always match the familiar patterns of traditional IT environments. From a research perspective, the work is therefore relevant because it shows that AI-assisted defense can be intended not only for post-event analysis but also for very fast countermeasures within network control functions.

The current publications identify larger multi-cell environments as the next step. That suggests the authors themselves do not yet view the transition into production networks as complete. There are also currently no signs from vendors that TwinGuard has already been integrated into commercial O-RAN or 5G core products. As a mitigation concept, only the general research approach can therefore be named: digital twins plus reinforcement learning for early detection and blocking of suspicious control-plane activity.

Der Beitrag Detecting 5G attacks with AI – TwinGuard tested in O-RAN and 5G core environments erschien zuerst auf Ilja Schlak InfoSec Blog.