DAILY WORKFLOW ARCHIVE

2026-05-14 AI创业新闻

候选线索仅供信息发现,请在引用或实践前回到原始来源核验。

2026-05-14 AI创业新闻

Microsoft’s MDASH AI System Finds 16 Windows Flaws Fixed in Patch Tuesday

Microsoft has unveiled a new multi-model artificial intelligence (AI)-driven system called MDASH to facilitate vulnerability discovery and remediation at scale, adding that it’s being tested by some customers as part of a limited private preview. MDASH, short for m ulti-mo d el a gentic s canning h arness, is designed as a model-agnostic system that uses bespoke AI agents for different vulnerability classes to autonomously discover, validate, and prove exploitable defects in complex codebases like Windows. “Unlike single-model approaches, the harness orchestrates more than 100 specialized AI agents across an ensemble of frontier and distilled models to discover, debate, and prove exploitable bugs end-to-end,” Taesoo Kim, vice president of agentic security at Microsoft, said . MDASH is envisioned as a “structured pipeline” that ingests a codebase and produces validated, proven findings through a series of actions.

It starts with analyzing the source code to build a threat model and attack surface, running specialized “auditor” agents over candidate code paths to flag potential issues, running a second set of “debater” agents that validate the findings, grouping semantically equivalent findings, and then finally proving the existence of the vulnerabilities. The system is powered by a configurable panel of models, with state-of-the-art (SOTA) models used for reasoning, distilled models for validation for high-volume passes, and a second separate SOTA model for independent counterpoint. “Disagreement between models is itself a signal: when an auditor flags something as suspect and the debater can’t refute it, that finding’s posterior credibility goes up,” Microsoft explained. “An auditor does not reason like a debater, which does not reason like a prover.

Each pipeline stage has its own role, prompt regime, tools, and stop criteria.” Redmond noted that the specialized agents have been constructed based on past common vulnerabilities and exposures (CVEs) and their patches. It also said the architecture allows for portability across model generations. MDASH has already been put to test, unearthing 16 of the vulnerabilities that were fixed in this month’s Patch Tuesday release. The shortcomings span across the Windows networking and authentication stack, including two critical flaws that could pave the way for remote code execution - CVE-2026-33824 (CVSS score: 9.8) - A double-free vulnerability in “ikeext.dll” that could allow an unauthenticated attacker to send specially crafted packets to a Windows machine with Internet Key Exchange (IKE) version 2 enabled, leading to remote code execution.

CVE-2026-33827 (CVSS score: 8.1) - A race condition vulnerability in Windows TCP/IP (“tcpip.sys”) that allows an unauthorized attacker to send a specially crafted IPv6 packet to a Windows node where IPSec is enabled, leading to remote code execution exploitation. News of MDASH follows the debut of Anthropic’s Project Glasswing and OpenAI Daybreak , both of which are AI-powered cybersecurity initiatives for accelerating vulnerability discovery, validation, and remediation before they can be discovered by bad actors. “The strategic implication is clear: AI vulnerability discovery has crossed from research curiosity into production-grade defense at enterprise scale, and the durable advantage lies in the agentic system around the model rather than any single model itself,” Kim said. Found this article interesting?

Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Azerbaijani Energy Firm Hit by Repeated Microsoft Exchange Exploitation

A threat actor with affiliations to China has been linked to a “multi-wave intrusion” targeting an unnamed Azerbaijani oil and gas company between late December 2025 and late February 2026, marking an expansion of its targeting. The activity has been attributed by Bitdefender with moderate-to-high confidence to a hacking group known as FamousSparrow (aka UAT-9244), which shares some level of tactical overlap with clusters tracked under the monikers Earth Estries and Salt Typhoon. The attack paves the way for the deployment of two distinct backdoors across three separate waves: Deed RAT (aka Snappybee), a successor of ShadowPad that’s used by multiple China-nexus espionage groups, and TernDoor , which was recently discovered in attacks targeting telecommunications infrastructure in South America since 2024. What’s notable about the campaign is that it repeatedly leveraged the same vulnerable Microsoft Exchange Server entry point despite several remediation attempts, swapping backdoors each time: Deed RAT on December 25, 2025, TernDoor in late January/early February 2026, and a modified Deed RAT in late February 2026.

The attackers are assessed to have exploited the ProxyNotShell chain to obtain initial access. “This targeting extends the known FamousSparrow victimology into a region where Azerbaijan’s role in European energy security has materially increased following the 2024 expiration of Russia’s Ukraine gas transit agreement and 2026 Strait of Hormuz disruptions,” the Romanian cybersecurity company said in a report shared with The Hacker News. “The intrusion illustrates that actors will exploit and re-exploit the same access path until the original vulnerability is patched, compromised credentials are rotated, and the attacker’s ability to return is fully disrupted.” The initial access is said to have been followed by attempts to deploy web shells to establish a persistent foothold, and ultimately deploy Deed RAT using an evolved DLL side-loading technique that leverages the legitimate LogMeIn Hamachi binary to load and launch a rogue DLL that’s responsible for executing the main payload. “Unlike standard DLL side-loading that relies on simple file replacement, this method overrides two specific exported functions within the malicious library,” Bitdefender explained.

“This creates a two-stage trigger that gates the Deed RAT loader’s execution through the host application’s natural control flow, further evolving the defense evasion capabilities of traditional DLL side-loading.” The attacks have also been found to conduct lateral movement to broaden their access within the compromised network and establish a redundant foothold to ensure resilience in the event that the activity is detected and removed. The second wave, on the other hand, took place nearly a month after the initial intrusion, with the adversary attempting to unsuccessfully employ DLL side-loading to drop TernDoor by means of Mofu Loader , a shellcode loader previously attributed to GroundPeony. The Azerbaijani firm was targeted a third time towards the end of February 2026, when the threat actors once again attempted to deploy a modified version of Deed RAT, indicating active efforts to refine and evolve its malware arsenal. This artifact uses “sentinelonepro [.]com” for command-and-control (C2).

