CSOonline

IB Photography – shutterstock.com Im Jahr 2010 war Office 365 eine einfache Suite mit Office-Anwendungen und zusätzlicher E-Mail-Funktion. Das hat sich 15 Jahre später mit Microsoft 365 geändert: Die Suite ist ein wesentliches Element in den Bereichen Kommunikation, Zusammenarbeit und Sicherheit. Dienste wie Entra, Intune, Exchange, Defender, Teams und SharePoint verfügen über Tausende von Konfigurationsdetails, die dafür sorgen, dass Unternehmen reibungslos und sicher laufen. Wenn diese verloren gehen, versehentlich gelöscht oder absichtlich geändert werden, hat das enorme Auswirkungen auf die Geschäftsabläufe. Dabei geht es um weit mehr als nur um Daten. Die Tenant-Konfigurationen sind die Blaupause für den Betrieb der M365-Umgebung. Einfach ausgedrückt: Wenn der Microsoft-365-Tenant ausfällt, fällt auch der Geschäftsbetrieb aus. Trotz dieser enormen Bedeutung der Tenant-Konfigurationen ist in der IT-Welt eine Fehlannahme weit verbreitet: Rund die Hälfte aller IT-Verantwortlichen geht fälschlicherweise davon aus, dass die nativen Backup-Lösungen von Microsoft einen umfassenden Schutz für wichtige Tenant-Konfigurationen, -Einstellungen und -Richtlinien bieten. Um es deutlich zu sagen: Microsoft sichert die Konfigurationen nicht und kann sie folglich auch nicht wiederherstellen. Dies liegt gemäß dem Modell der „shared responsibility“ in der Verantwortung der Anwender. Die Bedeutung der Tenant-Konfigurationen Tenant-Konfigurationen sind die digitale Grundlage für die Sicherheitslage und die betriebliche Integrität eines Unternehmens. Sie umfassen über 10.000 einzigartige Richtlinienelemente für kritische Dienste. Sie regeln den Benutzerzugriff, die Compliance und das Anwendungsverhalten, also alles, was für den reibungslosen Ablauf eines Unternehmens unerlässlich ist: Sicherheitseinstellungen: Diese erste Verteidigungslinie umfasst Richtlinien für den bedingten Zugriff, die festlegen, wer von wo aus auf was zugreifen darf, sowie Regeln für die Multi-Faktor-Authentifizierung (MFA). Gehen diese Einstellungen verloren oder werden sie manipuliert, haben Angreifer ein leichtes Spiel und können Perimeter-Kontrollen einfach umgehen. Identitätsmanagement: Nahezu jedes Unternehmen (95 Prozent) war in den vergangenen 18 Monaten von einer Cloud-bezogenen Sicherheitsverletzung betroffen, wobei die meisten davon auf unsichere Identitäten zurückgeführt werden konnten. Benutzer- und Gruppeneinstellungen, Administratorrollen und App-Berechtigungen in Entra ID (ehemals Azure AD) bilden den Kern der Identitätssicherheit. Wenn diese kompromittiert werden, bricht das gesamte Framework zusammen. Compliance-Richtlinien: In regulierten Branchen ist der Nachweis der Regeltreue unverzichtbar. Policies zum Schutz vor Datenverlust (Data Loss Prevention, DLP) verhindern, dass sensible Informationen das Unternehmen verlassen, während Aufbewahrungsrichtlinien sicherstellen, dass Daten für rechtliche und Prüfungszwecke aufbewahrt werden. Kann ein Unternehmen die Einhaltung der Vorgaben nicht nachweisen, drohen empfindliche Strafen. Einstellungen für die Zusammenarbeit: Richtlinien in Teams, SharePoint und Exchange regeln die externe Freigabe, den Gastzugriff und den Datenfluss. Wenn diese Einstellungen fehlen oder falsch konfiguriert sind, riskieren Unternehmen eine unkontrollierte Offenlegung von Daten. Dadurch vergrößert sich die Angriffsfläche erheblich. Die Integrität dieser Einstellungen ist das Rückgrat jeder Zero-Trust-Architektur. Ohne korrekte Konfigurationen lassen sich weder das Least-Privilege-Prinzip durchsetzen noch die Compliance einhalten. Entsprechend ist der Verlust der Konfigurationen keine bloße Unannehmlichkeit, sondern bedeutet einen erheblichen Kontrollverlust über die gesamte digitale Infrastruktur. Häufig übersehen, aber essenziell Das Fehlen von Konfigurations-Backups ist nicht nur eine potenzielle Security-Katastrophe, sondern spiegelt auch ein fundamentales Missverständnis darüber wider, was Microsoft 365 eigentlich ist. Dabei handelt es sich eben nicht um eine einfache Lösung. Vielleicht kann man es sich wie ein Glas Wasser vorstellen: Der Tenant ist das Glas und das Wasser sind die Daten. Nicht alle Vorfälle, die Konfigurationen gefährden, sind gleich schwerwiegend. Auf der einen Seite des Spektrums können geringfügige Manipulationen an wichtigen Konfigurationen zwar ärgerlich sein, stellen jedoch keine existenzielle Bedrohung für das Unternehmen dar. Auf der anderen Seite könnten Sicherheitsverantwortliche damit konfrontiert werden, dass die Identitätsinfrastruktur und Sicherheitsvorkehrungen großflächig gelöscht worden, was eine Katastrophe mit potenziell existenzbedrohenden Folgen für das Unternehmen darstellt. Treten kleinere Fehlkonfigurationen auf, wie zum Beispiel versehentlich geänderten Berechtigungen eines einzelnen Benutzers, kann die Fehlerbehebung zwar Stunden dauern, stellt aber letztlich keine existenzielle Krise für das Unternehmen dar. Es ist vergleichbar mit einem angestoßenen Glas: Man kann es problemlos und ohne Risiko nutzen, auch wenn es nicht ideal ist. Wenn ein fehlerhaftes PowerShell-Skript einen bestimmten Dienst für eine begrenzte Anzahl von Benutzern unterbricht, verlangsamt dies die Produktivität und führt zu Störungen des Geschäftsbetriebs. Allerdings kann das Skript wiederhergestellt werden, auch wenn der Ausfall unbequem und zeitaufwändig ist. Dies ist vergleichbar mit einem gesprungenen Glas. Es ist zwar noch verwendbar, aber das Risiko für die Stabilität des Glases steigt. Ein vollständiger Verlust der Tenant-Konfigurationen führt schließlich zu massiven Ausfallzeiten und bedeutet für Unternehmen ohne Konfigurations-Backups das reine Chaos. Bedeutende Richtlinien wie Authentifizierung, E-Mail-Fluss oder Zugriffskontrolle wurden beschädigt, manipuliert oder versehentlich gelöscht, wodurch der gesamte digitale Arbeitsbereich unbrauchbar ist. Das Glas ist zerschellt. Erst wenn ein neues zur Verfügung steht, also der Tenant auf sichere Weise wiederhergestellt wurde, kann man auch wieder mit den Daten arbeiten (also das Wasser einfüllen, ohne dass es gleich wieder irgendwo ausläuft). Ohne Konfigurations-Backups, einschließlich Richtlinien, Berechtigungseinstellungen und Benutzerrollen, können Unternehmen nur mit enorm hohem Zeit- und Ressourcenaufwand zum sicheren Ausgangszustand zurückkehren. Deshalb führt an einem intelligenten Konfigurations-Backup kein Weg vorbei. Seit Jahren ist die Sicherung kritischer Daten für Unternehmen eine Selbstverständlichkeit. Es ist höchste Zeit, dass auch die Sicherung des Tenants flächendeckend umgesetzt wird. (jm) View the full article

IB Photography – shutterstock.com Im Jahr 2010 war Office 365 eine einfache Suite mit Office-Anwendungen und zusätzlicher E-Mail-Funktion. Das hat sich 15 Jahre später mit Microsoft 365 geändert: Die Suite ist ein wesentliches Element in den Bereichen Kommunikation, Zusammenarbeit und Sicherheit. Dienste wie Entra, Intune, Exchange, Defender, Teams und SharePoint verfügen über Tausende von Konfigurationsdetails, die dafür sorgen, dass Unternehmen reibungslos und sicher laufen. Wenn diese verloren gehen, versehentlich gelöscht oder absichtlich geändert werden, hat das enorme Auswirkungen auf die Geschäftsabläufe. Dabei geht es um weit mehr als nur um Daten. Die Tenant-Konfigurationen sind die Blaupause für den Betrieb der M365-Umgebung. Einfach ausgedrückt: Wenn der Microsoft-365-Tenant ausfällt, fällt auch der Geschäftsbetrieb aus. Trotz dieser enormen Bedeutung der Tenant-Konfigurationen ist in der IT-Welt eine Fehlannahme weit verbreitet: Rund die Hälfte aller IT-Verantwortlichen geht fälschlicherweise davon aus, dass die nativen Backup-Lösungen von Microsoft einen umfassenden Schutz für wichtige Tenant-Konfigurationen, -Einstellungen und -Richtlinien bieten. Um es deutlich zu sagen: Microsoft sichert die Konfigurationen nicht und kann sie folglich auch nicht wiederherstellen. Dies liegt gemäß dem Modell der „shared responsibility“ in der Verantwortung der Anwender. Die Bedeutung der Tenant-Konfigurationen Tenant-Konfigurationen sind die digitale Grundlage für die Sicherheitslage und die betriebliche Integrität eines Unternehmens. Sie umfassen über 10.000 einzigartige Richtlinienelemente für kritische Dienste. Sie regeln den Benutzerzugriff, die Compliance und das Anwendungsverhalten, also alles, was für den reibungslosen Ablauf eines Unternehmens unerlässlich ist: Sicherheitseinstellungen: Diese erste Verteidigungslinie umfasst Richtlinien für den bedingten Zugriff, die festlegen, wer von wo aus auf was zugreifen darf, sowie Regeln für die Multi-Faktor-Authentifizierung (MFA). Gehen diese Einstellungen verloren oder werden sie manipuliert, haben Angreifer ein leichtes Spiel und können Perimeter-Kontrollen einfach umgehen. Identitätsmanagement: Nahezu jedes Unternehmen (95 Prozent) war in den vergangenen 18 Monaten von einer Cloud-bezogenen Sicherheitsverletzung betroffen, wobei die meisten davon auf unsichere Identitäten zurückgeführt werden konnten. Benutzer- und Gruppeneinstellungen, Administratorrollen und App-Berechtigungen in Entra ID (ehemals Azure AD) bilden den Kern der Identitätssicherheit. Wenn diese kompromittiert werden, bricht das gesamte Framework zusammen. Compliance-Richtlinien: In regulierten Branchen ist der Nachweis der Regeltreue unverzichtbar. Policies zum Schutz vor Datenverlust (Data Loss Prevention, DLP) verhindern, dass sensible Informationen das Unternehmen verlassen, während Aufbewahrungsrichtlinien sicherstellen, dass Daten für rechtliche und Prüfungszwecke aufbewahrt werden. Kann ein Unternehmen die Einhaltung der Vorgaben nicht nachweisen, drohen empfindliche Strafen. Einstellungen für die Zusammenarbeit: Richtlinien in Teams, SharePoint und Exchange regeln die externe Freigabe, den Gastzugriff und den Datenfluss. Wenn diese Einstellungen fehlen oder falsch konfiguriert sind, riskieren Unternehmen eine unkontrollierte Offenlegung von Daten. Dadurch vergrößert sich die Angriffsfläche erheblich. Die Integrität dieser Einstellungen ist das Rückgrat jeder Zero-Trust-Architektur. Ohne korrekte Konfigurationen lassen sich weder das Least-Privilege-Prinzip durchsetzen noch die Compliance einhalten. Entsprechend ist der Verlust der Konfigurationen keine bloße Unannehmlichkeit, sondern bedeutet einen erheblichen Kontrollverlust über die gesamte digitale Infrastruktur. Häufig übersehen, aber essenziell Das Fehlen von Konfigurations-Backups ist nicht nur eine potenzielle Security-Katastrophe, sondern spiegelt auch ein fundamentales Missverständnis darüber wider, was Microsoft 365 eigentlich ist. Dabei handelt es sich eben nicht um eine einfache Lösung. Vielleicht kann man es sich wie ein Glas Wasser vorstellen: Der Tenant ist das Glas und das Wasser sind die Daten. Nicht alle Vorfälle, die Konfigurationen gefährden, sind gleich schwerwiegend. Auf der einen Seite des Spektrums können geringfügige Manipulationen an wichtigen Konfigurationen zwar ärgerlich sein, stellen jedoch keine existenzielle Bedrohung für das Unternehmen dar. Auf der anderen Seite könnten Sicherheitsverantwortliche damit konfrontiert werden, dass die Identitätsinfrastruktur und Sicherheitsvorkehrungen großflächig gelöscht worden, was eine Katastrophe mit potenziell existenzbedrohenden Folgen für das Unternehmen darstellt. Treten kleinere Fehlkonfigurationen auf, wie zum Beispiel versehentlich geänderten Berechtigungen eines einzelnen Benutzers, kann die Fehlerbehebung zwar Stunden dauern, stellt aber letztlich keine existenzielle Krise für das Unternehmen dar. Es ist vergleichbar mit einem angestoßenen Glas: Man kann es problemlos und ohne Risiko nutzen, auch wenn es nicht ideal ist. Wenn ein fehlerhaftes PowerShell-Skript einen bestimmten Dienst für eine begrenzte Anzahl von Benutzern unterbricht, verlangsamt dies die Produktivität und führt zu Störungen des Geschäftsbetriebs. Allerdings kann das Skript wiederhergestellt werden, auch wenn der Ausfall unbequem und zeitaufwändig ist. Dies ist vergleichbar mit einem gesprungenen Glas. Es ist zwar noch verwendbar, aber das Risiko für die Stabilität des Glases steigt. Ein vollständiger Verlust der Tenant-Konfigurationen führt schließlich zu massiven Ausfallzeiten und bedeutet für Unternehmen ohne Konfigurations-Backups das reine Chaos. Bedeutende Richtlinien wie Authentifizierung, E-Mail-Fluss oder Zugriffskontrolle wurden beschädigt, manipuliert oder versehentlich gelöscht, wodurch der gesamte digitale Arbeitsbereich unbrauchbar ist. Das Glas ist zerschellt. Erst wenn ein neues zur Verfügung steht, also der Tenant auf sichere Weise wiederhergestellt wurde, kann man auch wieder mit den Daten arbeiten (also das Wasser einfüllen, ohne dass es gleich wieder irgendwo ausläuft). Ohne Konfigurations-Backups, einschließlich Richtlinien, Berechtigungseinstellungen und Benutzerrollen, können Unternehmen nur mit enorm hohem Zeit- und Ressourcenaufwand zum sicheren Ausgangszustand zurückkehren. Deshalb führt an einem intelligenten Konfigurations-Backup kein Weg vorbei. Seit Jahren ist die Sicherung kritischer Daten für Unternehmen eine Selbstverständlichkeit. Es ist höchste Zeit, dass auch die Sicherung des Tenants flächendeckend umgesetzt wird. (jm) View the full article

