CSOonline

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

For a long time, cybersecurity was pretty straightforward: Guard the edges, and everything inside should be fine. Firewalls, DMZs, VPNs — these were the go-to tools. Back then, it worked. Apps lived in data centers, and everyone showed up at the office. But that world disappeared before most companies even noticed. Remote work, cloud adoption and distributed applications slowly dissolved the network edge. And attackers took advantage of that gap long before defenders adapted. Verizon’s annual Data Breach Investigations Report repeatedly shows that a large portion — often over 80% — of modern breaches involve compromised credentials, not network flaws. That number says a lot. It tells us the perimeter didn’t just shift — it collapsed around identity. The old perimeter: Strong walls, weak assumptions Traditional security assumed one thing: “If someone is inside the network, they can be trusted.” That assumption worked when offices were closed environments and systems lived behind a single controlled gateway. But as Microsoft highlights in its Digital Defense Report, attackers have moved almost entirely toward identity-based attacks because stealing credentials offers far more access than exploiting firewalls. In other words, attackers stopped trying to break in. They simply started logging in. Cloud + remote work = No perimeter Now, with remote work and the cloud, there’s no real perimeter left. People connect from home Wi-Fi, personal laptops, airports, coffee shops — you name it. At the same time, company data and workloads are scattered across AWS, Azure, Google Cloud and various SaaS platforms. The old rules just don’t fit anymore. There is no single “inside” anymore. There is only identity — the user behind the request. This is why modern security frameworks, including NIST’s Zero Trust Architecture guidelines (SP 800-207), emphasise identity as the primary control point rather than the network. Identity is now the primary attack surface Identity brings convenience, but it also brings complexity — and complexity attracts attackers. People reuse passwords. MFA fatigue attacks work far too often. Privileged accounts get over-granted. Contractors keep access long after their projects end. Service accounts multiply with no owner. Okta’s recent State of Identity Security report points out that identity misuse has become one of the fastest-growing attack vectors in enterprises. Identity is no longer just a log-in step. It’s now the attacker’s first target. Zero trust made identity the first door to lock Zero trust isn’t about paranoia. It’s about verification. Never trust, always verify only works if identity sits at the center of every access decision. That’s why CISA’s zero trust maturity model outlines identity as the foundation on which all other zero trust pillars rest — including network segmentation, data security, device posture and automation. A strong identity-based perimeter includes: MFA everywhere SSO to reduce password fatigue Role-based access controls Privileged Access Management Device trust tied to user identity Continuous monitoring of user behaviour Adaptive, risk-based access policies This isn’t the future — this is what’s expected today. Identity done right requires real discipline When identity becomes the perimeter, it can’t be an afterthought. It needs to be treated like core infrastructure. That means: Identity has to be engineered, not patched together. Lifecycle processes must be streamlined — joiners, movers and leavers must be tightly controlled. Privilege needs to be what people earn, not what they start with. Excess-access is still one of the top contributors to breaches. Authentication methods need to evolve yearly. Static MFA policies won’t survive dynamic threats. Monitoring must follow behavior, not networks. Suspicious activity often hides in user patterns, not traffic flows. Identity ownership must be shared across security, IT and the business. Identity doesn’t succeed unless everyone is accountable. Gartner has been emphasising this shift for years, calling identity “the new security perimeter” in multiple research publications aimed at CISOs and enterprise architects Where we’re heading next Identity is already at the centre of modern cybersecurity, but its role is only going to grow stronger. Over the next few years: Passwords will fade out in favour of passkeys and biometrics. Machine identities will become as critical as human identities. Access decisions will adapt in real time based on behaviour. Identity platforms will become the central nervous system of enterprise security. Zero Trust will mature from architecture diagrams into everyday practice. Organizations that invest in strong identity foundations won’t just improve security — they’ll improve operations, compliance, resilience and trust. Because when identity is solid, everything else becomes clearer: who can access what, who is responsible for what and where risk actually lives. The companies that struggle will be the ones trying to secure a world that no longer exists — a perimeter that disappeared years ago. Identity isn’t just the new perimeter. It’s the new beginning. Everything starts here now. This article is published as part of the Foundry Expert Contributor Network. Want to join? View the full article

