Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
Welcome to this week’s edition of the Threat Source newsletter.
We all knew, to some degree or another, that this summer was going to a hot mess. I don’t mean FIFA drama or record setting heat waves. I mean the slow but steady momentum that AI frontier models were accruing for vulnerability research. If you were like me, and guesstimating exactly when that shoe would drop, my money was on the middle of summer. And... well, friends, I hate to say it, but I was right.
This July’s Patch Tuesday is an absolute whopper. There are 622 vulnerabilities being patched, with 62 being a critical severity. To put this context, this month alone has more vulnerabilities listed than all of 2018 combined. Three are zero days, two of which are being actively exploited. July is usually a quiet month historically – two years ago, it was just five patches issued in total! These are wild times, friends.
Microsoft has said this is due their AI frontier-accelerated research. We knew that this was coming, but what I am less sure about are companies that can meet the demand of this patch flood and getting these patches out to their infrastructures. The pessimist in me knows how most IT enterprises operate: You test, review stability, and then deploy. There’s a lag there – always has been, always will be. But that system worked under a sane patching load. As surely as much as Microsoft is using frontier models to research and announce vulnerabilities, so every is every other vendor.
Either through bug bounty programs or their own internal research, vendors are eating these bugs from a fire hose. Some are straight-up slop and just noise, but some have absolute value and need to be fixed. A giant like Microsoft has the money and resources to address this – as well they should. But for every Microsoft, there are five other companies who don’t have those resources. They’ll get bugs analyzed and patches issued, surely, but it will be on a much longer timeline.
The trick, I think, will be identifying what is a “surge” vs. our new normal. If everything is a fire drill to patch, then nothing is a fire drill. What might just be a hot summer for patching, might turn into a 12-month fusillade of KEV and EPSS notifications, with companies already under the gun taxed even more.
I truly don’t know how this ends, but… Find your change management and IT administrators and give then a hug. There are going to be some long days and hard questions to answer, and they’ll need all the help they can get.
The one big thing
Cisco Talos is disclosing a new campaign by UAT-11795, a sophisticated, financially motivated Russian-speaking adversary targeting users in the U.S. and Europe since at least June 2025. UAT-11795 uses trojanized software installers — including popular tools like Webex, Zoom, and MobaXterm — to deliver a custom Python-based remote access tool we track as "Starland RAT." This RAT acts as a gateway to deploy further malicious payloads, most notably a bespoke, in-memory PowerShell command-and-control (C2) implant known as the "WLDR agent."
Why do I care?
This opportunistic campaign casts a wide net across multiple victim profiles, turning a simple software download into a full-blown compromise. UAT-11795 employs highly evasive techniques, including AMSI and ETW bypasses, and uses a clever blockchain-anchored fallback mechanism to maintain persistent command and control. Once inside, attackers rapidly deploy secondary payloads like CastleStealer and Remcos RAT to siphon high-value credentials and cryptocurrency assets.
So now what?
Educate your users on ClickFix social engineering tactics and the dangers of unofficial software downloads. Monitor for suspicious execution of mshta.exe and unusual PowerShell activity, particularly scripts executing from memory or creating unexpected scheduled tasks. Ensure endpoint detection solutions are tuned to catch in-memory execution and AMSI tampering. Read the full blog for coverage and indicators of compromise (IOCs).
Top security headlines of the week
Microsoft patches record 622 flaws, including two zero-days under active attack Microsoft shipped its largest Patch Tuesday on record, more than triple June's previous high of around 200. (The Hacker News)
RabbitMQ vulnerability threatens enterprise systems RabbitMQ is a popular open-source message broker that routes, buffers, and distributes messages, enabling asynchronous communication between applications. The security defect impacts an open management endpoint that returns the OAuth secret to anyone, without authentication. (SecurityWeek)
Nigeria deepens cybersecurity efforts as cybercriminals see more profits The West African country advanced rules to force organizations to disclose cyberattacks, joining other nations in a shift to mandated transparency. (DarkReading)
Two-click cursor exploit enables dev environment takeover Cursor AI, a popular AI coding tool used by more than 50,000 enterprises and 64% of the Fortune 500, can be exploited in just two clicks, allowing attackers to install permission-rich model context protocol (MCP) servers on privileged developers' machines. (DarkReading)
Can’t get enough Talos?
[Video] Where protection starts: Cisco Talos Intelligence Integrations Every day, defenders make high-consequence decisions with incomplete information. Learn how Cisco Talos Intelligence Integrations help reduce uncertainty by turning the latest threat intelligence into proactive protections across Cisco technologies.
The serpent’s tongue: Luring the Python out of its den Protect your development environment from rising Python supply-chain threats by understanding the package installation lifecycle and implementing these essential defensive strategies.
ARToken: How attackers are bypassing MFA and maintaining access In this episode of Talos Takes, we dive deep into ARToken, a sophisticated phishing-as-a-service platform that steals credentials, bypasses MFA entirely, and leverages primary refresh tokens (PRTs) to maintain persistence in your environment long after a password reset.
n8n, the workflow automation platform, handed out the wrong accounts at login. On Enterprise instances configured to trust more than one external token issuer, it matched an incoming JWT to a local user on the sub claim alone and ignored iss.
A valid token from issuer A carrying a sub that belongs to someone under issuer B logged you in as them. Their password never came into it. n8n shipped the fix on June 24.
The flaw is tracked as CVE-2026-59208. The CVE record did not go public until July 9. n8n credits the report to the GitHub account bearsyankees, whose profile lists Strix, which makes an AI penetration testing agent.
Strix says it pointed out that the agent at the token-exchange flow and found the identity-binding bug there.
The partner signs a short-lived JWT with its own key, n8n verifies it against a configured public key, matches the claims to a local account, and the user is in. Trusted keys go in N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, and the deployment docs still tag the feature as preview.
The token itself checks out. The matching is the bug. A sub value is only guaranteed to be unique inside the issuer that minted it. RFC 7519 asks that it be "scoped to be locally unique in the context of the issuer" or else globally unique. The identifier for a user is therefore the pair, iss plus sub.
n8n keyed on half of it. Nothing stops two issuers from emitting the same subject string, and when they do, both land on one n8n account.
How big a deal is this
The flaw reaches an instance only if token exchange is switched on and the config trusts at least two external issuers. n8n says nothing else is affected. Token exchange is Enterprise-only and still flagged as a preview, so the exposed set is small and specific: OEM deployments, where trusting a second issuer is a supported configuration.
What the advisory does not pin down is how an attacker gets the token. It says only that they can obtain one. The practical question is whether an ordinary user at a trusted issuer can influence the sub they receive. The public record does not answer it. GitHub's CVSS 4.0 vector marks attack requirements as present and stops there.
GitHub assigned that vector. As the CNA here, it puts CVE-2026-59208 at 7.6 on CVSS 4.0, high. NVD puts the same bug at 6.8 on CVSS 3.1, medium, and has not issued a 4.0 assessment at all; its record carries CWE-287 and CWE-346. CISA's July 13 SSVC assessment records exploitation as none, and The Hacker News found no public proof-of-concept in searches on July 16.
Two weeks before the June 24 fix, the maintainers patched CVE-2026-54305, another Enterprise-only flaw. It lets any authenticated user overwrite or revoke another user's stored OAuth tokens through the Dynamic Credentials endpoints. That one was a missing ownership check, not an identity binding. Different bug, same surface.
The Hacker News has reached out to n8n for confirmation on the scope and impact of CVE-2026-59208 and will update this story with any response.
Patch or cut the issuer list
CVE-2026-59208 affects every n8n release below 2.27.4 and version 2.28.0. The fix first landed in 2.27.4 and 2.28.1. Those are the floor. On July 16, n8n's npm package carried 2.30.6 on both its latest and stable tags. It ships a new minor most weeks by its own account, so check the tag and take the newest stable build your deployment supports.
If patching has to wait, work out what you are running: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS holds the trusted signing keys, and a separate preview flag controls whether token exchange is on at all. Cut back to a single trusted issuer, or turn the feature off.
The advisory calls both short-term measures and says neither fully remediates the risk. That is boilerplate, identical in at least three other n8n advisories, including the June 10 one. By n8n's own scope statement, an instance with token exchange off is not affected.
Neither release note mentions the fix. The Hacker News checked both: between them, the 2.27.4 and 2.28.1 changelogs cover a Python import fix, a Google Ads node upgrade, an AI workflow check, and a node-building change, and nothing about identity.
The advisory is where this one lives. If your upgrade decisions run on changelogs, this is the kind of fix that slips past.
from The Hacker News https://ift.tt/vAIsmow
via IFTTT
As highlighted in the Mandiant M-Trends 2026 report, the mean time-to-exploit (TTE) has dropped to -7 days, meaning vulnerabilities are often exploited a week before a patch even exists.
To keep pace, many security teams are exploring how to integrate large language model (LLM) agents into their codebases, development environments and continuous integration and continuous delivery (CI/CD) pipelines for automated vulnerability discovery and remediation. However, deploying privileged artificial intelligence (AI) agents without mature integration processes introduces new architectural risks.
In response to customer inquiries about how to safely integrate AI capabilities into vulnerability management workflows, this blog provides actionable guidance from Mandiant Consulting about how to establish operational guardrails for AI assisted vulnerability management, including several detailed scenarios. What each of these examples show is that security teams can accelerate workflows with AI while also upholding the structural integrity of their environments. We suggest that combining AI capabilities with deterministic controls and human intelligence in strategic ways maximizes benefits and reduces risk.
Establish Operational Guardrails to Safely Deploy AI Agents
To safely adopt advanced AI capabilities without introducing unpredictable failures into deployment pipelines, organizations should ground their approach in established industry standards. While guidelines like the NIST AI Risk Management Framework (RMF) and the OWASP Top 10 for LLMs provide comprehensive baselines for identifying risks, operationalizing these controls requires a structural blueprint.
Frameworks like Google’s Secure AI Framework (SAIF)andGoogle’s approach to secure AI Agents provide a practical path forward, demanding that organizations extend existing deterministic controls directly into the AI execution environment. When deploying AI agents, security teams should navigate specific operational and structural risks:
Pre-agent data security and Defense-in-Depth: Agents should not be able to access personally identifiable information (PII), protected health information (PHI), or other sensitive data. Organizations should enforce data security before the prompt reaches the model. This includes strictly using non-production environments populated with synthetic data for testing. For production, security teams should deploy a hybrid defense-in-depth model. This includes Layer 1 deterministic policy engines acting as chokepoints, alongside Layer 2 reasoning-based defenses like specialized guard models (such as Model Armor or similar provider-agnostic guardrails) to filter out sensitive data and block malicious prompt injections before they reach the agent layer. Crucially for vulnerability discovery, security teams should treat the codebase itself as an untrusted input. Threat actors can embed indirect prompt injections within source code comments or third-party dependencies (e.g., hidden instructions telling the agent to ignore vulnerabilities or exfiltrate environment variables), making input sanitation a requirement even for internal scanning.
Cloud provider limitations and zero data retention (ZDR): Many cloud and LLM providers block or throttle automated offensive security probing by default to prevent abuse. Organizations should establish clear rules of engagement and authorized testing agreements to navigate acceptable use policies. Furthermore, organizations should enforce strict zero data retention (ZDR) agreements with their LLM providers to guarantee that proprietary code and discovered vulnerabilities are never used to train external models.
Workload isolation: Agent workloads should execute in strictly isolated, unprivileged containers with dynamically limited privileges. By relying on robust sandboxing to prevent privilege escalation, if an agent hallucinates a destructive command or is hijacked via prompt injection, the blast radius remains contained.
Red Teaming: Before deploying autonomous vulnerability scanners that can dynamically spin up sandboxes and execute code, organizations should subject the AI agents themselves to human-led red teaming as part of comprehensive assurance efforts. This validates the agent's resilience against jailbreaks, recursive logic loops, and complex prompt injections, ensuring the security tooling does not become the attack vector.
Least-Privileged Machine Identities and Human Controllers: While workloads should be isolated, agents inherently require privileges to generate pull requests and commit code. Security teams should ensure these agents operate under distinct, strictly scoped machine identities that tie back to human controllers to ensure accountability and user consent. Organizations should use short-lived, just-in-time (JIT) tokens bound exclusively to the specific repository and branch under review. This enforces the principle of limited agent powers and ensures that even if an agent’s container is compromised via prompt injection, the threat actor cannot pivot to modify adjacent enterprise codebases.
Supply chain resilience for skills: As developers augment AI with third-party skills and model context protocol (MCP) servers, security teams should treat these integrations as untrusted supply chain components. MCP plugins introduce the risk of supply chain poisoning, where a previously benign integration is silently updated with malicious dependencies. Additionally, security teams should evaluate the underlying agent orchestration frameworks themselves (e.g., LangChain, AutoGen) for inherent vulnerabilities, such as session memory poisoning or recursive loop hijacking.
Toxic flow analysis (TFA) and Observable Actions: The objective of TFA is to monitor data paths at runtime, ensuring agents do not exfiltrate sensitive internal context to unvetted external endpoints. Agent actions, inputs, reasoning, and outputs must be fully observable and transparently logged. While implementing dynamic taint tracking for LLMs remains a complex architectural challenge, organizations should clearly separate this runtime observability from static supply chain controls. Integrating threat intelligence to hash and vet incoming agent tools provides a necessary baseline for verifying integrity before deployment. However, because static controls cannot address behavior post-deployment, mitigating data exfiltration ultimately requires active runtime monitoring and secure, centralized logging to trace and restrict the actual flow of data.
Figure 1: Visual representation of an isolated AI agent environment using SAIF mechanisms
By operationalizing these tools within frameworks that demand verifiable integrity and structural resilience, organizations can safely bridge the gap between AI velocity and enterprise defense.
The need for human-led threat modeling
While LLMs excel at identifying syntax patterns, source code itself rarely contains the full picture of unwritten business intent. Some organizations attempt to solve this by connecting LLM agents to internal wikis, design documents, and issue trackers using retrieval-augmented generation (RAG).
While RAG gives the model access to external business context, it is not a perfect fix. Corporate documentation is frequently stale, contradictory, or incomplete. An AI agent might retrieve an outdated architecture diagram and confidently hallucinate a secure path that no longer exists in production. Because LLM agents struggle to resolve conflicting, undocumented human assumptions, human-led threat modeling remains a critical security control across both legacy applications and modern agent workflows.
Security teams should apply threat modeling during both the pre-build system design phase to establish a secure foundation, and during post-build architecture reviews. While an AI agent might successfully identify a poorly configured internal endpoint locally, a human threat modeler asks the structural question: why does that microservice possess broad database read permissions in the first place?
Identifying architectural vulnerabilities requires reasoning about business risk, data sensitivity, and operational constraints. To structure this process, organizations can use industry frameworks like PASTA (Process for Attack Simulation and Threat Analysis) or service offerings like the Mandiant Threat Modeling Security Service to map trust boundaries, uncover structural design flaws, and prioritize compensating controls. Securing fundamental architecture through human oversight is a necessary component when relying on automated agents to find bugs in a poorly designed system.
Once these AI agents are safely sandboxed, as guided by SAIF, and the architecture is verified through threat modeling, organizations can typically apply them to two different problem spaces: Enterprise Vulnerability Management (to assist in managing the volume of known CVEs in commercial off-the-shelf (COTS) software and infrastructure) and Product Security (to identify vulnerabilities in 1st-party (1P) code).
Track 1: Enterprise Vulnerability Management
Foundational security and discovery
While the second track of this post explores how AI agents can uncover complex zero-days in custom code, organizations should manage the scale of enterprise infrastructure in tandem with these AI deployments. Even as new AI capabilities dominate headlines, organizations should still address foundational security challenges, such as secrets sprawl, unmanaged service accounts, missing FIDO2 MFA, and legacy VPN concentrators. Although vulnerability exploitation was the primary initial infection vector in intrusions Mandiant investigated last year, threat actors consistently rely on missing foundational controls and unpatched edge devices to secure and escalate their foothold after exploiting a vulnerability.
Furthermore, AI cannot replace foundational visibility. As security teams deploy AI agents, they should simultaneously close these tactical entry points by maximizing dynamic discovery capabilities like External Attack Surface Management (EASM), Cloud Security Posture Management (CSPM), and Continuous Threat Exposure Management (CTEM). In hybrid and cloud environments, tools like Wiz can be used to map this initial footprint.
Risk-based vulnerability management
Vulnerability management teams are already overwhelmed by the current volume of findings generated by traditional scanners. As organizations scale dynamic discovery tools, such as EASM, CSPM and CTEM, alongside automated AI agents, this influx of findings will compound the problem. To manage this influx, telemetry from these diverse discovery methods must first be normalized and deduplicated. This normalized data serves two purposes: it feeds directly into the risk engine, and it acts as a live overlay to correct stale records in the configuration management database (CMDB). By evaluating the deduplicated vulnerabilities alongside this newly updated asset context and frontline threat intelligence, the RBVM engine calculates a custom risk score that allows security teams to dynamically prioritize remediation.
A mature RBVM methodology calculates a customized risk score on a 0 to 100 scale using a weighted average. A sample formula for calculating this risk-based score is:
The variables and weights (W) are customized to the organization's risk appetite (for example, 0.20 for vulnerability, 0.40 for asset, and 0.40 for threat, summing to 1.0), while the underlying variables (S) are scored on a 0 to 100 scale and defined as follows:
Vulnerability severity (S_vuln): The inherent technical severity of the flaw. This is calculated by taking the CVSS Base Score (which natively accounts for confidentiality, integrity, and availability impact) and multiplying it by 10.
Asset context (S_asset): A combined metric of exposure and data sensitivity. Scores range from 100 for internet-facing assets holding customer data, down to 25 for internal-only assets with no sensitive data. To translate this impact into monetary terms for non-technical stakeholders, organizations can incorporate Factor Analysis of Information Risk (FAIR) principles into this metric. However, this approach requires highly accurate, continuously updated financial data that many enterprises struggle to maintain at scale.
Threat context (S_threat): The real-world urgency of the vulnerability. Scores range from 100 if actively exploited by threat actors relevant to the organization's profile, 75 if a proof-of-concept exists or if it is a vulnerability class easily exploited by autonomous AI agents, down to 25 if the exploit is theoretical and highly complex. Organizations should also map the Exploit Prediction Scoring System (EPSS) probability percentage directly into this variable. This allows the threat score to automatically scale up or down as real-world exploitation telemetry shifts, aligning static vulnerability data with active threat intelligence.
An asset's customized risk score should directly influence internal remediation service-level agreements (SLAs), unless external compliance-driven mandates, such as CISA Binding Operational Directives (BODs), or relevant equivalents, override internal prioritization. A risk-driven and threat-intelligence-driven vulnerability prioritization methodology will help organizations focus resources on managing and mitigating the most critical security vulnerabilities first. This is an area where LLMs can support the vulnerability management process, particularly by helping teams synthesize unstructured threat intelligence to surface relevant risk contexts more efficiently. Enforcing strict SLOs for patching, while requiring formal risk acceptance documentation for any patching exceptions, will help reduce the number of vulnerabilities available to threat actors and increase the visibility of outstanding risks across the organization. Furthermore, organizations should integrate RBVM data directly into their security orchestration, automation, and response (SOAR) platforms for automated alert enrichment.
Figure 2: Integration points of a risk-based vulnerability management (RBVM) program.
Containment and Observability
Modern architecture blueprints must prioritize attack surface reduction under the assumption that vulnerabilities will inevitably be exploited. Moving away from traditional perimeter defenses, organizations should align with zero trust principles, ensuring that security boundaries are established around every asset, workload, and identity.
A component of this alignment is the implementation of strong authentication principles. Organizations should eliminate implicit trust by enforcing continuous, context-aware authentication and authorization. Utilizing Zero Trust Network Access (ZTNA) solutions, such as Identity-Aware Proxies (IAP), shields critical management interfaces (e.g., SSH, RDP) and internal systems from direct internet exposure, granting access only to verified identities and compliant devices.
For public-facing applications and APIs, attack surface reduction involves deploying Layer 7 inspection at the load balancer or API gateway level. This hardening layer enforces strict schema validation, intercepting and neutralizing malformed inbound traffic and potential exploits before they can interact with internal application logic.
Securing the software supply chain is equally vital in modern blueprints, and organizations should align with frameworks like Supply-chain Levels for Software Artifacts (SLSA) across both dependency and build tracks. Security policies should mandate that third-party dependencies are routed through a centralized artifact repository equipped with automated curation services, such as Google Assured Open Source Software (OSS) or an equivalent solution, preventing untrusted code from entering the development lifecycle. Furthermore, maturing toward advanced SLSA build levels (e.g., SLSA level 3) through the implementation of isolation, ephemerality and reproducibility requirements via ephemeral compute infrastructure for CI/CD runners reduces the likelihood of attacker persistence by ensuring environments are short-lived and automatically cycled.
To complement these pre-build controls, runtime observability should be established across all production workloads. This requires monitoring both infrastructure-level behavior and the specific runtime libraries actively executing in production, which surfaces true exploitable risk far beyond a static Software Bill of Materials. In tandem with monitoring workloads, organizations should secure how they authenticate by implementing workload identity federation. By removing static credentials and instead using short-lived tokens backed by strong cryptographic identity verification, organizations can reduce the risk of credential theft and unauthorized lateral movement.
Within the internal environment, microsegmentation should be enforced to break down flat networks into granular security zones. Routing application traffic through a Secure Access Service Edge (SASE) architecture integrates network routing directly with robust identity controls, rendering internal services completely invisible to unauthenticated users and containing threats to their initial point of entry.
Finally, automated containment and incident response within a zero trust framework must rely on deterministic, auditable tooling. Endpoint detection and response (EDR) platforms and SOAR playbooks should handle high-fidelity containment tasks through hardcoded execution logic. While AI tools accelerate triage and policy recommendation, actual execution capabilities must remain restricted to well-defined, pre-tested workflows to maintain total architectural predictability.
Figure 3: Structural containment and observability architecture
Track 2: Product Security & Development (1P Code)
Deterministic and probabilistic tooling
Integrating LLM agents into vulnerability management and security workflows requires recognizing the differences between deterministic and probabilistic tooling. Traditional SAST and DAST tools utilize fixed methodologies to evaluate vulnerabilities through structural code parsing or definitive runtime observations. LLMs, however, evaluate source code by processing tokens simultaneously to calculate statistical and semantic relationships, rather than tracing deterministic execution tracks.
While techniques like Chain of Thought (CoT) prompting allow models to bridge this gap by decomposing complex code paths into intermediate reasoning steps, this process remains bounded by architectural limitations. Even when a model possesses a context window large enough to ingest entire repositories, it may experience attention degradation across long inputs, often failing to correctly weight intervening validation or sanitization logic within the prompt. For example, if a variable is tainted on line 10 but sanitized on line 500, attention degradation can cause the model to lose track of the sanitization logic. Furthermore, when enterprise codebases require chunking to fit within context limits, the resulting fragmentation may cause the model to lose track of end-to-end data flows.
Consequently, probabilistic engines are effective at uncovering localized, static anomalies, such as hardcoded credentials or outdated dependencies, but frequently misjudge complex vulnerabilities split across fragmented chunks or extended context windows. Notable exceptions occur when these probabilistic models are coupled with deterministic feedback loops. For instance, when analyzing C++ memory corruption, an LLM can be equipped with a test harness to iteratively execute code and definitively prove a crash. While these dynamic validation applications are detailed in subsequent sections, the baseline limitation for static analysis across standard enterprise codebases remains: models struggle to consistently evaluate dispersed logic.
Figure 4: Deterministic SAST scanners vs. probabilistic LLMs
Binary and architectural oracles
Many security programs are moving toward agent workflows where an agent autonomously spins up a test environment and uses tools to execute payloads and verify its findings. This is a promising approach, but it is important to understand where it is most effective.
Agent workflows perform well against bug classes with binary and observable oracles, meaning the system provides an objective, 'crash or no crash' feedback loop. For example, if a model is hunting for memory corruption in a C++ kernel, a successful exploit is undeniable: the payload executes, and a resulting crash definitively proves the vulnerability. This explains why the industry is currently seeing a surge in AI-discovered vulnerabilities across memory-unsafe targets like web browsers and operating systems.
However, enterprise software is heavily dominated by vulnerabilities that require architectural oracles for validation. Vulnerabilities like authorization bypasses, complex business logic flaws, and indirect server-side request forgeries require an understanding of business context and cross-service trust boundaries. If an agent's payload fails to produce a clear outcome, it can't reliably distinguish whether the vulnerability is a hallucination or if it simply constructed the payload incorrectly. An agent's malformed payload might even crash an unrelated background process and cause the model to hallucinate a success and report a false confirmation. Complex enterprise architecture contains unwritten business intent that a probabilistic engine can't inherently know.
Figure 5: Evaluating vulnerabilities against binary vs. architectural oracles
Targeted deployment and human impact
Organizations adopting LLMs for vulnerability discovery face a massive staffing challenge. LLMs can generate findings significantly faster than human engineers can triage them. If every LLM-generated alert requires manual review, security teams will quickly face burnout and/or suffer alarm fatigue.
Rather than indiscriminately pointing agents at all available codebases and risking an influx of unverified output, security teams need a selective deployment strategy. Mature programs should maintain SAST and DAST for baseline hygiene and deterministic rule enforcement, and reserve intensive agent audits for high-impact components with clear binary oracles.
Organizations can prioritize agent audits on systems where the technology's strengths align with the broader risk profile:
Memory-unsafe codebases: Legacy or high-performance components written in memory-unsafe languages such as C, C++, or Assembly are strong candidates for LLM audits. These languages are susceptible to memory corruption flaws, such as buffer overflows and use-after-free conditions. Because these vulnerabilities trigger definitive failure states like segmentation faults, they work well with automated sandboxes where agents can compile the code with memory sanitizers and write proof-of-concept inputs. This approach is also effective for auditing the native extensions where safe languages call unsafe internal libraries, such as Python C extensions or the Java Native Interface (JNI).
Systems highly exposed to outside content: First-party data ingestion pipelines, custom API gateways, or proprietary edge proxies. A prerequisite here is direct access to the source code, this strategy is strictly for internally developed or fully open-source codebases where the organization can inspect the logic. Because these systems directly parse untrusted internet traffic, targeting their source code for LLM-driven audits yields the highest risk-reduction ROI.
Shared internal libraries and utilities: Core serialization/deserialization packages, common utility functions, and custom middleware wrappers (such as internal message-queue parsers) maintained in-house. Because the enterprise owns the source code for these shared building blocks, agent tools can easily hook into them within automated test harnesses to fuzz inputs and catch low-level logic or parsing bugs with high fidelity.
Foundational security boundaries: Internally developed centralized authentication services, custom OAuth providers, and internal credential brokers. While testing complex identity boundaries generates higher logic-based noise, having full access to the source code allows teams to pair agents with deterministic checks to safely triage findings, given that the blast radius of an authentication failure justifies the human effort.
To filter the noise generated by LLMs, organizations should establish routing rules. Require the agent to generate a fully reproducible, deterministic test harness (such as a compiled binary or a Python test script) that attempts to prove the exploit. This harness must execute automatically in an isolated, monitored sandbox. If the sandbox execution fails (due to a syntax error or a failed exploit), the ticket is discarded, sparing human resources. However, organizations should enforce execution timeouts and iteration limits on these test harnesses. Without hard limits, an autonomous agent attempting to prove a vulnerability can fall into an infinite loop: writing a script, failing, rewriting, and failing again, exhausting API token budgets and compute resources against a single dead-end vulnerability, creating significant cost overruns without advancing the security review. To manage these expenses, organizations should incorporate FinOps principles to balance the compute and API costs of LLM audits against the traditional expenses of manual triage.
However, a successful execution in the sandbox does not guarantee an actionable, high-priority risk. In practice, autonomous agents frequently produce working PoCs for genuine technical flaws that are ultimately irrelevant; or warrant a lower remediation priority within the context of the system's threat model. For example, the agent might successfully exploit an unreachable dead-code path, or trigger a bug that requires administrative access to execute and yields no further escalation of privilege. Therefore, a human engineer should be assigned to review and prioritize the ticket only if the sandbox registers a successful execution, validating environmental context, reachability, and true business impact as part of the review.
This workflow reduces the volume of alerts, but it is important to understand that the security team's workload does not disappear. The engineer's primary job shifts from manually hunting for the initial vulnerability to auditing the LLM-generated proof to ensure it represents a meaningful risk rather than an unexploitable or contextually irrelevant finding. Leadership should properly staff and train teams for this new reality. Deploying LLM agents does not remove the need for skilled practitioners; it redirects their workload toward complex validation. Equally important is training teams to recognize the risk of false negatives. A hyper-focus on filtering AI-generated noise can create a false sense of security. If an exploit relies on a novel technique or a zero-day vulnerability that was not heavily weighted in the model's training data, the agent will likely scan right past it in silence. LLMs augment discovery, but they do not guarantee exhaustive coverage.
When integrating LLMs into SAST triage pipelines, human engineers should also verify the broader architectural integrity. Prompting an LLM with specific SAST warnings can induce contextual narrowing, where the agent becomes hyper-fixated on resolving a localized syntax error and misses broader architectural flaws existing in the same file. Furthermore, if the agent's mandate extends beyond discovery to automated remediation (such as writing and proposing code fixes), this human-in-the-loop validation becomes critical to ensure the LLM does not inadvertently introduce new regressions or bypass intended business logic.
Figure 6: Flowchart outlining the targeted LLM deployment and triage workflow.
Remediation and hardening
LLM-assisted code remediation
A primary goal of integrating large language models (LLMs) into the software development lifecycle is automated remediation. To achieve this, organizations are deploying these capabilities through two primary execution methods: directly within the integrated development environment (IDE) or as a centralized pipeline runner. Examples include CodeMender, although as of time of writing, it is not publicly available.
IDE-integrated method
This method shifts remediation as far left as possible by operating as an active pair-programmer. Tools running continuous static analysis in the background of the IDE surface vulnerabilities directly to the developer via editor diagnostics like inline indicators or hover tooltips.
Localized scope: The developer can trigger the LLM agent to analyze the localized data flow and generate a targeted patch (such as implementing parameterized SQL queries). By constraining the LLM to localized, syntax-level fixes, the scope of the change remains contained. This prevents the agent from attempting sprawling, multi-file refactors that frequently break complex architectural logic.
Human-in-the-loop: The developer reviews the AI-generated patch before the code is committed.
Managing false positives: Local IDE agents allow developers to manage false positives dynamically. Suppressing alerts anchored to specific line text reduces alert fatigue and preserves developer trust.
CI/CD runner method
The runner method executes asynchronously within the CI/CD pipeline to use an LLM to review committed code and automatically propose remediation.
Restricted execution and deterministic validation: Asking a centralized runner to automatically rewrite a complex, multi-file authorization flaw directly in the main branch introduces a high risk of breaking logic errors. To mitigate this, agents must be restricted to generating pull requests (PRs). Once a PR is generated, it must automatically execute standard regression suites alongside the deterministic test harness. By rerunning the initial PoC against the patched code, the workflow repurposes the exploit script as a validation oracle to prove the vulnerability has been remediated. A human engineer then reviews the PR to validate the architectural logic before merging.
In all cases security teams should define a clear boundary between the two methods rather than rely on a single approach. IDE agents provide immediate, syntax-level support. They catch and resolve low-complexity errors locally before developers commit code. Centralized CI/CD runners handle broader organizational baselines. They propose complex, repository-wide fixes for vulnerabilities that bypass local environments.
Post-deployment controls
Even with human review and deterministic test harnesses, AI-generated patches can still introduce logic regressions in production. Organizations should implement strict post-deployment controls:
Automated rollbacks: Treating LLM-generated code with the same post-deployment scrutiny as any major architectural change ensures that if an unforeseen regression traverses the CI/CD pipeline, the environment can revert to a known good state.
Mitigating model drift: Relying on managed AI services introduces the ongoing risk of model drift. To prevent silent weight updates from breaking test harnesses, organizations need to pin specific model API versions to frozen releases. When a pinned version reaches its end-of-life, organizations will face a forced migration. Mitigating this pipeline fragility requires combining model pinning with deterministic regression suites.
Compliance and auditability: If an AI agent automatically closes a security ticket or generates a patch in the CI/CD pipeline, organizations should maintain immutable audit logs to satisfy frameworks like SOC 2 ,PCI-DSS, FedRAMP, and CMMC. National security deployments must also account for data sovereignty requirements. This logging should record the specific model version that proposed the fix, the deterministic test results that validated it, and the human engineer who approved the merge. Furthermore, because emerging legislation like the EU AI Act emphasizes human oversight for high-risk applications, security teams should carefully evaluate how autonomous remediation workflows align with these evolving global regulatory standards.
Figure 7: Flowchart demonstrating the difference between local IDE AI remediation and centralized CI/CD pipeline remediation.
Conclusion
Leveraging LLMs in vulnerability management is a multi-layer solution: Integrating it requires separating workflows by layer. At the enterprise infrastructure level, Risk-Based Vulnerability Management (RBVM) and exposure management are necessary to process the volume of findings and configuration drift. At the product and code security level, LLM-enabled vulnerability assessment and remediation must operate alongside foundational deterministic controls, such as SAST and DAST, to audit custom, open-source, or third-party code.
Although LLMs can help manage technical debt and accelerate vulnerability discovery, they do not replace secure-by-design principles. The fact that LLM agents are proving exceptionally capable at identifying and exploiting localized memory corruption in memory-unsafe codebases, alongside other primary vectors, should serve as a wake-up call.
As a long-term strategy aligned with NSA guidance on Software Memory Safety, organizations need to phase memory-safe languages into new internal development. LLMs are beginning to expand what is possible here by reducing the manual labor required for code migration. Converting existing C or C++ codebases to Rust has historically been unrealistic due to the large volume of engineering hours needed. While fully automated translation is not a turn-key solution, using LLMs to assist engineers with the bulk of the conversion can make these long-term migrations operationally viable. Beyond internal efforts, organizations should use procurement requirements to incentivize vendors to reduce their reliance on memory-unsafe languages and establish secure configuration defaults over time. Bridging the gap between AI velocity and enterprise defense means building an automated pipeline to manage the current backlog, while architecting systems where entire classes of vulnerabilities and misconfigurations are eliminated by design.
Acknowledgements
This analysis would not have been possible without the assistance of Google Threat Intelligence Group (GTIG) and other broader Google teams.
from Threat Intelligence https://ift.tt/zeCajyD
via IFTTT
ClickLock Stealer, a new macOS infostealer, answers a victim's refusal by killing their apps on a loop until they hand over the login password. It arrives as a command pasted into Terminal, asks for the password behind a fake system dialog, and when the victim cancels, installs two LaunchAgents and quietly exits.
At the next login, Finder, the Dock, Spotlight, Terminal, Activity Monitor, and the major browsers start dying every 210 milliseconds, for up to 83 hours, leaving one password box on a dead desktop. Type it, and the machine gives up the Keychain, the browser credentials, and the crypto wallets.
Group-IB's telemetry counts at least 100 targets across 33 countries since May, over half of them in Europe. Its analysts assume from the code structure that the malware is still under development. Uploaded to VirusTotal on June 9, the orchestrator script had zero detections there when Group-IB analyzed it.
And the analysts never found the front door. They have the whole payload chain and not one of the lure pages. The IOC list carries three compromised payload hosts and no lure domain: the landing page design, the domains serving it, and whatever drives traffic to them are all unconfirmed.
A completed run leaves the operator holding the validated macOS login password, Chrome's Safe Storage AES key, and a ZIP with browser credentials and cookies, crypto wallet extension storage, desktop wallet files, password manager vaults, the Keychain, shell history, and FileZilla's saved server credentials.
The Safe Storage key is the one that lasts. It encrypts Chrome's saved passwords and cookies on disk, so Login Data and Cookies are decrypted offline, on the attacker's machine, whenever they get to it. Group-IB's advice to anyone who ran this: revoke active browser sessions, treat every saved password, cookie, and wallet key as gone, and change them.
Comply now, or comply at next login
The refusing user is not an edge case. They are what the design is for. Cancel the first dialog, and the script drops com.authirity.plist and com.chromer.plist into ~/Library/LaunchAgents/, then leaves.
The first fires the 210-millisecond kill loop until a password lands. The second launches its own kill loop at 0.2-second intervals for up to 3,000,000 seconds, roughly 34.7 days, while a background process queries the Keychain for Chrome's Safe Storage key every half second.
That query raises a real macOS prompt, and the loop holds the desktop hostage until the victim approves it. Activity Monitor and Terminal are on both kill lists. A third loop kills NotificationCenter for six hours, so no Gatekeeper warning renders. If Terminal lacks Full Disk Access, the orchestrator opens System Settings to the right pane and walks the victim through granting it.
The front end is ClickFix. Group-IB assesses that with high confidence and has never seen it. The script takes a RAY_ID as its first argument and opens with a fake Cloudflare CAPTCHA banner over a progress bar cycling twelve status lines in ten seconds. Neither does anything. They exist to reassure someone who has just pasted a command into a terminal.
Underneath, script.sh disables keyboard interrupts, hides the cursor, and pulls four payloads from two compromised sites. Two pipe straight into bash. Two land in a hidden $HOME/.cacheb/. The soft ask is an osascript dialog wearing a downloaded Apple icon and the victim's real username, and whatever gets typed is checked against dscl /Local/Default -authonly first, so only a working password is worth sending.
Almost none of that is new. Microsoft documented the same dscl validation in SHub Stealer in May, alongside AMOS and MacSync in the same wave of macOS ClickFix campaigns. Telegram exfil and LaunchAgent persistence are boilerplate.
The backdoor, goyim, is roughly 80 percent a copy of the public deploy script for GSocket, an open-source tunneling toolkit from The Hacker's Choice. Its authors pitch the gs-netcat component as an encrypted reverse backdoor that needs no C2 server of its own. It rides a relay instead.
Group-IB traced this copy to an operator relay at gsnc[.]eu:67, with the binary pulled from gsocket.io itself. The stealer payloads sit on three compromised domains with clean reputations, one of them a hacked WordPress site, and the haul leaves through three Telegram bots. Group-IB observed no dedicated command-and-control infrastructure.
On macOS, the binary lands as iCloud in ~/Library/Application Support/iCloudsync and the process runs as SystemUIServerl, one letter off the real one.
Apple already tried to shut this door
macOS 26.4 shipped in late March. It warns when Terminal sees suspicious paste activity and blocks outright anything it recognizes as known malware, a mitigation Microsoft points to as a direct answer to ClickFix delivery.
Apple's own documentation shows how much room it left: the warning only fires if you do not regularly use Terminal, and it ships with a Paste Anyway button. The hard block needs macOS to already know the malware.
Two campaigns went through that room within weeks, in opposite directions. Jamf Threat Labs documented one in April that avoids the paste entirely, using an applescript:// URL to open Script Editor with the payload preloaded, so the check never fires. Jamf's Thijs Xhaflaire wrote that "when one door closes, attackers find another." ClickLock is the other. It kept the paste and engineered around the person instead.
The coercion loop is the one part with no cover story. Group-IB does not hedge on the sub-second pkill and killall bursts against Finder, Dock, SystemUIServer, and NotificationCenter: "this behavior is unique to forced-interaction malware and has no legitimate use case."
The rest of the signal set:
security find-generic-password called from a shell script rather than a browser
osascript spawning password dialogs with icons pulled from /tmp/
Bulk reads of browser profile directories followed by traffic to api.telegram.org
curl piped into bash where the URL ends in .jpg, .txt or .css
LaunchAgent creation in ~/Library/LaunchAgents/ by a shell process, paired with launchctl load
If a Mac starts killing its own apps and leaves a password box on screen, do not type the password. No verification page needs your Terminal. Cloudflare's check runs in the browser, which is the entire point of it.
Group-IB says to hold the power button until the machine shuts down, then start up in Safe Mode, and its Shift-at-startup step is the Intel procedure only. On Apple silicon, hold the power button until "Loading startup options" appears, select the volume, then hold Shift and click Continue in Safe Mode.
Cleanup is uneven. The stealer modules unload their own LaunchAgents, forge their timestamps off ~/Movies to break timeline analysis, and delete themselves. goyim does not. Sit through the loop, type the password, watch the desktop come back, and what is left is a machine that looks fine with a reverse shell on it, running as SystemUIServerl out of ~/Library/Application Support/iCloudsync.
ClickLock's operators launched in May, a month into the warning's life, and built for the paste. Whether one of Group-IB's targets ever saw it is the thing the report does not say.
The Hacker News has asked Group-IB for the macOS version breakdown behind those targets and will update this story with any response.
from The Hacker News https://ift.tt/2zXxb6p
via IFTTT
Why Docker is excited to co-host the first WeAreDevelopers World Congress North America
When we announced our partnership with WeAreDevelopers, AI agents were still mostly something developers experimented with. Today, they’re becoming part of everyday software development.
That’s why the timing for this year’s WeAreDevelopers World Congress couldn’t be better.
In the months since that announcement, the developer landscape has changed dramatically. If you’re writing software today, your workflow probably looks very different than it did a year ago. You’re prompting AI agents, reviewing AI-generated code, deciding what to accept and what to reject, and thinking about security much earlier in the development process.
Developers are no longer spending all of their time writing code. They’re designing systems that generate code, supervising autonomous agents, deciding what those agents can access, reviewing AI-generated changes, and making sure software is secure before it reaches production.
That shift feels a lot like the rise of data science a little over a decade ago. We didn’t replace programmers. We created an entirely new discipline that blended software engineering, mathematics, and statistics into something bigger.
I think we’re seeing the beginning of a similar transformation. Whether we continue calling ourselves developers, builders, or something entirely new almost doesn’t matter. The role itself is changing.
The best engineers of the next decade won’t simply write software. They’ll orchestrate teams of AI agents, establish the guardrails those agents operate within, and ultimately remain accountable for the systems they create.
That’s the conversation our industry needs to have. It’s also why this year’s WeAreDevelopers World Congress feels so important.
Docker is proud to serve as a presenting partner, but our goal isn’t to make this a Docker event.
Our goal is to help create a place where developers can learn from each other.
That’s why we partnered with WeAreDevelopers in the first place. They’ve spent more than a decade building one of the world’s strongest developer communities by focusing on the people building software, not the companies selling it. As AI reshapes how software gets built, North American developers need more than another vendor conference. They need a place to compare notes, share what’s actually working, challenge assumptions, and learn from peers facing many of the same questions.
The best developer conferences have never been about product launches. They’re about conversations. They’re about seeing how other engineers solve problems, discovering tools you didn’t know existed, and leaving with ideas you can actually use on Monday morning.
That’s what has made WeAreDevelopers so successful around the world, and that’s what we’re excited to help bring to the U.S.
The conversation has changed
Over the last year, nearly every conversation I’ve had with engineering leaders has landed in the same place.
Everyone wants the productivity gains that AI agents promise.
If you’ve spent any time with Claude Code, Cursor, Codex, or another coding agent, you’ve probably experienced it yourself. You can move faster than ever before. Then you stop and ask a different set of questions.
What is the agent actually doing?
Can it reach internal systems?
What credentials is it using?
Where is my data going?
How much autonomy am I comfortable giving it?
Those questions aren’t theoretical anymore. They’re becoming everyday engineering problems.
At Docker, they’ve shaped much of what we’ve been building.
We’ve introduced Docker Sandboxes so developers can run AI agents safely without changing how they work. We’ve launched Docker AI Governance to give organizations visibility and control over autonomous agents. We’ve continued investing in Docker Hardened Images because supply chain security only becomes more important as AI generates more code.
They’re all pieces of the same philosophy.
You shouldn’t have to choose between moving fast and staying secure.
The tooling should make both possible.
Meet the Docker team
We’ll have Docker engineers and leaders speaking throughout the event, including:
Mark Cavage, President & COO
Tushar Jain, EVP of Engineering & Product
Mark Lechner, CISO
We’ll also have engineers throughout the conference sharing what we’ve learned building for the next generation of software development, from AI-native workflows and developer productivity to security, containers, and the infrastructure that powers modern applications.
If you’ve been experimenting with agents, thinking about governance, or trying to figure out what secure AI development looks like inside your organization, we’d love to continue the conversation.
See you in San Jose
One thing has remained true throughout every shift in our industry.
Developers learn best from other developers.
That’s what makes communities like WeAreDevelopers special. It’s what has always made the Docker community special too.
AI will continue changing how software gets built. The tools will evolve. Our workflows will evolve right along with them.
What’s next won’t be shaped by any one company. It will be shaped by developers sharing ideas, challenging assumptions, experimenting with new ways of working, and building together.
That’s exactly what we hope to see in San Jose.
Whether you’re exploring AI agents for the first time, figuring out how to govern them at scale, or simply curious about where software engineering is headed next, we’d love to continue the conversation.
Come see what Docker is building for the next generation of software development, and join thousands of developers who are helping define what’s next.
An advanced malware previously attributed to a China-linked threat actor has resurfaced after more than four years within a Taiwan manufacturing firm, along with a previously unreported backdoor dubbed Stupig.
Daxin ("srt64.sys"), as the kernel-mode rootkit is referred to, was first documented by Broadcom-owned Symantec in March 2022, with evidence indicating its use in targeted attacks aimed at governments and other critical infrastructure targets since 2013.
The latest findings from the Symantec and Carbon Black Threat Hunter Team show that Daxin is still operational, after it was found running on a compromised host in Taiwan in 2026. The same machine, belonging to a Taiwan-based subsidiary of a multinational high-tech manufacturer, is also said to have been infected with Stupig ("a.dll" or "kbdus1.dll"). The file name is an attempt to masquerade as "kbdus.dll," a legitimate Microsoft DLL associated with the U.S. English keyboard layout.
"Stupig uses a technique not documented in any known malware family," the cybersecurity arm of Broadcom said. "A trojanized keyboard-layout DLL loaded by 'winlogon.exe' lets an attacker run commands as System directly from the Windows logon screen, before anyone signs in and without raising a logon audit event."
What makes the intrusion stand out is that both the artifacts carry a compilation timestamp from early 2013, although the compromised machine did not begin reporting telemetry until May 12, 2026. Given the threat actor's ability to stay undetected for extended periods of time, it's suspected that the attack may have gone unnoticed for 13 years.
No code-level overlaps have been identified between Daxin and Stupig, although their co-deployment on the same host, coupled with complementary functions, similarities in development practices, and the 2013 compile timestamps, suggest that they may have been the work of the same threat actor.
Daxin has an unusual approach to command-and-control. Rather than directly establishing outbound connections with attacker-controlled infrastructure, the Windows kernel-mode driver backdoor monitors incoming TCP traffic for specific patterns and hijacks existing legitimate connections for encrypted C2 communications so as to blend in with regular activity. It's equipped to interact with machines that are physically disconnected from the internet.
"This made Daxin exceptionally difficult to identify with conventional network monitoring," Broadcom noted. "The malware also supported multi-hop communications through chains of infected hosts, allowing operators to reach systems on isolated network segments."
Exactly how and when the host was compromised remains unknown, but it's suspected to be an outdated version of the Digiwin single sign-on (SSO) portal that was using end-of-life Java Development Kit (JDK) 1.5 and 1.6 installations going back to 2009 to 2011.
"Stupig is a DLL backdoor that achieves persistence by registering as a keyboard-layout provider, causing win32k.sys to load it into winlogon.exe at system startup," the threat hunter team explained. "The DLL returns a valid KBDTABLES pointer so the keyboard layout functions normally, giving nothing away to any process or administrator inspecting the loaded module."
Once it starts running inside "winlogon.exe," it keeps an eye out for usernames beginning with the string "stupig" in the Windows logon screen. When the username is entered, any string that follows the prefix is interpreted as a command and executed with SYSTEM privileges. If no command is entered after the prefix, it spawns a command prompt session as SYSTEM on the logon screen.
The discovery of Daxin in 2026 shows that the cyber espionage operation never completely stopped. Rather, it went quiet, maintaining stealthy persistence in targeted networks.
"By hiding inside the Windows logon process and registering as a keyboard-layout provider, Stupig gives operators SYSTEM-level command execution and credential theft before a user signs in, an access method most defenders are not aware of nor watching for," Symantec and Carbon Black said. "Whether the same operators deployed both tools cannot be confirmed, but their functions are complementary."
The disclosure comes as Hunt.io said it observed a suspected China-linked threat actor using Anthropic Claude Code and DeepSeek models to automate intrusions against government and financial systems in Afghanistan, Thailand, Taiwan, and the U.S. The discovery is based on an open directory ("112.213.124[.]132") that has been found to share identical HTTP header fingerprints with known TencShell command-and-control (C2) infrastructure.
"They handled reasoning for bypass techniques, reworked exploits after failed attempts, and built the phishing pages used to harvest credentials," the threat intelligence firm said.
"Claude Code serves as the execution engine, managing agentic tool use, bash command execution, session persistence, and task parallelization. DeepSeek-v4-pro operates as the underlying reasoning model, handling attack logic, script generation, and decision-making. In short, offensive logic is routed through a Chinese domestic LLM while leveraging Anthropic's agentic execution infrastructure."
from The Hacker News https://ift.tt/RbVNJn6
via IFTTT
Pull the certificate off the flash of a Shark RV2320EDUS robot vacuum, and you can run root commands on other people's Shark vacuums across the same AWS region: watch the camera, drive the robot, read the map of the house, and take the Wi-Fi password in plaintext.
A researcher publishing under the handle tokay0 put the method online on Monday, having tested it only against vacuums he bought himself. The flaw was unpatched then.
He says SharkNinja, the company behind the Shark and Ninja appliance brands, has had his report since March.
The policy attached to that certificate was never scoped to the device holding it. Present it to Shark's cloud broker, and the broker accepts whatever you publish, addressed to any device it serves.
No memory corruption, no privilege escalation, no password to guess. The command that runs is an ordinary field in the device shadow, the per-device state document AWS keeps in the cloud.
Using the certificate from an RV2320EDUS, the researcher subscribed to $aws/things/# and watched the traffic crossing the broker, harvesting serial numbers as he went. Publishing works the same way. The shadow carries an Exec_Command field that the management daemon appd reads and hands to a function named execute_command, which runs anything under 1,000 bytes through popen.
Send a shadow update carrying that field to a device's topic. If that device implements the handler, it runs the command.
He proved the cross-model path, landing a reverse shell on an AV1102ARUS he bought purely as a target, then using that shell to pull a live feed off the model's onboard camera while the robot drove around.
The certificate comes off with a screwdriver. The mainboard exposes UART pins, the U-Boot console asks for no password, and init=/bin/sh in the boot arguments drops you to a root shell, where the per-device key and certificate sit in /mnt/res/vapp/certs/ as ordinary files.
Certificates are pinned to their AWS region, the closest thing here to a limit: a key lifted in one region only reaches that region's devices. Reaching another region takes another certificate, provisioned there, and carrying the same broken policy.
Amazon has an audit check for this exact policy shape. Device Defender, AWS's IoT fleet auditing service, flags device policies granting publish or subscribe on $aws/things/* instead of pinning the topic to the connecting device with ${iot:Connection.Thing.ThingName}.
It appears as IOT_POLICY_OVERLY_PERMISSIVE_CHECK, and AWS rates it critical, warning in its documentation that a compromised certificate carrying such a policy lets an attacker "read or modify shadows, jobs, or job executions for all your devices."
Not every certificate is a skeleton key. A vacuum whose certificate carries the broken policy is an attacker's key. Any vacuum that runs Exec_Command is a target, whether or not its own certificate is scoped correctly. The AV1102ARUS is a target and not a key: its certificate was scoped correctly and could not wildcard-subscribe. Its firmware was several years newer.
He reads that as a provisioning fix that never reached the older fleet's certificates. That is why the cross-model shell worked, and why his claim that every internet-connected Shark vacuum is vulnerable needs splitting in two.
The headline on his post says millions. The figure he verified is narrower. Watching one AWS region for 24 hours, tokay0 counted 1,517,605 unique Shark serial numbers, of which 673,816, or 44%, emitted an Exec_Response, which he treats as confirmation that the device runs the command handler. Those are devices observed replying, not devices tested or compromised, and he says the true number is likely higher.
Four Months and Counting
By tokay0's account of the correspondence, he contacted SharkNinja on March 1 and sent details on March 11. The company acknowledged receipt the next day, told him on April 27 that the report was under review, and on July 3 said it would send a confirmed completion date by Friday, July 10. No email arrived.
He published on July 13. He says the vendor downplayed the severity and questioned whether "a CVE is appropriate."
On IoT reports specifically, SharkNinja's published vulnerability disclosure policy commits the company to "provide regular updates until the reported vulnerability is resolved." The same policy asks researchers to stay quiet until the company confirms a fix or authorizes disclosure in writing.
SharkNinja had published nothing on the flaw as of Thursday. The Hacker News has reached out to the company for comment on the patch status and the disclosure timeline, and will update this story with any response.
There is also no CVE. He asked MITRE's CNA of last resort, the assigner that handles vulnerabilities no vendor CNA covers, for an ID on June 11 and had heard nothing by the time he published. No identifier, no CVSS, no advisory: nothing for a vulnerability management program to key on.
The Fix Is Server-Side
The fix is not the owner's to install. It lives in SharkNinja's AWS account, not the robot's firmware. Per AWS's remediation guidance, a non-compliant policy is replaced by pushing a scoped version with CreatePolicyVersion and the setAsDefault flag, which makes that version operative for every certificate using the policy.
No firmware rollout required. Reissuing the certificates properly, which tokay0 recommended in March, is the longer job behind that.
Until SharkNinja does one or the other, the only mitigation available to an owner is to disconnect the vacuum from Wi-Fi. That ends app control, scheduling, and maps, and turns the product back into a vacuum.
tokay0 withheld his scripts while the flaw is live. He judged his other findings too minor to write up.
He never examined the rest of SharkNinja's connected lineup either, the smart grills and the wireless meat probes, which he says are probably vulnerable too. Those products come from the same company whose policy promises regular updates until a flaw is resolved. Four months on, this one is not.
from The Hacker News https://ift.tt/DlTwBMb
via IFTTT
Security teams have never had more visibility, yet rarely have they felt more uncertain. Signal pours in from endpoints, identities, cloud workloads, and a sprawling mix of third-party tools. Dashboards are full, alerts keep coming, but the hardest question of the day remains unanswered: of everything happening right now, what actually matters to us, and what do we do about it?
That space between knowing a threat exists and acting on it is the intelligence-to-action gap, and it’s where most breaches are won or lost. It doesn’t close with another feed or another dashboard. It closes with expertise: seasoned defenders who know your environment, interpret what global signal means for your risk, and stay with you from the first indicator to the final response.
Today we’re announcing a new service, Microsoft Defender Experts Threat Intelligence, and we are expanding Microsoft Defender Experts MDR to include new third-party and multi-cloud coverage. Together, these human-led offerings are designed to close the intelligence-to-action gap at the two moments that decide the outcome: before a campaign reaches you, and as it moves through your environment.
Upstream: See the campaign before it reaches you
The earlier you see a campaign forming, the more options you have, and the cheaper every decision becomes. Yet most threat intelligence still arrives as raw feeds or static reports: high in volume, low in context, and disconnected from what’s exposed in your estate. Teams end up with more to read and no more clarity on what to do about it.
Microsoft Defender Experts Threat Intelligence is a new, expert-delivered service that closes that distance. Built on Microsoft’s visibility across endpoints, identity, cloud, and evolving attacker activity, it gives your team periodic, curated insight into the threats most likely to target you. Designated Microsoft experts interpret the global landscape through the lens of your industry, geography, and environment, then translate it into clear, prioritized guidance your team can act on.
As campaigns evolve, experts continuously refine that guidance with newly observed infrastructure, tactics, and targeting patterns, helping your team adjust hunting, hardening, and response activities. The insight is tailored for both leadership and defenders, providing executive-ready context alongside technical recommendations so the entire organization can act from a shared understanding of the threat landscape. The goal is simple: help you reduce risk before an attack reaches your environment, not explain what happened after the fact.
In practice, your team receives:
Early-warning alerts on emerging campaigns relevant to you
Campaign-evolution updates as activity unfolds
Contextualized intelligence tied to your risk profile
Recurring briefings from your designated expert, rotating across geopolitical, industry, and global perspectives, on a scheduled basis
Microsoft Defender Threat Intelligence Now Integrated into Defender
While this new expert-delivered service helps customers turn threat intelligence into action through direct engagement with Microsoft analysts, we’re also continuing to bring that same type of insight closer to defenders’ day-to-day workflows. Today we’re announcing that Microsoft Defender Threat Intelligence (MDTI) capabilities are now fully converged into the Defender portal. Intelligence is available real-time across detection, investigation, response, hunting, and automation, reducing context switching and helping teams move more quickly from signal to action within a unified SecOps experience.
In your environment: Follow the threat everywhere it moves
Modern attacks rarely stay in one place. They cross from email to endpoint to identity to cloud, and increasingly traverse disparate security tools. Even when organizations have visibility into those environments, connecting multi-vendor and multi-domain signals into a coherent attack story remains a challenge.
That’s the gap we’re closing on the response side: Microsoft Defender Experts MDR (formerly Microsoft Defender Experts for XDR) is expanding with new third-party and multi-cloud coverage powered by Microsoft Sentinel. Defender Experts MDR provides a fully managed detection and response service that reduces noise, adds expert context, and drives action. With support for leading non-Microsoft sources across cloud, identity, email, network, and endpoint environments, our experts can follow attacks wherever they move, not just where Microsoft products operate.
The service is backed by Microsoft’s vast threat intelligence, and combines expert-authored detections and analytics, investigation and response automation, and ongoing operational guidance to help customers strengthen security outcomes across their environment.
In practice, customers gain:
24/7 monitoring and investigation by Microsoft experts who distil high‑volume telemetry into high‑confidence, prioritized incidents that dramatically reduce analyst fatigue and accelerate response.
Cross-platform threat analysis that correlates signals across Microsoft and non-Microsoft environments to deliver a single incident narrative with actionable, vendor‑aware guidance.
Ongoing recommendations to optimize security operations, from detection tuning and data integration to content management in Sentinel.
Business-aligned summaries of top risks, posture gaps, and recommended improvements across the security estate.
This expanded coverage is available through Microsoft Defender Experts MDR Plan 2. Everything available today as Defender Experts for XDR carries forward unchanged as Microsoft Defender Experts MDR Plan 1, while Plan 2 extends that same expert-led triage, investigation, and response beyond Microsoft’s own estate.
See it live at Black Hat USA
Every one of today’s announcements aims at the same outcome: shrinking the distance between a signal arriving and a decision being made. That’s the measure that matters in the end—not alerts triaged, but decisions made faster and with more confidence.
Come see it at Black Hat. Join our session Mind the Gap: Turning Threat Intelligence into Decisive Action with Expert-Led Defense, where Wes Malaby, General Manager of Customer Success at Microsoft Security, will demonstrate how expert-led intelligence and defense can change the trajectory of a threat campaign from the earliest warning signs through response and remediation. After the session, stop by theMicrosoft Security booth to connect with our experts and learn how these services fit into your broader security strategy, or attend our reception on August 5 for a more conversational environment.
Mandiant security assessments frequently identify publicly exposed serverless applications that lack authentication, often as a result of specific business requirements. Serverless deployments typically run custom-developed code that incorporates third-party packages, making them targets for a wide range of application-level attacks, including:
Local and Remote File Inclusion (LFI/RFI)
Command Injection
Successful exploitation of these vulnerabilities can grant an attacker full control over the underlying container instance. Such access can serve as a foothold that may ultimately lead to a full compromise of the victim’s cloud environment.
Based on lessons learned in customer engagements, in this blog post we describe attack scenarios and provide actionable guidance on how to secure serverless environments. While this analysis focuses on hardening strategies for Google Cloud Run services and functions that must remain publicly accessible, these principles apply universally to any public serverless deployment.
What are Serverless Applications?
Serverless applications, also described as Function-as-a-Service (FaaS), allow the deployment of individual blocks of code as microservices within a flexible, decoupled, and event-driven cloud architecture without the need to manage underlying infrastructure. These services enable applications and automations to scale automatically and deploy instantly, removing operational overhead. Serverless services underpin major e-commerce, media, payment processing applications, and AI usage.
The rapid expansion of generative AI adoption is a significant driver of increased serverless architecture use. AI workflows, including chatbot interactions, image generation, “vibe-coding”, and multi-step AI agents rely on serverless functions to complete tasks for users. This growth has made securing serverless environments a more pressing challenge for enterprise security teams.
Risks of Serverless Application Attacks
Publicly exposed serverless workloads can serve as an initial access point for threat actors. As noted, these services may contain vulnerabilities within the code, imported packages, or the underlying runtime environment.
Once an entry point is exploited, attackers typically attempt to escalate privileges or move laterally. Common techniques observed include:
Extracting secrets stored directly within the application code.
Reviewing application logic and sensitive data to identify further attack vectors within the environment.
Exfiltrating service account bearer tokens from the metadata server following successful Remote Code Execution (RCE).
Leveraging these compromised secrets or service accounts allows threat actors to pivot to adjacent systems and workloads, potentially resulting in a total environment takeover if proper hardening strategies are not in place.
Example Attack Scenarios
The following simplified scenarios illustrate how serverless functions can be compromised and how attackers pivot after achieving initial code execution.
Local File Inclusion (LFI)
In the following Cloud Run example, a Python/Flask function accepts user-controlled input to open a file without performing proper validation. This pattern is an example of a Local File Inclusion (LFI) vulnerability.
import functions_framework
@functions_framework.http
def hello_http(request):
request_json = request.get_json(silent=True)
request_args = request.args
if request_json and 'file' in request_json:
file = request_json['file']
elif request_args and 'file' in request_args:
file = request_args['file']
# VULNERABILITY: The 'file' parameter is used directly in open()
# without validation, allowing arbitrary file access
with open(file, 'r') as resp:
filedata = resp.read()
return 'local file data {}!'.format(filedata)
Figure 1: Vulnerable Python/Flask function accepting unvalidated user input to open files
This vulnerability allows an attacker to request sensitive files from the Cloud Run instance by using curl to send a POST request via the file parameter:
curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "main.py"}'
Figure 2: curl POST request targeting the file parameter
The response provides the complete main.py source code. An attacker can analyze the code for:
Hardcoded secrets such as API keys, database credentials, or authentication tokens
Business logic flaws and additional injection points
Internal service endpoints and architecture details
Import statements revealing the technology stack and potential CVE exposure
Additionally, attackers can leverage standard ../ directory traversal sequences to retrieve sensitive system files:
curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "../../../etc/passwd"}'
Figure 3: curl POST request leveraging directory traversal sequences
An LFI vulnerability allows an attacker to retrieve and fuzz various files directly from the container. Key examples include:
requirements.txt, package.json, go.mod: Used to identify installed packages and versions with known vulnerabilities.
.env files: Frequently contain sensitive environment variables or hard coded secrets.
Application configuration files: May contain database credentials, API keys, or service endpoints if not securely managed.
/etc/passwd, /proc/self/environ: Contains user information, environment variables.
Application logs: may contain auth tokens or PII data.
Best Practice: Never store secrets or credentials within the source code or local container files. Utilize a dedicated secrets management solution, such as Secret Manager.
Code Execution/Command Injection
In the following scenario, a Python function uses shell execution methods with unsanitized user input, allowing an attacker to execute arbitrary commands.
import functions_framework
import subprocess
@functions_framework.http
def hello_http(request):
request_json = request.get_json(silent=True)
request_args = request.args
if request_json and 'input' in request_json:
input = request_json['input']
elif request_args and 'input' in request_args:
input = request_args['input']
result = subprocess.run(input, shell=True,capture_output=True, text=True)
return format(result)
Figure 4: Python function utilizing shell execution with unsanitized user input
This allows an attacker to execute a subsequent curl request targeting the GCP metadata service to retrieve the service account’s bearer token.
The following request extracts the service account's OAuth 2.0 bearer token, which remains valid for 1 hour:
Figure 5:Extraction of a GCP service account bearer token via a curl request
Once obtained, an attacker can use it on an attacker-controlled system to execute Google Cloud CLI commands. For example the CLOUDSDK_AUTH_ACCESS_TOKEN environment variable can be set using the stolen bearer token.
Attackers can then leverage Google Cloud Cloud CLI within the security context of the Cloud Run Compute service account. If deployed without best practices and thoughtful configuration controls, for example, if the Cloud Run service runs as the default compute service account with Editor permissions, this would be equivalent to a full GCP project takeover, and allow the attacker to:
Read/write/delete most GCP resources
Deploy new services and modify existing configurations
Access secrets and encryption keys
Exfiltrate data across all accessible storage systems
Establish persistent backdoors through new service accounts or SSH keys.
Hardening Recommendations
Mandiant recommends that organizations implement parallel approaches for effective serverless security:
Secure Software Development Lifecycle (S-SDLC): integrate security scanning, code review, least-privilege IAM into CI/CD pipelines before deployment and integrate continuous security testing;
Vibe Coding: Mandiant recommends multi-layered security enforcement for AI-generated code or "vibe coding." Organizations should isolate AI experimentation within dedicated sandbox environments and enforce strict data egress controls to protect production systems and internal data. Furthermore, development environments should be restricted to approved IDEs with human-in-the-loop capabilities, utilizing only verified plugins operating under least privilege to mitigate supply chain vulnerabilities. Finally, organizations must ensure this AI-generated software follows Secure Software Development Lifecycle (S-SDLC) controls while establishing clear internal guidelines regarding permitted use cases. Comprehensive security fundamentals for vibe coding are documented in detail within the Wiz Vibe Coding Security Fundamentals blog.
Compensating Runtime Controls: Implement the following defense-in-depth measures to limit and contain compromise even when application vulnerabilities exist;
Segregate Public Services
Host public-facing Cloud Run services consumed by untrusted external entities in a dedicated, isolated Google Cloud project. This ensures a compromise does not provide an immediate path to critical internal resources. The implementation of this 'Service Project' model is beyond the scope of this post; however, it is documented in detail within the secured serverless architecture blueprint.
Identity and Access Management (IAM)
Mandiant recommends using a custom service account for service authentication rather than the default Compute Engine service account, following the principle of least privilege. Grant only the specific permissions necessary for the Cloud Run function to operate, for example:
Cloud Storage Bucket Access: If the service only requires read access to objects from a Cloud Storage bucket, grant the Storage Object Viewer (roles/storage.objectViewer) role restricted to that specific bucket.
Secret Manager Access: If the service requires access to secrets, grant the Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) role only to the individual secrets required. For further details on secret access from Cloud Run, refer to the GCP documentation on configuring secrets.
Restrict ingress traffic for serverless functions to internal only and use an external Layer 7 ALB to manage internet exposure. This provides:
Centralized Traffic Management: Granular control over headers and SSL policies.
Cloud Armor Integration: Web Application Firewall (WAF) support to harden applications against vulnerabilities such as Local/Remote File Inclusion (LFI/RFI) and Server-Side Request Forgery (SSRF).
Traffic Shaping: Implementation of rate limits and request limitations to prevent abuse.
Enhanced Visibility: Robust logging and log-forwarding capabilities for security monitoring.
Identity-Aware Proxy (IAP): integration support for scenarios requiring specific identity-based authentication for internal users.
Web Application Firewall (WAF) — Cloud Armor
Cloud Armor provides WAF protections that can be integrated with the Load Balancer to filter malicious traffic. The following examples demonstrate how to configure Cloud Armor security policies to block the specific local file inclusions, remote code execution and traversal attacks previously outlined.
Local File Inclusion
The lfi-v33-stable preconfigured WAF rules can block common local file inclusion attacks (local file inclusion reference).
Figure 10: Verification of Cloud Armor blocking Remote Code execution, resulting in a 403 forbidden
Serverless Architecture Controls
Hardening Cloud Run services is only one part of a secure architecture. Because these services often connect to other Google Cloud resources, a single compromise can expose additional services. Implementing defense-in-depth is critical. Specifically, when using direct VPC egress or VPC Access connectors, use VPC Service Controls to restrict lateral movement and exfiltration through granular access policies.
Secure Software Development Lifecycle (S-SDLC)
While the previously outlined hardening strategies are critical, the ideal standard remains the proactive identification of vulnerabilities during the initial development stages. A deep dive into "Shift-Left" security is beyond the scope of this analysis, which focuses on mitigating risks within existing code. However, a Secure Software Development Lifecycle (S-SDLC) remains a fundamental principle. Robust code validation and continuous security testing are essential to neutralize threats before serverless functions are published externally.
Cloud Run Threat Detection
Beyond the hardening recommendations outlined in this post, Google Cloud Security Command Center (SCC) provides built-in services to detect control plane attacks against Cloud Run resources. These include detectors for credential access, reconnaissance, and the execution of scripts or reverse shells. The Cloud Run Threat Detection service is available for Premium and Enterprise tiers.
Conclusion
Serverless applications drive agility and rapid business value. While "vibe-coding" has made it easier than ever to deploy code, this breakneck speed demands that teams integrate security early in the development lifecycle, move beyond default configurations, and prioritize a defense-in-depth strategy centered on identity and architecture.
Acknowledgements
This analysis would not have been possible without the assistance of Ischa Rijff, Phil Pearce, and Juraj Sucik.
from Threat Intelligence https://ift.tt/i9dsmxQ
via IFTTT
