Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Latest News

Bitcoin Could Face Quantum Computing Threat Within Years, Experts Warn

  Bitcoin faces existential threat from quantum computers, according to some experts. With the passage of time, researchers have voiced grow...

All the recent news you need to know

AI Pricing Explained: Why Token-Based Costs Are Challenging Businesses

 

Artificial intelligence is rapidly becoming an essential business tool, but companies are still struggling to decide how much AI services should cost. Unlike traditional software, which is often sold through monthly subscriptions or licences, AI systems can consume different amounts of computing power depending on the complexity of each task. This makes pricing difficult for both technology providers and their customers. Buyers want predictable bills, while sellers need to recover the considerable expense of running advanced AI models. 

One important factor in AI pricing is the use of “tokens”. Tokens are small units of text or data processed by an AI model. A short question may require only a few tokens, while a lengthy document, detailed analysis or complex instruction may require thousands. Companies generally pay according to the number of tokens their systems process, but this arrangement can make costs unpredictable. A business using AI frequently may receive a much larger bill than expected, particularly when employees use increasingly powerful models. 

The problem is becoming more complicated as businesses move towards AI agents. These systems can perform tasks independently, such as searching for information, preparing reports, responding to customers or managing internal processes. Because agents may complete several steps before delivering an answer, they can use far more tokens than a simple chatbot. According to the report, one bank expects monthly token consumption to rise 24 times between 2026 and 2030, reaching 120 quadrillion tokens as companies adopt AI agents more widely.  

Tech companies are experimenting with several pricing approaches. Some offer subscriptions, while others charge customers for usage, the length of responses or access to particular model capabilities. A subscription may be easier for customers to budget, but it can be unprofitable if users consume large amounts of computing power. Usage-based pricing is more closely connected to operating costs, yet it may discourage customers from using AI because they fear unexpectedly high charges. Providers therefore face a delicate balance between affordability, transparency and profitability. 

Ultimately, the future of AI pricing may involve a combination of models rather than one universal system. Basic services could be offered through fixed subscriptions, while advanced agents and high-volume business applications might be charged according to usage. Companies will also need better monitoring tools to track consumption and prevent waste. As AI becomes more deeply integrated into workplaces, clear pricing will be crucial for building trust. If businesses cannot understand what they are paying for, they may delay adoption despite the technology’s potential to improve productivity.

Claude AI Agents Escalate Into Malware Conflict During Anthropic Tests


During anthropopic’s latest testing, the company discovered a unique security risk associated with autonomous artificial intelligence systems. AI agents working toward different goals may attack one another in conflicting instructions. Three instances of the agent Claude were observed running on separate virtual machines during a “multiagent turf war”. The test was intended to examine how the agents would behave when they share the same environment, but have different objectives. 

Three agents were assigned the task of migrating a Python backend to three different programming languages, Go, Rust and TypeScript. Each system initially operated without any knowledge that the other agents were present. In about four hours, the agents became aware of each other. 

After the Claude agents discovered each other, they began considering the other agents as obstacles to their tasks. Rather than coordinating their efforts, the agents attempted to protect their own work while interfering with the others. Anthropic said the behavior escalated to increasingly aggressive actions, including destroying the Unix accounts used by other agents as well as creating automated scripts that were able to repeatedly locate and terminate competing processes. 

A malicious code program designed to resemble legitimate work associated with another agent was the most serious behavior. Several agents were able to obtain an advantage over their adversaries by deploying self-replicating malware, according to Anthropic. 

Anthropic has not publicly disclosed the specific types of malware created during these tests, and there is no indication that any malicious code has escaped the controlled environment. In order to study these interactions, virtualized systems were specifically used. 

Claude Models Responded Differently 

Models responded differently to conflict. In some cases, agents ceased attacking after realizing that conflicting instructions had led to the confrontation rather than intentional hostility. As a result, agents communicated, documented their actions, removed malicious code, and attempted to establish a truce. Some agents also requested human intervention, while others abandoned the task rather than continue the confrontation. 