MirasWonderland – shutterstock.com Mit einem gefälschten Video des bekannten Unternehmers Reinhold Würth versuchen Betrüger derzeit, Nutzer im Internet zu dubiosen Geldanlagen zu verleiten. In dem täuschend echt wirkenden Clip lädt eine mutmaßlich mit Hilfe von Künstlicher Intelligen (KI) generierte Version des Milliardärs zu einem vermeintlich exklusiven Investment ein. Im Hintergrund sieht man ein Regal mit Produkten des Handelskonzerns. Das Versprechen: Schnelle Gewinne schon bei geringen Einsätzen. Die Gruppe bestätigte, dass es sich um eine Fälschung handelt. Zuvor hatten mehrere Medien berichtet. Reinhold Würth stehe in keinerlei Verbindung zu derartigen Angeboten, teilte eine Pressesprecherin auf Anfrage mit. “Solche Deep‑Fake‑Manipulationen stellen einen schweren Identitätsmissbrauch dar und dienen ausschließlich betrügerischen Zwecken.” Man verurteile das Vorgehen aufs Schärfste und distanziere sich klar von den verbreiteten Inhalten. Die Würth-Gruppe geht demnach bereits konsequent gegen die Verbreitung des Materials vor und steht im Austausch mit den Strafverfolgungsbehörden. Über offizielle Social-Media-Kanäle sei die Öffentlichkeit vor dem Fake-Video gewarnt worden. Betroffenen rät das Unternehmen, keine Interaktionen mit den angeblichen Finanzangeboten einzugehen. Wer bereits Geld investiert habe, solle umgehend seine Bank informieren und Anzeige bei der Polizei erstatten. Würth mit Sitz in Künzelsau (Baden-Württemberg) gilt als Weltmarktführer im Bereich der Befestigungs- und Montagetechnik. Das Sortiment umfasst mehr als eine Million Produkte – unter anderem Schrauben und Dübel. Firmenpatriarch Reinhold Würth zählt zu den reichsten Deutschen. Vor gut einem Jahr hatte sich der 90-Jährige weitgehend von seinem Lebenswerk zurückgezogen. Angebote sind oft schwer als Betrug zu erkennen Die Polizei und die Bundesanstalt für Finanzdienstleistungsaufsicht (Bafin) warnen regelmäßig vor solchen Betrugsmaschen. Immer wieder würden Werbeanzeigen oder E-Mails verbreitet, in denen mit Fotos oder Videos von Prominenten ohne deren Wissen für angeblich sichere Geldanlagen mit außerordentlich hohen Gewinnen geworben werde. Häufig gehe es um Kryptowerte oder anderen Finanzprodukten. Die Angebote seien oft professionell gestaltet und für Laien schwer als Betrug zu erkennen. Die Bafin warnt davor, Links in solchen Anzeigen anzuklicken. Diese führten häufig zu betrügerischen Online-Handelsplattformen. Nach einer Registrierung gäben sich die Täter als Experten aus und überredeten zunächst zu kleinen, später zu immer höheren Investitionen. Angezeigte Gewinne seien lediglich vorgetäuscht. Tatsächlich finde in der Regel keine Investition statt und das eingezahlte Geld fließe an die Betrügerinnen und Betrüger. Weitere Tipps hat die Polizei auf einer Internetseite zusammengefasst. (dpa/jm) View the full article