CISO’s are increasingly turning to AI-enabled security technologies to augment their organizations’ cyber defense and extend the capabilities of their teams. According to Foundry’s latest Security Priorities Study, 73% of security decision-makers are now more likely to consider a security solution that uses artificial intelligence, up from 59% the year prior. CISOs plan to leverage AI in a range of security functions, including malware detection, threat detection, anomaly detection, real-time risk prediction, and audit and compliance. They are also eyeing AI for automating security responses, performing authentication, ensuring data loss prevention, and improving enterprise system visibility. CSO Survey respondents cited AI-enabled benefits such as faster detection of unknown threats, accelerating response times, and automating security tasks to reduce employee workload. The findings are in line with an October 2025 study from management consultancy PwC, which found AI ahead of cloud security and data protection as the top cybersecurity investment priority for enterprises over the next 12 months. But cutting through the hype to ensure AI investments have optimal impact remains an issue. Experts quizzed by CSO said that security leaders should prioritize AI investment over the next 12 to 18 months to boost anomaly detection, enhance identity and access management, and automate response, but they should also be aware of potential pitfalls such as hallucinations, over-reliance on AI, and governance gaps when implementing AI in their security strategies. Cutting through the noise Oliver Newbury, chief strategy officer at cyber resilience vendor Halcyon and previously CISO at Barclays, tells CSO that the “strongest uses of AI in security are the ones that improve visibility and reduce noise.” “Teams need clearer signals, earlier warnings, and quicker routes to certainty in the middle of an unfolding incident,” Newbury says. “AI that can sift large volumes of activity, highlight meaningful patterns, and present them in a way that analysts can act on immediately is where organizations see real benefit.” Newbury adds: “These capabilities help shorten investigation time and support faster, confident decision-making during high-pressure situations.” A human-led approach is no longer sufficient to deal with the increased complexity and volume of threats, many security experts contend. Strategic use of AI technology has the potential to recognize patterns of attack and offer analysts the ability to cut through the noise and make better decisions, freeing up time and resources to deal with higher-value security work and move beyond constant firefighting. “Most security teams are overloaded, and not because they lack tools, but because they lack time and clear signals,” Newbury says. “AI earns its keep in the areas where speed and pattern recognition genuinely outperform manual effort: behavioral anomaly detection, early-stage threat indicators, and the subtle identity-related activity that often precedes a ransomware event.” Check against delivery David Tyler, founder of tech consultancy Outlier Technology, warns that some vendors slap the label ‘AI’ on existing capabilities while adding a higher price tag combined with solid product development and real advances from others. “A lot of what’s being sold as breakthrough AI is actually decades-old technology finally being implemented properly; this isn’t necessarily bad, as good product management matters as much as novel algorithms,” Tyler says. “But if a vendor’s ‘AI security solution’ appeared overnight in the last couple of years, you’re probably looking at rebranding rather than genuine capability building.” CSO / Foundry CSOs should be asking how long the vendor has been investing in these capabilities and what their product evolution looks like, according to Tyler. “Companies that have been building graph-based correlation, adaptive baselining, and behavioral analytics for a decade are very different from those who just added an AI chat function to their user interface and called it innovation,” Tyler says. Dr. Andrew Bolster, senior manager of R&D at application security vendor Black Duck, also warns CISOs about vendors slapping neural networks onto existing tools without fixing underlying data quality issues. “Your AI-powered authentication system is only as good as your identity data hygiene,” Dr. Bolster says. “Your AI-powered malware detection is only as good as your sample corpus quality and labelling accuracy.” Dr Bolster adds: “Before signing contracts for AI security platforms, audit your data governance maturity.” Bolster also argues that CISOs themselves should focus more on how to build an AI-ready security data platform rather than which security tools they need to buy. “CISOs should invest in data mesh architectures that treat security telemetry as a first-class data product with defined ownership, quality SLAs [service level agreements], and standardized schemes,” he says. Building an AI security platform Merlin Gillespie, operations director at managed security services provider Cybanetix, sees the AI security market maturing — and moving away from point solutions that offer reduced operational expenditure toward a more integrated approach. Gillespie warns that this shift creates fresh challenges for security leaders. “These days every security tool has a layer of AI ‘assistance’ but instead of simplifying operations this is creating overlapping tools, inconsistent reporting, and unclear provenance of data,” according to Gillespie. “The learning is that AI-labelled tools are helpful but aren’t a solution in themselves.” The exercise most organizations face is classifying which processes are eligible for automation, and which of these are enhanced by the determinism and reasoning of AI, Gillespie advises. “Security teams should apply the same top-down analysis used across their wider business to support software and personnel efficiency, rather than being led by vendor tooling which can result in further siloing,” Gillespie says. Potential pitfalls Halcyon’s Newbury warned that these issues were far from the only potential pitfalls that come from deploying AI systems. For example, over-reliance on AI systems can lead to greater risk. “AI shouldn’t replace the fundamentals such as asset management, patching, identity governance, proper segmentation, or tested recovery plans,” Newbury says. “Those disciplines matter even more as attackers adopt AI at speed.” Issues inherited from the inadequate training of AI systems can also create problems. “AI systems can easily inherit blind spots if they’re trained on narrow or unrealistic datasets,” he says. “CISOs must understand how models are trained and where their assumptions break down.” Ransomware remains the clearest test of whether AI investment is being prioritized in the right places, Newbury argues. “Most modern [ransomware] incidents are effectively identity-based attacks,” Newbury says. “Attackers are logging in rather than ‘hacking in,’ often armed with credentials harvested at scale by infostealers.” Newbury adds: “As adversaries fold AI into their operations, you’ll see more of these attacks landing faster and hitting harder. That makes the resilience question far more urgent.” Newbury concludes: “AI is worth the investment but only where it sharpens decision-making, reduces noise, and gives teams the time and clarity to act before a problem becomes a crisis.” View the full article

Lately, the Curl code library has been receiving a lot of AI-generated reports from users hoping to receive financial compensation from the tool’s bug bounty program. Going through all the reports has taken up so many resources that Curl has decided to eliminate compensation for bug hunters altogether. “AI slop and generally bad reports have only increased even more recently, so we have to make an attempt to slow down the river so as not to drown,” Curl’s chief administrator Daniel Stenberg said in a comment to Elektroniktidningen. Over the years, Curl has distributed a total of $101,020 in compensation for bug hunter reports. Curl is not alone in enduring the significant changes in the bounty industry due to AI-powered bug hunting, which democratizes and accelerates vulnerability discovery while also taxing bug bounty programs with false positives and “AI slop.” View the full article

A critical two-factor authentication bypass vulnerability in the Community and Enterprise editions of the GitLab application development platform has to be patched immediately, say experts. The hole is one of five vulnerabilities patched Wednesday as part of new versions of GitLab. Three are ranked High in severity, including the 2FA bypass issue, while the other two are ranked Medium in severity. GitLab says the 2FA hole, CVE-2026-0723, if exploited on an unpatched system, could allow an individual with knowledge of a victim’s ID credentials to bypass two-factor authentication by submitting forged device responses. It’s this hole that has drawn the attention of experts, because of the implications. The goal of multifactor authentication is to protect login accounts with an extra verification step in case usernames and passwords are stolen. If a threat actor can access an account, they can do almost unlimited damage to IT systems. In the case of GitLab, if critical code is sitting in a developer’s account, a threat actor could compromise it, notes David Shipley, head of Canadian-based security awareness training firm Beauceron Security. If that code is to be used in software that can be downloaded or sold to other organizations, then inserted malware could be spread in a supply chain attack. The latest example, Shipley said, is the Shai-Hulud worm, which is spreading because a developer’s account in the npm registry was hacked. If the code contains cloud secrets, he added, the threat actor could gain access to cloud platforms like Azure, Amazon Web Service, or Google Cloud Platform. Discovery of the 2FA bypass hole “is a reminder that these [security] controls are important,” Shipley said in an interview. “They absolutely help reduce a number of risks: Brute force attacks, password spraying, and so forth. But they will never be infallible. “This is not the first time someone has found a clever way to get around 2FA challenges. We have a whole series of attacks around session cookie capture which are also designed to defeat 2FA. So it’s important to remember this when someone drops some Silver Bullet thinking that ‘This magic solution solves it [authentication]’ or ‘That’s the bad MFA. Here’s the new MFA.’ And I include [trusting only] Yubikeys,” he said. “Yubikeys are amazing. They’re the next generation of 2FA. But because they are made for humans, eventually they will have some flaws.” Even if there weren’t flaws in these controls, employees might be tricked into giving up credentials through social engineering, he added. It would be easier for an attacker to use techniques like phishing to collect user credentials rather than forge a device credential to exploit this particular 2FA bypass, said Johannes Ullrich, dean of research at the SANS Institute. But, he added, once the attacker has access to valid passwords, they can log in to the GitLab server and perform actions on the source code — download it, alter it or delete it — just as a legitimate user would. What infosec leaders need to do This is why Cybersecurity 101 — layered defense — is vital for identity and access management, Shipley said. That includes forcing employees to have long, unique login passwords, monitoring the network for unusual activity (for example, if someone gets in without an MFA challenge recorded) and, in case all fails, an incident response plan. MFA bypass vulnerabilities are very common, noted Ullrich. “The core problem is usually that MFA was added later to an existing product,” he said, “and some features may not properly check if MFA was successfully completed.” When testing a multifactor authentication solution, infosec leaders should always verify that an application has not marked authentication as completed after the username and password were verified. Enabling MFA should not relax password requirements, he asserted. Users must still pick unique, secure passwords and use password managers to manage them. Secure passwords will mostly mitigate any MFA failures, Ullrich said. Any vulnerability found in GitLab is significant, he added. GitLab is typically used by organizations concerned enough about the confidentiality of their code that they want to run the platform on premises. GitLab ‘strongly’ recommends upgrades In describing the patches released Wednesday, GitLab said it “strongly” recommends all self managed GitLab installations be upgraded to one of the three new versions (18.8.2, 18.7.2, 18.6.4) for GitLab Community Edition (CE) and Enterprise Edition (EE). Those using GitLab.com or GitLab Dedicated – a single tenant software-as-a-service version – don’t have to take any action. The other vulnerabilities fixed in Wednesday’s updates are: CVE-2025-13927, a denial of service issue in Jira Connect integration. If exploited on an unpatched system, it could allow an unauthenticated user to create a denial of service condition by sending crafted requests with malformed authentication data. It carries a CVSS severity score of 7.5; CVE-2025-13928, an incorrect authorization issue. If exploited on an unpatched system, it could allow an unauthenticated user to cause a denial of service condition by exploiting incorrect authorization validation in API endpoints. It carries a CVSS severity score of 7.5; CVE-2025-13335, an infinite loop issue in Wiki redirects. Under certain circumstances, this hole could allow an authenticated user to create a denial of service condition by configuring malformed Wiki documents that bypass cycle detection. It has a CVSS score of 6.5; CVE-2026-1102 – a denial of service issue in an API endpoint that could allow an unauthenticated user to create a denial of service condition by sending repeated malformed SSH authentication requests. It has a CVSS score of 5.3. In keeping with standard GitLab practice, details of the security vulnerabilities will be made public on an issue tracker 30 days after the release in which they were patched. The new versions also include bug fixes, some of which, GitLab said, may include database migrations. In cases of single-node instances, a patch will cause downtime during the upgrade. In the case of multi-node instances, admins who follow proper GitLab zero-downtime upgrade procedures can apply a patch without downtime. View the full article

