Security & IT News

Threat actors brute-forced VPN credentials and bypassed multi-factor authentication (MFA) on SonicWall Gen6 SSL-VPN appliances to deploy tools used in ransomware attacks. [...]

Microsoft has identified an active supply chain attack targeting the @antv node package manager (npm) package ecosystem. A threat actor compromised an @antv maintainer account and published malicious versions of widely used data-visualization packages, resulting in cascading downstream impact. The compromise propagated through dependency chains into libraries like echarts-for-react (which has more than 1 million weekly downloads), expanding the blast radius into CI/CD pipelines and cloud workloads across the ecosystem. The malicious payload—a ~499 KB obfuscated JavaScript file—runs silently during npm install and is purpose-built to steal credentials from GitHub Actions environments. Key capabilities observed in the payload include multi-platform credential theft (GitHub, Amazon Web Services, HashiCorp Vault, npm, Kubernetes, 1Password), GitHub Action Runner process memory scraping, privilege escalation, dual-channel data exfiltration, and Supply chain Levels for Software Artifacts (SLSA) provenance forgery. These capabilities suggest a deliberate effort to evade analysis and an apparent focus on CI/CD environments. The authors of the antv account have also since confirmed in a ticket on the repo that the situation is now resolved. Attack chain overview Figure 1. @antv npm supply chain attack flow. The @antv organization maintains charting libraries (G2, G6) embedded across dashboards and applications. The attack proceeds through: Maintainer account compromise and publication of malicious @antv package versions Downstream dependency amplification ( echarts-for-react , size-sensor , and others) Automatic payload execution through a preinstall hook during npm install Execution chain: node → shell → bun → payload (Bun runtime installed if absent) Technical analysis The payload replaces the legitimate index.js with a single-line obfuscated script. Obfuscation Layer 1: 1,732 Base64-encoded strings in a rotated array, decoded through lookup function with the shuffle key 0xa31de Layer 2: Critical strings such as command-and-control (C2) domain and env var names are encrypted with a custom PBKDF2 and SHA-256 cipher, which is decrypted at runtime. Environment gating: The payload exits immediately if it’s not running on GitHub Actions on Linux Branch avoidance: Skips the main , master , dependabot/ , renovate/ , and gh-pages when using Git API exfiltration // Layer 1: 1,732 strings in rotated array with base64 decode (function(_0x44be0e, _0x3ff020){ // Array shuffle IIFE with key 0xa31de _0x335af4['push'](_0x335af4['shift']()); })(_0x71ec, 0xa31de)); // Layer 2: PBKDF2+SHA256 runtime decryption for critical strings var e6 = "a8269c01069452afb8a54de904e6419578d155fdbdb9e566bab8576a4266b61e"; var t6 = "7f44e4ba6f6a71bd0f789e7f83bd3104"; var u5 = new du(e6, t6); // PBKDF2 cipher instance globalThis["f2959c600"] = function(s) { return u5.decode(s); }; // Environment gate - exits if not GitHub Actions on Linux this['isGitHubActions'] = process.env[f2959c600('68

Microsoft has unveiled two new open-source tools called RAMPART and Clarity to assist developers in better testing the security of artificial intelligence (AI) agents. RAMPART, short for Risk Assessment and Measurement Platform for Agentic Red Teaming, functions as a Pytest-native safety and security testing framework for writing and running safety and security tests for AI agents, covering