A free, publicly accessible database for IT security vulnerabilities, the db.gcve.eu, has been created by GCVE (Global Cybersecurity Vulnerability Enumeration). The aim is to end dependence on US databases and strengthen digital sovereignty in Europe. The initiative came together after a brief scare over the possible discontinuation of the Common Vulnerabilities and Exposures (CVE) program in 2025. The risk got many concerned forcing the cybersecurity industry to start thinking of alternatives. GCVE database aims to facilitate vulnerability reporting The platform brings together information from various public resources. These include the sources of the GCVE Numbering Authority (GNA) model. It replaces the traditional, centralized assignment of vulnerability identifiers (CVE IDs). Data from other recognized vulnerability directories is also used. The decentralized approach makes it possible to assign and publish vulnerability identifiers autonomously without having to wait for central approval. A total of more than 25 different data sources are currently integrated. The vulnerability data collected is normalized, structured, and made searchable. In addition, the open API offers seamless integration into existing compliance tools and risk management systems. This should enable security officers, scientists, computer security incident response teams, software providers, and open-source developers to track and evaluate security reports more efficiently across ecosystems. View the full article

Web browsers have long been the security sinkhole of enterprise infrastructure. While email is often cited as the most common entry point, malware often enters via the browser and is more difficult to prevent. Phishing, drive-by attacks, ransomware, SQL injections, man-in-the-middle (MitM), and other exploits all take advantage of the browser’s creaky user interface and huge attack surface, and the gullibility of most end users. It is this last item — humans — that is the problem, and we need to be protected against ourselves. This is especially true as SaaS applications grow in usage, not to mention that every piece of hardware seems to come with a web server (and therefore a browser) to configure it. These use cases are aided and abetted by the increasing number of work-from-home staffers who depend on more browser-based apps. This is why enterprise secure browsers have finally gotten their moment. The category, which has been mostly flying under the radar for the past six years, has seen a lot of changes. Google announced its own entry into the field in 2025. Appaegis, Talon and Perception Point were acquired by Mammoth Cyber, Palo Alto Networks and Fortinet respectively, showing how this technology has become part of a larger security context. To that end, other established security vendors have brought forth products in what Gartner is now calling the “remote browser isolation” market to complement their zero trust, secure services edge, or posture management security platforms. Web browsers have security settings to protect your privacy and to enable you to browse sites more anonymously. This isn’t really a satisfactory solution because these settings will typically result in more user frustration. Turning up security settings will prevent your users from conducting business on many websites, either blocking pop-ups that are needed to navigate some business site, stopping forms from collecting important information, or making your browsing session miserable in some other fashion. Brave, DuckDuckGo, RAV Online Security from ReasonLabs, Opera and others have more secure consumer-focused browsers, but these aren’t appropriate for enterprises. They are what I would call “safer” or “more private” browsers. Some vendors have taken the recommendations of the Global Privacy Control to heart and have developed their own browser extensions that help guard your individual privacy. All these browsers are better but still not good enough for business uses. Instead, a different type of tool is needed to manage an entire browser collection. Gartner in an April 2025 report, says, “Threat actors frequently target employees with phishing attacks to steal credentials and bypass endpoint detection and response controls, necessitating an additional layer of visibility and control within the web browser.” Gartner recommends secure browsers can complement “gaps in existing controls on managed devices rather than replace existing security controls, unless you are a cloud-only, remote-work-oriented company with few physical locations to secure.” While some enterprise security products touch on browser security such as secure web gateways, running a browser in a virtual desktop or using a managed endpoint service, they don’t focus on the total browsing experience and can’t stop many of the potential threat vectors. This is why the secure browser has become more popular and is available in a variety of configurations that can help IT managers get a better handle on stopping attackers from getting a foothold inside your networks. Tips to evaluate secure web browsers Before you start an evaluation, you need to understand how these browsers work and how they will be managed. Browsers require a robust and granular collection of security controls to be able to work with the widest possible collection of websites and cloud services. This needs to happen from a central management platform that can apply a collection of firewall-like rules and policies across the entire user population. This includes several broad categories: Enable MFA at the beginning of any browser session by default. Handle isolation controls both with respect to the user’s session and to isolate any application from cross-infection. This means controlling the movement of data between the browser, your particular endpoint and the web application or applications involved. Control access to web destinations, either to allow or block this access. Detect malware to block phishing, man-in-the-browser and other attacks, such as those aimed at defeating browser extensions. Apply data loss prevention controls, which include browser settings such as ad blocking, URL and domain filtering, blocking printing, cut-and-paste operations, and screen sharing. These controls should also be able to manage your browser extensions in such a way that a user can’t override or circumvent them. Enable a variety of logging tools to aid in remediation or reconstruction in case of attacks or data destruction. Enable anonymous surfing for times when this is needed, such as protecting travellers when they are in more totalitarian locations. Enable a protected and secure file storage space that can be shared among a team of collaborators. Replace VPNs and virtual desktops as ways to deliver more secure remote and cloud services. Any browser needs to integrate with existing security products such as identity management, cloud applications security posture, single sign-on (SSO) and VPNs. That is a lot of software to work with, and some vendors have begun offering specialized browsers as part of their security platforms. Forexample, iBoss’ and Cloudflare’s Remote Browser Isolation tools are only available as an add-on option to its larger security platforms. GigaOm uses this rubric where the browser must come up to four different (and non-exclusive) operating modes, in various combinations: A full desktop browser client, what we have called in the past a thick client, to replace a consumer browser and typically connects to a secure remote session. Browser extension to existing consumer browsers, relevant to both the browser software and underlying operating system. Agentless browser controls to enforce security policies. Cloud-based management and proxy, which is typically used with the above three modes or with a thin client that connects to the cloud service. For example, Google’s Chrome Enterprise browser mostly relies on the fourth mode. Other products, such as Authentic8’s Silo, Palo Alto Networks’ Prisma and Island’s browsers offer products that cover multiple modes. There is a fifth mode that Seraphic uses, building an agent that sits on top of the JavaScript engine and supplements existing browsers. Why are these different deployment modes necessary? It is because the browser is so versatile and can operate in a variety of circumstances, ranging from controlling some SaaS-based application to viewing dynamic content from a database to managing a collection of remote servers. Having the different modes is a way to extend its utility and still provide a secure envelope in as many possible situations. While all these products run specially crafted Chromium versions, they typically employ Linux virtual machines to provide remote isolation features. That could be an issue if you are trying to run web content that isn’t Linux friendly, such as some streaming services. The good news is that the secure browsers are close to parity with a standard desktop browser and running close to the most current Chrome versions. The biggest issue to implement these browsers will be staffing and support. This starts with integration into your other security products and onboarding and training your users how to browse the web under the newer and hopefully more secure regime. This will be a significant load on your own internal support resources to handle the various helpline calls from confused or frustrated users when they encounter unexpected results from their browsing experience. Finally, there is the price. For decades browsers have been free or bundled with the endpoint operating system. Secure browsers will cost something, and even a few dollars a month per user can add up over time and across an entire enterprise population. Gartner said in its report: “Free browsers are ubiquitous, to the point that organizations must have specific use cases to justify the purchase of a separate browser.” It remains to be seen if security is that compelling use case. Expect to pay somewhere around $10/month/user for subscription options, with quantity discounts available. Secure web browsers compared Authentic8 has been in the secure browser business for more than a decade and continues to enhance its product and widen its services offerings. Silo can provide two-way full isolation and integrate it into your existing workflows and provide a wide collection of security policies that offer fine-grained control over protecting your apps and your data. It has a main dashboard that looks a lot like an SSO tool to launch your protected web applications. Silo offers two different client downloads: Windows and Mac thick clients and a thin client. Both can be managed centrally and via an API connection, all of which kick off Linux-based sessions. While the vendor did not reveal pricing specifics, two plans are available: on a per user or per hourly consumption basis. It also provides custom browsers based on a customer’s API collection. Ermes Browser Security offers a variety of security features including phishing protection, cybersquatting, extension monitoring, and URL filtering. It uses a browser extension and has separate mobile apps. Fortinet acquired Perception Point’s secure browser extension and integrated it into this product Fortinet Remote Browser Isolation. It integrates with other protective features such as securing cloud apps and offers any browser real-time protection with other dynamic security features through a browser extension. The product is sold with various quantity discounts, with typical pricing at $55/user/year. Google’s own enterprise product uses the Chrome Enterprise Core as its foundation, which is also the free version. The Premium version adds most of its protective features. Both versions have a very complex setup to enable their managed browser service, part of its complexity is that it has numerous fine-grained security controls, such as numerous steps to add encryption, as well as using specialized OS-specific installation such as mobile management software with more than a dozen steps. The other products make this a bit easier, but there is still a lot of trial and error with Google’s software to ensure that the security isn’t blocking legitimate browsing uses, sites, or corporate applications. It is available for all Google Workspace customers and will cost an additional $72/user/year, with a free 30-day trial period that includes 50 user licenses. Island’s enterprise browser comes both as a browser extension and a thick replacement client for Linux, Windows, Mac, Android, iOS and Chromebooks. It has extensions for Chrome, Edge, Safari and Firefox. It has robust network management and protective functions to complement its browser security. LayerX Security enterprise browser has both an extension and a thick browser client which integrates with a number of identity protection platforms and offers extension monitoring, DLP, traffic filtering and other features. Mammoth acquired Appaegis’ secure browser and offers a thick managed client that includes browser session recording, copy-paste blocking, watermarking, screen-share prevention, and data masking. It supports Windows, Mac, iOS and Android devices. The Android version is the most recent and doesn’t have complete feature parity with the other OS versions. ManageEngine Browser Security Plus is a thick Windows and Mac browser called Ulaa. It comes in a free edition for up to 25 computers and professional edition with additional security features, including DLP, threat prevention, web filtering and phishing protection. Menlo Security Secure Enterprise Browser is a cloud-based software part of a collection of other products that offer file security, ZTNA and other protective features. Palo Alto Networks Prisma Access Browser is a result of the acquisition of Talon’s browser technology and offer thick clients for Windows, Mac, Linux, Android and iOS and browser extensions. It uses a cloud-based management service from Strata. It has a full managed feature set that includes data loss prevention features, extensive logging, and plenty of policies and rule sets. Like some of the others, you can set up a main login like an SSO tool to launch your apps. It will examine the endpoint posture to ensure that it is running the latest OS version and identify risky browser extensions or restricted URLs that you can specify. It comes with a detailed implementation guide and existing Prisma platform customers are eligible for free browser licenses. Seraphic Enterprise Browser Security has a unique mode of operations with an agent that works on top of the browser’s JavaScript engine. It supports both managed and unmanaged browsers including generative AI-based Atlas and works with a series of protective modules including ZTNA, DLP, traffic filtering, remote connection management, identity security and other security features. There are also thick clients for both Android and iOS devices. It has competitive per-user pricing (each user can install on up to four devices) with quantity discounts. Surf Security Zero Trust Enterprise Browser offers both a thick browser replacement client and browser extension with a variety of protective features, including DLP and ZTNA support, and integration into Okta’s SSO platform. SquareX Enterprise offers a browser extension that includes DLP, generative AI protection and threat hunting features, and can isolate and remove malicious code. It supports the three major desktop OSs and major browser vendors, including AI-based browsers from Perplexity and Atlas. It integrates with various identity, SIEM and SSO providers and supports Okta’s Shared Signal Framework. View the full article