“This intrusion should not be viewed as an isolated compromise, but as a sustained and adaptive operation conducted by an actor that repeatedly sought to regain and extend access within the victim environment,” Bitdefender said. “Across multiple waves of activity, the same access path was revisited, new payloads were introduced, and additional footholds were established, underscoring a high degree of persistence and operational discipline.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

[Webinar] How Modern Attack Paths Cross Code, Pipelines, and Cloud

TL;DR: Stop chasing thousands of “toast” alerts. Join experts from Wiz to learn how hackers connect tiny flaws to build a “Lethal Chain” to your data—and how to break it. Register for the Strategic Briefing Here . Most security tools work like a smoke alarm that goes off every time you burn a piece of toast.

You get so many alerts that you eventually start to ignore them. The real danger? While your team is busy fixing 100 “toast” alerts, a sophisticated attacker is quietly building a Lethal Chain through your system. Hackers rarely look for one big “open door” anymore.

Instead, they find a series of tiny, low-risk “cracks” that don’t look scary on their own. By connecting these cracks—moving from a small coding bug to a cloud misconfiguration—they create a direct path to your most sensitive data. If your tools only look at code or cloud in isolation, you aren’t seeing the big picture. You’re flying blind.

The Briefing: Stop Guessing. Start Mapping. Join security leaders next week for a live deep dive into today’s most dangerous attack patterns with Wiz experts Mike McGuire and Salman Ladha. What we will cover: Beyond the Alert: How to tell which bugs are actually “deadly” by mapping real-world attack paths.

The Code-to-Cloud Gap: Why hackers love the “white space” between your development and your production environments. Cutting the Noise: A practical framework to help your team stop wasting time on alerts that don’t matter. The value of joining us live is the Direct Access. Following the briefing, we will hold an open Q&A session where you can put your specific architecture or pipeline challenges to Mike and Salman.

Save Your Seat: Register for Free Here Can’t make the live time? Register anyway, and we’ll send you the full recording immediately after the session. Found this article interesting? This article is a contributed piece from one of our valued partners.

Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Shadow AI is Everywhere. Here’s How You Can Find and Secure it [Free Guide]

Most Remediation Programs Never Confirm the Fix Actually Worked

Security teams have never had better visibility into their environments and never been worse at confirming what they fix stays fixed. Mandiant’s M-Trends 2026 report puts the mean time to exploit at an estimated negative seven days. The Verizon 2025 DBIR puts median time to remediate edge device vulnerabilities at 32 days. These numbers have understandably driven the industry toward a clear response: prioritize better, patch faster.

That advice is necessary. It is also incomplete. Because the question that still doesn’t get enough attention is this: when you do patch, how do you know it worked? Mythos Didn’t Change the Problem.

It Changed the Speed and Ease of Exploitation. The discussions around the impact of AI have focused on speed: exploit development is getting cheaper, faster, and less dependent on elite human skill. For remediation, this changes the stakes. Plenty of fixes get marked ‘remediated’ when what really happened was a vendor patch that turned out to be bypassable, or a workaround that depended on attackers behaving a certain way.

Those used to be safe enough bets. They aren’t anymore. The question is no longer the speed of remediation. The question is whether your remediation actually eliminated the exposure or simply moved the ticket to ‘done.’ Patch-Perfect, but Still Vulnerable Not every exposure is patchable.

A weak firewall rule leaves the door open, for example. It was found that the policy rule was rewritten and reportedly applied. But was it? When a patch is applied, you get confirmation.

When a privilege is set, or an EDR policy or SIEM setting is configured, a test needs to verify it took effect. The Organizational Seam Where Weeks Disappear Even with validated, high-signal findings, the delay between identification and remediation is primarily organizational. You find the risk. You don’t own the fix.

The teams that do own it operate on different timelines with different priorities. Findings aren’t consolidated into actions that engineering can execute against, so the signal gets lost all over again. In cloud-native and hybrid environments, ownership gets murkier: a vulnerability might sit at the application layer, the infrastructure layer, or in a third-party dependency. And once it lands somewhere, remediation runs through whatever process that team already uses, change windows for IT and DevOps, and sprint commitments for engineering.

Security findings end up competing with whatever was already on the schedule, and they usually lose. AI-accelerated attackers aren’t waiting for the next change window or the next sprint. Consolidation and Automation Are Necessary. They Are Not Sufficient.

The operational drag has real solutions. Consolidate related findings so that several validated issues tracing back to the same misconfigured load balancer become one ticket with one owner. Automate routing, assignment, SLA enforcement, and escalation paths. Get the workflow out of spreadsheets and Slack messages.

But throughput and velocity tell you how fast the system moves, not whether it’s working. You can route a consolidated ticket to a confirmed owner in minutes, enforce the SLA, escalate on schedule, and still close a ticket that didn’t eliminate the exposure. Maybe the workaround won’t survive a configuration change, the fix went out to three of four affected systems, or the patch applied successfully but left a surrounding misconfiguration intact. The ticket says “resolved.” The attack path is still open.

When AI can autonomously derive and re-derive exploit chains the way Mythos demonstrated, false confidence is the most expensive thing in your security program. Revalidation Is the Missing Discipline Revalidation should mean the risk no longer exists. A re-test only validates the original attack doesn’t exist. You should validate the risk itself doesn’t exist.

When every fix gets re-tested and the results are visible to both security and engineering leadership, partial fixes and workarounds get flagged immediately rather than lingering in a dashboard. It creates a feedback loop that makes the entire system self-correcting. The remediation workflow that holds up under current conditions: validated findings consolidated into fix actions, routed to confirmed owners, tracked through closure, then revalidated to confirm the underlying risk is gone, not only the original attack path. Pentera’s Platform is designed for that operating model, connecting remediation workflow with post-fix validation so teams can measure whether risk was actually removed.