The Deputy CISO blog series is where Microsoft Deputy Chief Information Security Officers (CISOs) share their thoughts on what is most important in their respective domains. In this series, you will get practical advice, tactics to start (and stop) deploying, forward-looking commentary on where the industry is going, and more. In this article, Aaron Zollman, Vice President and Deputy CISO for Gaming at Microsoft discusses the unique challenges and rewards of securing gaming . There are more than 500 million monthly active players¹ across Xbox consoles, PC, handheld, and more through Xbox cloud gaming . They’re the folks who come to mind when people refer to “gaming culture.” But they’re not really the whole story. Globally, more than 3 billion people engage with gaming.² The majority of these people are gamers, but the number also includes developers working for independent gaming studios, engineers supporting the Xbox platform, and the security and operations professionals that support them all. In my role as Deputy CISO for Gaming at Microsoft, it’s this much larger, much more complex community that I have to take into account. My team and I aren’t tasked solely with protecting consoles or player accounts. We’re safeguarding intellectual property (IP), live operations, and the trust of billions of interactions. We’re also partnering on risks that range from cheating and monetization exploits to supply chain vulnerabilities and regulatory compliance for child safety and privacy. Gaming isn’t really a single culture, but rather a culture of cultures—each with their own risk factors to account for. At the heart of gaming is the player experience—their need for seamless access, low latency, and frictionless, immersive experiences. This goes hand-in-hand with privacy and safety in a world where cyberattackers could target well-known players. But aside from those basic needs, players form their own tribes, and a diverse, global player base requires a different approach—which makes securing gaming unique. You don’t approach it like you might traditional enterprise. Studios operate with creative autonomy, platforms demand global scale and low latency, and players expect frictionless experiences. That diversity makes gaming vibrant while also creating unique security challenges. Each culture comes with its own security risks Let’s first take a look at the risks that most often appear with each of the overlapping cultures that make up the world of gaming: Platforms , underpinning services like Xbox Game Pass and Xbox Cloud Gaming, require centralized infrastructure with high availability. Here, security must integrate seamlessly with identity systems and Microsoft-wide standards without slowing down gameplay. But platforms face a number of distinct risks. The complexity of platforms makes them a rich target for financially-motivated cyberattackers seeking to take over top accounts—or send targeted messages to individuals in an environment where they aren

The Grafana data breach was caused by a single GitHub workflow token that slipped through the rotation process following the TanStack npm supply-chain attack last week. [...]

Premium Deception campaign uses 250 Android apps to silently sign victims up to paid services

Trump Mobile is leaking customers’ email and home addresses but has not responded to people alerting the company of the data exposure, according to two YouTubers who said they verified that their leaked data is authentic.

In this article Why we are investing in this RAMPART: Continuous safety testing for agentic AI Clarity: Helping check software engineering assumptions RAMPART and Clarity available now The AI systems shipping inside enterprises today are fundamentally different from the ones we were building even two years ago, because they have moved well past answering questions and into accessing your email, retrieving records from your CRM, writing and executing code, and taking actions on your behalf across dozens of connected systems. That shift from “generate text” to “do things in the world” changes the safety equation entirely, because an agent that can act can also potentially act in ways nobody intended. Today Microsoft is open-sourcing two tools designed to help engineers: Microsoft RAMPART , an agent test framework for encoding adversarial and benign scenarios as repeatable tests that can run in CI, making it easy to turn red-team findings and AI incidents into lasting regression coverage; and Clarity , a structured sounding board that helps teams figure out whether they are building the right thing before they write a single line of code. We built these tools because we believe that AI safety has to become a continuous engineering discipline rather than a periodic checkpoint, and we think the best way to make that happen is to put practical, open tools in the hands of the people doing the building. Why we are investing in this Helping teams think through the “why,” before the “how” of software building: In the vibe coding era, execution is easy and the harder question is the “why.” The most expensive safety failures we see almost always trace back to design mistakes that nobody questioned early enough, long before any adversary got involved — say, when a product team decided their agent should have access to a tool, or handle a particular user flow, without fully working through what could go wrong. By the time a red team engagement surfaces the issue, the system is largely built, and addressing it means going back to the drawing board. We wanted to give product managers and engineers a way to pressure-test their assumptions at the start of a project, when changing course is cheap and the right conversation can save months of rework. Scaling the lessons of red teaming across the industry. The techniques that uncover vulnerabilities in one agentic product almost always shed light on another. A cross-prompt injection attack that works against one system will often work, with minor variations, against a customer service agent or a coding assistant. But those lessons tend to stay locked inside individual engagement reports. Our goal was to build a system where the lessons of red teaming exercises can be turned into runnable engineering assets. Making incidents reproducible and mitigations verifiable. If something goes wrong in production AI systems, the team responding needs to do two things quickly: replicate the incident