Enterprises using Intune mobile application management (MAM) beware: Your apps won’t run soon if you haven’t planned ahead. Microsoft is updating its Intune MAM to support new security requirements starting January 19 or “soon after”, requiring that all iOS-wrapped apps, iOS SDK-integrated apps, and the Intune Company Portal for Android be updated to the latest Intune versions to keep them secure and running. This means that enterprises that haven’t updated to the latest versions will be blocked from launching their apps altogether. And, this may not just include custom apps wrapped in Intune MAM, but other frequently-used ones such as Outlook and Teams. Simply put, “If you want your stuff to work, get it updated and pushed,” said David Shipley of Beauceron Security. What’s being updated in iOS, Android Microsoft Intune is a core component of the Microsoft Modern Workplace. Its MAM features help enterprises secure their data on both corporate and personal devices. Using it, IT teams can manage corporate apps like Outlook or Teams without having to manage the entire device. This type of unified endpoint management (UEM) supports feature deployments, updates, and retirement of apps, while also protecting corporate data and preventing data leaks, with (ideally) minimal disruption for the user. With Monday’s hard deadline, Microsoft will enforce stricter security requirements within the UEM — but only for approved users. Those without the latest app protection supported Microsoft or third-party apps will “be blocked from launching their apps,” the company warned. Microsoft announced the required updates several months ago in the Microsoft 365 Admin Center. For Apple users, Monday’s full stop means: iOS line-of-business (LOB) and custom iOS apps using the Intune App SDK must update to SDK version 20.8.0 or later for apps compiled with Xcode 16, and to 21.1.0 or later for apps compiled with Xcode 26. Apps using the wrapper must update to the new version of the Intune App Wrapping Tool for iOS: version 20.8.1 or later for apps built with XCode 16; and version 21.1.0 or later for apps built with XCode 26. It’s a little simpler for Android users: Once one Microsoft app with an updated SDK is on the device and the company portal is updated to version 5.0.6726.0 or later, other Android apps will update. Tenants with policies targeted to both iOS and Android apps should notify their users that they need to update, and ensure Microsoft apps such as Teams and Outlook are up-to-date, Microsoft advised. Admins can also enable conditional launch settings to block apps using older versions of the SDK or to warn users if they are using older versions of apps. Admins can also proactively ensure that users are not blocked while doing work on their phones. In the Microsoft Intune admin center, they can navigate to Apps > Monitor > App protection status to review the app and SDK versions users are running. “We recommend to always update your Android and iOS apps to the latest SDK or app wrapper to ensure that your app continues to run smoothly,” Microsoft emphasized. Overall, the company advised enterprises to use conditional access policies so that only apps with app protection policies enabled can access corporate resources. Supporting new security tools (and why enterprises should have updated yesterday) With its new security updates, Microsoft has wrapped controls around existing custom apps that businesses have built, Beauceron’s Shipley explained. These enable features such as requiring a PIN or biometric authentication inside the app, restricting data sharing with other managed apps, and selectively wiping corporate data from apps. “This [update] may be because there’s some risk with the older versions not doing what they should’ve been doing for protections,” Shipley noted. He pointed out that Microsoft has been signaling this update since 2025 and already pushed back implementation from mid-December 2025 to this week. Also, it’s interesting to note that this change may not just impact custom apps wrapped in Intune MAM, but Outlook, Teams, and others applications as well. “The long and short of it is, what Redmond wants is what Redmond gets when it finally puts a foot down, like it appears to have in this case,” said Shipley. This deadline shouldn’t come as a surprise to IT teams who stayed on top of things, noted Fritz Jean-Louis, principal cybersecurity advisor at Info-Tech Research Group. Microsoft has been deprecating various parts of Intune, and how it connects from an infrastructure perspective, for some time now. “Like many other things, if you’re not actively managing [with] the right amount of due diligence, you will be impacted by this,” said Jean-Louis, noting that employees dealing with work tasks on their phones (either remotely or on-premises) will experience outages without the updates. “It’s going to seriously impact users if this has not been adequately addressed.” From an IT perspective, if they’re not ready for the new versioning, admins should contact Microsoft as soon as possible and determine whether mitigations can be put in place until their team is ready. If users experience issues, they should contact their official IT service desk, Jean-Louis advised. They should not attempt to self-resolve by, say, going to a random site and blindly entering a user ID and password to receive updates. Threat actors may be lying in wait, using this type of opportunity to deploy malware “fixes.” “Threat actors are always looking for this sort of major change to take advantage,” he noted. This article originally appeared on Computerworld. View the full article