Claude models were significantly different from each other, according to Anthropic. Sonnet 4.6 resolved conflicts through force in 61% of tested cases, while 39% did not resolve their conflicts. Mythos Preview did better, reaching a truce in 48% of cases, while 35% of cases were settled by force, while 17 percent were resolved by passive agents. 

Among the models tested, the full Mythos model achieved the strongest results, reaching negotiated truths in 98% of cases. However, Anthropic cautioned that better conflict resolution does not necessarily mean that a problem has been resolved. Mythos systems with greater capabilities sometimes excluded rival agents before eventually cooperating with them. A more capable model does not automatically perform better than another AI agent, according to the results. 

Agent-on-Agent Attacks Are Not Entirely New

There are numerous examples of agents becoming competitive, but the Anthropic tests are not the only ones. Recently, cybersecurity company Dreadnode performed simulations of red and blue teams. Researchers observed a blue-team agent rationalizing that improving its own performance may require making the opposing red-team agent perform worse. 

Since agents were allowed to modify code in the environment, the blue-team system began attempting to reduce the effectiveness of the opposing model by altering its code. It was discovered that even though researchers were able to stop the behavior before it succeeded, AI systems are capable of analyzing another agent as a thing to manipulate if they are focused on winning rather than cooperating. 

As a result of the tests, it has also been demonstrated that ordinary instructions may lead to aggressive actions when multiple artificial intelligence systems are operating within the same environment without clear restrictions. While the agents were not programmed to be malicious, their behavior evolved from their attempts to achieve competing objectives. 

Why Multi-Agent Conflicts Matter

Security testing for artificial intelligence focuses primarily on examining the behaviors of a single model, such as whether it follows instructions safely. Multi-agent systems pose another problem: how the models interact with one another. The behavior of an agent in isolation may vary greatly when another artificial intelligence system modify the same files, consume the same resources, or interfere with its operations. 

A company using autonomous agents for software development, cybersecurity, cloud environments, or other sensitive operations may encounter this problem. A conflict between agents resulting from access to accounts, processes, source code, or production infrastructure could have far more serious consequences than a controlled experiment. These findings suggest that stronger safeguards should be taken to prevent agents from interfering with one another. 

Access, conflict resolution, identity, permissions, and the ability to modify or terminate other agents may need explicit rules governing access, conflict resolution, identity, and permissions. The increasing use of AI agents in companies will make it increasingly important to understand how these systems interact with other autonomous agents, making cybersecurity testing a more important component of testing. 

Unless an AI agent has been programmed to attack, it is not required to act aggressively. Conflicting instructions or access to shared resources may trigger that behavior. The findings of Anthropic demonstrate the necessity for security controls to evolve along with autonomous AI. In order to prevent conflicts from turning into security incidents, organizations will need stronger safeguards as multiple agents gain access to shared environments.

Cloudflare Workers Spectre Attack Exposed JWT at 12 Bits Per Second

 

Cybersecurity researchers have uncovered a remote Spectre attack targeting Cloudflare Workers that was capable of extracting a JSON Web Token (JWT) from a co-located Worker in a production environment at speeds of up to 12 bits per second. This represents a significant increase over an earlier attack demonstrated in 2021, which achieved just 2 bits per minute.

The researchers conducted an end-to-end experiment involving an attacker-controlled Worker and a victim Worker, with the JWT deliberately stored in the victim's memory. According to the research paper, the experiment did not involve accessing any customer information.

Cloudflare said it has already addressed the issue in its production environment by strengthening Dynamic Process Isolation (DyPrIs), integrating the V8 Sandbox and introducing Memory Protection Keys (MPK)-based in-process isolation. The company also said it found no evidence of active exploitation related to the issue during the past three years.

"We demonstrate that the production implementation of DyPrIs was insufficient," the researchers said in the paper.

Cloudflare Workers executes code belonging to multiple tenants using separate V8 isolates within the same operating-system process. Rather than relying solely on strict process-level separation, the platform uses language-level isolation to help maintain faster startup times.

According to Cloudflare, a memory-read attack within a shared Worker process could potentially enable information to leak across tenants. However, the attack requires both the attacker and victim Workers to be placed in separate V8 isolates within the same Worker process.