Mini Shai-Hulud worm hits Alibaba AntV ecosystem in largest npm supply chain wave to date

Before indicators, before oscillators, before anything that requires a formula – the market communicates through price structure. Peaks…

Microsoft on Tuesday said it disrupted a malware-signing-as-a-service (MSaaS) operation that weaponized the company's Artifact Signing system to deliver malicious code and conduct ransomware and other attacks, compromising thousands of machines and networks across the world. The tech giant attributed the activity to a threat actor it calls Fox Tempest, which it said offered the MSaaS scheme

Good report : Executive Summary: Let’s say you wanted to make sure that your AI is secure. Can you just maximize the security and privacy benchmark and call it a day? Nope, because benchmarks don’t actually work for measuring AI capabilities (even when they are NOT emergent systemic properties like security). So let’s take a step back: how do you measure security in the first place? Good question. Over the last 30 years, security engineering for software evolved from black box penetration testing, through whitebox code analysis and architectural risk analysis to de facto process-driven standards like the Building Security In Maturity Model (BSIMM). Software had a very deep impact on business operations, and it appears that AI is going to have an even deeper impact. Will a software security-like measurement move work for AI? Probably. In the meantime we can make real progress in AI security by cleaning up our WHAT piles and managing risk by identifying and applying good assurance processes. (Spoiler alert: no matter what we do, we still don’t get a security meter for AI, so we need to be extra vigilant about security.)

Identity checks alone can't stop attackers using stolen session tokens and compromised devices. Specops Software outlines why Zero Trust strategies increasingly depend on continuous device verification. [...]

GitHub Breach: TeamPCP stole 3,800 internal repositories through a malicious VS Code extension and is now selling the data online for $95,000.

The code hosting giant GitHub said it was investigating a breach, but said there was no evidence of customer data theft.

Drupal has announced a "core security release" scheduled for later today, warning that threat actors might develop exploits within hours of the update disclosure. [...]

Cybersecurity researchers have flagged fresh activity from a China-aligned threat actor known as Webworm in 2025, deploying custom backdoors that employ Discord and Microsoft Graph API for command-and-control (C2 or C C) communications. Webworm, first publicly documented by Broadcom-owned Symantec in September 2022, is assessed to be active since at least 2022, targeting government agencies

Verizon DBIR 2026 reveals software vulnerabilities overtook stolen passwords in cyberattacks, with AI helping hackers exploit flaws within hours.

Modern attack surfaces don’t sit still. Cloud expansion, SaaS sprawl, identity complexity, and shadow IT are continuously reshaping organizational risk. For security leaders, visibility isn’t the challenge anymore, but actually operationalizing that visibility is. Surface Command was built to unify asset and identity intelligence across your external attack surface. But translating that intelligence into executive-ready dashboards or operational reporting has often required knowledge of Cypher queries. Today, that changes: We’re introducing filter-based dashboard widgets in Surface Command, enabling teams to build meaningful attack surface management (ASM) dashboards in minutes, without writing a single query. And for CISOs focused on advancing continuous threat exposure management ( CTEM ), this is more than a usability enhancement. It’s an operational accelerator. From filters to dashboards, instantly Security teams already use saved asset and identity filters to answer critical questions: Which internet-facing assets are high risk? Where do privileged identities intersect with exploitable exposures? Which business units own unmanaged cloud infrastructure? What third-party SaaS applications expand our attack surface? Now, those same saved filters can be converted directly into live dashboard widgets. If your team can build a filter table, they can now build a dashboard. There’s no need to understand query syntax or rely on specialized expertise for common reporting needs. With just a few clicks, exposure views become shareable, persistent dashboards built on the same unified data model that powers Surface Command. Figure 1: Creating dashboard “widgets” in the Rapid7 Command Platform Reducing friction in exposure reporting For many organizations, the barrier to effective exposure management isn’t visibility, it’s friction. When dashboard creation requires query expertise, reporting slows down, operational teams depend on a small group of power users, executive visibility lags behind exposure reality, and CTEM initiatives stall under complexity. Filter-based widgets remove that bottleneck. Security teams can now spin up exposure dashboards in minutes, empower analysts and vulnerability teams to self-serve, deliver consistent reporting to leadership, and standardize exposure views across business units. This lowers the barrier to building and maintaining exposure intelligence across the organization, and that matters when “continuous” is the goal. A practical enabler for continuous threat exposure management (CTEM) Beyond a framework, CTEM is a discipline. One that treats exposure management as an ongoing cycle, not a point-in-time project. CTEM is commonly organized into five continuous steps: Scope – Define what you’re focusing on (systems, business services, exposure themes, time horizons). Discover – Identify the assets, identities, and exposures within scope. Prioritize – Determine what matters most based on risk and impact. Validate – Confir