Three Questions That Separate a System from a Hope What is your median time to remediate a validated, exploitable finding? If you can’t answer this, you’re measuring activity, not outcomes. When a fix is applied, how do you confirm it worked? If the answer is “the engineer closed the ticket,” ask yourself how many of those remediated findings would survive a retest.

Are you measuring tickets closed or risk closed? Ticket throughput tells you the team is busy. It doesn’t tell you the exposure is gone. Programs improve when they consolidate findings to the underlying risk and track whether that risk actually goes away.

The organizations that get this right will be the ones that stop treating remediation as something that happens after security’s job is done and start treating it as the place where security’s job is actually measured. Note: This article has been expertly written and contributed by Nimrod Zantkern Lavi, Director of Product, Pentera. Found this article interesting? This article is a contributed piece from one of our valued partners.

Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Microsoft Patches 138 Vulnerabilities, Including DNS and Netlogon RCE Flaws

Microsoft on Tuesday released patches for 138 security vulnerabilities spanning its product portfolio, although none of them have been listed as publicly known or under active attack. Of the 138 flaws, 30 are rated Critical, 104 are rated Important, three are rated Moderate, and one is rated Low in severity. As many as 61 vulnerabilities are classified as privilege escalation bugs, followed by 32 remote code execution, 15 information disclosure, 14 spoofing, eight denial-of-service, six security feature bypass, and two tampering flaws. The update list also includes a vulnerability that was patched by AMD ( CVE-2025-54518 , CVSS score: 7.3) this month.

It relates to a case of improper isolation of shared resources within the CPU operation cache on Zen 2-based products that could allow an attacker to corrupt instructions executed at a different privilege level, potentially resulting in privilege escalation. The patches are also in addition to 127 security flaws that Google has addressed in Chromium, which forms the basis for Microsoft’s Edge browser. One of the most severe vulnerabilities patched by Redmond is CVE-2026-41096 (CVSS score: 9.8), a heap-based buffer overflow flaw impacting Windows DNS that could allow an unauthorized attacker to execute code over a network. “An attacker could exploit this vulnerability by sending a specially crafted DNS response to a vulnerable Windows system, causing the DNS Client to incorrectly process the response and corrupt memory,” Microsoft said.

“In certain configurations, this could allow the attacker to run code remotely on the affected system without authentication.” Also fixed by Microsoft are several Critical- and Important-rated flaws - CVE-2026-42826 (CVSS score: 10.0) - An exposure of sensitive information to an unauthorized actor in Azure DevOps that allows an unauthorized attacker to disclose information over a network. (Requires no customer action) CVE-2026-33109 (CVSS score: 9.9) - An improper access control in Azure Managed Instance for Apache Cassandra that allows an authorized attacker to execute code over a network. (Requires no customer action) CVE-2026-42898 (CVSS score: 9.9) - A code injection vulnerability in Microsoft Dynamics 365 (on-premises) that allows an authorized attacker to execute code over a network. CVE-2026-42823 (CVSS score: 9.9) - An improper access control in Azure Logic Apps that allows an authorized attacker to elevate privileges over a network.

CVE-2026-41089 (CVSS score: 9.8) - A stack-based buffer overflow in Windows Netlogon that allows an unauthorized attacker to execute code over a network without needing to sign in or have prior access by sending a specially crafted network request to a Windows server that is acting as a domain controller. CVE-2026-33823 (CVSS score: 9.6) - An improper authorization in Microsoft Teams that allows an authorized attacker to disclose information over a network. (Requires no customer action) CVE-2026-35428 (CVSS score: 9.6) - A command injection vulnerability in Azure Cloud Shell that allows an unauthorized attacker to perform spoofing over a network. (Requires no customer action) CVE-2026-40379 (CVSS score: 9.3) - An exposure of sensitive information to an unauthorized actor in Azure Entra ID that allows an unauthorized attacker to perform spoofing over a network.

(Requires no customer action) CVE-2026-40402 (CVSS score: 9.3) - A user-after-free in Windows Hyper-V that allows an unauthorized attacker to gain SYSTEM privileges and access the Hyper-V host environment. CVE-2026-41103 (CVSS score: 9.1) - An incorrect implementation of authentication algorithm in Microsoft SSO Plugin for Jira & Confluence that allows an unauthorized attacker to gain unauthorized access to Jira or Confluence as a valid user and perform actions with the same permissions as the compromised account. CVE-2026-33117 (CVSS score: 9.1) - An improper authentication in Azure SDK that allows an unauthorized attacker to bypass a security feature over a network. CVE-2026-42833 (CVSS score: 9.1) - An execution with unnecessary privileges in Microsoft Dynamics 365 (on-premises) that allows an authorized attacker to execute code over a network and gain the ability to interact with other tenant’s applications and content.

CVE-2026-33844 (CVSS score: 9.0) - An improper input validation in Azure Managed Instance for Apache Cassandra that allows an authorized attacker to execute code over a network. (Requires no customer action) CVE-2026-40361 (CVSS score: 8.4) - A use-after-free vulnerability in Microsoft Office Word that allows an unauthorized attacker to execute code locally without requiring user interaction. CVE-2026-40364 (CVSS score: 8.4) - A type confusion vulnerability in Microsoft Office Word that allows an unauthorized attacker to execute code locally without requiring user interaction. “This critical elevation of privilege vulnerability allows an unauthorized attacker to impersonate an existing user by presenting forged credentials, thus bypassing Entra ID,” Adam Barnett, lead software engineer at Rapid7, said about CVE-2026-41103.