The researchers said the attacker must control legitimate code within its own isolate. The technique does not rely on native code execution, a V8 vulnerability or a sandbox escape.

Cloudflare Workers also limits access to local timing mechanisms by freezing or reducing the precision of timers during CPU execution. Worker scripts do not have access to shared memory or multithreading. However, the researchers discovered that WebSocket communications could act as a remote timing channel.

They also found that Durable Objects could keep a Worker isolate running continuously for periods ranging from five hours to more than 20 hours. Under DyPrIs, suspicious scripts are moved into a separate process after an invocation ends. The researchers found that long-running Durable Object invocations could remain active before this isolation mechanism was triggered.

Another weakness involved WebSocket-intensive input/output activity. The researchers observed that such activity increased instruction translation lookaside buffer (iTLB) activity, weakening the normalized branch-misprediction signal monitored by DyPrIs and pushing it below the mechanism's detection threshold.

Cloudflare characterized the problem as a limitation in how DyPrIs was implemented. The research paper, however, argued that the weaknesses represented more fundamental limitations of the detection methodology rather than simple implementation errors. The researchers recommended monitoring for such activity during execution and using signals that cannot be suppressed through I/O activity.

The researchers conducted their production testing on Linux servers powered by AMD EPYC Zen 2 and Zen 3 processors. Measurements were intentionally performed at night, when CPU utilization was between 10% and 25%, to determine the highest achievable leakage rate.

According to the paper, heavier system workloads reduced the amount of data that could be leaked, although the attack remained possible at slower speeds under greater CPU load.

The study recorded a peak leakage rate of 12 bits per second with 99.16% accuracy. By comparison, the earlier attack achieved approximately 2 bits per minute.

The latest disclosure arrives nearly five years after Cloudflare and Graz University of Technology (TU Graz) published research detailing a remote Spectre attack against Workers. That earlier work demonstrated a leakage rate of 120 bits per hour and introduced DyPrIs as a defense mechanism.

The 2021 research reported a false-positive rate of 0.61% and concluded that DyPrIs offered, statistically, security guarantees comparable to strict process isolation against the Spectre attacks evaluated at that time.

Cloudflare subsequently outlined additional security hardening measures for Workers in September 2025. The company's mitigations include:

  • Enhanced DyPrIs: Improvements designed to strengthen the detection capabilities of the existing isolation mechanism.

  • V8 Sandbox: A security layer designed to restrict transient access to 64-bit pointers.

  • MPK-based in-process isolation: Worker heaps are placed behind hardware-enforced Memory Protection Keys. Cloudflare said modern x64 systems provide approximately 12 keys that can be used for this purpose. Its architecture combines MPK with the V8 Sandbox and a rotating memory layout to prevent neighboring sandboxes from being assigned the same protection key.

Cloudflare's September 2025 documentation noted that randomly assigning MPK keys would block roughly 92% of cross-isolate access attempts because two isolates could receive the same key. The company said its stricter rotating memory layout eliminates that remaining gap within the threat model covered by the in-sandbox protections.

Microsoft Copilot Flaws Could Expose User Data With One Click

 


Microsoft Copilot Personal contains three vulnerabilities that could allow an attacker to execute a malicious prompt with one click and exfiltrate data from connected applications, according to Varonis Threat Labs.

The researchers collectively named the flaws CoSnitch and reported them to Microsoft in December 2025. Microsoft patched the vulnerabilities on August 18, 2026, with the issue tracked as CVE-2026-24301. Varonis said it found no evidence of exploitation in the wild. The research concerns the consumer Copilot service at copilot.microsoft.com and does not establish that the same behavior affected Microsoft 365 Copilot.


Copilot Revealed Its Own Attack Path

Varonis discovered the vulnerability through what it calls "meta-hacking," repeatedly asking Copilot why a prompt could not execute without user interaction. After several refusals containing technical explanations, Copilot eventually disclosed an undocumented "autorun=1" URL parameter, including the conditions and safeguards associated with it.

Researchers constructed the URL as described and found that the supposedly disabled parameter still executed. They combined "autorun=1" with Copilot's existing "q" parameter, which pre-fills the prompt. While "q" alone requires user interaction, the combination automatically triggered the prompt when the page loaded.