Internal testing, product demonstrations, and security training are critical practices in cybersecurity, giving defenders and everyday users the tools and wherewithal to prevent and respond to enterprise threats. However, according to new research from Pentera Labs, when left in default or misconfigured states, these “test” and “demo” environments are yet another entry point for attackers — and the issue even affects leading security companies and Fortune 500 companies that should know better. Researchers discovered that popular public training apps like Hackazon, Damn Vulnerable Web Application (DVWA), and OWASP Juice Shop have been frequently left accessible to the public internet, inadvertently exposing top vendors including Palo Alto Networks, Cloudflare, and F5. “This is not theoretical research,” Noam Yaffe, Pentera’s senior researcher and offensive security team lead, wrote in a technical blog post. His team discovered “clear evidence” that these attack vectors are being exploited in the wild to enable crypto miners, webshells, and persistence mechanisms. The attackers are believed to be of Eastern European origin. “This research proves that labeling something as ‘training’ or ‘dev’ doesn’t make it invisible to attackers,” Yaffe noted. “If it’s on the internet and it has cloud credentials, it’s a target.” Exposing crown jewels through seemingly harmless labs After identifying an exposed instance of Hackazon, a free, intentionally vulnerable test site developed by Deloitte, during a routine cloud security assessment for a client, Yaffe performed a five-step hunt for exposed apps. His team uncovered 1,926 “verified, live, and vulnerable applications,” more than half of which were running on enterprise-owned infrastructure on AWS, Azure, and Google Cloud platforms. They then discovered 109 exposed credential sets, many accessible via a low-priority lab environment, tied to overly-privileged identity access management (IAM) roles. These often granted “far more access” than a ‘training’ app should, Yaffe explained, and provided attackers: Administrator-level access to cloud accounts, as well as full access to S3 buckets, GCS, and Azure Blob Storage; The ability to launch and destruct compute resources and read and write to secrets managers; Permissions to interact with container registries where images are stored, shared, and deployed. Attackers maintained persistent access, moved laterally across networks, exploited cloud credentials and other sensitive information, and crypto-mined victim infrastructure. Further, Pentera’s researchers easily discovered active secrets such as Slack keys, GitHub tokens, and Docker Hub credentials, as well as real user data and proprietary source code. Alarmingly, in DVWA, 54% of instances discovered still used the default credentials ‘admin:password,’ and attackers could downgrade security settings in a single click (from “impossible” to “low”), making every built-in vulnerability “trivially exploitable,” Yaffe noted. “What began as a harmless lab could lead directly to an organization’s crown jewels,” he said. Real-world exploitations In one real-world instance, Pentera’s team discovered a misconfigured buggy web application (bWAPP) linked to Cloudflare cloud accounts running on Google Cloud Platform (GCP). bWAPP is a free, open source, deliberately insecure web app used for training purposes. Querying GCP’s metadata services, the researchers were able to impersonate default service accounts and gain read access to “hundreds” of storage buckets. Similarly, a DVWA linked to F5’s cloud accounts was found running on a GCP instance, again allowing the researchers to access numerous storage buckets containing logs and metric data. In addition, a misconfigured Palo Alto-linked DVWA app was identified running on AWS; Yaffe and his team used the attached IAM role and temporary credentials to gain full administrative access to the AWS account. Researchers also exfiltrated OAuth tokens for a GCP service account to assume its identity, and list and access specific bucket content. For instance, one “cloud_build” bucket stored .tgz files that attackers could easily download. The account was managed by an admin email and violated least privilege because it contained policy permission, Yaffe explained. “Even though this was a ‘dev’/ ‘training’ account, it contained highly sensitive secrets, credentials, and API tokens,” he said. In assessing these misconfigured, vulnerable applications, his team found “clear evidence” that they were already being fully exploited in the wild. Roughly 20% of the DVWA instances they discovered contained artifacts deployed by malicious actors, including: XMRig Crypto Miner actively running, sending proceeds to attacker-controlled wallets, and configured to run silently without user knowledge; A “sophisticated” watchdog script that maintained persistence even after a compromise had been discovered. This featured self-recovery, automated downloads, encrypted payload delivery, evidence deletion, and kill switches that threat actors could use to easily shut down operations; A PHP webshell that granted attackers the ability to read, write, delete, upload and download files; run operating system (OS) commands and scripts on remote machines; and access credentials, API keys, and other secrets embedded in source code. All discoveries were responsibly disclosed to the impacted organizations and were subsequently mitigated prior to publication, Yaffe emphasized. “These weren’t isolated incidents; they represented an organized, ongoing exploitation campaign,” he warned. What enterprises can do now To defend against this widespread threat, Yaffe and his team developed SigInt, a Python-based, large language model (LLM)-powered autonomous reconnaissance framework. The tool, which is available on GitHub, generates fingerprint signatures directly from a live target or GitHub repository, searches for matches, and applies confidence scoring. It also incorporates IP intelligence, cloud provider detection, attribution data, and provides analysis to support further investigation. Beyond this, Yaffe advised enterprises to “inventory everything” to establish a complete, up-to-date picture of all cloud resources, including ‘temporary’ and ‘test deployments,’ perform regular audits to scan for exposed services, and apply least privilege. “Never attach broad IAM roles to training or demo environments,” he said. Further, defenders should isolate training environments from production networks and apply the same monitoring and alerting to them as production environments, restrict their outbound internet access, document and enforce changes to default credentials pre-deployment, and set controls that expire temporary testing environments after a specified timeframe. “If it doesn’t have an end date, it will run forever,” Yaffe noted. Ultimately, he emphasized: “These are fixable problems. Basic hygiene … would have prevented every case we found.” View the full article

In July 2025, Ingram Micros suffered devastating consequences from a ransomware in which the IT distributor’s logistics were paralyzed for a week. It has now emerged that sensitive data was also leaked. As Ingram Micro confirmed in a mandatory filing with US authorities, more than 42,000 people are affected. The perpetrators reportedly obtained information from current and former employees as well as job applicants. In addition to basic personal data such as names and contact information, birth dates, ID numbers, and Social Security numbers were also disclosed. Furthermore, documents from application processes and employee evaluations were stolen. The IT distributor employs approximately 23,500 people worldwide. Shortly after the attack became public, the ransomware gang Safepay announced it had stolen 3.5 terabytes of data from Ingram Micro. The group emerged in September 2024 and is now one of the most active cyber gangs. View the full article

Oracle has handed security teams their first big patching workload of the year, with its latest quarterly update containing a hefty 337 security fixes across its product range, including 27 rated critical. This imposing number of patches won’t surprise anyone whose job it is to look after Oracle products; in 2025 the company averaged 344 per update, so 337 is in line with this. The first job with large updates like this is working out where to start and what to prioritize. That usually means assessing the flaws in core products while paying careful attention to severity. In terms of the latter, the good news is that, as far as Oracle knows, none of January’s vulnerabilities is being exploited in the wild. That means there are no zero days to worry about this time. There is no guarantee this won’t change, which is why security teams will pay closest attention to the 27 patches that map to 13 CVEs with a critical rating. There was a time when updates were about fixing flaws in proprietary code. Those days are long gone; a significant portion of the January update deals with issues affecting third-party code such as open source libraries used by Oracle inside its products. That’s also why individual CVEs now often generate multiple patches across different products, which can make assessing what to fix more demanding. A high-priority example of this is CVE-2026-21962 affecting the Oracle HTTP Server and Oracle Weblogic Server Proxy Plug-in. Given a maximum CVSS score of 10, this critical severity vulnerability is addressed by seven different patches, depending on which product contains the vulnerable code. CVE bloat Also confusing is the fact that some CVEs listed in the latest update relate to CVEs from previous quarterly updates. A notable example of this is CVE-2025-66516, rated 9.8 (critical) on CVSS, affecting Oracle Middleware Common Libraries and Tools, which has a precursor in CVE-2025-54988. It addresses the high-profile Apache Tika issue first discovered in August, whose scope was expanded to cover more components in December. This phenomenon of CVE bloat applies to around 50 of the vulnerabilities in the January update, in some cases with a single new CVE referring to multiple older CVEs. As for products, the biggest offender, with 56 patches to be applied, is the Zero Data Loss Recovery Appliance (ZDLRA); almost all are fixes for third-party components. Despite 34 of these being described as remotely exploitable, only one has a new CVE identifier, the CVSS 3.1 (low) severity CVE-2026-21977. For anyone applying patches, this nuance is important; a product might only have one new CVE behind which lie multiple others identified in CVEs from other vendors. Just behind ZDLRA in patch volume are Oracle Enterprise Manager, with 51 patches, 47 of which can be remotely exploited without authentication, and Oracle E-Business Suite, with 38 patches, 33 of which are remotely exploitable. Despite Oracle’s comprehensive patching cycle, the company’s approach to security has not always been effective. In 2025, a threat actor claimed to have stolen six million records from a vulnerable Oracle server, a claim the company repeatedly denied. Security company CloudSEK later identified the vulnerability that led to the alleged hack as being CVE-2021-35587, an old issue that should have been patched. Presumably coincidentally, in August it was announced that long-serving chief security officer Mary Ann Davidson was leaving the company. View the full article

The European Commission has presented a new cybersecurity package to strengthen the European Union’s resilience to increasing cyber and hybrid attacks from state and criminal actors. The key is to reduce risks from high-risk suppliers outside the EU, especially in critical infrastructure such as mobile networks, through a common and risk-based framework. The Commission’s news release did not mention any specific suppliers targeted by the measures. The move should make it possible to reduce the risk to sensitive parts of the EU’s IT ecosystem based on previous work on 5G security. An updated European Cybersecurity Certification Framework (ECCF) will also make it faster and easier to security test products and services. The package also simplifies compliance with existing cybersecurity rules to reduce the administrative burden, especially for small and medium-sized enterprises. At the same time, the EU’s cybersecurity agency, ENISA, will be strengthened, among other things by giving it a more central role in threat analysis, incident response, vulnerability management, and coordination within the EU. The package of measures needs to be approved by the European Parliament and the EU Council of Ministers. Member states will then have one year to implement the changes in their national legislation. View the full article

Threat actors behind the long-running Contagious Interview campaign were seen expanding from traditional social-engineering lures to the abuse of Microsoft Visual Studio Code (VS Code) as an execution and persistence mechanism. According to new findings from Jamf Threat Labs, the actors are embedding malicious logic directly into VS Code project configurations, allowing code to execute as soon as a victim opens a repository and grants it “trust”. Rather than relying on standalone malware or exploit chains, the campaign now leans on trusted developer workflows. Victims are lured to clone Git repositories, often under the guise of interview assignments or shared projects. Once opened in VS Code, weaponized configuration files automatically trigger commands that fetch and execute malicious JavaScript payloads. Instead of targeting operating systems or browsers directly, the DPRK-linked actors are embedding themselves inside this IDE tool developers use every day, to reduce friction, evade suspicion, and achieve stealth within trusted environments. Weaponized VS Code for a persistent backdoor The new technique revolves around the abuse of Visual Studio Code’s tasks.json files, which are designed to automate development actions such as builds and scripts. In Jamf-observed attacks, these tasks’ definitions are modified to include hidden commands that execute automatically once the repository is opened and trusted by the user. Those commands run shell processes that retrieve obfuscated JavaScript from remote infrastructure and pipe it directly into Node.js for execution. Jamf researchers noted that the payloads are often hosted on legitimate platforms such as Vercel, further reducing the likelihood of early detection or blocking. Once running, the JavaScript establishes communication with a remote command-and-control server and enables remote code execution (RCE). Importantly, the backdoor does not depend on VS Code remaining open. After initial execution, the malicious code can persist independently, meaning closing the IDE does not stop the activity. This turns what appears to be a one-time development task into a long-lived foothold on the victim’s system. Social engineering to developer trust abuse The effectiveness of the campaign hinges on social engineering rather than technical exploitation. Victims are tricked into interacting with unfamiliar repositories as part of legitimate-looking projects. Once the repository is opened, VS Code’s built-in trust prompt becomes the key, and approving it enables the malicious task execution chain without further warnings. Jamf researchers also observed redundancy built into the attack flow. In some cases, attackers included fallback mechanisms, such as dictionary files containing embedded JavaScript, ensuring code execution even if the primary task-based delivery failed. Additional payloads were seen being fetched minutes after the initial execution, suggesting layered persistence and ongoing control. The researchers shared indicators of compromise (IoCs) associated with the campaign, including malicious infrastructure and artifacts observed during the investigation, to support detection. Additionally, they recommended caution while interacting with unfamiliar repositories, particularly those obtained through third parties or interview-style engagements. “Before marking a repository as trusted in Visual Studio Code, it’s important to review its contents,” they added in a blog post. “Similarly, ‘npm install’ should only be run on projects that have been vetted, with particular attention paid to package.json files, install scripts, and task configuration files to help avoid unintentionally executing malicious code.” View the full article

JHVEPhoto | shutterstock.com Im Juli 2025 sorgte ein Ransomware-Angriff für verheerende Folgen bei Ingram Micro: Die Logistik des IT-Distributors wurde eine Woche lahmgelegt – davon betroffen war nicht nur der Hauptsitz in den USA, sondern auch der Standort in Deutschland. Nun hat sich herausgestellt, dass dabei auch sensible Daten abgeflossen sind. Wie Ingram Micro in einer Pflichtmitteilung an US-Behörden bestätigt, sind davon mehr als 42.000 Personen betroffen. Die Täter sind demnach an Informationen von aktuellen und ehemaligen Mitarbeitern sowie Bewerbern gekommen. Neben Stammdaten wie Namen und Kontaktinformationen wurden dabei auch Geburtsdaten, Ausweis- und Sozialversicherungsnummern offengelegt. Zudem wurden Unterlagen aus Bewerbungsverfahren und Mitarbeiterbeurteilungen entwendet. Der IT-Distributor beschäftigt weltweit rund 23.500 Mitarbeiter. Kurz nachdem der Angriff bekannt wurde, hatte die Ransomware-Bande Safepay damals verkündet, 3,5 Terabyte Daten von Ingram Micro erbeutet zu haben. Die Gruppe ist im September 2024 aufgetaucht und zählt mittlerweile zu den aktivsten Cyberbanden. View the full article