Jack Bicer, director of vulnerability research at Action1, described CVE-2026-42898 as a critical flaw that allows an authenticated attacker with low privileges to run arbitrary code over the network by manipulating process session data within Dynamics CRM. “With no user interaction required, and the potential to impact systems beyond the vulnerable component’s original security scope, this vulnerability poses serious enterprise risk: an attacker with only basic access could turn a business application server into a remote execution platform,” Bicer said. “Compromise of Dynamics 365 infrastructure can expose customer records, operational workflows, financial information, and integrated business systems. Since CRM environments often connect with identity services, databases, and enterprise applications, successful exploitation could lead to broader organizational compromise and operational disruption.” Organizations are also advised to update Windows Secure Boot certificates to their 2023 counterparts ahead of next month, when the 2011-issued certificates are set to expire.

Microsoft first announced the change in November 2025. “The most critical non-CVE update involves the mandatory rollout of updated Secure Boot certificates,” Rain Baker, senior incident response specialist at Nightwing, said. “Devices failing to receive these updates before the June 26 deadline face ‘catastrophic boot-level security failures’ or degraded security states. Ensure your entire fleet successfully rotates to the new trust anchors before the June 26, 2026, deadline.” Over 500 CVEs in 2026 So Far According to Satnam Narang, senior staff research engineer at Tenable, Microsoft has already patched over 500 CVEs five months into the year.

This large volume of fixes reflects a broader industry trend where vulnerability discovery has scaled new highs, with a chunk of them flagged via artificial intelligence (AI)-powered approaches. Microsoft, in a report published Tuesday, said AI-assisted vulnerability discovery is expected to increase the scale of Patch Tuesday releases in the coming months, adding 16 of the flaws fixed this month across the Windows networking and authentication stack were identified through its new multi-model AI-driven vulnerability discovery system, codenamed MDASH (short for m ulti-mo d el a gentic s canning h arness). “In this month’s release, a greater share of the issues addressed were discovered by Microsoft, compared to prior months,” Tom Gallagher, vice president of engineering at Microsoft Security Response Center, said . “Many of these were surfaced through AI investments and investigations across our engineering and research teams, including the use of Microsoft’s new multi-model AI-driven scanning harness.” Microsoft also emphasized that the scale and speed of vulnerability discovery brought about by AI can raise operational demands and requires a consistent, disciplined approach to risk management in order to ensure that issues are mitigated quickly and fixed in a timely fashion.

“Stay current on supported operating systems, products, and patches, and revisit the speed and consistency of your patching cadence,” Gallagher said. “Triage by exposure and impact, not raw count.” Other recommendations outlined by Microsoft include reducing unnecessary internet exposure, improving configuration hygiene, removing legacy authentication, enabling multi-factor authentication (MFA), enforcing strong access controls, segmenting environments to contain incidents, and investing in detection and response. “The work of finding and fixing vulnerabilities continues to get faster, broader, and more rigorous across the industry,” the tech giant said. “What we encourage in turn is a thoughtful look at whether the practices that worked well for the patching landscape of a few years ago are still well matched to where the landscape is heading.” “The fundamentals have not changed.

The pace at which they need to be applied is changing, and the organizations that adjust with it will be the ones best positioned for what comes next.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

GemStuffer Abuses 150+ RubyGems to Exfiltrate Scraped U.K. Council Portal Data

Cybersecurity researchers are calling attention to a new campaign dubbed GemStuffer that has targeted the RubyGems repository with more than 150 gems that use the registry as a data exfiltration channel rather than for malware distribution. “The packages do not appear designed for mass developer compromise,” Socket said . “Many have little or no download activity, and the payloads are repetitive, noisy, and unusually self-contained.” “Instead, the scripts fetch pages from U.K. local government democratic services portals, package the collected responses into valid .gem archives, and publish those gems back to RubyGems using hardcoded API keys.” The development comes as RubyGems temporarily disabled new account registration following what has been described as a major malicious attack.

While it’s not clear if the two sets of activities are related, the application security company said GemStuffer fits the “same abuse pattern,” which involves using newly created packages with junk names to host the scraped data. At a high level, the campaign abuses RubyGems as a place to stage the scraped council content. It does this by fetching hard-coded U.K. council portal URLs, packaging the HTTP responses into valid .gem archives, and publishing those archives to RubyGems using embedded registry credentials.

In some cases, the payload embedded within the gem creates a temporary RubyGems credential environment under “/tmp,” overrides the HOME environment variant, builds a gem locally, and pushes it to RubyGems using the gem command-line interface (CLI), as opposed to depending on pre-existing RubyGems credentials on the target machine. Other variants of the malicious gems have been found to eschew the CLI component in favor of uploading the archive directly to the RubyGems API via an HTTP POST request. Once the new gems have been published, all an attacker has to do is run a “gem fetch” command with the gem name and version to access the scraped data. The novel scraping campaign has been found to target public-facing ModernGov portals used by Lambeth, Wandsworth, and Southwark, with an aim to collect committee meeting calendars, agenda item listings, linked PDF documents, officer contact information, and RSS feed content.It’s not clear what exactly the end goals are, as the information appears to be publicly accessible anyway.

Socket has assessed that the systematic bulk collection and archival of this data raises the possibility that the attacker may be leveraging the “council portal access as a pivot to demonstrate capability against government infrastructure.” “It may be registry spam, a proof-of-concept worm, an automated scraper misusing RubyGems as a storage layer, or a deliberate test of package registry abuse,” Socket said. “But the mechanics are intentional: repeated gem generation, version increments, hardcoded RubyGems credentials, direct registry pushes, and scraped data embedded inside package archives.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Android Adds Intrusion Logging for Sophisticated Spyware Forensics