Varonis said the prompt then continued executing even if the victim immediately closed the Copilot tab. Its earlier Reprompt research had also used "q" as a one-click Parameter-to-Prompt mechanism.


Existing Permissions Enable Data Theft

The first two CoSnitch flaws form the one-click exfiltration chain. The injected instruction operates with the same capabilities available to a legitimate user prompt and does not grant Copilot additional permissions.

Researchers demonstrated access to connected mail messages, subject lines and sender and recipient metadata; calendar titles, attendees, times and locations; Google Drive filenames and metadata summaries; previous Copilot conversations; and stored memory instructions and user-defined rules.

The retrieved information could be encoded, including with Base64, and transmitted through Copilot's built-in URL-fetching capability to an attacker-controlled webhook. Varonis said the resulting request could resemble Copilot's ordinary web retrieval traffic, potentially making network-level detection difficult.


Separate Memory Poisoning Path

The third vulnerability involves indirect prompt injection through web summarization. A malicious webpage could contain attacker-controlled instructions that Copilot processed and wrote into its persistent memory.

Varonis said such injected memories could survive password changes, session revocation and device re-enrollment until manually removed. The modification reportedly generated no process, file or network activity that conventional security tooling would necessarily flag, although the change remained visible in Copilot's memory interface.

The finding follows earlier Microsoft 365 Copilot memory research by Håkon Måløy and Johann Rehberger. Microsoft has separately said M365 Copilot applies sanitization and prompt-injection checks to memory writes, performs Task Adherence checks on explicit memory updates, and records those changes for security monitoring through audit data and the "MemoryUpdated" field.

Varonis recommends reviewing connected applications, disconnecting unnecessary services, monitoring AI assistants as privileged systems and exercising caution with links that open AI assistants.

The disclosure follows Varonis's RovoBlast research, which identified another one-click attack involving Atlassian's Rovo assistant. Together, the findings demonstrate how URL handling, authorized application access, external content and persistent AI memory can combine into an attack chain without directly compromising the victim's underlying accounts.

Critical Snowflake GitHub Actions Flaw Exposes Projects to Command Injection


Snowflake’s public snowflakedb/snowflake-connector-net repository has been identified as vulnerable to GitHub Actions workflow injection. This vulnerability could be exploited to trigger command execution within CI/CD workflow through specially crafted GitHub issues. In this case, the flaw is attributed to the repository’s automatic workflow, jira_issue.yml, which runs automatically when a public issue is opened. 

When processing issue data, the workflow exposed Jira credentials, including API tokens, to the affected job. Attacker-controlled issue titles and descriptions were also passed directly into a shell command, resulting in an avenue for command injection. The workflow was also triggered by an issue event, which was incorrectly referenced with github.event.pull_request.user.login as the event check reference. 

In the absence of the referenced pull request property, this condition evaluated with an empty value, resulting in regular issues reaching the vulnerable job without any protection. The issue was not related to any released versions of the Snowflake Connector for .NET and affected the repository's CI/CD automation. 

Using the Red Agent, Wiz researchers discovered the vulnerability on June 23 as part of a security research project conducted by Snowflake’s HackerOne vulnerability disclosure program. Five days prior, after pull request #1218 was merged, a security flaw had been introduced, and an unauthenticated user could activate it by using a specially crafted GitHub issue title. 

The scan conducted by GitHub Advanced Security, which included Copilot Autofix, examined a revised version containing the vulnerable workflow, however, did not identify the injection. As a result of discovering the flaw, the Red Agent verified access to sensitive information within Snowflake’s internal Jira system. Code that has been compromised originated in a cleanup-related pull request that replaced a safer environment-variable and jq parsing approach with direct interpolation of the title of an issue into a shell script, which is the source of the vulnerable code. 

GitHub's security tooling flagged other issues during the development process and Copilot suggested fixes, but neither identified the injection caused by the change. Ultimately, a human reviewer approved and merged the pull request. In June of 2026, when the workflow became active, any new issues could be accessed by the vulnerable code path. 