The common vulnerability scoring system (CVSS) has long served as the industry’s default for assessing vulnerability severity. It has become one of the few “sources of truth” for cybersecurity professionals. And, you know the drill. A new CVE drops; it gets a CVSS score; teams rush to patch the items with the biggest numbers. It all feels logical, scientific — even objective. But in practice, it often fails us. In the cases of Equifax, SolarWinds and Log4Shell, a similar pattern has emerged: the actual damage did not stem solely from the technical severity of the flaws, but rather from the manner in which those flaws propagated through interconnected systems. High CVSS scores did not always correlate with high operational impact. Low-scoring assets triggered the cascading failures. Often, a “medium” vulnerability can have the most significant impact due to its location and the systems it interacts with. CVSS scores have enormous value as a starting point. They do not capture the relational dynamics. They do not demonstrate how one vulnerability’s exploitation may amplify or propagate risk through dependencies, shared credentials or inherited configurations. We have historically treated vulnerabilities as isolated points on a list, yet the actual risk lies in their connections. Why the CVSS score isn’t the whole story The CVSS rating system focuses on the characteristics of a single asset — how easy a flaw is to exploit, whether a patch exists and the potential confidentiality or availability impact. That’s important, and it’s a solid starting point. But it doesn’t account for something crucial: context. A vulnerability in a tightly isolated sandbox may score a 9.8 but never affect anything else. Meanwhile, a 5.2 in a single sign-on service, the system that every other system trusts, can become a blast radius multiplier. The score alone tells us nothing about how that flaw might ripple across the enterprise. In the real world, vulnerabilities don’t stay put. They move. They inherit privileges. They hitch rides through pipelines. They land in places no one expected. Risk isn’t only about severity. It’s about propagation. A different way to look at vulnerabilities This is where the unified linkage model (ULM) comes in. Instead of asking, “How bad is this vulnerability on its own?” ULM asks, “What can this vulnerability affect once it starts moving?” It focuses on three kinds of relationships: Adjacency: Systems that sit side by side and can influence each other, even without direct data exchange. Inheritance: Flaws that travel downstream — like a vulnerability hidden inside an open-source library embedded in dozens of applications. Trust: Systems that depend on each other’s integrity — like identity providers, update services or CI/CD tools. When you map these relationships, you stop seeing a list of vulnerabilities and start seeing a network of pathways. Suddenly, a seemingly minor flaw can reveal a much larger story. How vulnerabilities really move Modern development pipelines make it incredibly easy for vulnerabilities to spread unnoticed. A flawed library pulled into a build is included in a Docker image. That image gets promoted to production. The container gains new permissions. And eventually, an external endpoint exposes it to the internet. By the time someone sees the CVE notification, the vulnerability may already be alive inside mission-critical systems. The question isn’t just “What’s the score?” — it’s “Where can this go?” Revisiting Log4Shell through a linkage lens Log4Shell didn’t become historic because it was technically severe. Hundreds of vulnerabilities are rated critical every year. It became historic because it was everywhere. Log4j was inherited through nested dependencies, embedded in countless libraries and trusted by systems that consumed untrusted data. It was a perfect storm of inheritance, adjacency and trust. Log4Shell taught us that a vulnerability’s true danger lies not only in what it is, but in where it lives. What happens when we score based on linkage? ULM doesn’t replace CVSS scores. It enhances them. It forces us to think about depth, reach and influence. A vulnerability in a retired development VM might score 9.8. However, if nothing depends on it, its real-world priority may be low. Meanwhile, a flaw in a GitHub runner that feeds production builds could score much higher when evaluated through linkage. It sits in a trusted pipeline, inherits credentials and can influence downstream systems. In a ULM view, its urgency skyrockets. A number alone can mislead. A narrative reveals risk. How organizations can start using ULM today This doesn’t require a massive overhaul. It starts with a mindset shift: Map how systems connect, not just what systems exist. Look for shared components, shared identities, shared pipelines. Ask which systems others trust, depend on or inherit from. Then prioritize vulnerabilities based on where they sit in that network — especially those near identity systems, CI/CD pipelines or widely used shared services. These are the silent amplifiers. Start small. Focus on the systems with the most downstream influence. The picture will come into focus quickly. The bottom line Vulnerability management isn’t a numbers game. It’s a relationship game. CVSS tells us, in theory, how severe a vulnerability is. ULM helps us understand how dangerous it could be in practice. And in a world of accelerating complexity, automation and interconnected systems, that context is no longer optional. To defend our environments, we have to stop seeing vulnerabilities as dots. We have to start seeing the lines between them. That’s where the real risk lives. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

Jacek Wojnarowski – shutterstock.com Die EU-Kommission will umstrittene Anbieter von Netzwerktechnik künftig in Deutschland und anderen EU-Staaten verbieten können. Bei dem Vorschlag dürfte es insbesondere um chinesische Technologiefirmen wie Huawei und ZTE gehen. Hintergrund ist die Sorge vor Sabotage und Spionage durch Drittstaaten. Mit einer entsprechenden Rechtsgrundlage soll die EU-Kommission in letzter Instanz untersagen können, Technik besonders risikobehafteter ausländischer Unternehmen zu nutzen, wie aus einem Gesetzesvorschlag hervorgeht. In dem Entwurf der Kommission werden weder Unternehmen noch Länder genannt. Seit Jahren nachdrücklich wiederholte Empfehlungen der Europäischen Kommission an die EU-Länder, Technik von Huawei und ZTE aus Sicherheitsgründen nicht in ihren Mobilfunknetzen zu verwenden, könnten dadurch verpflichtend werden. Aus Sicht der Behörde schließen bislang zu wenig Länder die beiden Hersteller beim Betrieb von 5G-Mobilfunknetzen aus. 2023 hieß es aus der EU-Kommission, von den Herstellern ZTE und Huawei gingen wesentlich höhere Risiken aus als von anderen 5G-Anbietern. Spanien schloss im vergangenen Jahr zunächst dennoch einen millionenschweren Vertrag mit Huawei ab, was die zuständige Vizepräsidentin der EU-Kommission Henna Virkkunen kritisierte. Huawei und ZTE in deutschen Mobilfunknetzen viel verbaut Seit der Einführung der 4. Mobilfunk-Generation vor rund 15 Jahren bildeten Huawei und ZTE das Rückgrat der deutschen Mobilfunknetze (Telekom, Vodafone und vor allem O2 Telefónica). Die beiden chinesischen Ausrüster boten moderne Technologie zu Preisen an, mit denen europäische Konkurrenten wie Ericsson oder Nokia kaum mithalten konnten. Der Einsatz der ausländischen Technik geriet in den vergangenen Jahren jedoch wegen vermuteter Sicherheitsrisiken und potenzieller Einflussnahme durch China immer stärker in die Kritik. Während des Handelskriegs zwischen den USA und China wuchs die Sorge vor Spionage und Sabotage. So wurde befürchtet, dass Inhalte abgehört oder Netze aus der Ferne abgeschaltet werden könnten. Nach jahrelangem Ringen einigte sich in Deutschland im Sommer 2024 das Bundesinnenministerium mit den Netzbetreibern. Demnach dürfen in 5G-Kernnetzen bis spätestens Ende 2026 keine Komponenten von Huawei und ZTE mehr eingesetzt werden. Auf Funkmasten kann noch bis Ende 2029 chinesische Technik verwendet werden. Verbote in anderen Bereichen kritischer Infrastruktur möglich Konkret würde der nun von der EU-Kommission vorgeschlagene Mechanismus es den Brüsseler Netzwächtern erlauben, zusammen mit den Mitgliedstaaten eine Risikobewertung für bestimmte Hersteller zu veranlassen. Wird ein Anbieter als zu risikobehaftet gesehen, könnte die Kommission ihn in einem letzten Schritt auf eine entsprechende Verbotsliste setzen. Technik von Herstellern auf dieser Liste dürfte dann nicht mehr in der kritischen Infrastruktur von EU-Ländern verbaut werden, bestehende Komponenten müssten nach dem Vorschlag binnen drei Jahren ersetzt werden. Komponenten nicht nur im Mobilfunk weit verbreitet Die Bedenken von Experten gegen den Einsatz von Technik aus China betreffen nicht nur den Mobilfunk. Auch in anderen Bereichen der kritischen Infrastruktur, etwa der Bahn, im Energiesektor oder in städtischen Netzen wurden jahrelang Geräte von Huawei oder ZTE verbaut. So ist Huawei etwa Weltmarktführer bei Wechselrichtern für Solaranlagen. Diese smarten Geräte sind ans Netz angeschlossen. Hier befürchten manche Experten ein spezielles Bedrohungsszenario: Wenn ein feindlicher Akteur Tausende dieser Wechselrichter gleichzeitig abschalten oder manipulieren könnte, wäre die Stabilität des Stromnetzes gefährdet. Auch hier könnte die EU-Kommission dem Gesetzesvorschlag nach zukünftig tätig werden und Hersteller, die ihrer Ansicht nach mit Sicherheitsrisiken verbunden sind, prüfen und ausschließen. Bevor die Vorschläge der EU-Kommission umgesetzt werden und die Brüsseler Behörde damit tatsächlich weitreichendere Befugnisse bekommt als bisher, müssen sich das Europaparlament und die EU-Staaten noch mit den Ideen auseinandersetzen. Sie können dabei auch Änderungsvorschläge machen. EU-Agentur für Cybersicherheit soll bei Abwehr helfen Die EU-Kommission will zudem die EU-Cybersicherheitsagentur ENISA mit mehr Befugnissen aufrüsten – und ihr damit auch mehr Aufgaben zu geben. So soll die Agentur mit Sitz in Griechenland etwa gemeinsam mit den nationalen Behörden sogenannte Ransomware-Attacken abwehren. Ransomware ist Schadsoftware, die Daten und Systeme verschlüsselt und erst gegen Zahlung eines Lösegelds wieder freigibt. Wie folgenreich solche Cyberangriffe für die Menschen in Europa sein können, hatten zuletzt etwa die zahlreichen Ausfälle und Verspätungen an mehreren europäischen Flughäfen im September des vergangenen Jahres gezeigt. Nachdem ein IT-Dienstleister mit einer Schadsoftware angegriffen wurde, kam es an Flughäfen in Berlin, Brüssel, Dublin und London Heathrow tagelang zu Problemen bei der Passagier- und Gepäckabfertigung. Zusammen mit den Mitgliedstaaten soll ENISA zudem Schwachstellen in der Cybersicherheit identifizieren und zusätzliche EU-weite Standards festlegen. Für ihre neue Verantwortung bekommt die Agentur den Plänen der EU-Kommission nach dann etwa 100 neue Mitarbeitende zusätzlich sowie deutlich mehr Geld. Auch mit diesen Vorschlägen der Kommission müssen sich das Europaparlament und die EU-Staaten noch befassen. (dpa/jm) View the full article

Jacek Wojnarowski – shutterstock.com Die EU-Kommission will umstrittene Anbieter von Netzwerktechnik künftig in Deutschland und anderen EU-Staaten verbieten können. Bei dem Vorschlag dürfte es insbesondere um chinesische Technologiefirmen wie Huawei und ZTE gehen. Hintergrund ist die Sorge vor Sabotage und Spionage durch Drittstaaten. Mit einer entsprechenden Rechtsgrundlage soll die EU-Kommission in letzter Instanz untersagen können, Technik besonders risikobehafteter ausländischer Unternehmen zu nutzen, wie aus einem Gesetzesvorschlag hervorgeht. In dem Entwurf der Kommission werden weder Unternehmen noch Länder genannt. Seit Jahren nachdrücklich wiederholte Empfehlungen der Europäischen Kommission an die EU-Länder, Technik von Huawei und ZTE aus Sicherheitsgründen nicht in ihren Mobilfunknetzen zu verwenden, könnten dadurch verpflichtend werden. Aus Sicht der Behörde schließen bislang zu wenig Länder die beiden Hersteller beim Betrieb von 5G-Mobilfunknetzen aus. 2023 hieß es aus der EU-Kommission, von den Herstellern ZTE und Huawei gingen wesentlich höhere Risiken aus als von anderen 5G-Anbietern. Spanien schloss im vergangenen Jahr zunächst dennoch einen millionenschweren Vertrag mit Huawei ab, was die zuständige Vizepräsidentin der EU-Kommission Henna Virkkunen kritisierte. Huawei und ZTE in deutschen Mobilfunknetzen viel verbaut Seit der Einführung der 4. Mobilfunk-Generation vor rund 15 Jahren bildeten Huawei und ZTE das Rückgrat der deutschen Mobilfunknetze (Telekom, Vodafone und vor allem O2 Telefónica). Die beiden chinesischen Ausrüster boten moderne Technologie zu Preisen an, mit denen europäische Konkurrenten wie Ericsson oder Nokia kaum mithalten konnten. Der Einsatz der ausländischen Technik geriet in den vergangenen Jahren jedoch wegen vermuteter Sicherheitsrisiken und potenzieller Einflussnahme durch China immer stärker in die Kritik. Während des Handelskriegs zwischen den USA und China wuchs die Sorge vor Spionage und Sabotage. So wurde befürchtet, dass Inhalte abgehört oder Netze aus der Ferne abgeschaltet werden könnten. Nach jahrelangem Ringen einigte sich in Deutschland im Sommer 2024 das Bundesinnenministerium mit den Netzbetreibern. Demnach dürfen in 5G-Kernnetzen bis spätestens Ende 2026 keine Komponenten von Huawei und ZTE mehr eingesetzt werden. Auf Funkmasten kann noch bis Ende 2029 chinesische Technik verwendet werden. Verbote in anderen Bereichen kritischer Infrastruktur möglich Konkret würde der nun von der EU-Kommission vorgeschlagene Mechanismus es den Brüsseler Netzwächtern erlauben, zusammen mit den Mitgliedstaaten eine Risikobewertung für bestimmte Hersteller zu veranlassen. Wird ein Anbieter als zu risikobehaftet gesehen, könnte die Kommission ihn in einem letzten Schritt auf eine entsprechende Verbotsliste setzen. Technik von Herstellern auf dieser Liste dürfte dann nicht mehr in der kritischen Infrastruktur von EU-Ländern verbaut werden, bestehende Komponenten müssten nach dem Vorschlag binnen drei Jahren ersetzt werden. Komponenten nicht nur im Mobilfunk weit verbreitet Die Bedenken von Experten gegen den Einsatz von Technik aus China betreffen nicht nur den Mobilfunk. Auch in anderen Bereichen der kritischen Infrastruktur, etwa der Bahn, im Energiesektor oder in städtischen Netzen wurden jahrelang Geräte von Huawei oder ZTE verbaut. So ist Huawei etwa Weltmarktführer bei Wechselrichtern für Solaranlagen. Diese smarten Geräte sind ans Netz angeschlossen. Hier befürchten manche Experten ein spezielles Bedrohungsszenario: Wenn ein feindlicher Akteur Tausende dieser Wechselrichter gleichzeitig abschalten oder manipulieren könnte, wäre die Stabilität des Stromnetzes gefährdet. Auch hier könnte die EU-Kommission dem Gesetzesvorschlag nach zukünftig tätig werden und Hersteller, die ihrer Ansicht nach mit Sicherheitsrisiken verbunden sind, prüfen und ausschließen. Bevor die Vorschläge der EU-Kommission umgesetzt werden und die Brüsseler Behörde damit tatsächlich weitreichendere Befugnisse bekommt als bisher, müssen sich das Europaparlament und die EU-Staaten noch mit den Ideen auseinandersetzen. Sie können dabei auch Änderungsvorschläge machen. EU-Agentur für Cybersicherheit soll bei Abwehr helfen Die EU-Kommission will zudem die EU-Cybersicherheitsagentur ENISA mit mehr Befugnissen aufrüsten – und ihr damit auch mehr Aufgaben zu geben. So soll die Agentur mit Sitz in Griechenland etwa gemeinsam mit den nationalen Behörden sogenannte Ransomware-Attacken abwehren. Ransomware ist Schadsoftware, die Daten und Systeme verschlüsselt und erst gegen Zahlung eines Lösegelds wieder freigibt. Wie folgenreich solche Cyberangriffe für die Menschen in Europa sein können, hatten zuletzt etwa die zahlreichen Ausfälle und Verspätungen an mehreren europäischen Flughäfen im September des vergangenen Jahres gezeigt. Nachdem ein IT-Dienstleister mit einer Schadsoftware angegriffen wurde, kam es an Flughäfen in Berlin, Brüssel, Dublin und London Heathrow tagelang zu Problemen bei der Passagier- und Gepäckabfertigung. Zusammen mit den Mitgliedstaaten soll ENISA zudem Schwachstellen in der Cybersicherheit identifizieren und zusätzliche EU-weite Standards festlegen. Für ihre neue Verantwortung bekommt die Agentur den Plänen der EU-Kommission nach dann etwa 100 neue Mitarbeitende zusätzlich sowie deutlich mehr Geld. Auch mit diesen Vorschlägen der Kommission müssen sich das Europaparlament und die EU-Staaten noch befassen. (dpa/jm) View the full article