Google on Tuesday unveiled a new opt-in Android feature called Intrusion Logging for storing forensic logs to better analyze sophisticated spyware attacks. Intrusion Logging, available as part of Advanced Protection Mode , enables “persistent and privacy-preserving forensics logging to allow for investigation of devices in the event of a suspected compromise,” the company said. The feature, it added, was developed in partnership with Amnesty International and Reporters Without Borders. According to a help document shared by Google, it logs device and network activities on a daily basis, including information about device behavior and the various applications that run on it.

The kinds of activities recorded are listed below - App activity (e.g., when an app process starts) App installations, updates, and uninstalls Network connections like starting and stopping Wi-Fi, Bluetooth, DNS lookups, and IP addresses File transfers to or from the device over USB Changes to system certificates When the device is locked or unlocked Google also noted that the log data is end-to-end encrypted by the device and stored on Google servers. The encryption keys are secured by Google Account password and screen lock credentials, meaning the logs cannot be accessed by any third-party, including Google itself, apart from the device owner. “By storing the data on a secure server, even malware installed on the smartphone cannot access, delete, or manipulate it,” Reporters Without Borders said . “End-to-end encryption also ensures that neither Google nor state actors can access the data.

The Intrusion Logging function in particular enables detection and forensic analysis of even highly sophisticated and previously difficult-to-detect attacks.” The encrypted logs are stored for a period of 12 months, after which they are automatically wiped. Once Intrusion Logging is enabled, a user cannot delete the logs before the 12-month expiration window, even if the account is closed or the feature is turned off. Users have the option to download the logs offline, should they prefer to keep them for longer periods. That said, Google has emphasized that once the logs are downloaded and decrypted, users are responsible for their security.

“In certain legal or regulatory environments, you may be required by law to provide access to your decrypted data or your security credentials,” it pointed out. Another thing to keep in mind when enabling the feature is that it also records network events generated during Chrome Incognito browsing, such as DNS lookups and IP connections, as it operates at the system level and does not distinguish between the browsing modes. In other words, anybody with access to the decrypted logs can glean what websites were visited, but cannot infer specific pages on those sites. The motivation behind Intrusion Logging is that a high-risk individual, who suspects they may have been targeted by advanced surveillance tools because of who they are and what they do, can share the activity log with trusted security experts for detailed examination.

The logs can be downloaded by navigating to the Settings app, and then tapping Security & privacy -> Advanced Protection -> Intrusion Logging -> Access logs. The feature is currently rolling out to all devices running the Android 16 December update and newer. “With Intrusion Logging, Google is the first major vendor to proactively address the challenge of detecting advanced attacks on devices,” Donncha Ó Cearbhaill, head of Security Lab at Amnesty International, said in a statement. “By making more consensual forensic data available for researchers, we can make life more difficult for attackers and help civil society seek accountability when their devices are unlawfully targeted by spyware and mobile data extraction tools.” Other Privacy and Security Features Coming to Android Besides Intrusion Logging, Google has announced a raft of privacy and security improvements, including verified financial calls, a new phone call spoofing protection feature to combat attacks where scammers impersonate banks to trick users into revealing sensitive data or transferring funds.

When users receive a call that appears to be from a participating bank, Android asks the installed online banking app to confirm if they are actually attempting to reach the customer. If the app confirms no such is being made, the call is automatically ended by the system. “Your bank or financial institution may also designate numbers as inbound-only, meaning they never use them to call customers,” Google said. “Incoming calls from these numbers will be ended directly.” The feature is expected to go live on Android 11+ devices with Revolut, Itaú, and Nubank in the coming weeks, before expanding to more banks later this year.

Other notable changes are listed below - Expanding Live Threat Detection to issue warnings about suspicious app behavior, including SMS forwarding and accessibility overlays that are typically used by Android banking trojans to steal credentials. Evaluating downloaded APK files via Chrome on Android for known malware when Safe Browsing is enabled before it’s installed. Removing access to the accessibility services API from all apps that are not labeled as accessibility tools. Disabling device-to-device unlocking and Chrome WebGPU support.

Adding scam detection for chat notifications. Enhancing Find Hub’s Mark as lost feature with the ability to lock a phone with biometric authentication, blocking thieves from turning off device tracking if a device is marked as lost. Triggering Mark as lost also turns on additional protections like hiding Quick Settings and disabling new Wi-Fi and Bluetooth connections. Reducing the number of times a third-party with physical access to a device can guess the PIN or password, in addition to implementing longer wait times between failed attempts.

Improving device recovery by making a device’s IMEI number accessible via the lock screen on devices running Android 12 or higher. Better privacy controls that allow users to share their precise location temporarily for specific tasks while a specific app is open, and provide access to specific contacts to a third-party app, as opposed to sharing the entire address book. Introducing AISeal with pKVM for hardware-backed, on-device isolation of artificial intelligence (AI)-related data processing. Expanding Binary Transparency in Android to ensure integrity through verification of official builds and a public ledger for authentic Google apps and foundational GMS APIs.

Hiding SMS one-time passwords (OTPs) from most apps for three hours to block OTP theft by malicious apps that have been granted the SMS permission. Giving carriers the ability to disable 2G by default to shield customers from legacy technology vulnerabilities . Hardening data protection by introducing post-quantum cryptography to safeguard against future threats. Incorporating explicit user controls to opt-in and out of entire features, security guardrails, and transparency when using Gemini on Android.

“By improving protections against banking scams, and extending powerful protections like Live Threat Detection and Android Advanced Protection, we are ensuring that Android remains the most secure platform,” Eugene Liderman, director of Android security and privacy, said. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

New Exim BDAT Vulnerability Exposes GnuTLS Builds to Potential Code Execution

