An attacker used a contributor's GitHub account to replace the download archives on five existing releases of OVHcloud's command-line tool on Monday, October 19. The account had been hijacked, and the new files were a build designed to steal secrets stored on the disk of any machine that runs it, the cloud provider says. They were live on GitHub for up to 94 minutes, from 12:47 to 14:21 UTC,
Microsoft urges organizations to secure AI Agents as insider threats, using dynamic permissions, continuous risk monitoring and automated containment. Microsoft published a detailed blog post explaining how organizations should secure AI agents. Microsoft sees them as a growing insider threat, not just a possible risk in the future. AI agents are not dangerous by nature, but they can access critical systems and may fail, be manipulated, or be compromised. “The most trustworthy agentic system will not be the one with the model we trust most. It will be the one designed that enables us to trust the model least.” said Satya Nadella This is not just a theory. It is a principle that should guide how organizations design and secure AI systems. The post makes a distinction worth holding onto. An agent that starts a task with the right permissions and behaves correctly can still become dangerous if its context changes mid-run. A prompt injection in an external document, a piece of untrusted data that shifts the agent’s reasoning, a task that evolves in a direction nobody anticipated, none of these require the agent to be compromised in the traditional sense. The model produces variable outputs, the context changes, and the agent’s behavior drifts. At machine speed, the window between that drift starting and it causing damage is very short. Microsoft’s proposed answer is continuous containment rather than upfront trust. You define what the agent is allowed to do before it acts, you monitor what it actually does while it runs, and you adjust its permissions in real time as its behavior or the risk calculation changes. An expense approval agent should start with access scoped exactly to reviewing and approving expenses, nothing broader, and those permissions should shrink or disappear the moment the agent tries something outside that task. The post introduces Dynamic Permissions to apply the principle of least privilege to AI agents. An agent should not automatically get the same access rights as the employee who deployed it. It starts with no permissions and receives only the access needed for its approved task. These permissions remain active only while the task is running. “The employee retains the employee’s access.” Microsoft states. “The agent receives its own identity, permissions and its own authority scoped to its current task and for the duration of the task only.” Alongside that, Dynamic Agent Risk is a continuously updated score that combines signals from identity, endpoints, network, cloud, runtime, and the agent’s own behavior to assess whether what the agent is currently doing still matches what it was authorized to do. The response when risk rises is graduated rather than binary: preserve reads while blocking writes, narrow accessible resources, require human approval for high-impact steps, or stop execution entirely if the risk warrants it. “Dynamic Agent Risk combines signals from identity, data, endpoints, cloud, network, runtime, and the agent’s own activity. It considers how securely the agent is configured, what resources it can reach, the potential impact if something goes wrong, and whether its actions are drifting from the user’s or organization’s intent.” Microsoft states. “The result is not a one-time score assigned at onboarding. It is a continuously updated understanding of the agent’s current risk and whether its current authority still matches that risk. “ Organizations frequently have AI agents running locally or introduced through third-party tools that were never formally registered in any central system. Microsoft says it’s expanding discovery to 60 types of local agents, including Claude Code, OpenAI Codex, and GitHub Copilot. Getting those into a unified registry with accountable identities is the prerequisite for applying any of the governance controls described in the rest of the post. You can’t set least-privilege permissions for an agent you don’t know exists. You can’t detect behavioral drift from an agent that doesn’t have a tracked identity. The agent registration problem is logistically harder than it sounds, especially for organizations where individual employees can spin up agents without IT involvement, which is most organizations right now. Microsoft recognizes that organizations cannot manually review every risk alert when they run hundreds of thousands of AI agents. Its solution is Guardian Agents, AI agents focused on security. They follow playbooks created by human operators, investigate changes in risk, apply or recommend security measures, and use what they learn to improve security policies. Humans set the goals and approve important decisions, while the agents handle continuous monitoring and response. However, this approach raises another concern. Guardian Agents are also AI agents, so they can fail or be manipulated, just like the agents they are supposed to control. Microsoft says security controls must operate outside the AI model and must not be changed by it. But this raises an important question: how can organizations ensure these controls remain reliable when the system enforcing them is also an AI agent? This is a challenge that real-world deployments will need to address in the coming years. “Organizations are adopting agents to serve customers better, solve problems faster, and give people more time for the work that matters most. The goal is not to make every model perfectly predictable before it can be useful.” Microsoft concludes. “The goal is to build systems that remain secure even when the model is not.” Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, AI Agents)
Ransomware operators including Spikey Scorpius (aka Qilin) and Tarnished Scorpius (aka Inc) are exploiting PAN-OS vulnerability CVE-2026-0257. The post Threat Brief: Active Exploitation of PAN-OS CVE-2026-0257 (Updated October 19) appeared first on Unit 42.
Staffing software company Bullhorn has disabled access to its platform to contain a cyberattack that caused a system-wide outage. The company says it has isolated the issue and eradicated the immediate threat. Currently, its team is working to restore services following thorough security reviews conducted with help from CrowdStrike specialists. Bullhorn is an American software company specializing in cloud-based staffing and recruitment solutions. Its platform helps staffing firms manage the recruitment lifecycle, including candidate tracking, onboarding, and payroll. The company says it serves more than 10,000 customers worldwide. According to a status page on the incident, customers started to experience issues with job posting in the Bullhorn application on Friday. The next day, the company said it was "experiencing a system-wide outage affecting the Bullhorn platform," and later confirmed that the issues were caused by a cyberattack.
The open-source AI coding project OpenCode has notified some users that stored API keys they used with external providers were exposed in a security breach. Multiple users reported that the incident led to unauthorized API charges and suspended projects in Google Cloud. According to the project maintainer, the breach affected 1.4% of OpenCode Console users, with some reporting more than $1,700 in unauthorized charges overnight. OpenCode is a model-agnostic AI coding agent that helps users understand code, write features, and fix bugs using natural-language instructions, through a terminal, desktop app, or code editor. Users can connect AI models from multiple AI providers to the OpenCode console to streamline and automate the development process. On Saturday, OpenCode announced that it suffered a large distillation attack that impacted only developers who linked external providers, including Anthropic, OpenAI, and Google.
Cybercriminals are selling forged identity documents, deepfake videos, and live verification services to help buyers bypass Know Your Client (KYC) checks. Flare examines how these underground services operate and the techniques used to create and maintain fraudulent verified accounts.
Attackers stole ConnectWise application credentials to access Microsoft 365 tenants, prompting the company to suspend cloud services. ConnectWise suspended its Cloud Backup service and took both SaaS Security and Cloud Management offline over the weekend after discovering that unknown attackers had obtained unauthorized access to seven of its application identities. The company discovered the incident on October 14 through internal monitoring, disabled the compromised identities on October 17, and is still investigating how attackers obtained the credentials. “We have taken protective action following unauthorized access to application identities associated with ConnectWise Cloud Backup, formerly known as SkyKick. Our investigation remains ongoing. Since implementing the mitigations described below, we have not observed successful threat activity in the environments we monitor.” reads the alert published by the company on October 17. “Out of an abundance of caution, we suspended Cloud Backup service by revoking certificates used for affected application connections across all users. This removed ConnectWise’s access through those connections. The shared credentials previously used for Cloud Backup are no longer valid and cannot be used. In addition to mobilizing our internal security teams and Security Operations Center (SOC), we have engaged a reputable third-party incident response firm to support our investigation and containment efforts. Together, these teams are actively monitoring our backup infrastructure and broader environment, with the investigation extending across all partner-facing services. At this time, we have no indication that any other ConnectWise product, service, or offering is impacted.” This was not a case of attackers stealing individual customers’ passwords. ConnectWise’s applications already had permission to access customer Microsoft 365 environments to manage services and run backups. After stealing the application credentials, the attackers could pretend to be ConnectWise’s own applications and request access tokens from Microsoft Entra ID. They did not need to steal any customer passwords. Depending on the permissions granted to these applications, the attackers could access mailboxes, SharePoint documents, Teams messages, and directory data. ConnectWise explained that disabling the affected connections prevents new authentication through those connections; however, it does not reverse changes previously made inside a tenant. In other words, disabling the compromised connections stops new access through them, but it does not undo what the attackers may have already done inside customer environments. Any changes made before the connections were disabled may remain. Here’s what makes this particularly hard to clean up. An attacker who used a stolen application credential to get into a tenant could add their own client secret to a different trusted application already registered in that tenant, or create an entirely new application and grant it permissions. Either path gives them a second key that still works even after ConnectWise’s original compromised credential is revoked. “The larger risk is what happens when that access is used to gain more. If an application can assign directory roles, as we saw in one tenant, it can make itself a Global Administrator, and an administrator can add credentials to other applications, create new applications and grant them permissions, reset passwords and authentication methods for users, and change Conditional Access policies.” reads the analysis published by cybersecurity firm Huntress. “Each of those steps gives the attacker another way back in that does not depend on the original vendor credential, which is why rotating the vendor credential is necessary, but not enough.” Huntress identified malicious sign-ins from IP address 144.172.64.128 through October 15 at around 14:20 UTC, and a second targeted wave later that same day aimed specifically at 16 tenants in the policy, national security, trade, and critical minerals sectors. That second wave appeared to be manual rather than automated and hit Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra, and Office 365 Management APIs in rapid succession. All 16 attempts in the second wave failed, but the fact that they were manually targeted at sensitive sectors is the detail worth sitting with. Of about 1,000 Microsoft Entra tenants that recorded sign-in activity from the suspicious IP address, around 300 sign-ins were successful. However, a successful sign-in did not always give the attackers access to a tenant. In some cases, they could not proceed because the required service principal was missing. This was a result of the tenant’s configuration, not a security measure that had been deliberately put in place. ConnectWise said its Cloud Backup archives remain encrypted, isolated, and preserved, with no evidence that attackers accessed or compromised them. “Cloud Backup remains suspended. Scheduled backups are not running, and access to affected backup archives and restoration capabilities remains unavailable.” continues the ConnectWise’s alert.”Existing archives remain encrypted, isolated, and preserved. We have no evidence that these archives have been accessed.” However, while the service remains offline, backups cannot run and customers cannot restore their data. This creates an operational risk for organizations that depend on the service to recover their systems and information. Huntress’s recommendation for anyone using ConnectWise Cloud Backup or Cloud Management is to review both their own Microsoft 365 tenant and every managed customer tenant, including any with dormant SkyKick connections. Look specifically for sign-in activity from 144.172.64[.]128 starting October 13. Before doing anything else, preserve available sign-in and audit logs, because containment steps can overwrite the evidence you need to understand what actually happened. The list of what to check is long: application credentials and federation trusts, directory role assignments, consent grants, recent policy changes, mailbox forwarding rules, and delegated mailbox access. Any of these could be the thing an attacker quietly added before the connection was killed. Full ConnectWise advisory and ongoing updates are available here. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, ConnectWise)
An intruder reached a legacy system at OpenCode on the night of October 16 and may have exposed the third-party AI provider keys that users had saved in OpenCode Console, the company said. Console is OpenCode's optional hosted service: a workspace saves its own OpenAI, Anthropic, or Google key there, and Console uses that key to call the provider so team members can use the models without
ConnectWise on Saturday said it has disabled seven ConnectWise application identities as it continues its investigation into an incident in which unknown threat actors obtained unauthorized access to the application identities and compromised Microsoft 365 tenants. The disabled identities are listed below - ConnectWise Cloud Backup - 506e08f9-6e9a-4da4-942b-a099a03644ae ConnectWise
ConnectWise has shut down customer access to its Cloud Backup service (formerly SkyKick Cloud Backup) after hackers accessed application identities and compromised Microsoft 365 tenants. Reports of the malicious activity began emerging on Friday, with administrators observing unauthorized access to client data in Microsoft 365 tenants due to a potential “SkyKick/CW breach.” Later on the same day, managed cybersecurity and threat detection platform Huntress confirmed the worries, saying that it had identified at least 162 compromised tenants in its environment. In a post today, Microsoft also confirmed malicious activity involving ConnectWise’s Cloud Backup service, saying it identified unauthorized authentication attempts from an IP address on October 15. ConnectWise’s cloud backup solutions provide backup and recovery services that help managed service providers (MSPs) and IT teams protect and restore customer data, such as emails and files, in cloud environments including Microsoft 365 and Google Workspace.
Confirm this action.
Leaving now will discard your changes.