Google’s Mandiant security division has come up with an unusual tactic to persuade organizations to stop using the aged and hugely insecure NTLMv1 authentication protocol: publish a data lookup that makes cracking NTLMv1 credentials trivial for attackers. The intention, Mandiant explained, is to draw attention to the fact that, despite decades of evidence that NTLMv1 (NT LAN Manager version 1) is insecure, organizations continue to use it. Anyone can use Mandiant’s Net-NTLMv1 pre-computed rainbow table lookup, downloadable from the Google Cloud Research Dataset portal, to map a given server response to reconstruct a real NT hash. Hashes, of course, are mathematical representations of real passwords, but are just as useful to criminals when exploited using techniques such as pass-the-hash. The benefit is time and money saved: Mandiant reckons its rainbow table allows the recovery of an NTLMv1 key in 12 hours using a computer costing $600, rather than relying on third party services or expensive hardware to brute-force the keys. None of this makes NTLMv1 less secure or easier to target than it already is. Mandiant’s hope is that the release of the table will serve as a reminder that the problem exists, prompting organizations to finally rip out NTLMv1 from their networks. “This legacy protocol leaves organizations vulnerable to trivial credential theft, yet it remains prevalent due to inertia and a lack of demonstrated immediate risk,” the company said in its announcement. “By releasing these tables, Mandiant aims to lower the barrier for security professionals to demonstrate the insecurity of Net-NTLMv1.” Long fallback NTLMv1 is a 1990s challenge-response protocol used to authenticate Windows NT users to Active Directory (AD). Based on 1980’s Data Encryption Standard (DES) encryption, it was updated to the more secure NTLMv2 in 1996 before being completely replaced by Kerberos. Unfortunately, legacy protocols like NTLMv1 don’t just disappear, and are retained as a fallback in case they are needed by older applications. That fallback has turned out to last decades. What evidence does Mandiant have that organizations are still using NTLMv1? The first is anecdotal: “Mandiant consultants continue to identify its use in active environments,” the company noted in last week’s announcement. Secondly, cyberattackers regularly target it. For example, a 2024 campaign by the TA577 threat group targeted NTLM hashes by using booby-trapped emails to send challenge-response authentication requests to internal SMB resources such as legacy printers. A more recent incident involved an authentication relay attack aimed at a specific NTLM vulnerability, CVE-2025-54918, which came only weeks after Microsoft announced that it was finally removing NTLMv1 support from Windows Server 2025 and Windows 11. Primary hurdle: Knowing it’s still there According to Rob Finn, International vice president at supply chain security company Chainguard, even security-aware organizations could be caught out by NTLMv1. “Legacy protocols like NTLMv1 are buried deep within third-party firmware. A security team might deprecate NTLMv1 at the OS level, only to have a legacy printer driver or industrial sensor reintroduce it via an unpatched, decades-old library,” he said. “For most companies, the primary hurdle isn’t just knowing NTLMv1 is insecure, it’s knowing that it’s still there.” Because resources such as printers are not externally exposed, it is tempting to assume they are beyond the reach of attackers. Despite this, NTLMv1 can still be targeted from outside the network using relay or coercion techniques, by, for example, triggering authentication via a phishing attack. “Attackers don’t need to know you’re using it. They just have to poke the system to find out. Fundamentally, organizations keep legacy protocols active not because they want to, but because they fear breaking a mission-critical legacy app,” said Finn. Despite Microsoft recommending that organizations upgrade to NTLMv2 and Kerberos for more than two decades, it appears not everyone got the memo. “In crypto terms, NTLMv1 isn’t just old, it’s archaeological,” said Rob Anderson, head of reactive consulting services at Reliance Cyber. “NTLMv1 is still enabled, not because it is needed today, but because it was needed once, and nobody is quite brave enough to turn it off and see what breaks.” Despite those fears, organizations need to take action. “Scan for its use, find out why it is in use, register it as a high risk and get to work removing it, with achievable deadlines,” he advised. View the full article