Attackers are getting more interested in operational data
"When people talk about operational data, they mean the information and access that keeps an organization running, rather than the customer records most people picture when they hear about a data breach. It’s more valuable to an attacker because losing customer records is expensive and damaging, but losing your operational systems means you stop operating, and that gives an attacker far more leverage."
What's happening: ClickFix attacks don't rely on users downloading obviously suspicious attachments or ignoring browser warnings. Instead, they present a technical problem and provide familiar troubleshooting steps to trick users into executing malicious commands. Users may be instructed to launch PowerShell, Command Prompt, the Windows Run dialog, or Terminal, and then paste a command to complete a fake CAPTCHA.
Why it matters: ClickFix attacks are able to bypass conventional phishing awareness. They typically begin on legitimate but compromised websites and imitate trusted digital routines like browser checks, login verifications, and troubleshooting prompts. Rather than relying on obviously risky behavior, attackers design ClickFix lures around the habits security-aware users have been taught to trust.
The big picture: ClickFix works because it doesn't depend on users being careless. As users become more cautious, attackers will continue adjusting prompts and delivery methods to appear more legitimate. Default-deny policies account for the possibility that even a security-aware user will eventually copy the wrong command and prevent it from executing before the attack can begin.
How indirect prompt injection attacks work and how to defend against them
What's happening: In an indirect prompt injection attack, threat actors insert malicious instructions into data an AI agent may consume in order to manipulate it into deviating from its intended task. Prompts can be hidden in webpages, online forums, attachments, calendar invitations, source code, and more. A successful attack can expose system credentials, publish unauthorized content, direct users to malicious websites, or modify records.
Why it matters: Malicious instructions do not always resemble an obvious attack. They can be split across several pieces of content, use different languages, remain dormant until a specific event, or hide instructions in images. Security teams cannot realistically predict and preemptively block every possible combination of language that may influence the LLM.
The big picture: You can't control every instruction an AI agent might encounter, but you can control what the agent is capable of doing. The impact of a successful prompt injection attack is ultimately determined by the agent's permissions, tools, and access. Applying least agency ensures that even when an agent is manipulated, the actions it can take remain limited.
How to determine what access and permissions are safe
What's happening: The autonomy of AI agents is what makes them useful and potentially dangerous. To use AI agents safely, organizations need to establish clear boundaries around what they can access and do. An AI assistant that summarizes a document needs access to that document, but it shouldn't automatically be allowed to search connected drives, run scripts, or update records. A useful agent permission model should answer the following questions: Which identity does it use, which data can it read or change, which tools or processes can it invoke, where can it communicate, and which actions require approval?
Why it matters: When an agent is given too much freedom, vague instructions or manipulated inputs can lead to unintended actions at machine speed. The greater the potential impact of an AI agent's actions, the narrower its permissions should be.
The big picture: Applying least agency shouldn't come at the expense of productivity. Define each agent's job, then give it only the tools, access, and privileges required to perform that job. Test agents in an isolated environment to determine what files, processes, and integrations they actually use, enforce policies around that behavior, and continuously review permissions as agents and workflows change.
Threats you need to know
Two SharePoint vulnerabilities combine for remote code execution
Two vulnerabilities could turn authentication bypass into full server compromise
What's happening: Two critical SharePoint flaws can be chained together to allow an unauthenticated attacker execute code on a vulnerable server. The first flaw, CVE-2026-55040, is a critical authentication bypass, while the second, CVE-2026-63520, is an improper input validation flaw. Microsoft released patches for each in its July and August updates. Researchers have observed authentication bypass, administrator enumeration, and probing of the second vulnerability, but have not yet seen successful code execution through the complete chain.
Why it matters: The authentication bypass is being actively exploited and was added to CISA's Known Exploited Vulnerabilities (KEV) Catalog earlier this month. In this case, bypassing authentication provides the initial access needed to exploit the second vulnerability and potentially achieve remote code execution. Researchers identified approximately 8,500 SharePoint servers exposed to the internet, giving attackers a sizable pool of potential targets.
The big picture:A flaw that provides initial access can become more dangerous if attackers discover another weakness that expands their capabilities. Organizations running affected SharePoint servers (2016, 2019, and Subscription Edition) should apply both Microsoft updates and review authentication activity for signs of exploitation.
Critical Gitea flaw exploited to execute malicious commands
CISA warns of active exploitation of recently patched flaw
What's happening: CVE-2026-60004 is a critical remote code execution flaw that allows users with repository write access to abuse Gitea's diffpatch endpoint to install a malicious Git hook and execute arbitrary shell commands. Gitea allows open registration by default, potentially enabling an outside attacker to create an account and repository themselves. The vulnerability affects Gitea versions starting with 1.17 and is patched in version 1.27.1.
Why it matters: At least one reported attack has used the flaw to deploy a cryptocurrency-miner-like payload. Before executing the payload, the attack attempted to terminate competing processes, downloaded a version based on the system architecture, executed it, and then deleted the file.
The big picture: A vulnerability that requires an authenticated user isn't necessarily protected from outside attackers when anyone can create an account. Organizations running Gitea should upgrade to version 1.27.1 or later and review whether open registration is necessary. Beyond patching, limiting what application service accounts can execute can help prevent a compromised application from turning into unrestricted command execution on the underlying system.
Next week's webinar
Why would an attacker target you?
The answer often comes down to economics.
Join ThreatLocker CEO Danny Jenkins and Lead Cybersecurity Engineer Kieran Human as they explore how today's cybercriminals identify, prioritize, and profit from their targets.
What makes you a target? Lessons from the cybercrime economy
"It was effective from the beginning, and we immediately saw results. It's empowering our users to do what they need to do with less helpdesk and IT interaction."
ThreatLocker events
Meet the Cyber Hero Team in person at these upcoming events