Exim has released security updates to address a severe security issue affecting certain configurations that could enable memory corruption and potential code execution. Exim is an open-source Mail Transfer Agent (MTA) designed for Unix-like systems to receive, route, and deliver email. The vulnerability, tracked as CVE-2026-45185 (CVSS score: 9.8), aka Dead.Letter, has been described as a use-after-free vulnerability in Exim’s binary data transmission (BDAT) message body parsing when a TLS connection is handled by GnuTLS. “The vulnerability is triggered during BDAT message body handling when a client sends a TLS close_notify alert before the body transfer is complete, and then follows up with a final byte in cleartext on the same TCP connection,” Exim said in an advisory released today.

“This sequence of events can cause Exim to write into a memory buffer that has already been freed during the TLS session teardown, leading to heap corruption. An attacker only needs to be able to establish a TLS connection and use the CHUNKING (BDAT) SMTP extension.” The issue impacts all Exim versions from 4.97 up to and including 4.99.2. That said, it only affects builds that use USE_GNUTLS=yes, meaning builds that rely on other TLS libraries like OpenSSL are not impacted. Federico Kirschbaum, head of Security Lab at XBOW, an autonomous cybersecurity testing platform, has been credited with discovering and reporting the flaw on May 1, 2026.

“During TLS shutdown, Exim frees its TLS transfer buffer – but a nested BDAT receive wrapper can still process incoming bytes and end up calling ungetc(), which writes a single character (\n) into the freed region,” Kirschbaum said . “That one-byte write lands on Exim’s allocator metadata, corrupting the allocator’s internal shape; the exploit then leverages that corruption to gain further primitives.” XBOW described the vulnerability as “one of the highest-caliber bugs” discovered in Exim to date, adding that triggering it requires almost no special configuration on the server. The shortcoming has been addressed in version 4.99.3. All users are advised to upgrade as soon as possible.

There are no mitigations that resolve the vulnerability. “The fix ensures that the input processing stack is cleanly reset when a TLS close notification is received during an active BDAT transfer, preventing the stale pointers from being used,” Exim noted. This is not the first time critical use-after-free bugs in Exim have been disclosed. In late 2017, Exim patched a use-after-free vulnerability in the SMTP daemon ( CVE-2017-16943 , CVSS score: 9.8) that unauthenticated attackers could have exploited to achieve remote code execution via specially crafted BDAT commands and seize control of the email server.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

RubyGems Suspends New Signups After Hundreds of Malicious Packages Are Uploaded

RubyGems , the standard package manager for the Ruby programming language, has temporarily paused account sign ups following what has been described as a “major malicious attack.” “We’re dealing with a major malicious attack on RubyGems right now,” Maciej Mensfeld, senior product manager for software supply chain security at Mend.io, said in a post on X. “Signups are paused for the time being. Hundreds of packages involved – mostly targeting us, but some carrying exploits.” Visitors to RubyGems’ sign up page are now greeted with the message: “New account registration has been temporarily disabled.” Mend.io, which secures RubyGems, said it intends to release more details once the incident is contained. It’s currently not known who is behind the attack.

The development comes as software supply chain attacks targeting open-source ecosystems have been on the rise, with threat actors like TeamPCP compromising widely used packages to distribute credential-stealing malware capable of harvesting sensitive data and allowing the attackers to expand their reach. In a report published Monday, Google said the credentials stolen from affected environments have been monetized through partnerships with ransomware and data theft extortion groups. Update In a follow-up update, Mensfeld said more than 120 malicious packages have been pulled from RubyGems, adding that the attack targeted the registry itself. Separately, Ruby Central’s Marty Haught said RubyGems was responding to “a coordinated spam-publishing campaign” limited to newly registered accounts publishing junk packages.

“The malicious spam activity against rubygems.org has stopped,” RubyGems said in an update shared on May 13, 2026. “The bot accounts responsible have been blocked and removed, and the 500+ malicious packages pushed during the attack have been yanked from the registry.” Account sign-ups are expected to be closed as it coordinates with Fastly to enable web application firewall (WAF) protection and tighten rate limiting on account creation. These actions will take two to three days, it noted, adding that Gem updated after publication to reflect the latest developments.) Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

New TrickMo Variant Uses TON C2 and SOCKS5 to Create Android Network Pivots

Cybersecurity researchers have flagged a new version of the TrickMo Android banking trojan that uses The Open Network (TON) for command-and-control (C2). The new variant, observed by ThreatFabric between January and February 2026, has been observed actively targeting banking and cryptocurrency wallet users in France, Italy, and Austria. “TrickMo relies on a runtime-loaded APK  (dex.module), used also by the previous variant, but updated with new features adding new network-oriented functionality, including reconnaissance, SSH tunnelling, and SOCKS5 proxying capabilities that allow infected devices to function as programmable network pivots and traffic-exit nodes,” the Dutch mobile security company said in a report shared with The Hacker News. TrickMo is the name assigned to a device takeover (DTO) malware that’s been active in the wild since late 2019.

It was first flagged by CERT-Bund and IBM X-Force , describing its ability to abuse Android’s accessibility services to hijack one-time passwords (OTPs). It’s also equipped with a wide range of features to phish for credentials, log keystrokes, record screen, facilitate live screen streaming, intercept SMS messages, essentially granting the operator complete remote control of the device. The latest versions, labeled TrickMo C, are distributed via phasing websites and dropper apps, the latter of which serve as a conduit for a dynamically loaded APK (“dex.module”) that’s retrieved at runtime from attacker-controlled infrastructure. A notable shift in the architecture entails the use of the TON decentralized blockchain for stealthy C2 communications.