Increased reliance on IT service providers, digital tools, and third-party software is greatly expanding the enterprise attack surface, with noteworthy cyberattacks over the past year underscoring this fact. In October 2025, Marks & Spencer terminated its longtime helpdesk deal with outsourcing giant Tata Consultancy Services following a cyberattack that cost the British retailer an estimated £300 million and temporarily shut down its online business. In August, a Chinese threat group leveraged compromised OAuth tokens from third-party platform Salesloft Drift to exfiltrate sensitive business data — AWS keys, Snowflake tokens, passwords — from as many as 700 organizations. This came on the heels of a wave of attacks in which cybercriminal gang ShinyHunters pretended to be IT support personnel to trick users into connecting to malicious versions of Salesforce’s Data Loader, which was then used to exfiltrate data from Salesforce environments. All told, 1.5 billion Salesforce records were claimed to have been stolen. And, back in April, a critical zero-day vulnerability in SAP NetWeaver, one of the most widespread incidents involving an ERP platform, illustrated that enterprise software has become a prime target for attackers because their compromise directly impacts the revenue, operations, and reputation of an organization. “Adversaries continue to exploit the path of least resistance, increasingly targeting third-party providers and human vulnerabilities to bypass technical controls,” says Casey Corcoran, field CISO at Stratascale, the cybersecurity division of SHI International. “By compromising trusted vendors, attackers can move undetected for longer periods, exploiting established access points across multiple organizations.” Because these are newer avenues for attack, companies have been caught on their heels. “We don’t have enough preparation or defensive tools to rapidly detect and defend against these attacks, leading to a significant level of risk for lots of companies,” says Joshua Wright, faculty fellow of the SANS Institute and technical director at Cyber Hack Challenges. John Alford, CSO at TeraType, an adviser to pharmaceutical, financial, and SaaS firms on cybersecurity, compliance, audit and AI governance, says legacy mindsets are also to blame. “Many organizations still defend their environments as if threats march up to the front gate when in reality the most effective attackers slip in through the service corridors that nobody monitors,” Alford says. “The Marks & Spencer situation proved this: A help desk workflow became a quiet passage into production because it relied on trust by default.” There appeared to be no strong caller verification processes, no step-up checks, and no guardrails on what support staff could change, he adds. The Salesforce ecosystem breaches demonstrate another common blind spot: Once attackers capture a token or exploit a permissive integration, they gain the full authority of a trusted insider. “Companies that rely on perimeter controls and MFA alone never see this risk because they are not watching the right places,” Alford says. The CSO’s role in vetting IT vendors Cyber obligations are already written into IT services and SaaS contracts, but “there are limits to what companies can do,” says Stephen Lilley, partner at law firm Mayer Brown. “Companies are unlikely to be able to impose cyber requirements that go beyond what is commonly seen in the relevant market. And even sophisticated companies still experience cyber incidents — meaning that IT providers, like their customers, are unable to entirely eliminate the risk from these attacks.” Although risk eradication is not possible, better mitigation is. Here, CSOs can play a crucial role. “CSOs are uniquely able to see across the full business process — data flows, dependencies, and downstream impact — but many organizations still don’t use that perspective to reassess third-party risk as reliance grows,” says Randy Gross, CISO for CompTIA. “Cross-functional collaboration is a core CSO imperative: partnering early with procurement, legal, IT, and business leaders so security, resilience, and exit risk are designed in, not bolted on.” When engagements are initiated at the business-unit level or come in below financial approval thresholds, CSOs may not even be aware of them. “In many organizations, security leaders are brought in only after a contract is executed or — worse — after a security issue arises,” says Melissa Ventrone, leader of law firm Clark Hill’s cybersecurity, data protection, and privacy practice. “They should be involved … [and] their involvement does not need to slow the contracting process.” In fact, CSOs can act as a “pragmatic technology advisor” says CompTIA’s Gross, seeking critical information they are uniquely qualified to assess. Vital vendor questions CISOs should ask To gain that critical information, security leaders and experts recommend CSOs ask IT partners the following cyber-specific questions. 1. What attestation will you provide to prove proper security controls are in place? These are essential, says Juan Pablo Perez-Etchegoyen, CTO for cybersecurity and compliance platform Onapsis. Some of the most commonly used include: SOC 2 Type II Report: considered the gold standard audit for IT and cloud service providers ISO/IEC 27001 certification: an international standard for information security Cloud Security Alliance STAR: a registry specific to cloud providers that combines ISO 27001 with a controls matrix for cloud-related risks Industry-specific attestations: for example, HIPAA/HITRUST for handling healthcare data, or PCI DSS for storing or processing credit card data. 2. How do you maintain and update cybersecurity controls over time, and how will we be notified of material changes? Would-be clients should have IT partners complete a detailed due diligence questionnaire and contractually obligate them to notify the company of any material changes that would require updates to their responses, advises Clark Hill’s Ventrone. “At a minimum, IT vendors should be prohibited from changing security controls that would decrease the security, protection, or resiliency of its systems and company data,” she says. 3. Who on your team is capable of altering our identity posture, and what prevents a social engineered request from triggering that action? CSOs can begin with general access inquiries: what access the provider’s team has to customer systems and data, and how that access is segmented and secured, Stratascale’s Corcoran says. Access should be limited by role, with least privilege enforced and multifactor authentication, single sign-on, and network segmentation in place. Look for “logged, monitored, and immediately revocable access — ideally aligned with access control best practices from the NIST RMF function, which emphasizes least privilege and separation of duties,” Corcoran says. Then CSOs can get specific. “Many clients focus on firewalls, endpoint agents, and MFA while overlooking the trust pathways that attackers prefer to use,” Alford says. Help desk workflows, OAuth integrations, supplier support portals, and automation connectors typically get less scrutiny even though they can alter identity states or extract large volumes of data with a single action. CSOs should look for strictly defined role scopes, multi-step verification, step-up authentication, and approval chains for credential resets. “Anything short of that signals a blind spot that no amount of technical hardening will cover,” says Alford. 4. How can we verify the workflows you use when onboarding, offboarding, or resetting access, and can you show evidence of how these workflows performed last quarter? Many companies underestimate how much operational trust they blindly hand over to providers. IT partners should offer workflow maps, execution logs, and testing records, not just policy documents. “The most significant gaps appear in the places people assume are safe. I have seen mature organizations with strong 27001 programs, disciplined PCI controls, and well-run internal security teams fall to issues that lived entirely inside vendor workflows,” Alford notes. “Help desk resets, poorly scoped automation tokens, and inherited admin rights all surfaced in post-incident reviews as quiet pathways that no one had modeled.” Risk assessments should focus not just on servers and networks but identity workflows and human-operated processes as well. “When you widen the lens, you often discover controls that look strong on paper but behave differently in practice,” Alford says. 5. What independent testing do you conduct, and how often is it performed? IT partners should have a third party run security tests and assessments, and provide copies or executive summaries of these vulnerability scans, penetration tests, and other audits at least annually and whenever there are material changes to their network, infrastructure, or security controls, Clark Hill’s Ventrone says. ThreatLocker CEO Danny Jenkins stresses frequency: “Threats are always evolving, so a once-a-year audit is not sufficient. All systems should be undergoing regular penetration testing and improvement.” 6. Can you list every OAuth integration and privileged API relationship in your service and explain how each is scoped, rotated, monitored, and revoked? “OAuth integrations are often treated as harmless conveniences rather than high-privilege conduits,” Alford explains. “In reality, they function like a network of forgotten tunnels. They bypass the front gate entirely and connect systems deep inside the environment.” Companies should ask service partners to provide a token inventory, minimal scopes, finite lifetimes, and behavioral monitoring. Broad or permanent tokens are red flags, signaling elevated risk. 7. If an attacker abused one of your processes without breaching your systems, what are your contractual and operational commitments? “These agreements often hand providers the practical ability to alter identity states, access sensitive data, or operate parts of the production environment. That level of delegated trust deserves the same scrutiny as hiring a senior operations leader,” says Alford. “When providers can reset passwords or manage OAuth integrations, the contract becomes a control document. It defines how risk will be shared and what evidence the client can demand.” Without CSO involvement, contractual clauses are usually weak. “They focus on uptime rather than security, and they rarely require the provider to support strong authentication, tamper-evident logging, or event-level transparency,” Alford adds. Clients should insist on obligations tied to process compromise, not just system compromise. 8. What controls govern your staff’s activity in our environment, and how would we detect if a privileged session deviated from expected behavior? “Modern attacks flow through trust relationships and soft operational processes,” Alford points out. “They exploit the places where no one expects danger — like help desks.” As a result, controls on vendor staff behavior and detection of deviations are critical. Companies should insist on session recording, real-time alerts, and segregation of duties, Alford advises. “Rapid detection and revoking access can make all the difference in an incident,” Onapsis’ Perez-Etchegoyen adds. Continuous application-level monitoring, clear incident response procedures, and the ability to immediately disable users or integrations are key. 9. How will you isolate our assets and data from other customers — including identity separation, automation boundaries, and admin segregation? CSOs should seek architectural clarity and concrete mechanisms that limit blast radius, says Alford. They should also ask how the IT partner manages the cybersecurity risks posed by their value chains of vendors and subcontractors. “IT partners should have a robust vendor management program and conduct appropriate due diligence on their own service providers,” advises Ventrone. 10. How quickly will you notify us of a security incident that impacts our data or systems? “The biggest gains come from simple steps,” says CompTIA’s Gross, including gaining clarity on how incidents are disclosed and outages are handled. CSOs should look for guaranteed notification within 24 to 72 hours, a tested incident response plan, and clearly defined breach reporting timelines and responsibilities written into the contract, says Stratascale’s Corcoran. When an incident occurs, “IT partners should provide customers with sufficient information to perform their own threat analysis,” Alford says. “If an IT partner doesn’t provide the insight needed to identify attacks against their customers, then customer organizations can only rely on the detection and reporting capabilities of the hosting provider.” 11. How do you identify, prioritize, and remediate vulnerabilities? Review of IT partner’s patching policies and remediation timelines should never be overlooked, as many cyberattacks exploit known vulnerabilities. “Slow patch cycles lead to supply chain disruptions, business operational issues, and even bankruptcy in some cases,” says Perez-Etchegoyen, who emphasizes SLAs related to critical patches and proof that fixes are validated. Ventrone gives the example of a company that outsourced firewall management to a vendor. After a vulnerability in the firewall was exploited, the vendor ended up restoring the vulnerable version, resulting in a second compromise. In another example, a client found out that its IT partner, which had experienced a ransomware attack through its VPN, patched just once a month. “I literally could not believe this was considered sufficient,” Ventrone says. 12. Do you carry enough cyber insurance to cover the impact to all your customers? “We’re going to see a lot more attacks against SaaS providers,” says SANS Institute’s Wright. “Attackers have lots of motive here since the access obtained when a SaaS provider is compromised is significant, with lots of subsequent opportunity for ransomware, extortion, and direct harassment attacks against customers.” Ventrone says clients should confirm their provider’s policy covers not only themselves but the full impact of a multi-customer incident. 13. Can we test your processes? Attestations regarding cybersecurity testing and monitoring — such as regular penetration testing, 24/7/365 security monitoring, threat hunting — are essential, Wright says. But Alford recommends going a step further. “Lots of firms do questionnaire-based reviews that confirm policies exist but rarely test how provider processes work in practice. They assume a support vendor has strong verification steps. They assume an integration partner follows least privilege. They assume a SaaS platform has adequate logging for delegated access,” says Alford, warning against presumptions. “Verification through evidence, realistic scenarios, and process testing changes everything,” he says. “It exposes where risk actually lives and gives you the ability to design controls that match how attackers think rather than how documentation reads.” Ongoing diligence necessary “Recent incidents underscore that many organizations are not adequately managing third-party risk over the full lifecycle of their IT provider relationships,” notes Clark Hill’s Ventrone, adding that too often due diligence is treated as a one-time exercise, with insufficient ongoing oversight to ensure that security controls and procedures remain appropriate as systems evolve. Stratascale’s Corcoran also notes that cyber due diligence often falls through the cracks. “Many client organizations still fall short in managing third-party risk because it’s often treated as a collateral duty, split between procurement and general risk functions rather than a dedicated, optimized process,” he says. “As a result, business stakeholders remain unsatisfied and critical risks go unmitigated, even as attackers increasingly exploit weaker links in the supply chain.” Increasingly, partners in the IT ecosystem are being seen by cybercriminals to be those weaker links. View the full article