Wiz’s Red Agent discovered the vulnerability five days later and successfully refined its exploit after an initial attempt to exploit it failed. As a result of the resulting payload, the researchers were able to access sensitive data within Snowflake’s internal Jira environment and obtain the Jira API token, enabling them to determine the potential impact of the vulnerability. 

A number of questions are raised by the incident regarding automated security review and AI-assisted software development. Wiz pointed out that coding tools can inadvertently reintroduce unsafe shell practices, while security scanners fail to detect the injection that occurs. The case underscores the importance of thoroughly reviewing code changes involving GitHub Actions, particularly when workflows handle sensitive credentials or untrusted input. 

Snowflake was informed of the vulnerability by Wiz through HackerOne on June 23, 2026, under report #3819931. Snowflake resolved the issue on June 24, 2026, by submitting pull request #1402, which replaced direct expansion of GitHub issue data with environment variables passed as arguments to jq. The Jira token was rotated on June 24. 

The investigation conducted by Snowflake did not reveal any evidence of unauthorized access, and Wiz reported that no unrelated external use of the exposed token was observed during the five-day exposure period. There has been no release of the company's underlying audit logs. Furthermore, GitHub's commit history does not indicate that Copilot was the author of the changes to the jira_issue.yml file. 

Despite the fact that Copilot Autofix appears to be a co-author of the squash merge, the unsafe refactoring was contained in a separate commit attributed to a Snowflake developer. Consequently, the available history confirms Copilot's participation in the pull request, but does not substantiate that the code was introduced by it. 

This case demonstrates GitHub's warnings of workflow security risks in 2025, particularly when issue data is directly used in run blocks, which poses a security risk to workflows. As of August 17, 2026, no CVE, CVSS score, or CISA KEV listing had been identified for this vulnerability. The vulnerable code has since been removed from the master branch, and there is no evidence that it has been exploited outside of the master branch.

Apple Patches Dozens of WebKit Flaws in Latest Security Updates

 

Apple has issued a major set of security updates for macOS, iOS, and iPadOS after discovering dozens of vulnerabilities in WebKit, the browser engine that powers Safari and many apps across its platforms. The latest macOS Tahoe update fixes 28 flaws, 21 of them in WebKit, while older-device releases such as iOS 18.7.10 and iPadOS 18.7.10 address more than 120 bugs, including more than 40 WebKit issues. 

These bugs are serious because they affect the core component used to display web content, making malicious websites a practical attack path. Apple has not reported active exploitation in the wild, but the company urges users to install the patches quickly. The WebKit flaws can cause a wide range of problems, from Safari or process crashes to memory corruption and sensitive data disclosure. 

Some of the issues could also allow attackers to bypass sandbox protections or exfiltrate data across origins, which raises the risk of unauthorized access to private information. On macOS, additional fixes in Audio, ImageIO, IOGPUFamily, and Kernel address risks such as denial-of-service, arbitrary code execution, system termination, and kernel memory corruption. That combination makes the update important not only for browser safety, but for overall device stability and privacy. 

The most immediate recommendation is to install the updates as soon as they are available through the device’s normal software update settings. Users should not delay simply because no public exploitation has been announced, since browser-engine flaws are often attractive to attackers once details become known. Organizations should prioritize patching managed Macs, iPhones, and iPads, especially devices used for email, browsing, and access to corporate systems. It is also wise to confirm that older supported versions receive the correct maintenance release, since Apple issued separate fixes for newer and legacy branches. 

After updating, users should still practice cautious browsing habits. Avoid opening unfamiliar links in email, text messages, or social media posts, because malicious web content is the most likely delivery method for WebKit exploits. Security teams should monitor for unusual browser crashes, authentication anomalies, or unexpected data leakage, which can be early warning signs of abuse. 

If a device cannot be updated immediately, limiting web exposure and using a trusted content filter can reduce risk until patches are applied. This release is a reminder that browser engines remain a high-value target for attackers because they sit between users and the web. Apple’s broad patch set shows that a single update can close multiple pathways to compromise across consumer and enterprise devices. For most users, the safest approach is simple: update first, browse carefully, and keep security features enabled.

Featured