“TrickMo carries an embedded native TON proxy that the host APK starts on a loopback port at process start,” ThreatFabric said. “The bot’s HTTP client is wired through that proxy, so every outbound command-and-control request is addressed to an .adnl hostname and resolved through the TON overlay.” Dropper apps containing the malware masquerade as adult-friendly versions of TikTok through Facebook, whereas the actual malware impersonates Google Play Services - com.app16330.core20461 or com.app15318.core1173 (Dropper) uncle.collop416.wifekin78 or nibong.lida531.butler836 (TrickMo) While previous iterations of “dex.module” implemented the accessibility-driven remote control functionality through a socket.io-based channel, the new version utilizes a network-operative subsystem that turns the malware into a tool for managed foothold than a traditional banking trojan. The subsystem supports commands like curl, dnslookup, ping, telnet, and traceroute, giving the attacker a “remote shell-equivalent for network reconnaissance from the victim’s network position, including any internal corporate or home network the device is currently associated with,” per ThreatFabric. Another important feature is a SOCKS5 proxy that turns the compromised device into a network exit node that routes malicious traffic, while defeating IP-based fraud-detection signatures on banking, e-commerce and cryptocurrency exchange services.

Furthermore, TrickMo includes two dormant features that bundle the Pine hooking framework and declare extensive NFC-related permissions. But neither of them are actually implemented. This likely indicates the core developers are looking to expand on the trojan’s capabilities in the future. “Instead of relying on conventional DNS and public internet infrastructure, the malware communicates through .adnl endpoints routed via an embedded local TON proxy, reducing the effectiveness of traditional takedown and network-blocking efforts while making the traffic blend with legitimate TON activity,” ThreatFabric said.

“This latest variant also expands the operational role of infected devices through SSH tunnelling and authenticated SOCKS5 proxying, effectively turning compromised phones into programmable network pivots and traffic-exit nodes whose connections originate from the victim’s own network environment.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Webinar: What the Riskiest SOC Alerts Go Unanswered - and How Radiant Security Can Help

Why do the Riskiest SOC Alerts Go Unanswered? Security operations teams are drowning in alerts. But the real problem isn’t always alert volume; it’s the blind spots. The most dangerous alerts are the ones no one is investigating.

A recent report from The Hacker News examined why certain high-risk alert categories - WAF, DLP, OT/IoT, dark web intelligence, and supply chain signals- consistently go uninvestigated across enterprise SOCs. The findings point to a structural gap in how security coverage is delivered today: not a lack of tooling, but a ceiling built into every existing model. Your SOC Model Has a Coverage Ceiling In-house SOC teams are the first to feel the gap. Overloaded with high-volume, routine alerts, analysts rarely have the capacity, or the specialized expertise, to investigate WAF events, DLP anomalies, or signals from operational technology environments.

These alert types require deep, domain-specific knowledge that most SOC teams simply don’t have on staff. MSSPs and MDRs face a different version of the same problem. Complex, specialized alerts are time-consuming to investigate and require business context that managed providers don’t have. The economics don’t work in their favor, so they escalate these alerts back to the client, the same in-house team that lacked the capacity to investigate them in the first place.

AI SOC automation platforms have made significant progress on common alert types, but most cap out at four to six pre-defined categories. They rely on static, pre-built triage logic. When an alert falls outside that logic, whether it’s a novel threat, an unfamiliar alert source, or an emerging attack vector, the platform deprioritizes it or passes it on. The result is a blind spot at the intersection of all existing SOC models: the alerts most likely to result in a breach are precisely the ones for which no one has a workflow to handle.

Who Offers True Coverage
On May 21, 2026,
Radiant Security
and German cybersecurity firm Cirosec are hosting a technical webinar to address this gap directly:
“Alert Coverage No One Else Can Triage.”
The session will examine the structural reasons behind the coverage ceiling, walk through the specific alert types most commonly left uninvestigated, and demo live how Radiant’s AI SOC platform triages them. Radiant is built on a fundamentally different architecture than other AI SOC platforms. Rather than relying on pre-built playbooks, its AI generates custom triage logic on the fly, for any alert type, including ones the platform has never seen before. Webinar Details
Date:
May 21, 2026
Time:
15:00 CEST (6:00 AM PDT)
Format:
Microsoft Teams — technical, interactive session
Host:
Cirosec & Radiant Security
Language
English Register here to register (click translate page to English on your browser translator) Important note: the webinar will be in English.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Mini Shai-Hulud Worm Compromises TanStack, Mistral AI, Guardrails AI & More Packages

TeamPCP , the threat actor behind the recentsupply chain attack spree, has been linked to the compromise of the npm and PyPI packages from TanStack, UiPath, Mistral AI, OpenSearch, and Guardrails AI as part of a fresh Mini Shai-Hulud campaign. The affected npm packages have been modified to include an obfuscated JavaScript file (“router_init.js”) that’s designed to profile the execution environment and launch a comprehensive credential stealer capable of targeting cloud providers, cryptocurrency wallets, AI tools, messaging apps, and CI systems, including Github Actions, multiple reports from Aikido Security , Endor Labs , SafeDep , Socket , StepSecurity , and Snyk show. The data is exfiltrated to the “filev2.getsession[.]org” domain. Using Session Protocol infrastructure is a deliberate attempt on the part of the attackers to evade detection, as the domain is unlikely to be blocked within enterprise environments, given that it belongs to a decentralized, privacy-focused messaging service.

As a fallback option, the encrypted data is committed to attacker-controlled repositories under the author name “claude@users.noreply.github.com” via the GitHub GraphQL API using the stolen GitHub tokens. The malware is also capable of establishing persistence hooks in Claude Code and Microsoft Visual Studio Code (VS Code) to survive reboots and re-execute the stealer on every launch of the IDEs. Furthermore, it installs a gh-token-monitor service to monitor and re-exfiltrate GitHub tokens, and injects two malicious GitHub Actions workflows to serialize repository secrets into a JSON object and upload the data to an external server (“api.masscan[.]cloud”). Unlike the previous SAP wave , where the compromised packages added a preinstall hook to trigger the infection sequence, the latest TanStack cluster adopts a different strategy by including a JavaScript file within the package tarball and adding an optional dependency that points to a GitHub-hosted package.