From a certain age, many people regularly visit their doctor for check-ups. In this way, risks and dangers can be identified early and appropriate measures taken. The same applies to cybersecurity: Regular risk assessments help security teams identify vulnerabilities and areas for improvement. Unfortunately, such assessments are not carried out universally. Advantages of a cyber risk assessment CISOs benefit from the following advantages when they integrate cybersecurity risk assessments into their work: Identifying vulnerabilities: A cyber risk assessment helps to identify security gaps in a company’s IT infrastructure, networks, and systems. This provides the opportunity to eliminate these vulnerabilities before they can be exploited by cybercriminals. Prioritize risk management measures: Not every system is critical, and not all of a company’s data is equally important. The results of the risk assessment clarify which assets and systems are most critical and at the highest risk of attack. Based on this, security managers can prioritize their measures and thus allocate their resources more effectively to address the most critical risks first. Meeting compliance requirements: Almost every company must comply with various data protection and data security regulations, such as the GDPR or the Payment Card Industry Data Security Standard (PCI DSS). Many of these legal requirements explicitly demand specific risk assessments, such as a data protection impact assessment under the GDPR. Risk assessments help to meet the compliance requirements of various regulations. This ensures that the necessary security standards are met and that potential fines or legal consequences for violations are avoided. Make smart decisions and reduce costs: Cyber ​​risk assessments give companies a comprehensive understanding of their cyber risks. This allows them to make informed decisions about risk mitigation strategies, thereby reducing the likelihood of a successful and costly cyberattack. Furthermore, it enables them to make targeted and therefore more effective investments in their cybersecurity. A look at data risk The target of most cyberattacks is a company’s data — with enormously costly consequences: According to IBM’s Cost of a Data Breach Report 2025, a data breach caused an average of $4.44 million in damages. Therefore, it is crucial to take a close look at data and the risks it faces. This is all the more important because, unlike infrastructure and other systems, data is not “uncompromising.” Servers can be reconfigured, cloud instances rebuilt. But once stolen, data remains in the hands of cybercriminals. Backups offer no protection against this. An analysis of nearly 10 billion cloud objects, conducted as part of data risk assessments at more than 700 companies across various industries worldwide, reveals the risks that data is generally exposed to. According to the analysis, one in 10 data sets in the cloud is accessible to all employees. This creates an internal radius that significantly increases the potential damage from a ransomware attack. However, a lack of multifactor authentication (MFA) also makes it easier for attackers to compromise internally exposed data: Microsoft has found that more than 99% of compromised accounts do not have MFA. Conclusion These general findings already highlight the biggest problem areas. Nevertheless, it is important to determine the individual data risk and identify weaknesses within the framework of a data risk assessment. Companies typically don’t know what data they possess, where it’s stored, or who has access to it. Only with this fundamental information can they identify their risks and take targeted measures. The time investment is manageable, at around two to four hours, and a comprehensive report provides immediately actionable recommendations. Furthermore, the assessment process often uncovers additional security issues, ranging from ongoing cyberattacks to Kerberos passwords that are up to 15 years old. Regularly conducted cyber risk assessments allow for clear and verifiable documentation of progress in data security — also for management. CISOs finally have a tool at their disposal that makes their cybersecurity successes visible. View the full article

Third Party Risk Management hilft Unternehmen, das Risiko von Compliance-Verstößen zu vermeiden. Foto: Diyajyoti – shutterstock.com In Zeiten der Digitalisierung ist es für Unternehmen unerlässlich, auf die Unterstützung von Drittanbietern zurückzugreifen. Sei es im Bereich der IT-Infrastruktur oder bei der Datenverarbeitung – externe Dienstleister helfen dabei, Geschäftsprozesse effektiver und effizienter zu gestalten. Doch mit der Zusammenarbeit mit Dritten geht auch ein Risiko einher. Unternehmen sollten deshalb ein Third Party Risk Management (TPRM) etablieren. Was ist Third Party Risk Management? TPRM ist ein strategischer Ansatz, der darauf abzielt, das Risiko der Zusammenarbeit mit Drittanbietern zu identifizieren, zu bewerten und zu steuern. Er hilft Unternehmen, die Risiken im Zusammenhang mit ihren Drittanbietern besser zu verstehen und zu managen, um Compliance-Verstöße zu vermeiden. Warum ist TPRM wichtig? “Unternehmen müssen beispielsweise überprüfen, ob ihre Drittanbieter den SOC2-Prüfungsstandard einhalten. Dieser soll sicherstellen, dass Drittanbieter sensible Kundendaten vor unbefugtem Zugriff schützen”, erklärt GreenPages-Manager Pasteris und ergänzt: “Auch Datenschutzgesetze wie die DSGVO sind in dieser Hinsicht relevant. Wenn Sie selbst compliant sind, nutzt Ihnen das überhaupt nichts, wenn Ihr Drittanbieter sich an nichts hält.” Lesetipp: 5 Wege, mit Drittanbietern unterzugehen Kernkomponenten einer effektiven TPRM-Strategie Ein Thrid Party Risk Managment sollte Folgendes enthalten: Risikoidentifikation und -bewertung: Der erste Schritt im TPRM-Prozess ist die Identifikation und Bewertung der Risiken, die mit der Zusammenarbeit mit Drittanbietern verbunden sind. Dies umfasst die Analyse der Sicherheitsmaßnahmen, Datenschutzpraktiken und Compliance-Standards der Drittanbieter. Unternehmen sollten eine detaillierte Due Diligence durchführen, um potenzielle Schwachstellen und Risiken zu identifizieren. Vertragsmanagement: Ein weiterer wichtiger Aspekt des TPRM ist die Implementierung von Vertragsklauseln, die die Verantwortlichkeiten der Drittanbieter hinsichtlich Compliance-Verstößen definieren. Es ist wichtig, dass Unternehmen klare Erwartungen an ihre Drittanbieter haben und dass diese Erwartungen in schriftlicher Form niedergelegt werden. Dies hilft Unternehmen, sich vor rechtlichen Konsequenzen im Falle von Compliance-Verstößen durch Drittanbieter zu schützen. Überwachung und Audits: Eine effektive TPRM-Strategie umfasst auch die kontinuierliche Überwachung von Drittanbietern, um sicherzustellen, dass sie weiterhin den Anforderungen entsprechen. Diese kann durch regelmäßige Audits und Prüfungen erfolgen. Unternehmen sollten sicherstellen, dass sie über die notwendigen Ressourcen und Tools verfügen, um die Einhaltung der Compliance-Standards durch ihre Drittanbieter zu überprüfen. Schulung und Sensibilisierung: Die Schulung und Sensibilisierung der Mitarbeiter über die Risiken und Anforderungen des TPRM ist ebenfalls entscheidend. Mitarbeiter sollten verstehen, warum TPRM wichtig ist und wie sie dazu beitragen können, die Risiken zu minimieren. Regelmäßige Schulungen und Workshops können dazu beitragen, das Bewusstsein für TPRM zu stärken und sicherzustellen, dass alle Mitarbeiter die Compliance-Standards einhalten. Best Practices für ein erfolgreiches TPRM Diese vier Tipps helfen bei der TPRM-Umsetzung: Etablierung klarer Richtlinien und Verfahren: Unternehmen sollten klare Richtlinien und Verfahren für das TPRM entwickeln und implementieren. Diese sollten alle Aspekte des TPRM abdecken, einschließlich der Auswahl von Drittanbietern, der Vertragsgestaltung, der Überwachung und der Berichterstattung. Nutzung von Technologie: Der Einsatz von Technologie kann das TPRM erheblich erleichtern. Es gibt zahlreiche Tools und Plattformen, die Unternehmen dabei unterstützen, die Risiken zu identifizieren, zu bewerten und zu überwachen. Diese Tools können auch bei der Automatisierung von Audits und Berichterstattungen helfen. Integration des TPRM in das Enterprise Risk Management (ERM): Das TPRM sollte nicht isoliert betrachtet werden, sondern in das umfassende Risikomanagement des Unternehmens integriert werden. Dies stellt sicher, dass alle Risiken, einschließlich derjenigen, die von Drittanbietern ausgehen, ganzheitlich betrachtet und gemanagt werden. Regelmäßige Überprüfung und Aktualisierung: Die TPRM-Strategie sollte regelmäßig überprüft und bei Bedarf aktualisiert werden, um sicherzustellen, dass sie den aktuellen Bedrohungen und Compliance-Anforderungen entspricht. Unternehmen sollten proaktive Maßnahmen ergreifen, um ihre TPRM-Strategie kontinuierlich zu verbessern. Sichere Geschäftsprozesse mit TPRM Third Party Risk Management ist ein wesentlicher Bestandteil der Compliance-Strategie jedes Unternehmens, das mit Drittanbietern zusammenarbeitet. Durch die Implementierung einer effektiven TPRM-Strategie können Unternehmen das Risiko von Compliance-Verstößen durch Drittanbieter minimieren und sich vor rechtlichen Konsequenzen schützen. Die Identifikation und Bewertung von Risiken, das Vertragsmanagement, die kontinuierliche Überwachung und die Schulung der Mitarbeiter sind entscheidende Komponenten eines erfolgreichen TPRM. (jm) Sie möchten regelmäßig über wichtige Themen rund um Cybersicherheit informiert werden? Unser kostenloser Newsletter liefert Ihnen alles, was Sie wissen müssen. View the full article

Threat actors could use prompt injection attacks to take advantage of three vulnerabilities in Anthropic’s official Git MCP server and cause mayhem with AI systems. This alert comes from researchers at Israel-based Cyata, which urges infosec leaders to make sure corporate developers using the official GIT MCP server update to the latest version as soon as possible. The risk is that an attacker could run unapproved code or tamper with a large language model (LLM), compromising its output. While the official Git MCP server can be exploited on its own, “the toxic combination is when both the Git MCP server and a Filesystem MCP server are enabled,” Cyata CEO Shahar Tal said in an interview. “Then that [AI] agent is at critical risk. We urge people to use the latest versions [of both applications].” At risk are developers using mcp-server-git versions prior to 2025-12.18. The three vulnerabilities are ·CVE-2025-68143, an unrestricted git_init. ·CVE-2025-68145, a path validation bypass. ·CVE-2025-68144, an argument injection in git_diff. Unlike other vulnerabilities in MCP servers that required specific configurations, these work on any configuration of Anthropic’s official server, out of the box, Cyata says. Model Context Protocol (MCP) is an open standard introduced by Anthropic in 2024 to provide a unified way for AI assistants (such as Claude Desktop, Cursor, Windsurf, and others) to interact with external tools and data sources including filesystems, databases, APIs, and development tools like Git. MCP servers expose capabilities to the AI, acting as a bridge between the LLM and external systems. As Cyata points out in its blog, MCP servers execute actions based on LLM decisions. If an LLM can be manipulated through prompt injection, a threat actor can influence the AI’s context to trigger MCP tool calls with attacker-controlled arguments. Since Anthropic released its model, thousands of vendors and third party providers have released official MCP servers. There are also unofficial servers for online platforms like LinkedIn. And, as might be expected, there are dodgy MCP servers circulating from crooks. Related content: What CISOs need to know about securing MCP servers It isn’t known how many enterprise developers use mcp-server-git, the official Git MCP server maintained by Anthropic. Nor is it known how many also use Filesystem MCP Server. Cyata researcher Yarden Porat first discovered that if a tool is called in mcp-server-git, the server will use the path it is given without validation, so an attacker could create a new git repository with malicious content that could be read by the LLM. The second hole is in a parameter that gets passed directly to the git command line without sanitization. That means a threat actor can inject any git flag, including one that could overwrite a target file. Third, it was discovered that an attacker could also delete files. Finally, researchers found that attackers could use git’s smudge and clean filters to run code. “All you have to know — and it depends on the agent you’re attacking — is how to get the [AI] agent to read something you control,” said Tal. “That is quite widespread. It’s a very wide attack surface.” Related content: Top 10 MCP vulnerabilities Cyata says defensive action not only means updating mcp-server-git to version 2025.12.18 or later, but also auditing which MCP servers run together. Combining Git + Filesystem increases the attack surface, the researchers say. Admins should also monitor for unexpected .git directories in non-repository folders. “Generally, it is very hard to protect against vulnerabilities in MCP servers,” said Tal. “Most assistant type agents don’t even let you sanitize parameters. Homegrown agents could include various prompt injection defenses, but none are fail-proof.” Cyata says it informed Anthropic of the first problem through the bug reporting service HackerOne on June 24, 2025. It was marked by Anthropic as informative. After Cyata reported the prompt injection issue, Anthropic took another look, but it wasn’t until September 10 that the report was accepted. The new version of Git MCP Server was released December 18. In an interview, Porat suggested there wasn’t much that infosec leaders or developers could have done between the discovery of the vulnerability and the release of the more secure version of Git MCP Server. A prompt injection attack would work on the unpatched version even in its most secure configuration, he said. “You need guardrails around each [AI] agent and what it can do, what it can touch,” Tal added. “You need to also, if there is an incident, be able to look back at everything the agent did.” The problem with MCP servers is that they give the LLM access to execute sensitive functions, commented Johannes Ullrich, dean of research at the SANS Institute. “How much of a problem this is depends on the particular features they have access to. But once an MCP server is configured, the LLM will use the content it receives to act on and execute code (in this case, in git). “Sadly, it is very unlikely that this will be the last time we see a prompt injection in this system. There is no simple fix for prompt injections, and usually you are going to create band-aids to prevent specific exploits. For an MCP server like this, the best option is to restrict the data it operates on, so it uses only data from trusted sources, and the functionality it can access. Some fine-grained access control can be used to implement this.” Tanya Janca, a Canadian-based secure coding trainer, said to mitigate potential issues, development teams using MCP should limit access and privileges for MCP servers — no root, read-only access, local access only — and only give users the least privileges they need. Admins should validate file paths completely, not just prefix matching, resolve symlinks properly and always perform careful input validation and use parameterized queries. View the full article