p CISA has added seven new vulnerabilities to its a href= /known-exploited-vulnerabilities-catalog data-entity-type= node data-entity-uuid= 79453b83-86b9-4e2f-b1ec-abf73c6eb291 data-entity-substitution= canonical title= Known Exploited Vulnerabilities Catalog Known Exploited Vulnerabilities (KEV) Catalog /a , based on evidence of active exploitation. /p ul li a href= https://www.cve.org/CVERecord?id=CVE-2008-4250 target= _blank CVE-2008-4250 /a Microsoft Windows Buffer Overflow Vulnerability /li li a href= https://www.cve.org/CVERecord?id=CVE-2009-1537 target= _blank CVE-2009-1537 /a Microsoft DirectX NULL Byte Overwrite Vulnerability /li li a href= https://www.cve.org/CVERecord?id=CVE-2009-3459 target= _blank CVE-2009-3459 /a Adobe Acrobat and Reader Heap-Based Buffer Overflow Vulnerability /li li a href= https://www.cve.org/CVERecord?id=CVE-2010-0249 target= _blank CVE-2010-0249 /a Microsoft Internet Explorer Use-After-Free Vulnerability /li li a href= https://www.cve.org/CVERecord?id=CVE-2010-0806 target= _blank CVE-2010-0806 /a Microsoft Internet Explorer Use-After-Free Vulnerability /li li a href= https://www.cve.org/CVERecord?id=CVE-2026-41091 target= _blank CVE-2026-41091 /a Microsoft Defender Elevation of Privilege Vulnerability /li li a href= https://www.cve.org/CVERecord?id=CVE-2026-45498 target= _blank CVE-2026-45498 /a Microsoft Defender Denial of Service Vulnerability /li /ul p These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise. /p p a href= https://www.cisa.gov/binding-operational-directive-22-01 Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities /a established the KEV Catalog as a living list of known Common Vulnerabilities and Exposures (CVEs) that carry significant risk to the federal enterprise. BOD 22-01 requires Federal Civilian Executive Branch (FCEB) agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the a href= https://www.cisa.gov/sites/default/files/publications/Reducing_the_Significant_Risk_of_Known_Exploited_Vulnerabilities_211103.pdf BOD 22-01 Fact Sheet /a for more information. /p p Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of a href= /known-exploited-vulnerabilities-catalog data-entity-type= node data-entity-uuid= 79453b83-86b9-4e2f-b1ec-abf73c6eb291 data-entity-substitution= canonical title= Known Exploited Vulnerabilities Catalog KEV Catalog vulnerabilities /a as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the catalog that meet the a href= /known-exploited-vulnerabilities data-entity-type= node data-entity-uuid= f2adba9a-0404-494c-a90c-4363a4a5c934 data-entity-substitution= canonical title= Reducing the Significant Risk of Known Exploited