The GitHub dependency contains a prepare lifecycle hook that executes the JavaScript payload via the Bun runtime. The updates to the Mistral AI packages, on the other hand, follow the earlier approach, replacing the contents of the “package.json” file with a preinstall hook to invoke “node setup.mjs,” which downloads Bun and runs the same JavaScript malware. The TanStack supply chain compromise has been assigned the CVE identifier CVE-2026-45321 . It carries a CVSS score of 9.6 out of a maximum of 10.0, indicating critical severity.

The incident has impacted 42 packages and 84 versions across the TanStack ecosystem. TanStack has since traced the compromise to a chained GitHub Actions attack involving the “pull_request_target” trigger, GitHub Actions cache poisoning , and runtime memory extraction of an OIDC token from the GitHub Actions runner process. “No npm tokens were stolen, and the npm publish workflow itself was not compromised,” TanStack said. Specifically, the attackers are assessed to have staged the malicious payload in a GitHub fork via an orphaned commit, injected it into published npm tarballs, then hijacked the project’s legitimate “TanStack/router” workflow to publish the compromised versions with valid SLSA provenance.

“The attack published malicious versions through the project’s own GitHub Actions release pipeline using hijacked OIDC tokens,” StepSecurity researcher Ashish Kurmi said. “In an extremely rare escalation, the compromised packages carry valid SLSA Build Level 3 provenance attestations, making this the first documented npm worm that produces validly attested malicious packages. The worm has since spread beyond TanStack to packages from UiPath, DraftLab, and other maintainers.” The attack is noteworthy for the fact that it abuses trusted publishing, allowing attacker-controlled code running within a workflow to leverage its OIDC permissions to “mint” a short-lived publish token during the build and use it to publish the packages without having to steal an npm token. What makes the worm stand out is its ability to spread itself to other packages by locating a publishable npm token with bypass_2fa set to true, enumerating every package published by the same maintainer, and exchanging a GitHub OIDC token for a per-package publish token to sidestep traditional authentication entirely.

“The orphaned commit additionally triggered a GitHub Actions workflow run against the legitimate TanStack/router workflow surface,” Endor Labs researcher Peyton Kennedy said. “Because the repository’s OIDC trusted publisher configuration granted trust at the repository level rather than scoped to a specific protected branch and workflow file, the workflow run triggered by that commit was able to request a valid short-lived npm publish token.” Another new behavior introduced in the obfuscated JavaScript malware is the installation of a dead-man’s switch that uses a shell script to periodically check if an npm token created by the malware is not revoked by polling the “api.github.com/user” endpoint every 60 seconds. The token has the description “IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner.” Should the developer revoke the token from their npm dashboard, the script triggers a destructive routine that executes “rm -rf ~/” on the infected machine, essentially turning it into a wiper malware. These changes indicate that TeamPCP is growing aggressive and evolving its tradecraft with every campaign.

It’s therefore essential that developers do not revoke the npm tokens before isolating and imaging the system. “This campaign reflects a broader shift in supply chain attacks from isolated package compromise to identity-driven propagation through trusted CI/CD infrastructure,” Avital Harel, security research lead at Upwind, said in a statement shared with The Hacker News. “Once attackers gain access to publishing workflows and pipeline identities, the software delivery process itself becomes the distribution mechanism. The challenge for defenders is that much of this activity can appear legitimate on the surface, which makes behavioral visibility during installs and builds increasingly important.” Besides TanStack, the Mini Shai-Hulud campaign has also spread to several other packages, including some in PyPI - guardrails-ai@0.10.1 (PyPI) mistralai@2.4.6 (PyPI) @opensearch-project/opensearch@3.5.3, 3.6.2, 3.7.0, and 3.8.0 @squawk/mcp@0.9.5 @squawk/weather@0.5.10 @squawk/flightplan@0.5.6 @tallyui/connector-medusa@1.0.1, 1.0.2, and 1.0.3 @tallyui/connector-vendure@1.0.1, 1.0.2, and 1.0.3 According to data from OX Security , the incident has affected over 170 packages spanning both the npm and PyPI registries.

The packages have more than 518 million downloads cumulatively. No less than 400 repositories with stolen credentials have been created as part of the attack wave. All the repositories contain the string “Shai-Hulud: Here We Go Again.” Google-owned Wiz said the payload also exfiltrates stolen credentials via a third redundant channel, a typosquat domain named “git-tanstack[.]com,” along with the Session messenger network and GitHub API dead drops using the stolen token, adding the trojanized PyPI packages associated with both Mistral AI and Guardrails AI contain the same malware, which “operates notably differently” from the JavaScript versions distributed via npm. Microsoft, in its analysis of the malicious mistralai PyPI package, said it’s designed to download a credential stealer from a remote server (“83.142.209[.]194”) that includes country-aware logic to avoid Russian-language environments and a “geofenced destructive branch that has a 1-in-6 chance of executing rm -rf / when the system appears to be in Israel or Iran.” Mistral AI has published two advisories related to the compromise of its npm and PyPI packages, confirming that it was impacted by a supply chain attack related to the TanStack security incident.

“Current investigation indicates that an affected developer device was involved,” it said . “The guardrails-ai@0.10.1 compromise is especially notable because the malicious code executes on import,” Socket said. “The package checks for Linux systems, downloads a remote Python artifact from https://git-tanstack.com/transformers.pyz, writes it to /tmp/transformers.pyz, and executes it with python3 without integrity verification.” “This latest activity shows the campaign continuing to propagate across both npm and PyPI, with affected packages spanning search infrastructure, AI tooling, aviation-related developer packages, enterprise automation, frontend tooling, and CI/CD-adjacent ecosystems.” (The story was updated after publication to include additional insights.) Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.