Threat actors could use prompt injection attacks to take advantage of three vulnerabilities in Anthropic’s official Git MCP server and cause mayhem with AI systems. This alert comes from researchers at Israel-based Cyata, which urges infosec leaders to make sure corporate developers using the official GIT MCP server update to the latest version as soon as possible. The risk is that an attacker could run unapproved code or tamper with a large language model (LLM), compromising its output. While the official Git MCP server can be exploited on its own, “the toxic combination is when both the Git MCP server and a Filesystem MCP server are enabled,” Cyata CEO Shahar Tal said in an interview. “Then that [AI] agent is at critical risk. We urge people to use the latest versions [of both applications].” At risk are developers using mcp-server-git versions prior to 2025-12.18. The three vulnerabilities are ·CVE-2025-68143, an unrestricted git_init. ·CVE-2025-68145, a path validation bypass. ·CVE-2025-68144, an argument injection in git_diff. Unlike other vulnerabilities in MCP servers that required specific configurations, these work on any configuration of Anthropic’s official server, out of the box, Cyata says. Model Context Protocol (MCP) is an open standard introduced by Anthropic in 2024 to provide a unified way for AI assistants (such as Claude Desktop, Cursor, Windsurf, and others) to interact with external tools and data sources including filesystems, databases, APIs, and development tools like Git. MCP servers expose capabilities to the AI, acting as a bridge between the LLM and external systems. As Cyata points out in its blog, MCP servers execute actions based on LLM decisions. If an LLM can be manipulated through prompt injection, a threat actor can influence the AI’s context to trigger MCP tool calls with attacker-controlled arguments. Since Anthropic released its model, thousands of vendors and third party providers have released official MCP servers. There are also unofficial servers for online platforms like LinkedIn. And, as might be expected, there are dodgy MCP servers circulating from crooks. Related content: What CISOs need to know about securing MCP servers It isn’t known how many enterprise developers use mcp-server-git, the official Git MCP server maintained by Anthropic. Nor is it known how many also use Filesystem MCP Server. Cyata researcher Yarden Porat first discovered that if a tool is called in mcp-server-git, the server will use the path it is given without validation, so an attacker could create a new git repository with malicious content that could be read by the LLM. The second hole is in a parameter that gets passed directly to the git command line without sanitization. That means a threat actor can inject any git flag, including one that could overwrite a target file. Third, it was discovered that an attacker could also delete files. Finally, researchers found that attackers could use git’s smudge and clean filters to run code. “All you have to know — and it depends on the agent you’re attacking — is how to get the [AI] agent to read something you control,” said Tal. “That is quite widespread. It’s a very wide attack surface.” Related content: Top 10 MCP vulnerabilities Cyata says defensive action not only means updating mcp-server-git to version 2025.12.18 or later, but also auditing which MCP servers run together. Combining Git + Filesystem increases the attack surface, the researchers say. Admins should also monitor for unexpected .git directories in non-repository folders. “Generally, it is very hard to protect against vulnerabilities in MCP servers,” said Tal. “Most assistant type agents don’t even let you sanitize parameters. Homegrown agents could include various prompt injection defenses, but none are fail-proof.” Cyata says it informed Anthropic of the first problem through the bug reporting service HackerOne on June 24, 2025. It was marked by Anthropic as informative. After Cyata reported the prompt injection issue, Anthropic took another look, but it wasn’t until September 10 that the report was accepted. The new version of Git MCP Server was released December 18. In an interview, Porat suggested there wasn’t much that infosec leaders or developers could have done between the discovery of the vulnerability and the release of the more secure version of Git MCP Server. A prompt injection attack would work on the unpatched version even in its most secure configuration, he said. “You need guardrails around each [AI] agent and what it can do, what it can touch,” Tal added. “You need to also, if there is an incident, be able to look back at everything the agent did.” The problem with MCP servers is that they give the LLM access to execute sensitive functions, commented Johannes Ullrich, dean of research at the SANS Institute. “How much of a problem this is depends on the particular features they have access to. But once an MCP server is configured, the LLM will use the content it receives to act on and execute code (in this case, in git). “Sadly, it is very unlikely that this will be the last time we see a prompt injection in this system. There is no simple fix for prompt injections, and usually you are going to create band-aids to prevent specific exploits. For an MCP server like this, the best option is to restrict the data it operates on, so it uses only data from trusted sources, and the functionality it can access. Some fine-grained access control can be used to implement this.” Tanya Janca, a Canadian-based secure coding trainer, said to mitigate potential issues, development teams using MCP should limit access and privileges for MCP servers — no root, read-only access, local access only — and only give users the least privileges they need. Admins should validate file paths completely, not just prefix matching, resolve symlinks properly and always perform careful input validation and use parameterized queries. View the full article

Two vulnerabilities in popular AI development framework Chainlit could enable attackers to read arbitrary files and database content from servers. If left unpatched, the flaws could allow attackers to leak API keys and other secret tokens to facilitate lateral movement inside the organization’s infrastructure. “These vulnerabilities can be triggered with no user interaction,” researchers from security firm Zafran said in a report on the Chainlit flaws. “Zafran confirmed the vulnerabilities in real-world, internet-facing applications operated by major enterprises.” Chainlit is a Python-based package for building AI apps with chatbot interfaces. It handles authentication and offers integrations with various backend systems, databases, and cloud services. With over 5 million downloads in the past year from the Python Index (PyPI), Chainlit is often mentioned in tutorials for building user-facing interfaces for RAG systems and other LLM-powered apps. The two vulnerabilities, tracked as CVE-2026-22218 and CVE-2026-22219, were fixed in version 2.9.4, released last month. The release notes at the time mentioned a “security vulnerability fix” but no other details until the advisory was released this week. Arbitrary file reads through custom elements The first vulnerability (CVE-2026-22218) is located in the framework’s Element class. In Chainlit, elements are pieces of content that can be attached to a message, for example images, PDF files, videos, audio files, and dataframes, among others. The framework’s Element class also supports a custom type for displaying JavaScript XML (JSX) files inside a message. JSX files extend JavaScript’s syntax to display HTML and are commonly used by libraries such as React. The Zafran researchers discovered that this custom element gives attackers control over all its properties, because it does not validate the fields. For example, if attackers send a custom element with the path property set to any file on the server, the file will be returned to the user session. Because of this, the flaw allows attackers to read any arbitrary file from the server, plenty of which could include sensitive information. For example, the /proc/self/environ file is used to store environment variables, and these can contain API keys, credentials, internal file paths, database paths, tokens for AWS and other cloud services, and even CHAINLIT_AUTH_SECRET, a secret that’s used to sign authentication tokens when authentication is enabled. On top of that, if LangChain is used as the orchestration layer behind Chainlit and caching is enabled, user prompts sent to the LLM and the corresponding responses are saved to a file called .chainlit/.langchain.db. This file stores prompts across users and tenants, so attackers could exfiltrate it periodically to obtain sensitive information. Zafran’s proof-of-concept exploit involved leaking this file. Cross-site request forgery The second vulnerability (CVE-2026-22218) uses the same custom element as an attack vector but exploits it in a different way, through the URL property. By setting this field, attackers can force the server to trigger a request to the specified URL to fetch its contents and save it in the database. Chainlit uses PostgreSQL by default but can also use SQLAlchemy with different backends such as SQLite or cloud storage providers such as AWS S3 or Azure Blobs. By exploiting this vulnerability, attackers can trigger a cross-site request forgery (SSRF) to obtain credentials. “If Chainlit is deployed on an AWS EC2 instance with IMDSv1 enabled, the SSRF vulnerability can be used to access http://169.254.169.254/latest/meta-data/iam/security-credentials/ and retrieve role endpoints, allowing lateral movement within the cloud account,” the researchers said. By combining these two flaws, attackers can extract a lot of information and credentials but also the database itself or source code files from the application that might contain custom code. “Once cloud credentials or IAM tokens are obtained from the server, the attacker is no longer limited to the application,” the researchers wrote in their report. “They gain access to the cloud environment behind it. Storage buckets, secrets managers, LLM, internal data, and other cloud resources may become accessible to an attacker.” The Zafran report contains signatures for the Snort network intrusion detection system and for the Cloudflare web application firewall, which can be used to block attack attempts until the applications are updated to a patched Chainlit version. View the full article

Airlock Digital, a leader in proactive application control and endpoint security, announced the release of The Total Economic Impact (TEI) of Airlock Digital, an independent study commissioned by Airlock Digital and conducted by Forrester Consulting. The study demonstrates a significant 224% return on investment (ROI) and a $3.8 million net present value (NPV) over three years for organizations adopting Airlock Digital’s allowlisting approach. These findings underline both the financial and security value of Airlock Digital’s solution. Cyber NewsWire Forrester’s TEI methodology evaluates the potential financial impact of technology investments by aggregating insights from customer interviews and modeling a composite organization representative of global organizations. According to the study, Airlock Digital enabled: 224% ROI over three years $3.8M net present value based on quantified benefits versus costs >25% reduction in overall risk of security breaches Zero breaches reported by interviewed organizations after deploying Airlock Digital Significant operational efficiencies with reduced administrative overhead David Cottingham, Co-founder and CEO at Airlock Digital, said: “For modern enterprises, trust cannot be assumed… it must be enforced. Allowlisting and application control give organizations the power to run only what they trust, blocking all malware and ransomware before they can execute. For us, the Forrester Consulting TEI study reinforces the importance of our mission at Airlock Digital, which is to deliver proactive endpoint security that makes application control not just possible, but effortless. It’s why we have become synonymous with this critical layer of cyber defense—and why every organization needs it at the core of their security strategy.” As cyberattacks continue to grow in scale and sophistication, more organizations are turning to application control and allowlisting as foundational components of a proactive security strategy. Traditional reactive security tools attempt to detect and block threats after execution attempts are made—often too late to prevent compromise. Allowlisting reverses this paradigm, enforcing a Deny by Default posture that ensures only trusted and approved software is permitted to run. This approach dramatically reduces the attack surface, curbs the spread of malware and ransomware, and helps organizations meet increasingly stringent regulatory and compliance requirements. Airlock Digital’s modern, operationally friendly implementation of allowlisting enables security teams to adopt this strategy without the administrative complexity historically associated with legacy tools. The study highlights that Airlock Digital helps organizations strengthen their security posture, lower ongoing maintenance costs, and improve software inventory management while keeping operational and administrative burden low. The study noted that a single security analyst can effectively manage Airlock Digital policies in much less time than traditional solutions require, contributing to cost savings and improved productivity. Patrick Dillon, CRO at Airlock Digital said: “The Forrester Consulting TEI study gives security leaders, in our opinion, clear, independent validation of the impact delivered by Airlock Digital. Forrester Consulting calculated the benefits to include a 224% ROI and fast payback — and most importantly — participating organizations reported zero breaches after implementation. Airlock Digital combines simplicity with enterprise-grade scale, enforcing a Deny by Default posture that blocks untrusted code, including malware and ransomware. For organizations ready to move from reactive defenses to proactive prevention, Airlock Digital provides a quantified and operationally efficient path forward — requiring, according to the Forrester Consulting study, only 2.5 hours per week to manage. We’d be glad to walk you through the findings.” About Airlock Digital Airlock Digital delivers market-leading allowlisting and application control solutions that empower enterprises to enforce a Deny by Default security posture. Trusted globally across industries, Airlock Digital enables organizations to prevent unauthorized code execution, simplify compliance, and strengthen cyber-resilience without sacrificing performance or user productivity. This approach minimizes attack surfaces and helps organizations align their cybersecurity strategies with government frameworks and standards. Users can download the full Forrester TEI study: https://www.airlockdigital.com/forrester-tei-report Contact VP of Marketing Erin Welke Airlock Digital [email protected] View the full article

T. Schneider – shutterstock.com Forscher des Security-Anbieters Socket haben eine koordinierte Kampagne entdeckt, die auf bösartigen Chrome-Add-ons basiert. Die Angreifer haben die Abwehrmechanismen des Chrome Web Stores umgangen und Erweiterungen als Produktivitätswerkzeuge beworben. „Die Erweiterungen arbeiten zusammen, um Authentifizierungs-Token zu stehlen, Incident-Response-Funktionen zu blockieren und durch Session-Hijacking die vollständige Übernahme von Konten zu ermöglichen“, erklären die Sicherheitsspezialisten in einem Blogbeitrag. Die Hintermänner der Kampagne veröffentlichten fünf Chrome-Erweiterungen, die trotz professionellem Branding und scheinbar legitimen Anwendungsfällen tief im Inneren der Unternehmens-Workflows bösartige Aktionen ausführen. Die Installationszahlen deuten darauf hin, dass über 2.300 Nutzer dazu verleitet wurden, diese Tools zu installieren. Die Erweiterungen zielen auf Systeme wie Workday, NetSuite und SuccessFactors ab, wo eine einzige gekaperte Sitzung Mitarbeiterdaten, Finanzdaten und interne Arbeitsabläufe offenlegen kann. Getarnte Produktivitäts-Tools mit bösartigen Codes Die Erweiterungen gaben sich als Produktivitäts-Booster oder Sicherheitshelfer für Enterprise-Anwender aus. In den Einträgen zeigten die Angreifer professionell gestaltete Dashboards und versprachen einen vereinfachten Zugriff auf HR- oder ERP-Tools. Die angeforderten Berechtigungen waren dabei „Standard“ und umfassten scheinbar harmlose Funktionen wie Cookie-Zugriff oder die Modifikation von Websites. Nach der Installation exfiltrierten jedoch drei der Erweiterungen, darunter DataByCloud Access, Data By Cloud 1 und eine Variante namens Software Access, Session Cookies mit Authentifizierungs-Token an eine vom Angreifer kontrollierte Infrastruktur. Diese Token reichen in vielen Unternehmenssystemen aus, um einen Benutzer ohne Passwort zu authentifizieren. In einigen Fällen wurden diese Cookies alle 60 Sekunden extrahiert, um aktuelle Anmeldedaten zu gewährleisten. Kompromittierte Sitzungen können wie gestohlene Passwörter fungieren, da sie bereits die Anmeldeseiten und Multi-Faktor-Prüfungen durchlaufen haben und somit einen direkten Zugriff auf ein Konto ermöglichen, ohne die üblichen Sicherheitswarnungen auszulösen. „Alle fünf Erweiterungen werden zum Zeitpunkt der Erstellung dieses Artikels noch untersucht“, so die Forscher. „Wir haben bei Googles Sicherheitsteam für den Chrome Web Store Anträge auf Entfernung gestellt.“ Blockierte Sicherheitsmaßnahmen und Hijacking von Sitzungen Die Kampagne ging aber über den Diebstahl von Anmeldedaten hinaus. Zwei der Erweiterungen, Tool Access 11 und Data By Cloud 2, enthielten DOM-Manipulationsroutinen, die den Zugriff auf Sicherheits- und Verwaltungsseiten innerhalb der Zielplattformen aktiv blockierten. Dadurch Enterprise-Admins selbst dann keine Passwörter ändern, die Anmeldungshistorie einsehen oder kompromittierte Konten deaktivieren, wenn sie verdächtiges Verhalten feststellten. Die technisch fortschrittlichste der fünf Erweiterungen, Software Access, bot zusätzlich zum Cookie-Diebstahl eine bidirektionale Cookie-Injektion, bei der gestohlene Session-Tokens wieder in einen vom Angreifer kontrollierten Browser eingebracht wurden. Mithilfe von APIs wie „chrome.cookies.set()“ implantiert diese Funktion gültige Authentifizierungs-Cookies direkt und gewährt den Angreifern eine authentifizierte Sitzung, ohne dass ahnungslose Benutzer weitere Maßnahmen ergreifen müssen. „Während vier Erweiterungen unter databycloud1104 und die fünfte unter einem anderen Markennamen veröffentlicht werden, weisen alle fünf identische Infrastrukturmuster auf, was auf eine einzige koordinierte Operation hindeutet“, fügen die Forscher hinzu. Tipps zum Schutz Socket rät Unternehmen, Browser-Erweiterungen streng zu prüfen und zu beschränken, Berechtigungsanfragen genau zu prüfen und Add-ons zu entfernen, die unnötigerweise auf Cookies oder Enterprise-Websites zugreifen. Zudem empfiehlt der Blog, ungewöhnliche Session-Aktivitäten zu überwachen und Tools zu verwenden, die bösartiges Verhalten von Erweiterungen erkennen können, bevor es die Benutzer erreicht. (jm) View the full article

T. Schneider – shutterstock.com Forscher des Security-Anbieters Socket haben eine koordinierte Kampagne entdeckt, die auf bösartigen Chrome-Add-ons basiert. Die Angreifer haben die Abwehrmechanismen des Chrome Web Stores umgangen und Erweiterungen als Produktivitätswerkzeuge beworben. „Die Erweiterungen arbeiten zusammen, um Authentifizierungs-Token zu stehlen, Incident-Response-Funktionen zu blockieren und durch Session-Hijacking die vollständige Übernahme von Konten zu ermöglichen“, erklären die Sicherheitsspezialisten in einem Blogbeitrag. Die Hintermänner der Kampagne veröffentlichten fünf Chrome-Erweiterungen, die trotz professionellem Branding und scheinbar legitimen Anwendungsfällen tief im Inneren der Unternehmens-Workflows bösartige Aktionen ausführen. Die Installationszahlen deuten darauf hin, dass über 2.300 Nutzer dazu verleitet wurden, diese Tools zu installieren. Die Erweiterungen zielen auf Systeme wie Workday, NetSuite und SuccessFactors ab, wo eine einzige gekaperte Sitzung Mitarbeiterdaten, Finanzdaten und interne Arbeitsabläufe offenlegen kann. Getarnte Produktivitäts-Tools mit bösartigen Codes Die Erweiterungen gaben sich als Produktivitäts-Booster oder Sicherheitshelfer für Enterprise-Anwender aus. In den Einträgen zeigten die Angreifer professionell gestaltete Dashboards und versprachen einen vereinfachten Zugriff auf HR- oder ERP-Tools. Die angeforderten Berechtigungen waren dabei „Standard“ und umfassten scheinbar harmlose Funktionen wie Cookie-Zugriff oder die Modifikation von Websites. Nach der Installation exfiltrierten jedoch drei der Erweiterungen, darunter DataByCloud Access, Data By Cloud 1 und eine Variante namens Software Access, Session Cookies mit Authentifizierungs-Token an eine vom Angreifer kontrollierte Infrastruktur. Diese Token reichen in vielen Unternehmenssystemen aus, um einen Benutzer ohne Passwort zu authentifizieren. In einigen Fällen wurden diese Cookies alle 60 Sekunden extrahiert, um aktuelle Anmeldedaten zu gewährleisten. Kompromittierte Sitzungen können wie gestohlene Passwörter fungieren, da sie bereits die Anmeldeseiten und Multi-Faktor-Prüfungen durchlaufen haben und somit einen direkten Zugriff auf ein Konto ermöglichen, ohne die üblichen Sicherheitswarnungen auszulösen. „Alle fünf Erweiterungen werden zum Zeitpunkt der Erstellung dieses Artikels noch untersucht“, so die Forscher. „Wir haben bei Googles Sicherheitsteam für den Chrome Web Store Anträge auf Entfernung gestellt.“ Blockierte Sicherheitsmaßnahmen und Hijacking von Sitzungen Die Kampagne ging aber über den Diebstahl von Anmeldedaten hinaus. Zwei der Erweiterungen, Tool Access 11 und Data By Cloud 2, enthielten DOM-Manipulationsroutinen, die den Zugriff auf Sicherheits- und Verwaltungsseiten innerhalb der Zielplattformen aktiv blockierten. Dadurch Enterprise-Admins selbst dann keine Passwörter ändern, die Anmeldungshistorie einsehen oder kompromittierte Konten deaktivieren, wenn sie verdächtiges Verhalten feststellten. Die technisch fortschrittlichste der fünf Erweiterungen, Software Access, bot zusätzlich zum Cookie-Diebstahl eine bidirektionale Cookie-Injektion, bei der gestohlene Session-Tokens wieder in einen vom Angreifer kontrollierten Browser eingebracht wurden. Mithilfe von APIs wie „chrome.cookies.set()“ implantiert diese Funktion gültige Authentifizierungs-Cookies direkt und gewährt den Angreifern eine authentifizierte Sitzung, ohne dass ahnungslose Benutzer weitere Maßnahmen ergreifen müssen. „Während vier Erweiterungen unter databycloud1104 und die fünfte unter einem anderen Markennamen veröffentlicht werden, weisen alle fünf identische Infrastrukturmuster auf, was auf eine einzige koordinierte Operation hindeutet“, fügen die Forscher hinzu. Tipps zum Schutz Socket rät Unternehmen, Browser-Erweiterungen streng zu prüfen und zu beschränken, Berechtigungsanfragen genau zu prüfen und Add-ons zu entfernen, die unnötigerweise auf Cookies oder Enterprise-Websites zugreifen. Zudem empfiehlt der Blog, ungewöhnliche Session-Aktivitäten zu überwachen und Tools zu verwenden, die bösartiges Verhalten von Erweiterungen erkennen können, bevor es die Benutzer erreicht. (jm) View the full article

Security researchers have uncovered a malicious browser extension campaign, dubbed CrashFix, that deliberately crashes victims’ browsers and then uses the resulting confusion to trick users into running attacker-supplied commands. The activity, attributed to a threat cluster Huntress calls KongTuke, involves a fake Chrome extension posing as an ad-blocking tool but ultimately delivering a novel malware payload. The extension, which Huntress identified as NexShield-Advanced Web Protection, was distributed through look-alike branding and deceptive metadata designed to resemble a legitimate browser security tool, uBlock Origin Lite ad blocker. After installation, it remains inactive for a period of time, likely to evade immediate suspicion, before intentionally destabilizing the browser by exhausting system resources and triggering repeated crashes. Once the browser becomes unusable, victims are presented with a fake “repair” prompt instructing them to paste and execute a command to resolve the issue. From fake protection to forced failure According to Huntress’ analysis, the malicious extension does not immediately perform malicious actions. Instead, it waits approximately an hour after installation before initiating the crash routine. The extension repeatedly opens connections and consumes memory until the browser becomes unresponsive, forcing users to restart or troubleshoot what appears to be a legitimate failure. “The extension sets up to two timers: the first triggers once after a 60-minute delay, and the second fires every 10 minutes after the initial trigger,” Huntress researchers said in a blog post. “This timing strategy is in place so that when a user installs the extension, nothing malicious happens immediately. Sixty minutes later, the malicious payload activates, and every 10 minutes thereafter, the payload continues to execute.” On relaunch, the victim receives an alert claiming the browser encountered a critical error and requires manual remediation. Victims are instructed to open the Windows Run dialog and paste a command already copied to the clipboard. This command launches the next stage of the attack. Huntress emphasized that this technique mirrors a growing trend in “ClickFix”-style attacks, where users are socially engineered into executing malicious code themselves under the guise of system recovery or security remediation. ClickFix techniques have been observed across multiple DPRK-linked campaigns, including variants associated with the long-running Contagious Interview operation. Payload delivery When the user executes the supplied commands, a multistage infection process begins that ultimately deploys a previously undocumented Python-based remote access trojan, which the researchers dubbed ModelRAT. The malware establishes persistence and enables remote control of the infected system. Huntress’ telemetry suggested differing behavior based on the environment. Systems joined to a domain were more likely to receive the full payload chain, while non-domain systems sometimes received lighter or incomplete stages. The researchers also drew parallels between the CrashFix execution flow and SocGholish (FakeUpdates) campaigns, noting the shared reliance on user-driven execution rather than technical exploitation. As with SocGholish activity, the attacker’s success depends on convincing the victim to manually run a command under the guise of remediation or system recovery. Recommendations included removing untrusted or look-alike browser extensions and reinforcing guidance against manually executing “fix” commands prompted by browser errors. The researchers also shared indicators of compromise (IOCs) tied to the malicious extension, command execution, and follow-on activity to aid detection and response. View the full article

A newly disclosed weakness in Google’s Gemini shows how attackers could exploit routine calendar invitations to influence the model’s behavior, underscoring emerging security risks as enterprises embed generative AI into everyday productivity and decision-making workflows. The vulnerability was identified by application security firm Miggo. In its report, Miggo’s head of research, Liad Eliyahu, said Gemini parses the full context of a user’s calendar events, including titles, times, attendees, and descriptions, allowing it to answer questions such as what a user’s schedule looks like for the day. “The mechanism for this attack exploits that integration,” Eliyahu said. “Because Gemini automatically ingests and interprets event data to be helpful, an attacker who can influence event fields can plant natural language instructions that the model may later execute.” Miggo’s researchers said the finding highlights a broader security challenge facing LLM-based systems, where attacks focus on manipulating meaning and context rather than exploiting clearly identifiable malicious code. “This Gemini vulnerability isn’t just an isolated edge case,” Eliyahu said. “Rather, it is a case study in how detection is struggling to keep up with AI-native threats. Traditional AppSec assumptions (including recognizable patterns and deterministic logic) do not map clearly to systems that reason in language and intent.” Severity vs traditional attacks The issue is significant not because it mirrors a conventional software flaw, but because it demonstrates how AI systems can be manipulated in ways similar to social engineering attacks. “Traditionally, a calendar invite, email, or document is treated as data only,” said Sunil Varkey, a cybersecurity analyst. “The attacker must break code logic or memory safety to make the system ‘do something’, rather than rely on data alone.” But in this case, the ‘bug’ is less about flawed code and more about how an LLM interprets language in context, combined with the permissions it has across connected applications, said Sakshi Grover, senior research manager for IDC Asia Pacific Cybersecurity Services. “That combination turns a normal business object, a calendar invite, into an attack payload,” Grover said. “It reveals that LLM security at major vendors is still catching up to real-world enterprise threat models, especially around indirect prompt injection, tool use, and cross-app data handling.” Keith Prabhu, founder and CEO of Confidis, said that while the execution of this attack occurs through Google Gemini, it more closely resembles a phishing-style technique. “Once the malicious invite is accepted by the user, Gemini considers the accepted invite as trusted and executes the prompt,” Prabhu said. “While the rest of the computing world is moving towards Zero Trust, AI tools still trust desktop components implicitly. This can be a serious flaw since AI tools can be misused to act as a ‘concierge’ to do tasks that malware cannot directly do.” Real enterprise exposure Analysts point out that the risk is significant in enterprise environments as organizations rapidly deploy AI copilots connected to sensitive systems. “As internal copilots ingest data from emails, calendars, documents, and collaboration tools, a single compromised account or phishing email can quietly embed malicious instructions,” said Chandrasekhar Bilugu, CTO of SureShield. “When employees run routine queries, the model may process this manipulated context and unintentionally disclose sensitive information.” Grover said that threats of prompt injection have moved from theoretical to operational. “In IDC’s Asia/Pacific Study conducted in August 2025, enterprises in India cited ‘LLM prompt injection, model manipulation, or jailbreaking AI assistants’ as the second most concerning AI-driven threat, right after ‘model poisoning or adversarial inputs during AI training’,” she added. Measures to prioritize Prabhu said that security leaders need to include AI security awareness as a part of their annual information security training for all staff. The endpoints would also need to be hardened, keeping in mind threats due to this new attack vector. Grover said organizations should assume prompt injection attacks will occur and focus on limiting the potential blast radius rather than trying to eliminate the risk altogether. She said this requires enforcing least privilege for AI systems, tightly scoping tool permissions, restricting default data access, and validating every AI-initiated action against business rules and sensitivity policies. “The goal is not to make the model immune to language, because no model is, but to ensure that even if it is manipulated, it cannot quietly access more data than it should or exfiltrate information through secondary channels,” Grover added. Varkey said security leaders should also rethink how they position AI copilots within their environments, warning against treating them like simple search tools. “Apply Zero Trust principles with strong guardrails: limit data access to least privilege, ensure untrusted content can’t become trusted instruction, and require approvals for high-risk actions such as sharing, sending, or writing back into business systems,” he added. View the full article