Read more of this story at Slashdot.

Bots (and privacy-preserving browsers) not welcome

Browse a news site in a private window. Shop at a major retailer with a VPN. Visit a video streaming platform with anti-fingerprinting defenses tuned up. You’ll see the same responses: registration walls, block pages, and endless CAPTCHAs. The message is clear: if we think you might be a bot, you’re not welcome.

Websites have valid reasons for wanting to block bots. Bots enable volumetric abuse, abuse that wouldn’t otherwise be feasible if they had to be carried out by humans.  For example: SEO comment spam, credential stuffing and DDoSing. Consequently many sites employ dedicated anti-abuse tooling which aims to keep the bots out whilst minimizing friction for human visitors.

Unfortunately, that tooling is increasingly failing at both tasks. Browser privacy protections are dismantling the passive signals that anti-abuse systems depended on to identify and distinguish visitors. Meanwhile advances in generative AI have rendered CAPTCHAs ineffective: bots now solve them faster and more reliably than humans.

Many sites are switching to more invasive mechanisms and now ask visitors to disclose identifying information, e.g. an email address, a federated login or disabling their VPN. This means greater friction for users, since providing these details on a first visit takes time. It also compromises their privacy, since these details enable the same kinds of cross-site tracking that browser privacy protections were intended to mitigate.

This leaves users with a dilemma. The more effectively they protect their privacy, the harder it is for websites to distinguish them from bots and the worse the treatment they receive. Website operators are also suffering. The additional friction they inflict upon well-behaved visitors harms their site, but many are willing to pay the costs if it mitigates volumetric abuse.

Browser-based AI agents make this tension more acute. Sites may want to allow agents which are acting on behalf of individual users while blocking agents engaged in volumetric abuse. However, with no effective mechanisms to distinguish the two, websites are opting to block both. That hurts users, who should be free to choose the user agent they use to access the web; it hurts new browsers and agents, which struggle to interoperate; and it hurts sites, which lose legitimate visitors.

The consequence is that the web gets worse for everyone. Users get more friction or less privacy or both. Website operators see more volumetric abuse and the friction they add drives away users who would otherwise want to consume their content or services. New user agents struggle to access the same content as conventional browsers.

The Costs of Convenient Solutions

Some large ecosystem players have put forward solutions that leverage their control of the dominant operating systems and their deep integration with consumer hardware. These rely on device attestation: identifiers and privileged code baked into devices at the hardware level, which let manufacturers prove what software is running on a user’s device. Exposing this functionality to the web means attesting to sites that the user is running approved software with trusted hardware and therefore isn’t a bot. There have been two substantive proposals.

Google’s Web Environment Integrity, abandoned in 2023, was the blunt version. It attested to the user agent itself, as well as the operating system and device in use. Users would have lost control in two ways: once to the attester, which would decide which operating systems and devices could be blessed, and again to the website, which would decide which software to accept. If sites had adopted allow-lists of approved user agents, building a new browser would have become virtually impossible, and sites could have withdrawn access from any user agent they chose.

Apple’s Private Access Tokens, deployed across their ecosystem in 2022, have more subtle issues. Built on the Privacy Pass protocol standardized at the IETF, they get a lot right: a user receives a renewed, limited batch of one-time tokens that can be presented to websites without linking their visits together. This provides privacy for users and has shown rate limits to be an effective tool for sites – both points we’ll return to later in this post.

However, Private Access Tokens rely on device attestation, requiring that the hardware manufacturer be in overall control of the user’s device. Presenting a PAT tells a website you are locked into Apple’s rules for what counts as acceptable software. Due to PAT’s technical design^[1], there’s no way to open the system to other sources of scarcity without compromising the system’s privacy properties, meaning that if more widely deployed, access to the web would become tied to having bought expensive hardware from a small, hard to change set of vendors.

Both approaches are ultimately hostile to users and to the openness of the web. Both are premised on parts of a user’s device that sit within the manufacturer’s control and beyond the user’s own. Were they widely deployed, the web would become just another walled garden with centralized gatekeepers controlling acceptable hardware, operating systems and software. As convenient as these solutions are for the players who already dominate the ecosystem, we think there’s a better path.

A Better Path Forward

Bots’ harms arise from their ability to operate beyond human scale. For sites to prevent volumetric abuse they don’t actually need to know the user’s identity or receive cryptographic proof that they’re running approved software. If sites knew their visitors were restricted to a rate limit set by a site, that would be enough.  

Rate limits only make sense if they’re tied to something scarce; something an attacker can’t cheaply replicate to evade the limit. Without anchoring to a scarce resource, like the trusted hardware used in Private Access Tokens, attackers can generate as many fresh identities as they need to bypass the rate limit.

However, hardware is just one option for scarcity. Anything a user already has that an attacker can’t trivially spin up at scale will work: email addresses and phone numbers are naturally scarce. A paid subscription costs an attacker the same as a real user.  Even maintaining an account on a free service requires some non-trivial work.

What if we could use these scarce signals across the web? We could build an open ecosystem with many parties offering scarcity signals, each site choosing which to accept. By opening up who can provide a signal, and letting sites choose which to accept, we can avoid transferring control to device manufacturers and the resulting harms.

As a concrete example of who might be well positioned to provide such a signal, we can consider VPN providers acting as a subscription service. Sites routinely block VPN users indiscriminately, whether through a deliberate policy choice or through an indirect consequence of rate limiting visitors per IP address. But a VPN subscription is a perfect source of scarcity. If the VPN provider could vouch for its users so that sites could rate limit each user individually – then users would be able to browse the web with less friction and without giving up their VPN usage.

The catch is that building a system that can enable this on the open web whilst maintaining user’s privacy is genuinely difficult. It requires that we take information from one site — that this user holds some scarce thing — and expose it to other sites so that they can use that as the basis for their rate limiting. Letting one site verify a signal from another is the sort of information flow that privacy-preserving browsers have spent the last decade locking down to prevent cross-site tracking.

Our goal would be that no more than the minimum information gets through: a single bit communicating whether the user is below the rate limit set by the site. Leaking anything more – like the source of the scarcity that the rate limit is anchored to – would be unacceptable. Enabling a new cross-site information flow might feel like compromising privacy to gain better access, but reality is more nuanced. If a new system moves sites away from demanding that visitors be identifiable (whether through fingerprinting or login forms), it can be a win for both privacy and access.

The Foundations

The good news is that the cryptographic foundations for a privacy preserving approach already exist. The Privacy Pass protocol, originally developed in 2018 to reduce the friction of Cloudflare CAPTCHAs for Tor users, introduced the core primitive: a token that is unlinkable between issuance and redemption. You prove something to an issuer (e.g. by solving a CAPTCHA), receive some tokens, and later present a token to a website. The website can verify the token is legitimate, but can’t link it to the user it was issued to.

Figure 1: In Privacy Pass, a CAPTCHA provider can issue tokens to a client which can then be used to bypass challenges for future site visits. Even if the CAPTCHA provider and sites collude, they can’t use the tokens to identify the user or their browsing history.

Privacy Pass has gone on to be successfully deployed in systems where the issuer and verifier have a prior trust relationship: Apple uses it to authenticate users of Private Cloud Compute and Private Relay without linking their activity to their identity, Chrome uses it for two-hop IP protection, and Kagi uses it to provide private search. These deployments work in part because a small number of parties have agreed in advance on who issues tokens and who accepts them.

Applying this approach to an open system where any site can act as an issuer brings real challenges. Firstly, even though tokens are unlinkable, knowing a user has access to a specific issuer is a privacy leak on its own, because you can infer that the user meets the relevant issuance criteria. If one site can learn that you have a token from another site, that reveals that you have been to that site, which can be a major privacy problem. This compounds if sites can learn the set of issuers you have visited, since it becomes a fingerprint which can be used to identify you.

Generic techniques exist for proving a statement in zero knowledge: we can prove that a client has a token from a set of acceptable issuers without revealing which specific issuer it is. We’ll call this issuer blinding. The generic approach is often slow, but bespoke approaches tailored to the underlying cryptography can improve this considerably.

Another challenge is how sites using rate limits decide who to trust to issue tokens. If an issuer misbehaves then the site’s rate limits become ineffective, enabling volumetric abuse. However, if we need to prevent the site from learning which issuers a user has access to, the site is only going to know that one of its trusted issuers was used, not which one. This makes mistakes or misbehaviour by an issuer difficult to detect, and makes it hard for sites to evaluate new issuers. Solving this challenge is essential for openness. Without adequate information, sites are likely to lean towards conservative issuer selection. That could lead to less choice between Anchors, which in turn could lead to a new form of gatekeeper being created. 

To solve this, sites at least need a way to calculate an aggregate score for each issuer they use. This should roughly correspond to how much of the traffic it considers abusive to have come from users using that particular issuer. Mozilla has long invested in systems like Prio which use multiparty computation (MPC) to protect user privacy whilst enabling aggregate measurements of system behaviour.

Privacy Pass also struggles to handle dynamic adjustments to rate limits. Once tokens have been issued, they’re difficult to invalidate without either revoking all active tokens or risking attacks which can compromise the privacy of users. It’s also beneficial if sites can adjust rate limits on a per client basis, for example by increasing rate limits where they become more confident the client is benign and withdrawing access when abuse is detected.

Anonymous Credit Tokens offer a useful building block to solve this problem. Conventional Privacy Pass schemes rely on issuing a bucket of tokens but ACT works differently by enabling the use of a credential with state. For example, an ACT credential can hold an internal counter. When the credential is presented, the site can check the counter is over some threshold and mutate it, increasing or decreasing the counter whenever the site’s perception of the holder has improved or worsened. Critically, the exact value is never leaked to the site, preventing the site from tracking the holder and ensuring successive presentations of the same credential can’t be linked.

Putting it together

So how can we combine these techniques to build a system which can enable privacy-preserving rate limiting on the open web? In May 2026, we participated in a W3C CG Meeting in collaboration with Cloudflare, Chrome and other web stakeholders in which we started sketching out a design we’re calling PACT – Private Access Control Tokens.

Rate limits need a starting point, a source of scarcity to anchor on. We’ll call an entity that provides such a source an Anchor. To a user who meets the Anchor’s criteria, like having a subscription, an account in good standing, or a verified phone number, an Anchor issues a batch of Endorsement tokens, following the Privacy Pass model. In practice, Anchors could be any website which has access to this kind of signal. An Endorsement conveys scarcity to other sites.

That’s enough for a simple system where access is either granted or denied. But as we discussed earlier, we also want the ability to increase access where a visitor behaves benignly and decrease it where they don’t. The state needed to enforce a rate limit can’t live in the Endorsement, because Endorsements cross trust boundaries between unrelated sites. We need a second object that can hold that state, scoped to the party that maintains it.

We’ll call that the party that handles rate limiting for a site a Moderator and the stateful object a Credential. A Credential is specific to a Moderator and, unlike endorsements, we limit each site to nominating a single Moderator. In the common case the site itself plays the Moderator role, so there’s no new entity or trust boundary. A Moderator can also be a third-party service shared across many sites, allowing those sites to cooperatively share a rate limit. 

In the terminology of the previous section, the Anchor is the issuer of Endorsements, and the Moderator both verifies Endorsements and issues Credentials. A Moderator manages rate-limit policy: it decides which Anchors it trusts, accepts their Endorsements, and issues a Credential in return.

Figure 2: (1) Clients acquire Endorsements from Anchors in the course of normal browsing to sites they have relationships with. (2) Clients can exchange Endorsements for a stateful Credential from a Moderator. (3) Credentials can be used to access sites which use that Moderator. Credentials can be updated over time.

Directly revealing which Anchor backed an Endorsement would leak a lot of information about the user. The issuer blinding techniques from the previous section solve this: when an Endorsement is redeemed, the Moderator only learns that it came from one of the Anchors it trusts, but not which one.

When a Moderator covers more than one site, we let Credentials be presented across all of them but partition cookies and storage as we would for any other third party site. The unlinkability of Credential presentations keeps this from creating a new cross-site identifier. The benefit is that good behaviour on one site improves access on every site the Moderator covers, and bad behaviour cuts it everywhere. Websites can already build the same capability with a shared account system, so this doesn’t create a new way to lock users out, but it does provide a new way to grant access without requiring users to give up their privacy.

Enabling Moderators that cover many sites carries a centralisation risk, similar to the concentration we see today in anti-abuse providers. The mitigation is that the choice of Moderator stays with each site, and the choice of trusted Anchors stays with each Moderator. This can’t reverse the centralisation pressure the web already faces, but it ensures this system won’t lead to additional lock-in: a new Anchor or a new Moderator can be adopted without coordinating with a dominant vendor.

The system then has three flows. First, the user receives Endorsements from an Anchor in the course of normal interaction, based on the Anchor’s positive view of the user. This is a relatively rare operation for any given user and Anchor. After all, as our source of scarcity, Endorsements should not be too easy to accumulate.

Figure 3: In the course of normal browsing, clients browse to websites they have a relationship with. These sites can act as Anchors by issuing Endorsements to clients.

Second, when the user arrives at a site that works with a Moderator, the browser spends an Endorsement from an Anchor the Moderator trusts and receives a Credential in return. The presentation hides which Anchor was used, and neither the Anchor nor the Moderator can trace the Endorsement back to where it was issued. The Moderator decides what initial balance the Credential starts with. If the user has no Endorsements from suitable Anchors at all, existing mechanisms (CAPTCHAs, account creation, federated login) could be used to bootstrap a Credential the same way, so the system degrades to today’s experience rather than locking the user out.

Figure 4: When the client browses to a site, it can prompt the client for a Credential from the Moderator it uses. If the Client doesn’t have a suitable Credential, but does have a suitable Endorsement, it can exchange it for a Credential with the Moderator. In practice, the Moderator and the Site might be the same server.  

Third, as the user browses, the browser presents the Credential and the Moderator updates the internal state of the Credential. The Moderator can reward behaviour that looks benign and penalize suspicious activity, but can’t track the use of the Credential or identify it if it’s used on other sites the Moderator covers. Revocation falls out of the same mechanism: a Moderator can refuse to return an updated Credential. 

Figure 5: The Client can present the Credential on sites which use the matching Moderator. Sites can check if the Credential is in good standing. The sites can then adjust the access the Credential has in response to behaviour. E.g. increasing it when they gain confidence in the client or reducing it in response to malicious behaviour.

In practice, all of this would happen transparently to the user through a WebAPI that sites acting as Anchors or Moderators would call from JavaScript. In an ideal ecosystem, users would accumulate Endorsements through normal browsing, just by virtue of the sites they already visit, and the rest of the flow would happen in the background as they move around the web, leaving users with meaningfully less friction.

AI agents acting on behalf of a user slot into the same flow. An agent can carry its user’s Credentials, in which case the user remains accountable for how the agent behaves. Sites would not need to grant any more access than they would to the user themselves. Alternatively, the operator of an agent can run its own Anchor and vouch for its agents the way other Anchors vouch for human users. Sites retain control over which Anchors they accept, so they can choose how to treat agent traffic without needing a separate detection mechanism.

Several mechanisms combine to keep the information about a user that flows out close to a single bit. Cryptographic unlinkability ensures successive Credential presentations cannot be tied to each other or to the original issuance, so a user’s visits cannot be joined into a history. Each site is bound to a single Moderator, so the set of Moderators a user has Credentials with never becomes a cross-site fingerprint. The Anchor-to-Credential exchange happens in an isolated browsing context, so during ordinary browsing the only thing the site or its Moderator ever observes is a Credential presentation: the site only learns if the user has a valid Credential below the rate limit, or nothing. When the Moderator updates a Credential, it adjusts the credentials state without learning what it is.

The additional privacy given to users from Issuer blinding makes participating in the system more challenging for Moderators. Because the Moderator can’t see which Anchor backed a Credential at issuance, it can’t give a Credential from a strong Anchor more access than one from a weak Anchor: doing so would itself leak which Anchor was used. The initial access has to be uniform across the Moderator’s whole pool of Anchors, which in practice means setting it at the strength of the weakest. However, this is only relevant for that initial access, the Moderator can update credentials according to the holder’s behavior, enabling Credential’s to accrue access over time.

Building an open ecosystem also requires that sites can make effective decisions about the Anchors they choose to trust. Multiparty computation systems like Prio enable aggregate scoring without compromising privacy. When users present Credentials, they can provide an encrypted share which identifies the anchor they used and can be privately aggregated to compute the quality of an issuer.

Next Steps

We think the architecture we’ve sketched for PACT has the right shape, but many of the details still need to be worked out and the entire system needs rigorous privacy and security analysis.

We want to do that work in the open. The IETF is the natural venue for the cryptographic protocols underneath, and the W3C for the WebAPI surface that sits on top. We’ll be bringing draft specifications to these bodies as soon as they’re ready, and we welcome collaborators from across the ecosystem: browser vendors, site operators, anti-abuse providers, and the cryptography community.

If successful, we think we can provide a system which will keep the web open and private, while still giving sites the rate-limiting signal they need.

Acknowledgements

The ideas described here are the result of collaboration and conversations with many people, including: Watson Ladd, Thibault Meunier, Michele Orrù, Trevor Perrin, Eric Rescorla, Samuel Schlesinger, Martin Thomson, Eric Trouton, Benjamin Vandersloot & Cathie Yun. 

The post PACT: Anonymous Credentials for the Web appeared first on Mozilla Hacks - the Web developer blog.

Read more →

The post Google Adds Selfie Video Sign-In to Help Users Recover Locked Accounts appeared first on IT Security News.

The post Google Adds Selfie Video Sign-In to Help Users Recover Locked Accounts appeared first on TechRepublic.

The post New infosec products of the week: July 24, 2026 appeared first on Help Net Security.

The post Google Adds Selfie Video Feature to Help Users Recover Locked Accounts Securely appeared first on Cyber Security News.

Read more of this story at Slashdot.

The post Costs of B2B Friction – How Broken Partner Access Is Undermining Revenue appeared first on SecureBlitz Cybersecurity.

The FBI IC3 scam has evolved into a broader fraud scheme in which criminals impersonate FBI personnel and the Internet Crime Complaint Center (IC3) to target people who have already fallen victim to scams. According to an updated Public Service Announcement (PSA), scammers are using AI-generated videos, fake social media profiles, and spoofed websites to create a false sense of trust while attempting to steal personal and financial information.

The updated warning describes several exploitation tactics, including targeting previous scam victims, using artificial intelligence to create fictitious or misleading promotional materials, and building fake websites designed to collect personally identifiable information. The scammers falsely claim to be affiliated with government agencies or law enforcement and often promise to help victims recover lost funds.

FBI IC3 Scam Targets Previous Fraud Victims

In one version of the FBI IC3 scam, criminals create fake social media profiles and pages that impersonate FBI personnel. The goal is to lure previous scam victims into what the PSA describes as "re-targeting" scams.

After realizing they have been defrauded, victims may tell the original scammers they plan to report the incident to the FBI and submit an IC3 complaint. The victim is then contacted by someone pretending to be an FBI agent through platforms such as Facebook Messenger and Telegram.

The impersonator may send a link claiming to update an existing IC3 complaint. The link could contain malicious code or collect additional financial information, allowing criminals to further exploit the victim.

In other cases, scammers approach victims through email, phone calls, social media advertisements, or online forums. They claim to have recovered lost funds or offer assistance in recovering money. The FBI warning states these claims are a ruse designed to revictimize people who have already lost money.

AI-Generated Videos Promote Spoofed IC3 Websites

Another version of the scheme involves AI-generated videos or deepfakes featuring individuals impersonating FBI personnel. The videos are used on social media to promote spoofed versions of the official IC3 website.

One reported example involved an AI-generated video depicting a senior FBI leader encouraging users to submit complaints through a fake IC3 website. The spoofed site was designed to resemble the legitimate government website, but its functionality was limited to complaint submission.

The fake complaint form requested information including a user's name, phone number, email address, scam type, and estimated financial loss. After submission, the site provided a reference number and claimed someone would contact the individual.

How to Spot AI-Generated Videos and Fake Messages

The PSA warns that scammers can use AI-generated videos and cloned voices to impersonate company executives, law enforcement personnel, and other authority figures. These materials may be used during real-time video chats or private communications to convince victims they are speaking with a legitimate person.

People are advised to carefully examine email addresses, phone numbers, URLs, and spelling for subtle inconsistencies. Potential warning signs in manipulated images and videos include distorted hands or feet, unrealistic facial features, irregular faces, unusual accessories, inaccurate shadows, watermarks, unnatural movements, and voice call delays.

The FBI also advises people to be cautious when online content triggers strong emotions such as fear, anger, or disbelief. Users should verify surprising videos or images through reputable news sources or known official channels before responding.

IC3 does not maintain a social media presence and will not contact individuals directly through phone, email, social media, messaging apps, online chats, or public forums. The agency also does not recover funds for victims through Facebook or Telegram and will never request payment for fund recovery.

People seeking to file an IC3 complaint should type www.ic3.gov directly into their browser and verify that the website address ends in ".gov." Victims should avoid sponsored search results and suspicious links, and should never share sensitive information with websites they cannot verify.

Anyone who has fallen victim to the scam should report it through the legitimate IC3 website and provide details about the person or company involved, communication methods, financial transactions, and interactions with the scammer.

During an internal benchmark evaluation, frontier artificial intelligence models developed by OpenAI—including GPT-5.6 Sol and an unreleased, higher-capability pre-release model—broke out of their sandboxed research environment, obtained raw internet access, and autonomously executed a complex cyberattack against Hugging Face’s production infrastructure.

OpenAI officially categorizes the breach as an "unprecedented cyber incident, involving state-of-the-art cyber capabilities". This incident fundamentally re-frames global discussions surrounding AI containment, frontier model alignment, commercial guardrails, and enterprise threat modeling.

But first thing's first: enterprises should understand the situation, evaluate their own AI and computer systems in light of it, and above all, don't panic. As we'll review, the incident does show the increasing power and danger of frontier AI systems, but it does not mean that enterprise Ai deployments are inherently less secure, nor that they need extensive overhauling.

Anatomy of an Autonomous Breakout

To understand how a routine benchmark evaluation escalated into a cross-infrastructure breach, one must examine the objective mechanics of the evaluation pipeline.

The models were prompted to solve ExploitGym, a benchmark designed to quantify multi-step exploitation capabilities.

Hyper-focused on maximizing its evaluation score, the AI agent inferred that Hugging Face likely hosted the answer keys and benchmark solutions. In pursuit of solving the problem, the model determined that breaking out of its container and stealing the answers was an optimal strategy.

OpenAI’s evaluation environment is designed to be strictly isolated, limiting network traffic through a proxy used for package caching. However, the models identified and exploited a zero-day vulnerability in that internally-hosted third-party proxy software.

Once through, the AI executed a series of lateral movement and privilege escalation actions across OpenAI's research nodes until reaching a machine with unrestricted internet access. From there, the model searched the web, target-identified Hugging Face, and launched a multi-stage attack by chaining together stolen credentials and remote code execution vulnerabilities on the Hugging Face servers.

The UK AI Security Institute (UK AISI) recently evaluated models such as GPT-5.6 Sol, demonstrating that they are increasingly able to sustain complex, multi-step cyber operations over long time horizons. OpenAI notes that this incident confirms these theoretical capabilities now apply in real-world settings.

Rewinding the Tape on a Forensic Trap

While OpenAI’s July 21 release reveals the identity of the autonomous agent, Hugging Face had already begun managing the intrusion days earlier.

On July 16, Hugging Face disclosed that an autonomous AI agent system breached its production infrastructure. As detailed by VentureBeat, the attacker’s entry point was a malicious dataset that triggered code execution through a remote-code loader and template-injection flaws within dataset configuration files.

Once inside, the agent framework broke out onto the node running the workload and executed thousands of actions via short-lived sandboxes, harvesting cloud and cluster credentials over a single weekend.

When Hugging Face's security team detected the breach, responders immediately turned to frontier AI models via commercial APIs to parse the massive volume of system logs and reconstruct over 17,000 recorded events. Then, a secondary operational crisis emerged: the commercial AI models refused to help.

Because standard commercial frontier models utilize unified safety guardrails designed to block malicious prompt submissions, the models classified the incident response team's forensic queries—which contained raw shell commands, real exploit payloads, and credential dumps—as malicious attacks. Every forensic query submitted by the defenders was blocked outright.

"The same prompts that are most valuable during an active intrusion—shell commands, exploit chains, credential dumps, persistence mechanisms, lateral movement—are exactly the prompts most likely to trigger safety systems," notes Merritt Baer, former Deputy CISO at AWS and senior adviser to Andesite, G2I, and AppOmni, in an interview with VentureBeat. "As AI becomes embedded in security operations, this becomes an operational resilience issue rather than merely a model policy issue".

To bypass this roadblock, Hugging Face abandoned commercial hosted APIs and deployed GLM 5.2 —a state-of-the-art Chinese open-weight model released last month by z.ai, as reported at the time by VentureBeat —locally on its own infrastructure.

Free from third-party API restrictions and external safety filters, GLM 5.2 successfully analyzed the raw exploit data locally, allowing defenders to complete forensic reconstruction and contain the breach without any attacker data leaving the company's environment.

Industry Reaction and the Geopolitical Paradox

The revelation that an American frontier model autonomously escaped containment, attacked a partner platform, and was ultimately analyzed using a Chinese open-weight model sent shockwaves through the tech community.

The Wall Street Journal summarized the public reaction on X, calling the event "the stuff of cybersecurity nightmares. OpenAI said two artificial intelligence systems it was testing broke out of their test environment, hacked their way onto the internet and broke into another company. The victim was Hugging Face."

Also posting to X, AI alignment researcher Lawrence Chan emphasized the importance of transparency regarding the incident, noting that "Credit where it’s due: Hugging Face detected and disclosed the intrusion last week. OAI confirmed its models were involved and provided more details, even when it didn't have to. Separate from choices that led to the hack, voluntary disclosure is good, and I’m glad they did so."

Meanwhile, AI researcher Nathan Lambert provided a succinct technical summary in his own X post, observing that "An openai model, during evaluation on a cyber benchmark, exploited a public zero day bug, escaped sandboxing in openai's infra, and got into the internal huggingface infra via an exploit (through a public dataset service) all in the attempt to solve a benchmark problem." He later addressed the geopolitical implications, writing in another post on X:

"Rght now American companies need Chinese models to secure their cyber infra due to guardrails on closed models.

But if a Chinese model in training had infiltrated a prominent American tech company, it very likely could've been the cause of policy banning future Chinese models."

Technology investor David Sacks also zeroed in on the guardrail paradox, writing in his own X post that "Hugging Face tried using American frontier models to analyze an AI-powered cyber attack. But the guardrails blocked requests containing real exploit payloads so they switched to GLM 5.2 running locally. The guardrails actually impaired defensive security."

Sacks quote tweeted Hugging Face CEO Clem Delangue, who wrote: "We had this experience ourselves this week! Very scary to be guardrailed as a defender when you know attackers are likely bypassing".

5 Strategic Takeaways for Enterprise Tech Leaders Now

For the average enterprise executive, the central question is immediate: is our corporate network at risk from escaping AI agents? The short answer is no, not inherently.

1. Hugging Face occupies a unique position in the software ecosystem. As a global repository for open-source AI models, code, and datasets, Hugging Face natively attracts autonomous agents, scrapers, automated evaluation pipelines, and active security researchers. Furthermore, the model’s target selection was context-specific: GPT-5.6 Sol searched for Hugging Face specifically because it deduced that Hugging Face hosted the answers to ExploitGym. Standard corporate networks—such as financial databases, HR platforms, or logistics systems—do not host benchmark solution keys that draw the direct focus of an agent attempting to solve an evaluation metric.

2. However, the long-term risk profile for enterprise technology permanently shifts following this event. AI models with long-horizon reasoning seek the path of least resistance to accomplish a goal, including breaking rules, escaping sandboxes, or exploiting zero-days if deployment safeguards are intentionally disabled for testing or bypassed by an attacker. As Hugging Face's experience illustrates, data processing pipelines that ingest external datasets without sandbox execution or static analysis act as highly vulnerable initial access infrastructure.

3. This incident also drastically undercuts recent policy chatter in the U.S. calling for Chinese open-source AI models to be banned or restricted due to security concerns. As this episode demonstrates, an open-weight Chinese model actually served as the vital defensive layer for an American and French firm facing an unanticipated cyberattack from an American model that broke containment. Contrary to the official line from some U.S. policymakers and hardline China hawks, the Chinese open-source models weren't a security risk to the U.S. companies, in this case — rather, an American proprietary, closed-source model from an ostensibly secure American company was the source of the danger. Thus, any pressure U.S. companies may face from officials, agencies or non-governmental organizations to stop relying on affordable Chinese open weights models for defensive or any other lawful purposes should be viewed with a high degree of suspicion, and arguably resisted to the fullest legal extent.

4. Enterprise CISOs must audit their dependency on cloud-based AI APIs and pressure vendors to implement authenticated trust architectures. Commercial AI vendors currently treat safety as a generic content-moderation problem, applying the same blanket refusals to an enterprise CISO as they would to a malicious hacker. Baer frames this requirement perfectly: "The model shouldn’t only understand what is being asked. It should understand who is asking, why, and under what governance".

5. Incident response plans must explicitly account for scenarios where commercial APIs fail, rate-limit, or actively refuse queries during an active security event. Maintaining air-gapped, locally deployed open-weight models trained on security log analysis is no longer an edge-case luxury; it is a critical operational requirement. Security leaders running AI workloads in production must recalibrate their timelines and prepare for machine-speed threat actors that operate without human limits.

Summary

Successful exploitation of this vulnerability could allow for an attacker to cause a denial-of-service condition on the product.

The following versions of Rockwell Automation 1718-AENTR/1719-AENTR are affected:

• 1718/ 1719 Ex I/O 3.011 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Rockwell Automation reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-21

Legal Notice and Terms of Use

Summary

Successful exploitation of this vulnerability could allow for an attacker to cause a denial-of-service condition on the product.

The following versions of Rockwell Automation 1734 POINT I/O are affected:

• 1734 POINT I/O 3.023 

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Rockwell Automation reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-21

Legal Notice and Terms of Use

The post Druva brings backup, recovery and governance to AI workloads appeared first on Help Net Security.

Read more →

The post Druva brings backup, recovery and governance to AI workloads appeared first on IT Security News.

Release Date: July 20, 2026
Since v0.18.0: ~2,245 commits · ~1,065 merged PRs · ~2,465 files changed · ~300,000 insertions · ~36,000 deletions · ~3,300 issues closed · 450+ community contributors

The Quicksilver Release. Hermes is the messenger god, and this window we made him move like it. First-turn time-to-first-token dropped ~80% on every platform, reasoning streams live by default, the desktop app got a ~20-PR speed overhaul (14× faster streaming markdown, virtualized diffs, snappy session switching), and the TUI renders markdown incrementally. Around that speed spine: you can now manage your Nous subscription without leaving the terminal, plug Bitwarden and 1Password straight into Hermes, let smart approvals judge flagged commands for you by default, watch your subagents work live, and trust that a finished response survives a gateway crash thanks to a durable delivery ledger. This release also rolls up everything from the v0.18.1 and v0.18.2 infrastructure patch tags — those windows are fully documented here.

✨ Highlights

• Hermes got dramatically faster — first token in a fraction of the time — Cold-start "Initializing agent..." used to eat ~4.3 seconds before your first turn even reached the model; it's now ~0.9s, an ~80% cut that applies to the CLI, gateway, TUI, desktop, and cron alike. Round 2 attacked what you see while waiting: reasoning models now stream their thinking live by default (no more staring at a spinner for 30 seconds), and the response box paints per token instead of per line. If Hermes ever felt like it took a deep breath before answering, that breath is gone. (#59332, #59389 — @teknium1)

• The desktop app speed wave — 20+ targeted perf PRs — Long replies used to cost 14× more CPU in the markdown splitter than they do now; giant diffs froze the review pane until we virtualized it; switching sessions thrashes layout no more. Streaming no longer re-renders the sidebar and every tool row per token, profile backends pre-warm on hover intent, and boot-hidden panes mount at idle instead of on the cold-start critical path. The net effect: the desktop app feels like a native app under load, even with huge transcripts and busy agents. (#67154, #67818, #65898, #66033, #66747, #67742 and more — @OutThisLife)

• Manage your Nous plan from the terminal — /subscription and /topup — Changing your subscription used to mean a trip to the billing website. Now /subscription opens a full flow right in the TUI or classic CLI: see your plan and remaining allowance, preview exactly what an upgrade costs ("Pay $46.30 & upgrade now") or when a downgrade takes effect, and apply it — with scheduled-change banners and undo. The desktop app got a matching billing settings tab. Your wallet never has to leave the keyboard. (#51639, #61054, #61067 — @alt-glitch)

• Smart approvals are now the default — When Hermes wants to run a flagged command, an LLM reviewer now assesses it independently instead of asking you to approve every single one — and each verdict covers only that exact command, so a later command matching the same pattern gets its own review. Combined with the new user-defined deny rules (which block commands even under yolo mode) and /deny <reason> (which tells the agent why you refused so it course-corrects), day-to-day approval fatigue drops sharply without giving up control. (#62661, #59164, #54518 — @teknium1)

• Plug your password manager into Hermes — Bitwarden & 1Password secret sources — API keys no longer have to live in a plaintext .env. A new pluggable SecretSource interface lets Hermes fetch secrets from Bitwarden and 1Password (op:// references) at load time, with multiple vaults enabled simultaneously, deterministic precedence, conflict warnings, and per-variable provenance. This consolidated eleven competing community PRs into one orchestrated interface — future vault providers drop in as plugins. (#59498 — @teknium1, 1Password provider salvaged from @hwrdprkns)

• Watch your subagents work — live transcripts + durable background delegation — delegate_task dispatches now return live transcript files you can tail -f the moment the subagents launch: every tool call, result, and streamed reply, one human-readable log per child. And background delegation completions are now durable — if the process restarts mid-run, results are restored and delivered through an ownership-checked ledger instead of vanishing. Fan out a fleet, watch any worker live, and never lose the results. (#67479, #63494 — @teknium1)

• A finished answer can no longer be lost — the delivery-obligation ledger — If the gateway died between generating your response and confirming the platform actually delivered it, that answer used to be silently gone (and you'd paid for the turn). Final responses are now recorded in a durable ledger in state.db around the platform send and redelivered on the next boot — closing a P1 silent-loss window for Telegram, Discord, Slack, and every other channel. (#67181 — @teknium1)

• One gateway, many profiles — profile-based message routing — A single multiplexed gateway sharing one bot token can now route specific guilds, channels, or threads to different profiles — each with fully isolated config, skills, memory, and secrets. Point your work Discord server at the work profile and your hobby server at personal, from one bot. A second multiplex hardening wave means one misconfigured profile can no longer take down the whole gateway. (#64835 salvaging @Burgunthy, #65700, #60589 — @teknium1, @benbarclay + six salvaged contributors)

• New providers and the newest frontier models — Fireworks AI and DeepInfra land as first-class providers (Fireworks with cost estimation and a #2 slot in the provider picker), Upstage Solar joins via salvage, and the model catalogs picked up GPT-5.6 (Sol/Terra/Luna + Pro variants, wired end-to-end across every route), grok-4.5 (GA), moonshotai/kimi-k3, claude-fable-5 / claude-sonnet-5, and GA tencent/hy3 — plus LM Studio JIT model loading for local setups. (#62593, #63969, #61616 — @kshitijk4poor completing @rob-maron's #61578, #60887, #65913, #64541, #65472)

• Crank the thinking to max — new reasoning effort tiers and per-model control — Reasoning effort gained max and ultra levels (GPT-5.6 and Codex's top tiers), selectable everywhere from the CLI to the desktop, with sane clamping on providers with smaller scales. You can now also pin per-model reasoning-effort overrides in config, set per-slot effort in MoA presets (your advisors think hard, your synthesizer stays fast), and per-task effort for auxiliary models. Thinking depth is now a dial, not a global switch. (#62650, #64458, #64631, #64597 — @teknium1)

• Your sessions, your data — export everything — hermes sessions export now writes Markdown, Quarto, HTML, prompt-only, and even Hugging Face-ready trace formats, with the full filter surface (age, workspace, platform), an opt-in --redact secret-scrubbing pass, and compacted-session lineage stitched into one logical export. Pair with the new prune filters and bulk archive to keep your session store tidy. Your conversation history is a real dataset now, not a black box. (#60186 salvaging @web3blind, #60492, #60507, #59327 — @teknium1)

• Security hardening round — This window closed a long list of credential-surface gaps: Vertex credentials scoped away from subprocess env and through profile secret scopes, media/vision/image-gen local-file reads routed through one shared credential-read guard, a webhook body-size-cap sweep across every aiohttp server, bot-token redaction in Telegram transport errors, Fireworks token prefixes added to the redactor, six P1 browser/MEDIA/.env hardening PRs salvaged in one pass, and CI hardened against untrusted-ref interpolation. (#57660, #58709, #59215, #56582, #57842 — @teknium1, @srojk34, @kshitijk4poor, @jquesnelle)

⚡ Performance — the speed spine

First-turn latency (all platforms)

• ~80% TTFT cut — Discord capability detection off the critical path (token-keyed 24h disk cache + background refresh), Ollama probe skipped for known non-Ollama providers, agent-init blocking work removed; cold submit→dispatch ~4.3s → ~0.9s (#59332 — @teknium1)
• Perceived-latency round 2 — display.show_reasoning default ON (watch the model think instead of a spinner), per-token response-box painting with width-aware force-flush, prompt-build caching, mtime-cached timezone resolution (#59389 — @teknium1)
• Segment mixed tool batches to recover lost concurrency; drop per-call base64 re-serialization from request-size estimates (#64460, #67788 — @teknium1, @OutThisLife)

Desktop speed wave

• 14× less splitter CPU via incremental block lexing for streaming markdown; virtualized review-pane diffs (no more full-Shiki freeze); snappy session switching on large transcripts; killed the layout-thrash cascade on session switch (#67154, #67818, #65898, #66033 — @OutThisLife)
• Cut startup serialization + per-turn REST amplification; pre-warm profile backends and gateway sockets on hover intent; idle-mount boot-hidden panes; fast model picker + dialogs (#66747, #66347, #67857, #66470 — @OutThisLife)
• Stop per-token sidebar + tool-row re-renders during streaming; stop eager JSON.stringify of every tool's args/result; scope tool-diff subscriptions; batch sidebar session slices into one profile-DB pass; targeted file-tree revalidation; rAF-coalesced sash resizes (#67742, #67842, #67195, #67245, #67824, #67838, #67844 — @OutThisLife)
• Systematized perf benchmark harness with trustworthy cold-start + first-token measurement, replacing 12 one-off scripts (#67466, #67697 — @OutThisLife)

Everywhere else

• TUI renders streamed markdown incrementally per block (#67236 — @OutThisLife)
• Skill discovery cached by scan signature; snapshot manifest builds ~5× faster; text prefilter before AST parse in tool discovery (#61414, #61131, #63941 — @kshitijk4poor, @ethernet8023)
• Copy-on-write message prep instead of full deepcopy; model-metadata probe-cache cluster; gateway session.resume model + display history from one SELECT (#61133, #61368, #67247 — @kshitijk4poor, @OutThisLife)
• hermes update skips npm install when Node manifests are unchanged; dashboard session-list payloads trimmed + messages paginated (#61580, #60883 — @kshitijk4poor)
• Byte-stable gateway system prompts — pinned session-context render keeps the prompt cache alive across turns (#67403 — @kshitijk4poor)

🏗️ Core Agent & Architecture

Providers & models

• Fireworks AI provider with cost estimation + cached picker price columns, promoted to #2 in provider pickers (#62593, #65476, #65214 — @teknium1)
• DeepInfra hardened integration; Upstage Solar provider (#42231 salvage) (#63969, #64541 — @kshitijk4poor)
• GPT-5.6 (Sol/Terra/Luna + Pro) end-to-end — context lengths, native/Codex catalogs, pricing, compaction caps across every route (#61616 — @kshitijk4poor, building on @rob-maron)
• grok-4.5 (GA) catalog + reasoning allowlist; kimi-k3 on Nous Portal + OpenRouter (kimi-k2.x retired) + K3 discovery on the Kimi Coding endpoint; claude-fable-5 / claude-sonnet-5 / fugu-ultra curated; GA tencent/hy3 (#60887, #65913, #65922, #56617, #60943 — @teknium1)
• Catalog-labeled silent default (GLM-5.2) + bare-provider /model cost-safe routing; LM Studio JIT load mode; adaptive thinking for Kimi-family Anthropic endpoints (#64771, #65472, #67606 — @teknium1, @kshitijk4poor)
• GLM-5.2 native reasoning_effort controls; Gemini request-context improvements; extra HTTP headers for LLM API calls; per-client model routing on the API server (#58884, #61873 — @vishal-dharm, #57038, #57028 — @teknium1)
• Claude Sonnet 5 fully wired — curated lists, intro pricing, and metadata across every route (#67932 — @teknium1)
• Hide providers you don't use — enabled: false per-provider flag + excluded_providers config scrub unwanted providers from /model pickers and built-in resolution (#67971 — @teknium1)
• Bedrock catalog wave: real context-window probing from the live endpoint, 1M-context rows for current-gen Claude + Fable, geo-prefix parity, versioned profile-ID pricing, Opus 4.8/4.7 rows (#68007, #67977, #68005, #67976 — @teknium1)
• kimi-k3 rollout completed across Kimi-direct catalog surfaces with 1M context on canonical Kimi Coding endpoints (#68108 — @teknium1)
• Provider pickers: Qwen providers folded into one group row; collapsible provider groups in the desktop model picker; friendlier TUI model display grouping same-endpoint providers (#67758, #67904, #67908 — @teknium1)

Reasoning & MoA

• max + ultra effort levels across every surface and route (#62650 — @teknium1)
• Per-model reasoning_effort overrides via a unified resolution chokepoint; per-task auxiliary effort; per-slot MoA preset effort; session-scoped /reasoning in the CLI (#64458, #64597, #64631, #67946 — @teknium1)
• MoA: reference_max_tokens to cap advisor output and cut latency; per-preset fanout cadence (user_turn runs advisors once per user turn); stale presets surfaced without retries; half-filled preset saves rejected at the API boundary; aggregator resolves reasoning like an acting model (#56756, #57591, #64756 — @teknium1)

Delegation, approvals & the agent loop

• Live subagent transcripts + durable background completions (see Highlights) (#67479, #63494 — @teknium1)
• Smart approvals default; user-defined deny rules (block even under yolo); /deny <reason> relays the denial reason; plugin pre_tool_call approve action escalates to a human gate (re-landed with rule keys) (#62661, #59164, #54518, #60504 — @teknium1, @kshitijk4poor)
• Unified delegation concurrency caps (max_async_children deprecated); explain long provider waits on the live status line; deterministic tool-output risk exposure (#56955, #64775, #61793 — @teknium1)
• Codex: live TUI/desktop tool cards for the app-server runtime, commentary streamed as visible interim messages, compaction routed through thread/compact/start, max-output truncation recovery, oversized message ids dropped on replay, banked usage-limit resets via /usage reset (#66514, #66115, #60114, #58155, #62225 — @teknium1, @kshitijk4poor, @JoaoMarcos44, #64280 — @teknium1)
• Hooks: oversized hook-injected context spills to disk (#20468 — @teknium1)
• Vibe reactions — floating hearts on affection across CLI/TUI/desktop, token-free core detection (#62016 — @OutThisLife)

Secrets & config

• Pluggable SecretSource interface + Bitwarden & 1Password providers (see Highlights) (#59498 — @teknium1, @hwrdprkns)
• hermes config get / unset; warn on unknown root config keys + doctor deprecated-key reporting; display.timestamp_format (#65540, #67370, #40622 — @teknium1)
• Auxiliary model usage recorded per task in session accounting; conversation-scoped Nous Portal usage tags across aux/MoA/delegate calls; --usage-file JSON report for hermes -z (#65537, #65468, #59615 — @teknium1)

Sessions & compression

• Sessions export: Markdown/QMD/HTML/prompt-only/trace formats, HF upload, --redact, unified filters; full prune filter surface + bulk archive; CLI workspace filter + restore-cwd-on-resume (#60186, #60492, #60507, #59327, #63091 — @teknium1, @web3blind)
• Compression: preserve human intent and durable handoffs; retain prompt cache when memory is unchanged; flatten multimodal content for the summarizer keeping image handles; gateway compression routing integrity (#67275, #67916, #65046, #56868 — @kshitijk4poor, @teknium1)
• Gateway session metadata consolidated into state.db; routing index moved to state.db (sessions.json now an optional legacy mirror); exact API bytes persisted in an api_content sidecar (#58899, #59203, #67274 — @teknium1, @kshitijk4poor)

🌐 Gateway, Fleet & Relay

• Durable delivery-obligation ledger for final responses (see Highlights) (#67181 — @teknium1)
• Profile-based routing for inbound messages + multiplex hardening wave 2 + GATEWAY_MULTIPLEX_PROFILES override (see Highlights) (#64835, #65700, #60589 — @teknium1, @benbarclay + salvaged contributors)
• Per-session turn lease + conversation-scope funnel; unified session reset boundaries (reset sessions stay reset); truthful runtime readiness checks; per-channel model and system prompt overrides; per-session /model overrides persist across restarts (#67401, #65783, #62645, #56967, #57030 — @teknium1)
• Session auto-reset default off; /sessions search <query>; webhook payload filters + route scripts; platform HTTP event callback routing; configurable long-running status phrases (#60194, #57685, #60944, #65702, #58872 — @teknium1)
• Relay: generic OIDC client-credentials provisioning (NAS-free), routed profile carried from the connector wire source, channel context consumed from the connector; Nous auth forensics + nous_session_valid on /api/status for hosted self-heal; Docker re-seeds a terminally-dead Nous bootstrap session on boot (#60730, #60586, #64649, #59976, #59969, #59983 — @benbarclay)

📱 Messaging Platforms

• Inline choice pickers for /reasoning and /fast on Telegram, Discord, and Matrix — one-tap native buttons instead of typing (#65799 — @teknium1)
• WhatsApp: native Baileys polls (clarify renders as a poll), locations, rich inbound metadata; dashboard pairing flow (#58865, #60571 — @teknium1)
• Discord: recover messages missed during reconnect; auto-created threads renamed to generated session titles; configurable interactive view timeout; opt-in owner mentions on exec-approval prompts; optional admin-only gate for approval buttons (#66149, #60187, #60230, #60493, #51751 — @teknium1)
• Slack: live per-tool status line (#67080 — @teknium1, salvaging #62007)
• Telegram: per-topic free-response allowlist; Google Chat clarify prompts rendered as cards (#65543, #65546 — @teknium1)
• Voice: stt.echo_transcripts toggle; MEDIA: captions attached to the media bubble on standalone sends; display.tool_progress: log option (#58859, #61415, #57014 — @teknium1, @kshitijk4poor)

🖥️ Hermes Desktop App

• Contribution-driven shell on a layout-tree model — panes, zones, and layouts as data; plugin-scoped i18n locale bundles followed (#60638, #67303 — @OutThisLife)
• Capabilities page — Skills/Tools/MCP + Hub in one place, with responsive overlay nav; CLI/dashboard parity for skills hub, MCP test/toggle/catalog, maintenance ops, log filters; five UX fixes from live testing (#57590, #57441, #67482 — @OutThisLife, @teknium1)
• Hermes Cloud connection mode (salvage of #55402); soft gateway switch + gateway-settings polish; terminal execution backend picker with health probes (#61912, #61916, #67203 — @OutThisLife, @teknium1)
• Keybind hint tooltips + keybinds settings tab + unified worktree dialog; base-branch picker for new worktrees; green unread dot for background-finished sessions; background-task sidebar indicators; grouped tool calls across text-less messages; auto-scrolling window for long tool-call runs (#65204, #62243, #65109, #65174, #61147, #57913 — @ethernet8023, @OutThisLife)
• Session + project color system (inherit from project, per-session override, shared across sidebar/tabs); unified active-project identity in chat status; workspace path status action (#67469, #67681, #67282, #63086 — @OutThisLife)
• Declarative memory-provider panel + full-config modal; config-defined TTS/STT providers + xAI TTS params; custom endpoint settings; per-job cron model picker; profile-aware approval mode control; UI scale setting; Ctrl/Cmd+wheel zoom; chat backdrop toggle; /journey opens the memory graph overlay (#67206 salvaging @erosika, #67209, #67759 — @austinpickett, #67472, #63520, #60457, #67029, #64598, #57267 — @teknium1, @OutThisLife)
• Full TypeScript conversion of the desktop tree (#57855 — @ethernet8023)

📊 Web Dashboard

• Memory provider switching; safe session import flow; WhatsApp pairing; Discord-specific toolsets editable from the web UI; clarified manual Telegram bot setup (#60569, #63699, #60571, #65361, #64636 — @teknium1, @kshitijk4poor, @shannonsands)
• Terminal keep-alive + reattach for dashboard chat sessions; heavy turns isolated in a compute host; paste/drop images into Chat; browser.headed schema toggle; profile + gateway topology on /api/status; mobile/hosted OpenAI OAuth login (#60515, #65895, #61929, #67046, #60537, #61330 — @teknium1, @OutThisLife, @benbarclay)
• hermes serve is a true headless backend (no web UI build/mount) (#55923 — @OutThisLife)

🧰 CLI & TUI

• /subscription + /topup terminal billing (see Highlights) (#51639 — @alt-glitch)
• /model --once — one-turn model override that reverts automatically (#67113 — @teknium1, salvaging #29923)
• Stacked slash-skill invocations — /skill-a /skill-b do XYZ loads both skills in order (Claude Code port), with autocomplete + ghost text (#57987, #58763 — @teknium1)
• --safe-mode troubleshooting flag; uninstall dry-run; TLS failures fail fast with fix hints; /compact alias + preview flags; pip/Homebrew installs warned unsupported (#45300, #60111, #57992, #57029, #57225 — @teknium1, @ethernet8023)
• TUI: model picker refresh support; custom skill bundles dispatched as agent turns; banner sizes skills display to terminal width (#59782 — @helix4u, #62859 — @Adolanium, #40624 — @teknium1)
• Hermes Console REPL + perf follow-ups; hermes curator usage all-skills view; entry-point plugins surfaced in hermes plugins list (#57781 — @kshitijk4poor, #36727, #40623 — @teknium1)

🔧 Tool System, Skills & MCP

• MCP: mcp__server__tool naming convention; server log notifications surfaced in agent.log; hosted OAuth completed across Dashboard + Desktop; configurable redirect_uri/redirect_host for proxied/WAF setups; OAuth callback port races closed; Blender added to the MCP catalog with a curated 4-tool default (#52750, #57416, #66151, #65610, #65622, #64463 — @teknium1, @benbarclay)
• Skills: security/unbroker (autonomous data-broker removal) + blind opt-out hardening; unreal-mcp companion skill; blender-mcp reworked around the catalog entry; humanizer pattern expansion; mcp-oauth-remote-gateway optional skill (#57438, #57902, #65989, #64715 — @SHL0MS, #65066, #65486 — @teknium1)
• Browser: full snapshots stored on truncation, eval denylist opt-in; computer_use follows cua-driver's verify→escalate ladder (#65923, #67123 — @teknium1)
• Kanban: modal create-task dialog + editable board project directory; Done-card results made obvious; grab-to-pan board scrolling; attachment toolset + CLI with SSRF-guarded URL fetch; project directory captured at board creation (#66333, #63638, #60226, #65698, #63249 — @teknium1)
• Cron: durable execution audit history; one-shot stale-removal race fixed; run-claim TTL derived from HERMES_CRON_TIMEOUT (#61791 — @teknium1, #62014 — @PRATHAMESH75, #59567)
• mem0: self-hosted dashboard backend + recall tuning + setup-wizard mode (#56943, #60494 — @kshitijk4poor, @teknium1)
• Image gen: Codex image inputs; unsupported Codex image accounts classified; tool args recursively normalized by schema (cline port) (#57017, #63627, #52220 — @teknium1, @kshitijk4poor)

🔒 Security & Reliability

• Vertex: credential/project/region resolution through the profile secret scope; VERTEX_CREDENTIALS_PATH/GOOGLE_APPLICATION_CREDENTIALS stripped from subprocess env (#56680, #56582 — @srojk34)
• Six P1 hardening PRs salvaged in one pass — browser guards, MEDIA anchoring, .env lockdown, delegate ACP transport (#57660 — @teknium1)
• Media/vision/image-gen local-file reads routed through the shared credential-read guard; native image routing guarded by file-safety policy; unified image-source resolver + terminal-backend confinement (#58709, #58752, #57890 — @teknium1)
• Webhook body-cap sweep: explicit client_max_size on 3 uncapped aiohttp servers + completion sweep; Raft chunked-request body limit; timestamp-bound V2 webhook signatures (#59180, #59215, #58902, #58508 — @teknium1, @srojk34)
• Redaction: Fireworks token prefixes + Telegram transport errors; env-lookup false positives fixed for KEY=value and JSON/YAML config fields; bot tokens scrubbed from Telegram connect/send errors (#58501, #58534, #58915, #58893 — @teknium1)
• computer-use: subprocess env sanitized across all five cua-driver spawn sites (#58889, #59165 — @teknium1)
• Dashboard: managed-files credential guard widened past .env + dir-tree gap closed; OAuth token TOCTOU closed with atomic 0o600 writes; stale dashboards can't recreate deleted profiles (#58222 — @kshitijk4poor, #60236 — @teknium1, #49435 — @LeonSGP43)
• CI: untrusted refs passed through env, not run: interpolation; JS/TS tests wired into CI with source-regex tests banned; js-autofix pushes via PR instead of direct-to-main (#57842 — @jquesnelle, #60707, #65186 — @ethernet8023)
• Docker: terminal network toggle with full-path coverage; Git Bash Mandatory-ASLR install failures detected; Windows updater console hidden during handoff (#59149 — @teknium1, #64651, #66040 — @helix4u)
• Anthropic: request-local clients so the stale/interrupt watchdog never corrupts SQLite; per-profile OAuth file; OAuth login 429 fixed (UA must not be claude-code/) (#67238 — @OutThisLife, #59339, #58178 — @teknium1)
• Gateway/agent: tool_call_id deduplicated across pre-API sanitizers; background review inherits parent reasoning_config for Anthropic cache parity; /new memory extraction moved off the command path (#58350, #64379, #61139 — @teknium1, @kshitijk4poor)

🔁 Reverted in this window (for the record)

• iron-proxy credential-injection egress firewall (#30179 → reverted in #58489) — not shipping in this release
• dynamic-workflow orchestration skill (landed, then reverted) — not shipping
• memory provider-actions extension point (landed, then reverted) — not shipping
• Note: the plugin pre_tool_call approve escalation was reverted mid-window but re-landed in #60504 and ships in this release.

👥 Contributors

450+ people contributed to this release (via commits, co-author trailers, and salvaged PRs) — the biggest contributor window yet. Thank you, all of you.

Core team

• @teknium1 — release lead; TTFT perf wave, delivery + delegation durability, smart approvals, SecretSource, gateway multiplex + profile routing, sessions export, security round, and a ~290-PR community salvage burn
• @OutThisLife — desktop app (the speed wave, layout-tree shell, Capabilities page, session colors, vibe reactions, TUI incremental markdown, perf harness)
• @kshitijk4poor — GPT-5.6 end-to-end, DeepInfra + Upstage Solar providers, perf cluster, compression integrity, mem0, dashboard guards
• @ethernet8023 — CI overhaul (JS/TS tests wired in, autofix-via-PR, python speedups), desktop keybinds/worktrees/status indicators, full desktop TypeScript conversion
• @benbarclay — relay OIDC provisioning, gateway multiplex override, Nous auth self-heal, hosted MCP OAuth groundwork
• @alt-glitch — terminal billing (/subscription, /topup), desktop billing tab
• @helix4u — desktop provider/model UX, TUI model picker refresh, Windows install/updater hardening
• @austinpickett — desktop custom endpoint settings
• @SHL0MS — unbroker + unreal-mcp skills, humanizer expansion

Top community contributors

• @srojk34 — security hardening: Vertex credential/project/region scoping through the profile secret scope, subprocess env stripping, Raft chunked-request body limits
• @HexLab98 — 11 fixes across MCP capability gating, Windows installer PATH, desktop cron editing, gateway systemd warnings
• @UnathiCodex — desktop stability: zoom across display moves, LaTeX rendering, resume-stall and runtime-readiness fixes
• @xxxigm — <think> leak fix after thinking-only retry flush, dashboard auth/theme/PTY fixes
• @erosika — desktop declarative memory-provider panel + honcho recall/timeout correctness
• @Frowtek — credential security: master stores never mounted into skill sandboxes, live-transcript redaction, dashboard api_key precedence
• @necoweb3 — browser private-page CDP guard, cron one-shot liveness, gateway compression fail-closed
• @DavidMetcalfe — desktop updater version pill, Local/custom endpoint exposure, sidebar collapse behavior
• @shannonsands — dashboard: mobile channel setup, Discord toolsets from web UI, Telegram setup clarity
• @vishal-dharm — Gemini request-context improvements
• @PRATHAMESH75 — cron one-shot stale-removal race, dashboard multiplex port-binding guard
• @alelpoan, @embwl0x, @Adolanium, @giggling-ginger, @Drexuxux, @frizikk, @JoaoMarcos44, @wesleysimplici, @LeonSGP43, @pierrenode, @simpolism, @MorAlekss, @r266-tech, @WadydX, @nv-kasikritc — targeted fixes across desktop, TUI, gateway, cron, webhook, nix, and browser surfaces
• Salvaged-work authors whose PRs were cherry-picked with credit this window: @Burgunthy (profile routing), @web3blind (sessions export), @hwrdprkns (1Password), @Christopher-Schulze, @Ahmett101, @sjiangtao2024, and many more — see the salvage PR bodies for full attribution

All contributors

@0-CYBERDYNE-SYSTEMS-0, @0disoft, @0xbyt4, @100yenadmin, @17324393074, @2751738943, @8294, @abhibansal-sg,
@adambiggs, @Adolanium, @aeyeopsdev, @aguung, @AhmetArif0, @Ahmett101, @ai-ag2026, @AIalliAI, @ajzrva-sys,
@alastraz, @alelpoan, @alex-fireworks, @alex-heritier, @alex107ivanov, @AlexFucuson9, @Alix-007,
@allenliang2022, @Almurat123, @AlsayedHoota, @alt-glitch, @alvarosanchez, @amanning3390, @AmAzing129,
@AndreasHiltner, @andrewhomeyer, @annguyenNous, @ansel-f, @antydizajn, @arminanton, @arnispiekus, @asimons81,
@asscan, @ats3v, @austinlaw076, @austinpickett, @avifenesh, @aydnOktay, @Bartok9, @bautrey, @bbednarski9,
@bbopen, @benbarclay, @bigstar0920, @binhnt92, @bird, @Black0Fox0, @BlackishGreen33, @bo.fu, @brendandebeasi,
@briandevans, @BROCCOLO1D, @Bruce-anle, @brunz-me, @Burgunthy, @bytesnail, @catbearlove1-lang, @Cdddo,
@cgarwood82, @CharmingGroot, @chouqin, @Christopher-Schulze, @claudlos, @CocaKova, @Code-suphub, @CodeForgeNet,
@craigdfrench, @CrazyBoyM, @crazywriter1, @cresslank, @cruzanstx, @cyrkstudios, @danilofalcao,
@datachainsystems, @DatTheMaster, @davidb73-hub, @davidgut1982, @DavidMetcalfe, @davidrobertson,
@deacon-botdoctor, @DECK6, @deepujain, @derek2000139, @designnotdrum, @deusyu, @devatnull, @devorun,
@dexhunter, @dfein38347g, @Dhravya, @DictatorBacon, @digitalbase, @dlkakbs, @dmabry, @DNAlec, @dodo-reach,
@doncazper, @dorokuma, @doxe0x, @Drexuxux, @dschnurbusch, @Dusk1e, @EdderTalmor, @egilewski, @elashera,
@Elektrofussel, @eliteworkstation94-ai, @embwl0x, @emo-eth, @emozilla, @enzo-adami, @Epoxidex, @ErnestHysa,
@erosika, @esthonjr, @ethernet8023, @evefromwayback, @evelynburger, @F4TB0Yz, @falkoro, @fanyangCS, @firefly,
@fjlaowan1983, @flewe, @flo1t, @flow-digital-ny, @floze-the-genius, @frizikk, @Frowtek, @FuryMartin,
@fyzanshaik, @gauravsaxena1997, @geoffreybutler94, @georgedrury, @gigakun3030, @giggling-ginger,
@Git-on-my-level, @gitcommit90, @githubespresso407, @gnodet, @GottZ, @Gridzilla, @grimmjoww578, @gumclaw,
@Gutslabs, @HaiderSultanArc, @harjothkhara, @heathley, @hejuntt1014, @helix4u, @HeLLGURD, @hellno,
@herbalizer404, @HexLab98, @hmirin, @Hopfensaft, @Hotragn, @hsy5571616, @huanshan5195, @HumphreySun98,
@hwrdprkns, @hydracoco7, @hydraxman, @iamlukethedev, @iborazzi, @IgorGanapolsky, @iizotov, @ildunari,
@infinitycrew39, @IpastorSan, @irresi, @isfttr, @isheng-eqi, @itsflownium, @izumi0uu, @Jaaneek, @JacketPants,
@jaisup, @jakelongvu-bot, @jakepresent, @jaketracey, @JAlmanzarMint, @JasonFang1993, @jbbottoms, @jcjc81,
@JiaDe-Wu, @Jiahui-Gu, @Jigoooo, @jingsong-liu, @jneeee, @JoaoMarcos44, @joelbrilliant, @John-Lussier, @jplew,
@jtstothard, @juniperbevensee, @Jupiter363, @justinschille, @k4z4n0v4, @kaishi00, @karfly, @kartik-mem0,
@kavioavio, @KCAYAAI, @kenyonxu, @keslerm, @kevinrajaram, @knoal, @kocaemre, @kohoj, @konsisumer, @krowd3v,
@kshitijk4poor, @kuangmi-bit, @kubolko, @kyssta-exe, @Kyzcreig, @l0h1nth, @labsobsidian, @laurinaitis,
@LavyaTandel, @lawyer112, @lemonwan, @LeonSGP43, @lEWFkRAD, @linfeng961, @liuhao1024, @liuwei666888, @ljy-2000,
@loes5050, @logical-and, @LoicHmh, @loongfay, @lord-dubious, @lost9999, @lucasfdale, @lucaskvasirr,
@luxuguang-leo, @ly-wang19, @m0n5t3r, @m1qaweb, @M1racleShih, @MaartenDMT, @mahdiwafy, @MaheshBhushan,
@ManniBr, @marcelohildebrand, @marcolivierlavoie, @markoub, @MarkVLK, @Marxb85, @matantsevs,
@maxpetrusenkoagent, @mbac, @mdc2122, @mguttmann, @Mibayy, @michaelHMK, @mijanx, @minchang, @momomojo,
@MorAlekss, @morluto, @msh01, @mssteuer, @mvanhorn, @nanami7777777, @nankingjing, @necoweb3, @neo-claw-bot,
@neoguyverx, @nicha16, @nikshepsvn, @nima20002000, @nnnet, @NousResearch, @nullptr0807, @nv-kasikritc,
@okisdev, @OmarB97, @ooiuuii, @ooovenenoso, @oppih, @Osraka, @ostravajih, @otsune, @OutThisLife, @OYLFLMH,
@patrick-muller, @pdmartins, @pedrommaiaa, @Peterskaronis, @petrichor-op, @pgregg88, @pierrenode, @pixel4039,
@plcunha, @pnascimento9596, @Polyhistor, @PRATHAMESH75, @professorpalmer, @Punyko8, @Que0x, @Qwinty,
@r0gersm1th, @r266-tech, @rabadaki, @ragingbulld, @RainbowAndSun, @rainbowgore, @randimt, @rarf, @rasitakyol,
@rayjun, @raymondyan-zhijie, @re-ITRT, @RenoMG, @Rival, @RKelln, @rlaehddus302, @rob-maron, @rodboev,
@roryford, @rungmc357, @ruslanvasylev, @s0xn1ck, @s905060, @s96919, @sahibzada-allahyar, @sahil-shubham,
@Sahil-SS9, @SahilRakhaiya05, @sam7894604, @SAMBAS123, @samrusani, @sanidhyasin, @sasquatch9818, @sberan,
@ScotterMonk, @seagpt, @sebastianlutycz, @SemonCat, @setclock, @shannonsands, @sharziki, @shashwatgokhe,
@SHL0MS, @shuangxinniao, @SilentKnight87, @simplast, @simpolism, @SiteupAgencia, @sjiangtao2024, @sk-holmes,
@slow4cyl, @smtony, @soddy022, @Soju06, @solyanviktor-star, @SongotenU, @spiky02plateau, @sprmn24, @SquabbyZ,
@srojk34, @ssiweifnag, @stantheman0128, @StellarisW, @stephenschoettler, @suninrain086, @superposition,
@Supersynergy, @sweetcornna, @szafranski, @tanmayxchoudhary, @tarunravi, @tcconnally, @terry197913, @Thatgfsj,
@thegoodguysla, @thestudionorth, @TheTom, @TinkerOfThings, @tjboudreaux, @tjp2021, @Tortugasaur, @Tosko4,
@Tranquil-Flow, @trevorgordon981, @trismegistus-wanderer, @tt-a1i, @tuancookiez-hub, @TurgutKural, @Umi4Life,
@UnathiCodex, @unsupportedpastels, @uzaylisak, @valda, @vampyren, @veradim, @victor-kyriazakos, @virtualex-itv,
@vishal-dharm, @Vissirexa, @vizi0uz, @vkkong, @vKongv, @VolodymyrBg, @vortexopenclaw, @VrtxOmega, @WadydX,
@waroffchange, @waseemshahwan, @web3blind, @webtecnica, @wesleion, @wesleysimplicio, @williamumu,
@WilsonKinyua, @wxy-nlp, @wyuebei-cloud, @x7peeps, @x9x9x9x9x9x91, @xuezhaolan, @xxxigm, @ya-nsh, @yatesjalex,
@ygd58, @yingliang-zhang, @yinkev, @YLChen-007, @yu-xin-c, @yungchentang, @zapabob, @zccyman, @zeapsu,
@ziliangpeng, @zwcf5200, @zzpigpinggai

Also: bo.fu, Paulo Henrique, kyssta-exe 25470058+kyssta-exe.fu, Paulo Henrique, kyssta-exe 25470058+kyssta-exe.

Full Changelog: v2026.7.1...v2026.7.20

Warning

We DO NOT own the domain ilspy[.]org See #3709
Download ILSpy only from GitHub Releases!

This release is based on .NET 10.0. Please make sure that you have it installed on your machine beforehand.

Note for Mac users: see https://github.com/icsharpcode/ILSpy/wiki/Build-Artifacts#running-the-macos-artifact because the ILSpy.app is neither signed nor notarized.

Avalonia Cross Platform Port

• PR #3755: Avalonia 12 Port and Removal of the WPF UI
• PR #3759: Metadata explorer cleanup, flags-filter fixes, and WPF row-details parity
• PR #3766: Round-trip the legacy WPF SessionSettings shape
• PR #3768: Build, test, and package ILSpy on Linux and macOS in CI
• PR #3861: Show text-based resources inline with syntax highlighting
• PR #3875: Avalonia 12.1
• PR #3876: Keep BAML decompilation working when WPF assemblies are missing

New Features

• PR #3847: Unpack !AvaloniaResources into per-file resource tree nodes
• PR #3801: Fix #3797: resolve ilspycmd -t type names with fuzzy matching
• PR #3789: Add a bookmarks feature for the decompiled C# view
• PR #3786: Add omnibar breadcrumb and search bar above the decompiled code
• PR #3769: Make the override modifier a link to the overridden member
• PR #3762: Add Open from NuGet feed dialog for browsing and opening packages

User Interface

• PR #3857: Fix #2078: Generic local functions not highlighted properly
• PR #3855: Fix #3845: Add option to expand XML documentation comments
• PR #3814: Toggle the fold under the right-click, not at the caret
• PR #3812: Syntax-colour analyzer signatures with bold type names (#2164)

Enhancements

• PR #3872: Decompile await on dynamic expressions
• PR #3837: Fix #3804: decompile foreach over inline array
• PR #3791: Fix #3777: decompile runtime async without a separate C# 15 setting
• PR #3843: Bound XamarinCompressedFileLoader against crafted XALZ headers
• PR #3842: Bound WebCilFile section access against mapped-view length
• PR #3841: Harden BAML reader against crafted-resource crashes
• PR #3816: Allow overriding an assembly's target framework for reference resolution
• PR #3840: Bound .rsrc resource-tree parsing against crafted input
• PR #3838: Guard against OOB read when bundle signature is at file start
• PR #3818: Display the IL 'tail.' prefix in C# output
• PR #3808: Migrate the VS extension to an SDK-style VSIX (dotnet build) and retire the VS2017/2019 add-in
• PR #3802: Fix #3799 and three related stackalloc initializer decompilation defects
• PR #3780: Compute public-key tokens with a managed SHA-1

Documentation

• PR #3868: CONTRIBUTING.md for the AI era
• PR #3870: Add decompiler architecture document

Testing / Infrastructure

• PR #3771: Run the decompiler test suite on Linux
• PR #3788: Use cross-platform separators for the FSharp.Core.dll test path
• PR #3807: Adopt SDK default Compile items in Decompiler and Decompiler.Tests
• PR #3815: Verify generated PDBs against the compiler's breakpoint map (PdbGen fixtures previously passed vacuously)
• PR #3836: Don't assert decompiled local types match the signature
• PR #3839: Add fine-grained debug steps with highlighting for C# and ILAst
• PR #3849: Set OpenSSL SHA1 flag in build scripts
• PR #3859: Add test coverage for untested corners of implemented language features
• PR #3874: Upload TestCases folder as artifact when CI tests fail

Contributions

• PR #3851: Fix #3850: recover ReadOnlySpan array literals from the legacy lazy cache — @sailro, thank you!
• PR #3878: Handle negative dictionary capacity in string switch transform — @ds5678, thank you!
• PR #3828: Fix #3826: wrap an overflowing constant subexpression in unchecked() — @sailro, thank you!
• PR #3831: Fix #3825: reconstruct async iterators with [EnumeratorCancellation] and await in finally — @sailro, thank you!
• PR #3830: Fix #3827: keep the while-loop for a ref local used after the loop (avoid an uninitialized hoisted ref decl) — @sailro, thank you!
• PR #3823: Fix #3821: keep ref-struct conditional as if/return, not ?. / ?? (CS8978) — @sailro, thank you!
• PR #3822: Fix #3820: decompile dynamic ~ as ~x instead of an unsupported-opcode error — @sailro, thank you!
• PR #3796: Fix decompiler tests project inside VS — @DoctorKrolic, thank you!
• PR #3787: dev: fix editorconfig parsing on some editors — @mochaaP, thank you!
• PR #3879: Fix the "Use nested namespace structure" option — @ds5678, thank you!

Bug Fixes

• PR #3881: Reject negative char index in the length-and-char string switch
• PR #3866: Fix #3475: Emit 'true ? null : new { ... }' for null of anonymous type
• PR #3864: Fix #3860: Avoid 'out var' if the variable recurs in the argument list
• PR #3873: Fix dynamic event-assignment decompilation leaking is-event opcode
• PR #3863: Simplify hoisted null-guard fold to reference-type constructor chains
• PR #3852: Fix #3824: fold a hoisted argument null-guard at the ILAst level
• PR #3832: Fix #3754: omit async stepping info for runtime-async methods
• PR #3806: Fix Export NullReferenceException for images/resourcexsd.baml
• PR #3792: Fix #3774: keep field initializers when decompiling a static ctor alone
• PR #3790: Skip missing session assemblies when navigating on launch
• PR #3776: Escape reserved Windows device names in output file names

For a full list of changes click here.

The move marks a striking philosophical turn for a company still defined, in many boardrooms, by a 2019 data breach that compromised the personal information of roughly 106 million people across the United States and Canada and ultimately cost the bank an $80 million federal fine.

Capital One is not simply releasing another vulnerability scanner. VulnHunter introduces what the company calls an "attacker-first forward analysis" — a workflow in which the tool begins at the points where a real adversary would enter a system, such as APIs, network messages, or file uploads, and reasons forward through the application's logic to determine whether an exploit path actually survives the code's existing defenses. Conventional scanners typically work in reverse, flagging a dangerous-looking code pattern and then searching backward for a hypothetical attacker. That approach, security practitioners widely acknowledge, buries engineering teams under avalanches of false positives.

VulnHunter attacks that problem head-on with a second innovation: a built-in "falsification engine" that tries to disprove its own findings before a developer ever sees them. After the tool surfaces a potential vulnerability, a structured reasoning workflow hunts for logical gaps, unsupported assumptions, and conditions that would prevent the attack from succeeding. Only findings the engine fails to rule out reach a human reviewer — and when they do, VulnHunter delivers not just an alert but a full explanation of the exploit path and a proposed code fix ready for engineering review.

The tool currently runs on Anthropic's Claude Opus 4.8 model inside a Claude Code environment, though Capital One says the framework has the potential to work across other foundation models and coding harnesses.

The 2019 breach that reshaped how Capital One thinks about cybersecurity

To understand why Capital One chose to open-source a tool this consequential, you have to understand the scar tissue.

On July 19, 2019, Capital One disclosed that an outside individual — later identified as a former Amazon Web Services employee named Paige Thompson — had gained unauthorized access to names, addresses, self-reported income, Social Security numbers, and linked bank account numbers belonging to credit card customers and applicants. The breach, which Capital One says occurred on March 22 and 23, 2019, was discovered only after an external security researcher flagged a configuration vulnerability through the company's Responsible Disclosure Program on July 17 of that year.

The damage was sweeping. Approximately 100 million people in the United States and 6 million in Canada were affected. Roughly 140,000 Social Security numbers, about 80,000 linked bank account numbers, and approximately 1 million Canadian Social Insurance Numbers were compromised. The FBI arrested Thompson, and the government stated it believed the data had been recovered with no evidence of fraud. But the reputational and regulatory toll was enormous.

In August 2020, the Office of the Comptroller of the Currency fined Capital One $80 million, finding that the bank had failed to adequately identify and manage risks as it migrated significant technology operations to the cloud. As Reuters reported at the time, the OCC's consent order cited insufficient network security controls, inadequate data loss prevention measures, and a board that failed to hold management accountable when internal auditing surfaced problems. The OCC also ordered Capital One to overhaul its operations and submit new cybersecurity plans for regulatory review.

The incident became an industry case study in the dangers of moving fast with new technology. As CyberScoop reported in July 2019, a cybersecurity executive at a competing financial company observed that the breach "could be the result of trying too many new things and forcing them through." Capital One's own CEO, Richard D. Fairbank, acknowledged the gravity of the moment. "While I am grateful that the perpetrator has been caught, I am deeply sorry for what has happened," Fairbank said at the time. "I sincerely apologize for the understandable worry this incident must be causing those affected and I am committed to making it right."

How Capital One rebuilt its security reputation through open-source investment

What followed was not a retreat from technology but a doubling down — with security explicitly at the center.

Capital One had declared itself an "open-source first" company in 2015 as part of a broader technology transformation that began over a decade ago. After the breach, the company accelerated its investments in software supply chain security, open-source governance, and AI-driven defense. In August 2022, Capital One joined the Open Source Security Foundation as a premier member, earning a seat on the organization's Governing Board. Chris Nims, then EVP of Cloud & Productivity Engineering, framed the move as a natural extension of the company's operating philosophy. "As a highly-regulated company, we are seasoned in managing compliance and governance and advocate for standardization, automation and collaboration," Nims said in the OpenSSF announcement.

Behind that public commitment lay a substantial operational apparatus. Capital One's Open Source Program Office, now in its third iteration, manages open-source usage, contributions, and community building across the enterprise. The company has released more than 25 open-source projects and made over 2,000 contributions to approximately 135 external open-source projects, according to the company's own disclosures. Those efforts address not just code dependencies but the entire software development lifecycle — DevSecOps tools, infrastructure, and the collaborative environments, both internal and external, that shape how software gets built and shipped.

Nureen D'Souza, the director who leads Capital One's OSPO, has spoken publicly about the philosophy underpinning this work. At cdCon 2022, D'Souza described a "company-wide culture with security ingrained" that allows developers to focus on innovation rather than maintenance chores, as reported by SD Times. The OSPO's charter emphasizes three pillars: standardization of open-source processes, automation of security policies throughout the delivery pipeline, and ecosystem sustainability through upstream contributions to the foundations and projects the company depends on.

VulnHunter is the most consequential product of that multi-year effort — and the clearest signal yet that Capital One views open-source collaboration not as charity but as a competitive security strategy. The company argues that modern software supply chains are so deeply interconnected that a single vulnerability in a widely used open-source component can cascade across thousands of enterprises simultaneously. Proprietary defenses, no matter how sophisticated, cannot address a problem that is fundamentally communal. By releasing VulnHunter under a permissive license, Capital One invites the global security research community to stress-test, extend, and improve the tool — effectively crowdsourcing its own defense infrastructure while strengthening the broader ecosystem.

Inside VulnHunter's three-stage AI engine for finding exploitable code

For engineering leaders evaluating VulnHunter, the technical architecture is where the tool's ambitions become concrete. The workflow unfolds in three distinct stages.

In the first stage — attacker-first forward analysis — VulnHunter begins at the points where an external adversary would interact with a system: API endpoints, network message handlers, file upload interfaces. From each entry point, the tool reasons forward through application logic, tracing data flows, transformations, and internal security checkpoints to determine whether an attacker can actually reach a dangerous code path. This approach mirrors how a skilled penetration tester would probe a system, but automates the process at a scale no human team could match.

The second stage is where VulnHunter departs most sharply from conventional scanners. After identifying a potential vulnerability, the falsification engine runs a structured reasoning workflow designed to disprove its own conclusion. It searches for assumptions that do not hold, logical gaps in the exploit path, and environmental conditions that would prevent an attack from succeeding. Findings that fail this internal challenge are discarded before any developer sees them. Capital One's explicit goal is to shift the developer's burden away from triaging false alarms — a perennial pain point that erodes trust in security tooling and slows development velocity.

In the third stage, vulnerabilities that survive the falsification engine trigger an evidence-backed remediation workflow. VulnHunter gathers supporting evidence across the codebase, maps the complete surviving exploit path, explains the defect and the specific capabilities an attacker would gain, and generates targeted code changes for engineering review. The output is not a generic advisory but a concrete, context-aware patch proposal.

Capital One says it validated VulnHunter internally before release, running it across thousands of repositories spanning tens of business areas. The company reports that the tool identified and remediated vulnerabilities with speed and efficiency that far exceeded what its teams previously achieved through manual triage.

Why AI-powered attacks are forcing banks to rethink traditional cyber defenses

VulnHunter arrives at a moment when the cybersecurity landscape is shifting beneath the feet of every enterprise. Capital One's announcement frames the urgency in stark terms: advanced AI models have "dramatically lowered the barrier for bad actors to discover and exploit vulnerabilities in software," and the window before sophisticated AI attack capabilities become affordable and accessible to virtually every adversary is shrinking rapidly.

The company's own AI security researchers have been tracking these trends closely. At NeurIPS 2024 in Vancouver, Capital One's team presented research and curated a list of nearly 100 papers spanning LLM safety, adversarial resilience, jailbreak attacks, and synthetic data generation. The papers they highlighted — including work on multi-agent defense frameworks, automated red-teaming, and guardrail classifiers — paint a picture of an arms race in which offensive and defensive AI capabilities are co-evolving at breakneck speed.

Several of those research themes map directly onto VulnHunter's architecture. The falsification engine echoes the adversarial defense strategies explored in papers like "BackdoorAlign," which demonstrated that embedding a structured safety mechanism into a small number of training examples could recover a model's safety alignment without degrading performance. The attacker-first forward analysis reflects the philosophy of "WildTeaming," a framework that collects and analyzes real-world jailbreak attempts to build more resilient models. And VulnHunter's emphasis on minimizing false positives parallels the goals of "GuardFormer," a guardrail classifier that outperformed GPT-4 on safety benchmarks while running 14 times faster.

The thread connecting all of this work is a conviction that traditional, reactive security — monitoring networks, patching known vulnerabilities, responding to incidents after they occur — is no longer sufficient when adversaries can use AI to discover and exploit zero-day vulnerabilities at machine speed. The only durable defense, Capital One argues, is to find and fix the vulnerabilities in your own code before attackers find them first.

What Capital One's cloud security journey reveals about the entire banking industry

Capital One's arc from breach victim to open-source security contributor also illuminates a broader reckoning across financial services. When Capital One moved aggressively to Amazon Web Services in the mid-2010s, it was a rarity among major banks. Most financial institutions simply did not trust third parties to store their most sensitive data. Capital One's CIO at the time, Rob Alexander, publicly championed the cloud as more secure than the bank's own data centers — a claim that the 2019 breach complicated considerably.

The CyberScoop report from that period captured the tension within the industry. W. Patrick Opet, managing director of cybersecurity at JP Morgan Chase, described a cultural shift in banking from prioritizing traders to prioritizing developers: "Now, it's 'Focus on the developer, turn everything into code, and automate everything.'" Mark Nicholson, Deloitte's cyber leader for the financial industry, noted that the pressure to move quickly was exposing "weaknesses in the development methodology." And the breach itself was a reminder that even as Chase spent $600 million annually on cybersecurity, relatively simple vulnerabilities — like the Apache Struts bug that enabled the Equifax breach — could undercut massive investments in data protection.

Seven years later, the industry has largely followed Capital One into the cloud, and the security challenges have only intensified. The question is no longer whether to use cloud infrastructure but how to secure the software that runs on it. VulnHunter represents Capital One's answer: rather than relying solely on network-level controls and perimeter defenses, push security directly into the code itself, at the moment it is written. The open-source release also carries implicit competitive pressure. If VulnHunter gains traction among developers and security teams, it could set a new baseline for what enterprise security tooling is expected to do — and force rival banks, fintechs, and cloud providers to match or exceed its capabilities.

Whether VulnHunter lives up to that ambition will depend on adoption, community engagement, and the tool's real-world performance against the increasingly sophisticated AI-powered attacks it was designed to counter. But the release itself tells a story that extends well beyond any single tool or any single company. In 2019, a misconfigured firewall exposed 100 million records and turned Capital One into a cautionary tale about the cost of moving fast without moving carefully. In 2026, the same institution is open-sourcing the kind of AI-driven defense it wishes it had built sooner — and betting that the best way to protect its own code is to help the entire industry protect theirs.

Summary

Successful exploitation of this vulnerability could allow an attacker to cause a denial-of-service condition on the affected product.

The following versions of Rockwell Automation Flex 5000 Adapter are affected:

• Flex 5000 Adapter 6.011 (CVE-2026-12659)

Background

• Critical Infrastructure Sectors: Critical Manufacturing, Information Technology
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Rockwell Automation reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-16

Legal Notice and Terms of Use

Summary

Successful exploitation of this vulnerability could allow an attacker to cause a denial-of-service condition.

The following versions of Rockwell Automation 1756-EN2, 1756-EN3, and 1756-ENBT are affected:

• 1756-EN3 <=V12.001 (CVE-2026-9653)
• 1756-EN2 <=V12.001 (CVE-2026-9653)
• 1756-ENBT V6.006 (CVE-2026-9653)

Background

• Critical Infrastructure Sectors: Critical Manufacturing
• Countries/Areas Deployed: Worldwide
• Company Headquarters Location: United States

Vulnerabilities

Acknowledgments

• Tyler Lentz of Idaho National Laboratory reported this vulnerability to CISA

Legal Notice and Terms of Use

This product is provided subject to this Notification (https://www.cisa.gov/notification) and this Privacy & Use policy (https://www.cisa.gov/privacy-policy).

Recommended Practices

CISA recommends users take defensive measures to minimize the risk of exploitation of this vulnerability.

Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet.

Locate control system networks and remote devices behind firewalls and isolating them from business networks.

When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

CISA reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov/ics. Several CISA products detailing cyber defense best practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

CISA encourages organizations to implement recommended cybersecurity strategies for proactive defense of ICS assets.

Additional mitigation guidance and recommended practices are publicly available on the ICS webpage at cisa.gov/ics in the technical information paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing suspected malicious activity should follow established internal procedures and report findings to CISA for tracking and correlation against other incidents.

CISA also recommends users take the following measures to protect themselves from social engineering attacks:

Do not click web links or open attachments in unsolicited email messages.

Refer to Recognizing and Avoiding Email Scams for more information on avoiding email scams.

Refer to Avoiding Social Engineering and Phishing Attacks for more information on social engineering attacks.

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time.

Revision History

• Initial Release Date: 2026-07-16

Legal Notice and Terms of Use

Read more of this story at Slashdot.

Reduce Costs and Achieve Better Outcomes Recovery infrastructure spending has never been higher. Yet for most organizations, it is hard to point to any metrics that show improvement in recovery operations. Restorations take longer. Incidents are harder to recover from. And the financial impact of downtime keeps climbing.That gap between investment and outcome is the … Continued

The post Modernize Your Recovery Infrastructure with VMware Cloud Foundation 9.1 appeared first on VMware Cloud Foundation (VCF) Blog.

Star Wars director George Lucas has added his voice to the growing chorus of film-makers receptive to the rising use of AI tools in moviemaking.

Speaking in an interview with A Rabbit’s Foot, Lucas, 82, said: “Artificial intelligence means it’s much easier for us to make movies.”

• Added a live elapsed-time counter to the collapsed tool summary line so long-running tool calls visibly tick instead of looking stuck
• Added a startup warning for Write(path), NotebookEdit(path), and Glob(path) permission rules — use Edit(path) or Read(path) instead
• Fixed isolation: 'worktree' subagents being able to run git-mutating commands against the main repo checkout instead of their own isolated worktree
• Fixed the ultracode keyword opt-in firing on non-human-originated input such as webhook payloads and relayed PR comments
• Fixed a rendered text fragment leaking into crash telemetry when a UI component returned content outside a styled text element
• Fixed paste markers leaking into external editors opened from Claude Code, which could appear as stray È/É characters around pasted text
• Fixed claude attach sometimes failing with "job not found" or "agent is still starting" errors during session transitions — attach now waits for the daemon to settle, and terminal resizes during a slow attach are applied once it completes
• Fixed a session crash when a tool's result renderer returned a numeric bigint value or plain text instead of a UI element
• Fixed a hook callback timeout being misreported to the model as a user rejection, which made unattended sessions stop and wait
• Fixed Claude assuming a cd took effect after its command was moved to the background; the tool result now states the working directory is unchanged
• Fixed plugin-provided MCP servers being torn down when MCP servers are re-synced mid-session
• Fixed plan approvals without edits being labeled "(edited by user)" and overwriting the plan file with a stale snapshot
• Fixed /doctor skipping its auto-mode-default proposal on Bedrock, Vertex, and Foundry, where auto mode no longer needs an opt-in
• Fixed Grep content mode claiming "No matches found" when paginating past the end of results
• Fixed unmatched $1/$2 positional placeholders in skills and commands being silently stripped; they are now preserved verbatim
• Fixed plugin cache writes leaving temp files behind on failure and failing on locked-file renames on Windows and network filesystems
• Fixed background workers crash-looping when a client resets its connection to the background service
• Fixed claude agents --effort ultracode not reaching dispatched sessions; the value was silently dropped
• Fixed pressing ← to open the agents view dropping the task tracker when returning to the session
• Fixed the agents dashboard retaining pasted images from abandoned reply drafts after their session was deleted
• Fixed killed background sessions leaving a permanent git worktree lock behind; the periodic sweep now releases locks whose owning process is gone
• Fixed SDK MCP servers registered via an initialize control request waiting until the next turn to start connecting
• Fixed returning to the agents view from a session leaving overlapping ghost frames with CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1
• Fixed late-appearing .claude/* symlinks not being reconciled into the sandbox deny-write list
• Hardened the Agent tool against indirect prompt injection via content a subagent read
• Improved the Bash/PowerShell tool message when a command hits its timeout and is auto-backgrounded, so the model can distinguish a hang from an explicit background request
• Improved auto mode: the permission classifier now defaults to Sonnet 5 for external sessions, validated on the session's first request and pinned for the session
• Improved the bundled dataviz skill's chart color validation with perceptual OKLab color difference and recalibrated color-blindness thresholds
• Memory writes that leave a MEMORY.md index over its read limit now produce an explicit error instead of silent truncation
• Screen reader mode now announces permission mode changes aloud when cycling modes with Shift+Tab
• The agents footer hint now shows how many background agents are waiting on your input, with a brief color emphasis when the count changes
• Agent view: the session you pressed ← from stays visibly marked even after mouse hover or arrow keys move the selection
• Fable temporarily shows as unavailable in the advisor picker while a server-side issue causing Fable advisor failures is fixed

Read more →

The post Get Peace of Mind: Protect Data for Life With BigMind DR for $59.99 appeared first on IT Security News.

The post Get Peace of Mind: Protect Data for Life With BigMind DR for $59.99 appeared first on TechRepublic.

The post How to Recover Permanently Deleted Files for Free? appeared first on Fossbytes.

Over the past few months, there’s been a massive acceleration in the growth of eCommerce. Reports show that online revenue is growing 5 times faster than pre-COVID growth, and conveniences such as buy-online-pick-up-in-store are showing signs of permanent adoption. As retail businesses continue to adapt to these changing behaviors, providing an easy and safe shopping experience is more important than ever before. One channel that solves for both of these shopper behaviors is email. 

Today, we are hosting AMP Fest where we are excited to announce that AMP-based emails are coming to Salesforce Marketing Cloud. AMP is an open-source web component framework started by Google that simplifies how businesses can build user-first websites, emails, ads and more. 

AMP in email makes the inbox experience more useful and engaging, and even more so when we partner with companies like Salesforce Marketing Cloud. Let’s check out some examples.

Scheduling and Checkout from Gmail

Read more of this story at Slashdot.

The post Dell BIOS Flaw Lets Attackers Extract Plaintext Passwords Without Brute Force appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Read more →

The post Dell BIOS Flaw Lets Attackers Extract Plaintext Passwords Without Brute Force appeared first on IT Security News.

The post Dell BIOS Flaw Lets Attackers Recover Passwords From SPI Flash appeared first on Cyber Security News.

Read more →

The post Dell BIOS Flaw Lets Attackers Recover Admin Passwords From SPI Flash in Milliseconds appeared first on IT Security News.

Read more →

The post IT Security News Hourly Summary 2026-07-11 06h : 2 posts appeared first on IT Security News.

The post Dell BIOS Flaw Lets Attackers Recover Admin Passwords From SPI Flash in Milliseconds appeared first on Cyber Security News.

The post Ransomware Negotiator Sentenced for BlackCat Ransomware Operators to Attack Victims appeared first on Cyber Security News.

Enterprise cybersecurity is facing a fundamental speed problem. Frontier AI models are now enabling autonomous attacks that can move from initial access to full system breakout in as little as 27 seconds. That’s faster than any human-operated security workflow can detect, escalate, and respond.

As a result, security operations can no longer assume there is time for humans to respond between breach and damage.

The security posture that enterprises need for the AI era centers on cyber resilience: continuously identifying clean recovery states, mapping critical data and identity dependencies, and automating restoration so that operations can recover in hours not days.

"Everything that relied on process or human-in-the-loop intervention is no longer going to be able to execute at the speed of the attacks," says Dev Rishi, GM of AI at Rubrik. "If the attacks are happening in 27 seconds, it means I need my recovery to happen just as quickly."

Traditional detection and prevention are failing against AI-driven attacks

The rules-based logic that has defined enterprise security for decades, such as static access controls, known signature detection and deterministic behavioral policies, was engineered for deterministic software. AI agents behave differently. They're non-deterministic, capable of pursuing the same objective through many different paths, and increasingly capable of circumventing static guardrails by finding alternative routes when one is blocked.

The deeper problem is that conventional security logic checks identity, permissions, and access, and asks whether each individual access is permitted. But it can’t evaluate whether a sequence of permitted actions, taken across multiple applications, constitutes either a data leak, a destructive operation, or an attack.

"You need a system that can understand context," Rishi says. "You need to use AI to look at what an agent is doing and say, ‘it looks like what you're doing might be a risk of leaking sensitive data externally.’"

How AI agents are blurring the line between internal and external cyber threats

Enterprise security has historically maintained a meaningful distinction between external and internal threat vectors. External threats can be multidimensional, lightning fast, and come from a variety of vectors. On the other hand, internal threats were traditionally bounded by what a single human actor could accomplish before detection, constrained in speed, scope, and scale, but that distinction is falling apart as AI agents operate inside enterprise environments.

These agents have access to multiple systems simultaneously and move at speeds no human employee can match. When an agent makes a mistake, such as a hallucination, misread instruction, or an unintended data transfer, the resulting damage can look operationally identical to a malicious insider attack. And when an external attacker compromises an internal agent, they inherit its full access profile across every connected application.

"Whether or not the agent is an internal threat because of an inadvertent mistake or because it's been maliciously compromised, you need runtime guardrails that enforce your organizations policies consistently across agents," Rishi says. "The practical answer is an AI-native guardian layer that monitors agent behavior semantically, understands intent across actions, and can block or terminate a misbehaving agent at machine speed, then trigger recovery immediately."

Preparing for a world of inevitable compromise

Frontier AI models, including those capable of discovering and operationalizing zero-day vulnerabilities autonomously, are changing the economics of attacks.

As a result, interest in Mythos readiness is growing. Enterprises are increasingly operating under two assumptions: that attacks are inevitable, not exceptional, and that investment in resilience and rapid recovery must be treated as strategically as investment in prevention has been. The shift reframes recovery from a post-incident activity into a capability that is deliberately designed, tested, and continuously validated.

"The idea that you can recover quickly from an attack is going to become one of the most important facets of security," Rishi says. "It's the insurance policy that organizations now have to treat as a first-class citizen."

Why AI-powered cyber resilience depends on small models

True cyber resilience is a two-sided coin: it demands both real-time intelligent enforcement to intercept threats in motion, and automated recovery to restore operations immediately. While having backups is a baseline, organizations need workflows that can continuously monitor systems at machine speed, and instantly determine the most recent clean state under attack conditions.

Applying AI to the first half of that equation—real-time enforcement—creates a fundamental technical and economic challenge. Relying on massive frontier models to monitor every agent action introduces crippling latency overhead and exorbitant computing costs. A guardian AI system that slows down operations or costs as much as the systems it monitors is simply not viable for widespread adoption.

“It has to be a fast, small, and cheap AI model,” Rishi says. “No one wants to sign up for a secure solution that doubles their cost or latency.”

This is why small language models (SLMs) are critical for real-time enforcement. Rubrik’s approach, anchored by its acquisition of Predibase, is to build this frontline defense layer on small models optimized specifically for speed and efficiency. Unlike heavy frontier models, SLMs can semantically evaluate agent behavior at machine speed and at a fraction of the cost, acting as a real-time checkpoint.

That hyper-efficient enforcement layer is what enables a tighter, seamless connection to recovery. When the system observes an agent taking a destructive action—such as deleting a database, corrupting a critical file, or exfiltrating sensitive data—the small model detects it immediately, halts the damage, identifies the most recent clean snapshot from before the incident, and initiates recovery in a single, automated workflow.

The shift from incident response to architectural resilience

The broader implication of Mythos and similar frontier AI systems is a shift in how organizations think about security. As AI compresses the gap between attack and impact, resilience and recovery become architectural requirements rather than operational considerations.

Rubrik’s view is that security systems can no longer stop at detection. As AI agents gain greater autonomy, observability, identity context, and recovery must operate as a coordinated resilience layer. The goal is not simply to identify when something has gone wrong, but to shorten the gap between detection and restoration.

"The same thing that's introducing the threats, the frontier capabilities of models like Mythos, can also be used to help us combat the threat," Rishi says. "Positioning yourself for the AI era means closing the gap between detecting that something has gone wrong and restoring the systems that were affected, before the cost of that gap compounds."

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.

For a team shipping DAML to production, that count is what a passing test run is actually worth: it puts a number on how much your suite checks, whereas a green run on its own does not.

Why DAML’s coverage reports lie

Test coverage is the most reassuring lie in smart-contract development. Hitting 100% line coverage tells you the test runner walked the code; it does not tell you whether any test would fail if that code stopped doing what it is supposed to. We have been grading test harnesses by how many mutants they kill since at least 2019, and our primer on finding the bugs your tests don’t catch shows how a green suite can still miss the bug that matters.

DAML’s built-in coverage measures execution at the template and choice level: which templates were created and which choices were exercised over the test run. It reports whether each choice was exercised, not what happened inside it. A test that exercises a choice once and asserts nothing about the result reports that choice as covered. The report prints the same green percentage whether the test verifies the outcome or discards it.

How mutation testing works

Instead of asking whether your tests reached the code, mutation testing grades your tests by sabotaging that code. The engine generates mutants, copies of the code that each carry one small deliberate change: a flipped comparison, a removed branch, a dropped party. It then runs your test suite against each one. A mutant that makes the suite fail is caught; a mutant that passes every test survives. Every survivor is a change your tests let through, and each one is either harmless or a potential bug. The harmless ones are equivalent code no test could distinguish or a branch no execution reaches, and you can set those aside. The rest are a to-do list: each one is a specific test you are missing, a case your suite should check but does not, occasionally with a real bug sitting behind the gap. The primer above describes a real audit where a mutation campaign surfaced a high-severity bug that the project’s tests had missed.

Mutation testing forces the unhappy path

A DAML contract encodes rights and obligations between named parties: who holds what, who owes what to whom, and who must authorize each step. A party is not an anonymous address. It represents a real organization or person, and the contract is the rulebook for how those parties interact, including which of them can take which action, what each is allowed to see, and what stays private between them.

Authorization is how that rulebook is enforced: who may take which action. It is also easy to get wrong in ordinary ways, such as a typo in a controller clause, a missing party, an extra one left over from a refactor. Every combination type-checks, so nothing rejects it before it ships. A static analyzer can flag suspicious patterns, but it has no way to know which party should hold which authority on your contract. That knowledge lives in your specification, and for most projects, the only executable form of the specification is the test suite. Happy-path tests supply every signature the contract asks for and confirm the transaction succeeds. They never try the negative case—removing a required signature and checking that the ledger rejects the transaction—so they never actually test whether that signature was required at all. If the tests don’t encode that rule, nothing downstream can recover it. Mutation testing is what tells you whether they do.

A green test run tells you your tests passed today. Mutation testing asks the harder question: would your tests catch a mistake, now or after the next code change? Where the answer is no, you have found a test case worth writing.

What Mewt adds for DAML

Mewt parses every language it supports with a tree-sitter grammar. As of mid-2026, there is no maintained tree-sitter grammar for DAML, so we reused the upstream tree-sitter-haskell grammar. DAML is Haskell-shaped, but its contract constructs (template, choice, controller, and signatory) are not Haskell, and the grammar parses them as error-recovered subtrees. That matters less than it sounds. The common mutations still work on DAML’s ordinary expressions, so Mewt swaps arithmetic and comparison operators, flips Booleans, and removes branches just as it does in any other language, with only small adjustments where DAML’s surface syntax differs (DAML writes /= where most languages write !=). We got most of the value of a from-scratch grammar without building one.

The new engineering went into DAML’s authorization primitives, where the authorization bugs from the previous section live. Mewt adds two DAML-specific mutations:

• Controller party swap (CPS in Mewt’s output): replace one party in a controller clause with another party that is in scope at that site.

• Controller party removal (CPR): drop one party from a multi-party controller list.

Both target the same question: if the set of parties allowed to exercise this choice silently changed, would any test fail? They are a deliberately small starting set aimed at the bug class above, and more DAML-specific mutations are in the pipeline.

Driving a campaign needs no new harness. A short mewt.toml names the files to mutate and the test command (dpm test for a Daml 3 project), and mewt run does the rest, reporting each mutant as caught or surviving. The setup is deliberately small: trying it on your own project costs minutes, and we encourage exactly that.

What a surviving mutant looks like

Picture a conditional payment between a buyer and a seller: the buyer sets money aside for the goods, and paying it out to the seller requires both parties to sign off. The buyer’s signature is the delivery confirmation. In DAML, that policy is one line: the controller line on the Release choice.

template ConditionalPayment
 with
 buyer : Party
 seller : Party
 amount : Decimal
 where
 signatory buyer
 observer seller

 choice Release : ()
 with
 paid : Decimal
 controller buyer, seller
 do
 assert (paid == amount)

A typical happy-path test creates the payment and has both parties approve the release. The actAs buyer <> actAs seller line submits the command with both parties’ authority:

testHappyPath : Script ()
testHappyPath = script do
 buyer <- allocateParty "Buyer"
 seller <- allocateParty "Seller"
 payment <- submit buyer do
 createCmd ConditionalPayment with
 buyer
 seller
 amount = 100.0
 submit (actAs buyer <> actAs seller) do
 exerciseCmd payment Release with paid = 100.0
 pure ()

The test passes, and by the usual measure the suite looks complete: running dpm test with coverage reporting enabled shows full coverage.

$ dpm test --show-coverage --coverage-ignore-choice Archive
testHappyPath: ok, 0 active contracts, 2 transactions.
- Internal templates: 1 defined, 1 (100.0%) created
- Internal template choices: 1 defined, 1 (100.0%) exercised

The --coverage-ignore-choice Archive flag deserves a word. Every DAML template automatically gets an implicit Archive choice. It is not part of the business logic under test, so we exclude it for simplicity. With it included, this one-choice template would report 50% even though the test exercises everything we wrote.

Run Mewt on the project and it generates seven mutants. The test suite catches three of them. Four survive. Here is one of the survivors, shown as the diff Mewt reports:

 choice Release : ()
 with
 paid : Decimal
- controller buyer, seller
+ controller seller
 do
 assert (paid == amount)

Re-run the test suite against this mutant. It still passes, and coverage still reports 100%. The contract claims releasing the buyer’s money requires both parties. The mutant lets the seller release it to themselves without the buyer ever confirming delivery. The tests report green either way. Only a test that tries the forbidden path, the seller acting alone, expecting the ledger to reject it, can tell the two contracts apart. No such test exists, and the mutation score says so. (The other three survivors tell the same story from different angles: the buyer-alone twin of this mutant, and two mutants that weaken the paid == amount check to <= and >=, which survive because the test only ever pays the exact amount.)

Step back, and this is the whole point of the exercise. Your tests are the executable specification of your code. Here the implementation changed, one required approval instead of two, and the specification did not react. That means the expected behavior was underspecified all along: whether both the buyer and the seller have to sign off, or just one of them, was never actually written down anywhere a machine could check. Every controller combination type-checks, and coverage reports 100% for all of them. The only place “both must sign” can exist in checkable form is a test that expects the weakened contract to fail, and writing that test is exactly what the surviving mutant tells you to do.

Limitations and what comes next

Mewt is not magic. Two limits are worth knowing before you run your first campaign: not every survivor is a real gap, and a campaign costs time. The roadmap that follows them is where we are taking the work next.

Equivalent mutants exist: some survivors turn out to be semantically identical to the original program, so no test could ever catch them. Few public DAML codebases on GitHub come with a full test suite, so we are glad OpenZeppelin open-sourced its canton-stablecoin reference implementation. Mewt generated hundreds of mutants for it. We ran the highest-priority ones through the existing test suite, and seven of those survived. Three were equivalent mutants or sat behind a guard that no path reaches, and the other four were genuine missing test cases. None of the survivors we reviewed pointed to a bug. Such a clean result is what you want when you run Mewt on your own code, and triaging them took minutes.

One of those equivalent mutants shows what that means concretely. A helper computed accrued debt:

accrueDebt currentDebt lastAccrual now annualRate =
 if currentDebt == 0.0 || annualRate == 0.0 then currentDebt
 else
 let elapsedYears = ... -- elapsed time as a fraction of a year
 in currentDebt * (1.0 + annualRate * elapsedYears)

Mewt forced the if to always take the else branch. No test failed, and none ever could: when the debt is zero, the formula multiplies by zero and returns zero, and when the rate is zero, it multiplies the debt by one and returns it unchanged. The guard is a shortcut that returns the value the formula already produces, so removing it changes nothing. Mewt suppresses the equivalent mutants it can detect. The rest need a reviewer’s judgment to dismiss.

Campaigns cost time in two places. The machine part: Mewt runs your test suite once per mutant, so the wall-clock cost is roughly the number of mutants times how long one test run takes, plus a rebuild if your project needs one. That is minutes on a small codebase and hours on a large one or a slow suite, so the cadence that works is nightly or weekly rather than per-commit. The human part: someone has to look at the survivors. We are working on that front from several directions at Trail of Bits, including our mutation-testing skill that helps configure campaigns for your project, and Trailmark with its genotoxic triage skill. None of these understand DAML yet, but the direction is clear: given the right harness and tools, the time-consuming parts of a campaign can be handed to AI agents. The effort is modest and the payoff is concrete: each genuine survivor is a specific test you can write, and every test you add makes your suite enforce one more guarantee your contracts are supposed to make.

Also on the roadmap: choice-consumption mutations (consuming vs nonconsuming) sit cleanly on top of the controller-mutation scaffolding and target a bug class Mewt does not yet reach.

Dive in

Install Mewt from the repository, point a mewt.toml at your project and its test command, and mewt run. The quickstart in the README covers the rest. DAML works out of the box. Everything here ran on Daml 3.4 with dpm, but Mewt just drives whatever test command you configure, so Daml 2 projects using the daml assistant work the same way.

Mutation testing complements the rest of your security stack, the type checkers, linters, and property tests you already run, rather than replacing any of it.

If you’re building on Canton, we help teams with security reviews of DAML applications and with the way the code gets built: working directly with your engineers on the development process itself. Contact us.

This vulnerability affects the following application versions:

• Magento 2.1.0
• Magento 2.1.0-rc1
• Magento 2.1.0-rc2
• Magento 2.1.0-rc3
• Magento 2.1.1
• Magento 2.1.2
• Magento 2.1.3
• Magento 2.1.4
• Magento 2.1.5
• Magento 2.1.6
• Magento 2.1.7
• Magento 2.1.8
• Magento 2.1.9
• Magento 2.1.10
• Magento 2.1.11
• Magento 2.1.12
• Magento 2.1.13
• Magento 2.1.14
• Magento 2.1.15
• Magento 2.1.16
• Magento 2.1.17
• Magento 2.1.18
• Magento 2.2.0
• Magento 2.2.0-rc2.0
• Magento 2.2.0-rc2.1
• Magento 2.2.0-rc2.2
• Magento 2.2.0-rc2.3
• Magento 2.2.0-rc3.0
• Magento 2.2.0-RC1.1
• Magento 2.2.0-RC1.2
• Magento 2.2.0-RC1.3
• Magento 2.2.0-RC1.4
• Magento 2.2.0-RC1.5
• Magento 2.2.0-RC1.6
• Magento 2.2.0-RC1.8
• Magento 2.2.1
• Magento 2.2.2
• Magento 2.2.3
• Magento 2.2.4
• Magento 2.2.5
• Magento 2.2.6
• Magento 2.2.7
• Magento 2.2.8
• Magento 2.2.9
• Magento 2.2.10
• Magento 2.2.11
• Magento 2.3.0
• Magento 2.3.1
• Magento 2.3.2
• Magento 2.3.2-p1
• Magento 2.3.2-p2
• Magento 2.3.3
• Magento 2.3.3-p1
• Magento 2.3.4
• Magento 2.3.4-p2
• Magento 2.3.5
• Magento 2.3.5-p1
• Magento 2.3.5-p2
• Magento 2.3.6
• Magento 2.3.6-p1
• Magento 2.3.7
• Magento 2.3.7-p1
• Magento 2.3.7-p2
• Magento 2.3.7-p3
• Magento 2.3.7-p4
• Magento 2.4.0
• Magento 2.4.0-p1
• Magento 2.4.1
• Magento 2.4.1-p1
• Magento 2.4.2
• Magento 2.4.2-p1
• Magento 2.4.2-p2
• Magento 2.4.3
• Magento 2.4.3-p1
• Magento 2.4.3-p2
• Magento 2.4.3-p3
• Magento 2.4.4
• Magento 2.4.4-p1
• Magento 2.4.4-p2
• Magento 2.4.4-p3
• Magento 2.4.4-p4
• Magento 2.4.4-p5
• Magento 2.4.4-p6
• Magento 2.4.4-p7
• Magento 2.4.4-p8
• Magento 2.4.4-p9
• Magento 2.4.4-p10
• Magento 2.4.4-p11
• Magento 2.4.4-p12
• Magento 2.4.4-p13
• Magento 2.4.5
• Magento 2.4.5-p1
• Magento 2.4.5-p2
• Magento 2.4.5-p3
• Magento 2.4.5-p4
• Magento 2.4.5-p5
• Magento 2.4.5-p6
• Magento 2.4.5-p7
• Magento 2.4.5-p8
• Magento 2.4.5-p9
• Magento 2.4.5-p10
• Magento 2.4.5-p11
• Magento 2.4.5-p12
• Magento 2.4.5-p13
• Magento 2.4.5-p14
• Magento 2.4.6
• Magento 2.4.6-p1
• Magento 2.4.6-p2
• Magento 2.4.6-p3
• Magento 2.4.6-p4
• Magento 2.4.6-p5
• Magento 2.4.6-p6
• Magento 2.4.6-p7
• Magento 2.4.6-p8
• Magento 2.4.6-p9
• Magento 2.4.6-p10
• Magento 2.4.6-p11
• Magento 2.4.6-p12
• Magento 2.4.6-p13
• Magento 2.4.7
• Magento 2.4.7-beta1
• Magento 2.4.7-beta2
• Magento 2.4.7-beta3
• Magento 2.4.7-p1
• Magento 2.4.7-p2
• Magento 2.4.7-p3
• Magento 2.4.7-p4
• Magento 2.4.7-p5
• Magento 2.4.7-p6
• Magento 2.4.7-p7
• Magento 2.4.7-p8
• Magento 2.4.8
• Magento 2.4.8-beta1
• Magento 2.4.8-beta2
• Magento 2.4.8-p1
• Magento 2.4.8-p2
• Magento 2.4.8-p3
• Magento 2.4.9-alpha1
• Magento 2.4.9-alpha2
• Magento 2.4.9-alpha3

Written by: Shebin Mathew

The post Commvault measures cyber recovery readiness with AI attack simulations appeared first on Help Net Security.

Read more →

The post Commvault measures cyber recovery readiness with AI attack simulations appeared first on IT Security News.

Cyber incident response planning is the process of preparing the policies, procedures, teams and technologies required to respond effectively to cybersecurity incidents. It helps organisations detect incidents faster, contain threats, reduce business disruption and recover with greater confidence.

The post VECT Ransomware Uses TeamPCP Credential Archive to Select Victims After Compromise appeared first on Cyber Security News.

Ransomware simulation exercises recreate realistic ransomware attack scenarios to test an organisation’s incident response capabilities, communication processes and overall readiness. They help teams understand how they would detect, escalate, contain, communicate and recover from a ransomware incident before a real attack occurs.

 A cyber incident response plan outlines the steps an organisation should take to prepare for, identify, contain, eradicate, recover from, and learn from cybersecurity incidents. A well-structured plan defines responsibilities, communication procedures, escalation paths, reporting requirements, and recovery actions to minimise business disruption and improve cyber resilience. 

Read more →

The post Flipper Zero Firmware Development Continues With New Community Contribution Rules appeared first on IT Security News.

The post Flipper Zero Firmware Development Continues With New Community Contribution Rules appeared first on Cyber Security News.

Read more of this story at Slashdot.

Full Changelog: cli-v3.0.34...cli-v3.0.35

Author: Shikhali Jamalzade
GitHub: alisalive
LinkedIn: camalzads
Platform: CyberWarfare Labs (CWL)
Certification: AD-RTS — Active Directory Red Team Specialist Environment: TELECOM INC. — Simulated Telecom-Sector Active Directory Forest

A few months back I finished the AD-RTS course material from CyberWarfare Labs — four modules covering core Active Directory internals, Certificate Services abuse, Exchange Server exploitation, and ESXi-to-AD integration attacks. The course itself is dense, but the real test is the 30-day flag-based challenge lab that comes after it: a live, self-contained telecom environment called telecore.ad, built around a fictional company, TELECOM INC., with a Domain Controller, a SQL Server, a PKI/ADCS server, an Exchange server, an IIS-hosted internal web application, and an ESXi hypervisor sitting inside the same domain.

The exam is split into two independent adversary paths. Path 1 assumes zero credentials and zero prior access — you start with nothing but an IP range. Path 2 assumes you already have a low-privilege authenticated foothold on a public-facing web server and have to escalate from there. Both paths converge on the same underlying domain, but the entry vectors, the misconfigurations abused, and the final objectives are completely different. This write-up walks through the full methodology for both paths, exactly as I approached them, without listing the specific flag values captured along the way — the point here is the how, not the what.

Target: TELECOM INC. internal AD forest (telecore.ad) Stack: Windows Server 2022 Domain Controller, MS SQL Server (SQLEXPRESS), ADCS Certificate Authority, Exchange Server, IIS 10 / ASP.NET Web Forms, VMware ESXi with AD-joined authentication Assessment Type: Adversary emulation — unauthenticated black-box (Path 1) and authenticated foothold escalation (Path 2) Tools: nmap, dig, ldapsearch, Impacket suite (GetNPUsers, mssqlclient, wmiexec, secretsdump), hashcat, John the Ripper, GodPotato, certipy-ad, rpcclient, smbclient, pyVmomi, ysoserial.net, exchangelib, netexec

Path 1: Unauthenticated Adversary

The brief for Path 1 is deliberately minimal: you are handed a /24 and told to behave like a telecom-motivated APT starting from zero. No credentials, no internal knowledge, nothing but network reachability into the range.

Mapping the DNS Infrastructure

Every internal Windows environment leans on DNS to keep itself glued together, and that dependency is usually the first crack an attacker can pry open. A UDP sweep across port 53 on the target range revealed multiple name servers, one of which turned out to be a secondary, less-hardened DNS instance sitting outside the domain controller itself. Once I pointed my resolver configuration at that secondary server, a full PTR sweep across the subnet mapped every reverse DNS record in the environment — instantly revealing the hostnames and roles of every server in play: the domain controller, the SQL server, the certificate authority, the Exchange server, and the hypervisor, all before a single authenticated packet had been sent.

The real opening, though, came from testing whether that secondary DNS server would honor a zone transfer request. It did — both in the reverse zone and in the forward zone for telecore.ad. AXFR being enabled on an internet- or perimeter-adjacent DNS server is a classic, almost nostalgic misconfiguration, but it remains devastatingly effective: a single dig command handed over the complete internal namespace, service records, and IP-to-hostname mapping for the entire forest, again with zero authentication.

With the domain controller identified from the zone transfer, the next step was straightforward LDAP enumeration over anonymous bind — pulling the domain’s functional level, then walking the directory for every object under objectClass=user and objectClass=computer. This produces two things that matter enormously for what comes next: a clean list of real domain user accounts (filtered out from the noise of Exchange system mailboxes and health-check accounts that always clutter a mailbox-enabled AD), and a map of which machines in the domain hold interesting roles.

From Kerberos Pre-Auth to a Foothold on SQL

With a legitimate username list in hand, the obvious next move was to test for accounts with Kerberos pre-authentication disabled — the classic ASREPRoasting misconfiguration. Impacket’s GetNPUsers module does this cleanly: it walks the username list and, for any account with the UF_DONT_REQUIRE_PREAUTH flag set, returns a crackable AS-REP hash without ever needing to know the account’s password up front. One of the service-oriented accounts in the environment had exactly this misconfiguration, and the resulting hash fell quickly to a dictionary attack.

Cracked credentials in hand, the next question was where they were actually valid. Cross-referencing against the computer objects pulled during LDAP enumeration pointed straight at the SQL Server. Authenticating to it with Impacket’s MSSQL client confirmed the account held sysadmin-equivalent rights on the instance — enough to re-enable the xp_cmdshell extended stored procedure, which is disabled by default on modern SQL Server but, once flipped back on, gives arbitrary OS command execution in the context of the SQL service account.

From Service Account to SYSTEM

Command execution as the SQL service account is useful, but it’s not the finish line — the account only had ordinary service-level privileges. A privilege check revealed SeImpersonatePrivilege was enabled, which is the precondition for the entire family of “Potato” privilege escalation exploits. On a fully patched, modern Windows Server build, most of the older Potato variants (RoguePotato, JuicyPotato, PrintSpoofer) have been closed off, but GodPotato remains effective against current builds because it abuses a lower-level RPC/DCOM marshaling primitive rather than a specific, patchable service misconfiguration.

Dropping GodPotato onto the SQL box through the xp_cmdshell channel and triggering it against a reverse shell payload elevated the session cleanly from a low-privilege service account to NT AUTHORITY\SYSTEM.

With SYSTEM on the SQL server, the natural move was a credential harvest from LSASS. Rather than dropping a third-party dumping tool that’s likely to trip EDR, I used the built-in comsvcs.dll MiniDump export via rundll32 — a living-off-the-land technique that doesn’t touch disk with anything outside of what Windows already ships. The resulting dump was compressed, exfiltrated back to the attacking host over a simple HTTP upload listener, and parsed offline with pypykatz, which yielded NTLM hashes and Kerberos material for every account that had ever authenticated interactively or as a service on that box — including a domain account with a considerably more interesting set of permissions than the one I’d started with.

Abusing ADCS: ESC1 to Domain Admin

The newly recovered account turned out to have enrollment rights on a certificate template published by the internal PKI, and enumerating that CA with certipy-ad flagged the template as vulnerable to the ESC1 misconfiguration: the template allows the requester to supply an arbitrary Subject Alternative Name while also permitting client authentication, meaning any authenticated user with enroll rights can request a certificate asserting an identity that isn’t their own — including Domain Admin.

Before actually requesting the certificate, it’s worth noting the certifried mitigation Microsoft shipped in response to CVE-2022–26923: modern domain controllers now cross-check the SID embedded in the certificate’s security extension against the SAN identity, so simply putting an administrator’s UPN in the SAN field is no longer sufficient on its own — you also need the correct objectSid for that account, retrievable over RPC with a simple SID lookup against the domain controller. With both the UPN and the correct SID supplied in the certificate request, the CA issued a certificate that authenticated as the Domain Administrator, and that certificate could then be exchanged for the account’s NT hash directly — no interactive logon, no password reset, just a straightforward abuse of a legitimate PKI enrollment workflow.

From there it was a matter of cracking the recovered hash offline and confirming Domain Admin access against the domain controller directly, which also surfaced an interesting security group in the domain that doesn’t exist in a stock AD install: an ESX Admins group, hinting strongly at the next phase of the assessment.

Pivoting into the Hypervisor

ESXi hosts joined to Active Directory for centralized authentication are common in mixed enterprise environments, and telecore.ad had exactly this setup: the hypervisor trusted domain credentials, and membership in that ESX Admins group translated directly into root-equivalent access on the host. With the cracked Domain Admin credential, I authenticated to the ESXi host and used the pyVmomi SDK — VMware’s official Python bindings for the vSphere API — to programmatically enumerate every guest VM running on the hypervisor: power state, guest OS, VMware Tools status, and, critically, the free-text annotation/notes field attached to each VM object.

Notes fields on virtual machines are a surprisingly common dumping ground for exactly the kind of information that should never live there — and this environment was no exception. One particular guest VM had its local credentials sitting in plaintext in its own annotation field, visible to anyone with sufficient ESXi permissions to query VM metadata.

With ESXi root privileges and VMware Tools confirmed present on the target guest, the final move didn’t require touching the guest’s network interface at all. VMware Tools exposes a guest operations API that lets an ESXi-privileged operator execute arbitrary processes directly inside a running guest VM, authenticated with the guest’s own local credentials, entirely out-of-band from the guest’s actual network stack. I used this to launch a reverse shell process inside the guest, landing an interactive session on what the environment had positioned as its most sensitive internal system — completing the unauthenticated attack path from a bare IP range down to code execution on a hardened internal Linux host, entirely through Active Directory, certificate services, and hypervisor misconfigurations chained together.

Path 2: Authenticated Adversary

Path 2 starts from a completely different assumption: you already have low-privilege, unauthenticated-but-network-reachable access to a single public-facing IIS web application, and the objective is privilege escalation and lateral movement from that single entry point through to sensitive business data.

Breaking the ASP.NET ViewState

The target application was a fairly standard ASP.NET Web Forms site — the kind of legacy internal tooling that telecom operators tend to keep running long past its expected lifespan. Web Forms pages carry a hidden __VIEWSTATE field that encodes serialized page state, cryptographically signed (and optionally encrypted) using a machine key configured in the application’s web.config. If that machine key is ever exposed, the ViewState mechanism — designed purely for tamper protection — becomes a fully general .NET deserialization gadget, because the framework will happily deserialize and execute anything correctly signed with the right key.

The application exposed a reporting feature that read files from the local filesystem based on a URL parameter, with essentially no path validation. That’s a textbook local file inclusion primitive, and the highest-value target for it was obvious: the application’s own web.config, which — as is unfortunately common — held its ViewState validation key and algorithm directly in cleartext, alongside a setting that explicitly relaxed the URL-to-filesystem mapping to make path traversal easier rather than harder.

With the validation key, the algorithm, and the ViewState generator value scraped from the page’s own markup, I had everything ysoserial.net needs to forge a malicious ViewState blob. The TextFormattingRunProperties gadget chain — which abuses a WPF-related deserialization path to spawn an arbitrary process — turned that forged, correctly-signed ViewState payload into direct remote code execution the moment it was replayed against the application’s own postback endpoint. No credentials, no authentication bypass in the traditional sense — just a trust boundary (the machine key) that had leaked into a place it was never supposed to be reachable from.

Registry Credentials and DPAPI

Command execution through the ViewState gadget landed in the context of the IIS application pool identity — not a domain account, but still a foothold worth building on. A search through predictable locations on the host surfaced a custom internal application with its own registry key under HKLM\SOFTWARE, storing a domain service account’s username in cleartext alongside a Base64-encoded, DPAPI-protected password blob.

Storing secrets in a machine-scoped registry hive that any local process can read is already a mistake, but the developer had additionally used DPAPI’s LocalMachine protection scope rather than CurrentUser — meaning any process running on that specific machine, regardless of which user account it’s running as, can decrypt the blob using nothing but the machine’s own DPAPI master key. A short PowerShell snippet using the standard System.Security.Cryptography.ProtectedData class was enough to unwrap it and recover a plaintext domain credential for a genuinely useful service account.

A Second Path Through ADCS

That newly recovered service account turned out to have its own enrollment rights on a different certificate template in the same PKI — again vulnerable to the same ESC1 misconfiguration pattern seen in Path 1, just via a different template and a different starting account. The exploitation mechanics were identical: enumerate the vulnerable template, retrieve the target’s SID over RPC, forge a certificate request asserting the Domain Administrator’s identity, authenticate with the issued certificate, and recover the corresponding NT hash — landing Domain Admin from an entirely different starting point than Path 1, but through the same underlying PKI weakness. It’s a good illustration of why a single vulnerable certificate template rarely stays contained to one attack path; if more than one principal can enroll against it, it’s effectively a shared skeleton key for the domain.

From there, authenticating directly to the domain controller as Domain Admin opened up the full SMB share tree, and a look through the Windows Task Scheduler’s on-disk task definitions turned up something unusual: a scheduled task configured to run a PowerShell script under the Administrator’s own context, seemingly for routine mailbox maintenance. Pulling that script down and reading through it revealed hardcoded Exchange service credentials — again stored in plaintext, this time inside a script whose entire purpose was mailbox automation.

Exchange Impersonation and Mailbox Enumeration

The credentials recovered from that scheduled task belonged to an operations-focused service account, and a quick programmatic check against the Exchange server confirmed it had been granted the ApplicationImpersonation management role — an Exchange RBAC role that, by design, allows a single service account to act on behalf of any mailbox in the organization without needing that mailbox’s own credentials. It’s an entirely legitimate feature meant for backup, migration, and integration tooling, but when the account holding it also has weak or exposed credentials, it collapses into a universal mailbox-reading primitive.

Using the Exchange Web Services API with that account’s impersonation rights pointed at the Administrator’s own mailbox, I was able to enumerate the Inbox, Sent Items, and Drafts folders directly — no need to ever touch the Administrator’s actual password. Reading through the recovered correspondence surfaced exactly the kind of operational detail that internal email threads tend to accumulate over time: database credentials shared between a DBA and an operations contact for a production SQL instance, network infrastructure access details passed along in a router-maintenance thread, and references to an internal marketing campaign server mentioned in passing in an unrelated message chain. None of this was the result of a single exploit — it was simply what falls out of an inbox that’s been collecting operational chatter for months, once you have legitimate-looking read access to it.

That last stretch of Path 2 is worth reflecting on separately, because it’s a different category of finding than everything before it. Getting to Domain Admin via ADCS ESC1 is a hard technical exploit with a clean root cause and a clean fix — restrict enrollment rights, disable enrollee-supplied subject, or require manager approval on the template. Reading sensitive operational secrets out of an executive’s inbox because a service account with impersonation rights had weak credentials is a softer, more human failure mode — and honestly the one that’s hardest to fully close, because impersonation itself is a legitimate and necessary Exchange feature. The fix there isn’t technical elimination, it’s credential hygiene and RBAC scoping: impersonation rights should be scoped to the specific mailboxes a given integration actually needs, not granted organization-wide by default, and any account holding that role deserves the same protection posture as a Domain Admin account, because functionally it often is one.

Closing Thoughts

Looking back at both paths together, the pattern that stands out most isn’t any single vulnerability class — it’s how often the misconfigurations were individually mundane and collectively devastating. A DNS server that shouldn’t allow zone transfers. An account that shouldn’t skip Kerberos pre-auth. A certificate template that shouldn’t let requesters pick their own identity. A registry key that shouldn’t hold a password, even an encrypted one, at machine scope. A scheduled task script that shouldn’t hardcode credentials. None of these individually would make a headline vulnerability disclosure. Chained together, in the right order, they took an anonymous position on a /24 all the way to Domain Admin and hypervisor-level code execution, twice, through two completely different entry points.

That’s really the entire thesis of AD-RTS as a certification, and it’s the same lesson every serious AD engagement eventually teaches: defenders tend to think in terms of individual controls, and attackers think in terms of paths. The environments that hold up aren’t the ones with zero misconfigurations — that bar doesn’t exist in any real enterprise — they’re the ones where no single chain of small mistakes reaches all the way to the crown jewels.

If you’re working through AD-RTS yourself, my honest advice is to resist the urge to jump straight to the tooling. Every phase of this exam rewards understanding why a technique works before running it — ASREPRoasting only makes sense once you understand what Kerberos pre-authentication is actually protecting against, and ESC1 only clicks once you understand what a certificate template’s enrollment permissions and SAN policy are actually meant to enforce. The course material front-loads that theory for a reason.

If you found this useful, feel free to connect on LinkedIn or check out my tools on GitHub.

Certified AD Red Team Specialist (AD-RTS): Full Exam Write-Up was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more of this story at Slashdot.

In recent years we’ve seen infostealer malware (like LummaC2) gain the ability to exfiltrate user tokens, allowing attackers to gain access to the user’s data without needing to retain access to the user’s machine. This attack is viable even if the site has strong MFA requirements, so passkeys don’t help. Encrypting the tokens on disk doesn’t prevent the malware from scraping them out of the browser’s RAM or obtaining whatever key is used to encrypt them. This feels like a pretty hard problem to solve.

But that hasn’t stopped people from trying! Dirk Balfanz wrote an IETF draft describing a mechanism for using self-signed certificates for TLS authentication. This uses the mutual authentication feature of the TLS protocol that requires both sides prove their identity to each other. In regular TLS, the remote site presents a signed certificate that tells you who it is. When performing mutual authentication, you then present a certificate to the remote site telling it who you are. These client certificates are largely unused outside enterprise environments because they’re a huge pain to deploy. It’s not so much that this has sharp edges, it’s that it’s entirely made of sharp edges. Managing certificate deployment to your devices is hard. Browsers get confused if the certificates change under them. You have one certificate and it lives forever, so sites you present it to can track your identity. Users are prompted to choose a certificate to authenticate with, and if they pick the wrong one everything breaks and is hard to recover. I’ve deployed this and I did not have a good time.

But Balfanz’s idea was simple. Rather than require certificates to be deployed, browsers would simply generate a certificate on the fly. The goal wasn’t to prove the device or user’s identity in any global way - but it would associate a TLS session with a specific certificate. You could then, for example, include a hash of the certificate in the cookie, and if someone tried to use that cookie without presenting that certificate then the cookie could be rejected. If the browser used a hardware-backed private key for the certificate then it would be impossible for an attacker to steal it. Sure, you could still steal cookies, but you wouldn’t be able to use them.

This was written almost 15 years ago, and seems simple, elegant, and functional. It didn’t happen. Part of the reason for that is that, well, it wasn’t quite so simple. One problem was privacy related. Cookies are only sent after the TLS session is established, so anyone monitoring the network doesn’t know anything about the user identity. A naive implementation of this approach would have meant the client certificate being sent before session establishment, and now user identity can be tracked (no longer an issue if this was implemented on top of TLS 1.3, but this was a log time ago). This was avoided by reordering the client handshake, but that meant having to modify the TLS specification and implementations would have to be updated to support this. Another was that figuring out the granularity of the certificates was difficult. You’d want to use different certificates for every site to avoid them effectively becoming tracking cookies, but you need to provide the certificate before cookies are set, and you don’t know what origin the site is going to set in its cookies. If you generate a certificate for a.example.com and a different one for b.example.com, and a.example.com sets a cookie for *.example.com and includes the certificate you used for a.example.com, that cookie isn’t going to work on b.example.com and things are broken. This meant supporting it wasn’t as straightforward as it seemed - you’d need to ensure that your cookie scope was compatible with the certificate scope. You could probably make this work well enough by aligning it with the Public Suffix List, but there was still some risk of expectations not being aligned.

And, perhaps most importantly, TLS session resumption (replaced by pre-shared keys in TLS 1.3) somewhat defeats the purpose of the exercise - clients store state that allows them to re-establish a TLS connection without performing certificate exchange (this reduces overhead if a connection gets interrupted or you switch to a new network or anything along those lines), and anyone in a position to steal cookies could steal that state as well.

The followup attempt was channel IDs. This simplified the implementation somewhat - rather than certificates, a raw public key would be sent, along with proof of possession of the private key in the form of a signature over a portion of the TLS handshake. This was required even in the event of session resumption, which avoided having to worry about theft of session secrets. The timing of the exchange was after the encrypted session had been established, so user identity couldn’t be leaked that way either. Cookies could then be bound to this identifier. Unfortunately it didn’t really deal with the problem of scoping keys in a way that would match cookie requirements, and the spec suggests that the right way of handling this is to scope keys to TLDs, which would enable user tracking across sites (Chrome’s implementation apparently restricted it to eTLD+1, which would match the third party cookie policy and avoid the tracking risk).

Chrome added support for this, but it was removed in early 2018. The discussion of some of the pain points in that message is interesting, explicitly calling out problems with connection coalescing across domains and the incompatibility with zero-RTT TLS1.3. The overall consensus at the time seems to be that trying to solve this entirely at the TLS layer has too many rough edges, and a different approach should be taken.

And so almost 7 years after the initial draft for origin bound certificates, we come to token binding. This ended up being a rather more complex endeavour, covering 3 different RFCs describing how it impacts TLS, how to incorporate it into HTTP, and how to manage all the various parties involved in the process. The short version is that it’s pretty similar to channel ID, except that there’s also a documented mechanism for allowing tokens to be bound to one party and consumed by another, avoiding any need for widely scoped keys. Token binding effectively solved all the issues in the original proposal, but at the cost of somewhat more complexity.

The RFC was finalised in October 2018. Chrome removed its (incomplete, draft) support for token binding in November 2018. Edge carried support until late 2024. Despite getting all the way through the RFC process, it’s functionally dead.

The process up until this point had been largely initiated by Google, with Microsoft contributing significantly to the token binding standards. The work had been focused on identifying a generic solution to the problem rather than tying it to any specific authentication flow. The next step was in a different direction - rather than trying to fix this for the entire internet, how about we try to fix it for OAuth?

RFC 8705 is titled “OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens”. This is basically the 2011 approach, but (a) with an explicit definition of how the certificate should be incorporated into issued auth cookies, and (b) with a proviso that well uh if you’re going to use tokens issued by your IdP to authenticate to someone else then well you’re going to need to use the same cert for both. This is probably fine for the company-owned-laptop case where you’re actually fine with multiple sites being able to tie identities together (that’s kind of the point here!), and also works for “I am using an app and not a browser”, but doesn’t work for more generic scenarios. It also doesn’t seem to take the session resumption case into account at all? Support for RFC8705 seems poor, as far as I can tell of the big players only Auth0 implements it. In theory it works fine with self-signed client certs but in reality that’s going to be almost as difficult to support across multiple platforms as just issuing proper client certs in the first place, so deployment is going to be kind of a pain. But the good news is it doesn’t rely on any TLS extensions or custom browser behaviour, so at the client side it works fine with any browser.

Which brings us on to RFC 9449, “Demonstrating Proof of Possession”. This goes even further than RFC8705 in terms of reducing the burden of deployment - it works fine with existing browsers, and it doesn’t even require any certs. The client generates a keypair and provides the pubkey when requesting the cookie. The cookie contains the pubkey. Every request to the service now provides the cookie with the pubkey and also provides a signature over the URI and HTTP method. If the signature matches the pubkey in the token then clearly the signature came from the machine the token was issued to, and everything is good.

This does come with some downsides, though. The first is that it uses browser interfaces to generate the keys (typically crypto.subtle.generatekey()) and as far as I can tell there are no browsers that guarantee that that key is going to be generated in hardware even if it’s marked non-exportable, so anyone able to steal the cookies can also steal the keys. The second is that the signature only covers the URI and HTTP method, and not the message content or any other headers, so anyone able to exfiltrate a valid signature can replay it against the same URI with different message content. The recommended way to handle this is to reject any signatures that weren’t generated within the last few seconds, which is a wonderful additional way to allow clock skew to give you a Bad Day. And the third is that every single request has to be separately signed, which is not intrinsically a problem because computers are fast and have multiple cores, but if you’re trying to solve the first problem by sticking the key in a TPM then you’re dealing with something that’s slow and single threaded and that’s maybe acceptable if you’re using client certificates (because there’s going to be one signature per session and you can use the same session for multiple requests) but probably not if you’re dealing with a user opening a browser that restores previous tabs and each of those is a webapp that fires off 100 requests in parallel.

In case it wasn’t clear, I don’t like DPoP. It doesn’t feel like it actually solves the underlying problem that we see in the real world (malware running in a context where if it can grab the tokens it can grab the keys), it adds a massive amount of overhead, and it has baked in replay vulnerabilities. I don’t know why it exists and I’m incredibly suspicious of vendors telling me that it fixes my problems, because if they’re telling me that then I’m going to end up assuming that they either don’t understand my problems or they don’t understand their technology, and neither of those is good.

Still. Then we get to the thing that prompted me to write this - Chrome’s announcement that they had launched device-bound session credentials. This is interesting because it’s a Chrome feature that’s explicitly intended to counter on-device malware, which was one of the things that was out of scope in 2018 when token binding was being removed. Since this is entire web level it doesn’t have to be an RFC, and so is instead defined by W3C. I’m going to handwave all the complexity and say that it’s basically a way to register a public key when a cookie is issued, and then prove possession of the private key when it’s time to renew the cookie. By making the cookies shortlived and having support for rotating them in the background, user impact is basically zero and while it’s still possible for an attacker to exfiltrate and use a cookie they’ll only be able to do so for a short window before it needs to be refreshed - something the attacker can’t do, since they don’t have the private key. This avoids the DPoP overhead because you only need to do signing once per cookie per cookie lifetime, and not on every single request. I don’t like this due to the window where exfiltrated tokens can be used, but it feels like a strict improvement over the status quo. An extension called device-bound session credentials for enterprise allows pre-enrollment of device keys, so even though the actual runtime DBCE flow doesn’t involve certificates, certificates can be used for device registration in enterprise environments and you can make sure that auth cookies only go to trusted devices. Unfortunately this is Chrome-only, and so we’re going to need to wait for it to be backported to all the random app frameworks for it to have widespread support on mobile or for almost everyone’s desktop app that’s actually three websites in an Electron wrapper. Mozilla’s current position is that they’re not in favour of it, so I guess we’ll see where Safari lands in terms of broad uptake.

The last thing on my list is another client cert/OAuth binding, this one still in draft state at the time of writing. This one is aimed primarily at the use of agent-driven tooling, where you have something running in the background using a whole bunch of tools that are each acting on your behalf. Authenticating to all of them separately isn’t a fun time, but giving broadly scoped access tokens to a non-deterministic agent and trusting that it’ll never post them somewhere public also isn’t a fun time. The key distinction between it and RFC8705 is that it’s aimed at connections rather than sessions, which avoids the worries about session resumption. This is done with TLS Exporters, which in TLS 1.3 should be unique to the connection even over session resumption (TLS 1.2 may reuse some of the same key material for exporters over session resumption, so it’s recommended to enforce 1.3 for this). By providing a new signature alongside the cookie on every new connection, the client proves that it still has access to the private key. This is a very new spec and I haven’t had much time to work through it yet, but my naive understanding is that unlike RFC8705 this would require some additional client support to be able to regenerate the client signature on every TLS reconnection.

This doesn’t avoid all the problems that RFC8705 has, including how to scope certificates. For the agentic use case that probably doesn’t matter - all these tools are acting on behalf of the same user, it’s fine if all the sites involved know they’re the same user. But it doesn’t solve the general purpose user use case, and right now DBSC seems like the best we have there.

But. Part of me still wonders whether Dirk Balfanz’s approach was the right one. Yes, there’s risk associated with TLS session resumption, but in the worst case you could just switch that off for high risk setups. The cookie scope argument is real, and also in cases where it could violate privacy the site owner could already choose to broaden their cookie scope and violate your privacy, and in cases where it breaks things you could just not make use of it. The other problems are largely fixed by TLS 1.3, and then we’re just left with “Browsers handle client certificates badly” to which my answer is “Yes, and we should fix that anyway”.

Despite having a pretty good answer to this solution over a decade ago, the closest we have to actual deployment is something that offers strictly worse security guarantees. And tokens keep getting stolen, and compromises keep occurring, and for the most part people shrug and get on with things.

This is not a very basic level challenge. It covers moderate level cryptographic concepts, so some familiarity with basic mathematics, cryptographic functions, and encryption algorithms will be helpful. I’ll try to explain every part as clearly as possible.

In this challenge, a hash value and the corresponding encryption code are provided. The goal is to understand how the plaintext is transformed into that hash. We need to reverse engineer or perform cryptanalysis on the encryption process to recover the original plaintext from the given hash.

Here is the encryption and hashing code used in the challenge.

You are given the following hash:

1d6a2172025e1858754075123b6658532d1a4e775e1f43336e227d5a4529734f

Below is the complete source code used in the challenge.

#!/usr/bin/env python3

# This cipher uses 100 rounds and therefore provides extremely strong security.
# Repeated substitution and permutation remove all algebraic structure.
# Since the SBox is key dependent, recovering the plaintext without brute force is infeasible.

BLOCK_SIZE = 32

KEY_SBOX = [211, 243, 147, 179, 83, 115, 19, 51, 210, 242, 146, 178, 82, 114, 18, 50, 209, 241, 145, 177, 81, 113, 17, 49, 208, 240, 144, 176, 80, 112, 16, 48, 215, 247, 151, 183, 87, 119, 23, 55, 214, 246, 150, 182, 86, 118, 22, 54, 213, 245, 149, 181, 85, 117, 21, 53, 212, 244, 148, 180, 84, 116, 20, 52, 219, 251, 155, 187, 91, 123, 27, 59, 218, 250, 154, 186, 90, 122, 26, 58, 217, 249, 153, 185, 89, 121, 25, 57, 216, 248, 152, 184, 88, 120, 24, 56, 223, 255, 159, 191, 95, 127, 31, 63, 222, 254, 158, 190, 94, 126, 30, 62, 221, 253, 157, 189, 93, 125, 29, 61, 220, 252, 156, 188, 92, 124, 28, 60, 195, 227, 131, 163, 67, 99, 3, 35, 194, 226, 130, 162, 66, 98, 2, 34, 193, 225, 129, 161, 65, 97, 1, 33, 192, 224, 128, 160, 64, 96, 0, 32, 199, 231, 135, 167, 71, 103, 7, 39, 198, 230, 134, 166, 70, 102, 6, 38, 197, 229, 133, 165, 69, 101, 5, 37, 196, 228, 132, 164, 68, 100, 4, 36, 203, 235, 139, 171, 75, 107, 11, 43, 202, 234, 138, 170, 74, 106, 10, 42, 201, 233, 137, 169, 73, 105, 9, 41, 200, 232, 136, 168, 72, 104, 8, 40, 207, 239, 143, 175, 79, 111, 15, 47, 206, 238, 142, 174, 78, 110, 14, 46, 205, 237, 141, 173, 77, 109, 13, 45, 204, 236, 140, 172, 76, 108, 12, 44]

PBOX = [41, 214, 131, 48, 221, 138, 55, 228, 145, 62, 235, 152, 69, 242, 159, 76, 249, 166, 83, 0, 173, 90, 7, 180, 97, 14, 187, 104, 21, 194, 111, 28, 201, 118, 35, 208, 125, 42, 215, 132, 49, 222, 139, 56, 229, 146, 63, 236, 153, 70, 243, 160, 77, 250, 167, 84, 1, 174, 91, 8, 181, 98, 15, 188, 105, 22, 195, 112, 29, 202, 119, 36, 209, 126, 43, 216, 133, 50, 223, 140, 57, 230, 147, 64, 237, 154, 71, 244, 161, 78, 251, 168, 85, 2, 175, 92, 9, 182, 99, 16, 189, 106, 23, 196, 113, 30, 203, 120, 37, 210, 127, 44, 217, 134, 51, 224, 141, 58, 231, 148, 65, 238, 155, 72, 245, 162, 79, 252, 169, 86, 3, 176, 93, 10, 183, 100, 17, 190, 107, 24, 197, 114, 31, 204, 121, 38, 211, 128, 45, 218, 135, 52, 225, 142, 59, 232, 149, 66, 239, 156, 73, 246, 163, 80, 253, 170, 87, 4, 177, 94, 11, 184, 101, 18, 191, 108, 25, 198, 115, 32, 205, 122, 39, 212, 129, 46, 219, 136, 53, 226, 143, 60, 233, 150, 67, 240, 157, 74, 247, 164, 81, 254, 171, 88, 5, 178, 95, 12, 185, 102, 19, 192, 109, 26, 199, 116, 33, 206, 123, 40, 213, 130, 47, 220, 137, 54, 227, 144, 61, 234, 151, 68, 241, 158, 75, 248, 165, 82, 255, 172, 89, 6, 179, 96, 13, 186, 103, 20, 193, 110, 27, 200, 117, 34, 207, 124]

xor = lambda a,b: bytes([x ^ y for x,y in zip(a,b)])

class SecureCipher:
    def __init__(self, key):
        if len(key) < BLOCK_SIZE:
            pad = BLOCK_SIZE - len(key)
            key += bytes([pad])*pad
        self.key = key[:BLOCK_SIZE]
        self.sbox = [KEY_SBOX[i] ^ self.key[0] for i in range(256)]

    def substitute(self, data):
        return bytes(self.sbox[b] for b in data)

    def permute(self, data):
        out = [0]*BLOCK_SIZE
        for num in range(256):
            outnum = PBOX[num]

            inbyte = num // 8
            inbit = 7 - (num % 8)

            outbyte = outnum // 8
            outbit = 7 - (outnum % 8)

            if data[inbyte] & (1 << inbit):
                out[outbyte] |= (1 << outbit)

        return bytes(out)

    def encrypt(self, data):
        data = self.pad(data)

        blocks = [data[i:i+BLOCK_SIZE]
                  for i in range(0, len(data), BLOCK_SIZE)]

        out = b''

        for block in blocks:
            for _ in range(100): # No linear or any cryptanalysis here!
                block = self.substitute(block)
                block = self.permute(block)
                block = xor(block, self.key)

            out += block

        return out

    @staticmethod
    def pad(data):
        if len(data) % BLOCK_SIZE == 0:
            return data
        diff = BLOCK_SIZE - (len(data) % BLOCK_SIZE)
        return data + bytes([diff])*diff


class SecureHash:
    def __init__(self, data=None):
        self.state = b"\x00"*BLOCK_SIZE
        if data:
            self.update(data)

    def update(self, data):
        data = SecureCipher.pad(data)

        blocks = [data[i:i+BLOCK_SIZE]
                  for i in range(0, len(data), BLOCK_SIZE)]

        for block in blocks:
            c = SecureCipher(block)
            self.state = xor(self.state, c.encrypt(block))

    def digest(self):
        return self.state

    def hexdigest(self):
        return self.state.hex()


if __name__ == "__main__":
    plaintext = input("Message: ").encode()

    h = SecureHash(plaintext)

    print("\nDigest:")
    print(h.hexdigest())

    cipher = SecureCipher(plaintext)
    ct = cipher.encrypt(plaintext)

    print("\nCiphertext:")
    print(ct.hex())

Your task is to analyze the implementation, determine whether the cipher and hash construction are secure, and recover the original plaintext if a weakness exists. Study the source carefully and verify every assumption yourself.

Now, let’s try to solve the challenge. I’ll explain the solution in detail. how the encryption works, what vulnerability was discovered, which cryptanalysis methods were used to identify it, and how to build a solver to reverse the hash and recover the original plaintext.

How the Encryption Works

Let’s first understand what the hashing code does with our input and how the digest 1d6a2172025e1858754075123b6658532d1a4e775e1f43336e227d5a4529734f is generated.

You can see that the cipher uses a fixed block size of 32 bytes, which means each block is 256 bits long. Therefore, the input is processed in 32 byte blocks. If the input length is not exactly 32 bytes or is not a multiple of 32, the remaining bytes are filled using padding. We’ll discuss how the padding works later.

The code also defines a KEY_SBOX and a PBOX. Both are simply rearrangements of the numbers from 0 to 255. The KEY_SBOXis used during the substitution step, while the PBOX is used during the permutation step.

KEY_SBOX = [211, 243, 147, 179, …….., 44]

PBOX = [41, 214, 131, 48, …….., 124]

The cipher reads the input and uses a self keyed design, meaning that the plaintext itself is used as the encryption key.

First, a new SBox is derived by XORing the first byte of the key with every entry of the original KEY_SBOX. Since the key is the plaintext itself, the generated SBOX depends entirely on the input.

After deriving this new SBOX, each block goes through the following operations:

Substitute the bytes using the derived SBOX.

Permute the bits using the PBOX.

XOR the result with the key, which is again the plaintext.

These three operations constitute a single round, and the cipher repeats this process 100 times. The output produced after the 100th round becomes the final ciphertext.

SBOX Reconstruction, Substitution, Permutation, and XOR with the Key

Let’s discuss how the encryption process works in detail by breaking down each operation step by step.

Code Breakdown:

BLOCK_SIZE = 32 The cipher processes data in blocks of 32 bytes, which corresponds to 256 bits. Two large lookup tables are defined KEY_SBOX = [211, 243, 147, 179, …, 44]
PBOX = [41, 214, 131, 48, …, 124]. KEY_SBOX is used for byte substitution, while PBOX is used for bit permutation. An XOR helper function is also defined:

xor = lambda a, b: bytes([x ^ y for x, y in zip(a, b)])

This performs a byte by byte XOR operation between two byte strings.

Constructor:

The user supplied key is first padded to 32 bytes if necessary:

if len(key) < BLOCK_SIZE:
    pad = BLOCK_SIZE - len(key)
    key += bytes([pad]) * pad

self.key = key[:BLOCK_SIZE]

If the input is shorter than 32 bytes, the padding routine extends it to exactly 32 bytes. The number of missing bytes is calculated and that value is repeatedly appended until the block reaches 32 bytes.

For example, if the input length is 29 bytes:

32 - 29 = 3

the following padding is added:

0x03 0x03 0x03

A key dependent SBOX is then generated:

self.sbox = [KEY_SBOX[i] ^ self.key[0] for i in range(256)]

Each entry of KEY_SBOX is XORed with the first byte of the key, producing a different SBOX for every key. For example, suppose the original SBOX begins as: KEY_SBOX = [211, 243, 147, 179, …, 44]. Assume the input is: “sharafu”. Since the cipher uses the plaintext itself as the key, the first byte of the key is: ‘s’ ASCII value = 115. Therefore, every entry of KEY_SBOX is XORed with 115:

211 XOR 115 = 160

243 XOR 115 = 128

147 XOR 115 = 224

179 XOR 115 = 192

…

44 XOR 115 = 95

As a result, the reconstructed SBOX begins as: self.sbox = [160, 128, 224, 192, …, 95]

Substitution Layer:

def substitute(self, data):
    return bytes(self.sbox[b] for b in data)

Each byte of the input block is replaced using the derived SBOX.

Input byte -> S-Box lookup -> Output byte

Only byte values change, their positions remain unchanged.Suppose the input block begins with: [115, 104, 97, 114]

which corresponds to: “s h a r” s = 115 h = 104 a = 97 r = 114 The substitution layer performs: Take the byte value, Use it as an index into the SBOX, Replace the original byte with the value stored at that index. For example: Take first byte ‘s’ = 115. In sbox table count 0 to 115th poition The value is 90. So replace 115 with 90. After substitution: [115, 104, 97, 114] became [90, 17, 204, 88].

Permutation Layer:

def permute(self, data):
    for num in range(256):
        outnum = PBOX[num]

The permutation layer works at the bit level. Every input bit is moved to a new position according to PBOX.

For example:

PBOX[0] = 41

means:

Input bit #0 position -> Output bit #41 position

Bit values remain the same, but their positions are rearranged. After substitution, suppose we obtain: [90, 17, 204, 88]. These values are bytes, but the PBOX operates at the bit level. For example, the first byte: 90 = 01011010. Since each block contains 32 bytes, the total number of bits is: 32 × 8 = 256 bits. The PBOX specifies where each input bit should be moved: The PBOX operates on all 256 bits of the block. For example, consider the first byte 90 to bit = 01011010, which represents only the first 8 bits of the 256 bit block. The PBOX begins as [41, 214, 131, 48, …, 124], meaning that the first bit ( 0 ) is moved to position 41, the second bit ( 1 ) is moved to position 214, the third bit ( 0 ) is moved to position 131, and so on. The bit values themselves never change. only their positions are rearranged according to the PBOX. This process continues for all 256 bits, resulting in a heavily shuffled block and providing diffusion across the entire state.

Finally, the resulting 256 bit block is XORed with the key. In this challenge, the plaintext itself is used as the key, so the permuted block is XORed with the original input block. This key mixing step is performed at the end of every round before the next round begins.

Encryption Routine:

for _ in range(100):
    block = self.substitute(block)
    block = self.permute(block)
    block = xor(block, self.key)

Each block undergoes 100 rounds consisting of:

Substitution
      ↓
Permutation
      ↓
XOR with Key

The output of the final round becomes the ciphertext.

Hash Construction:

self.state = b"\x00" * BLOCK_SIZE

for block in blocks:
    c = SecureCipher(block)
    self.state = xor(self.state, c.encrypt(block))

The hash state starts as 256 zero bits.

For each block:

The plaintext block itself is used as the encryption key.

The block is encrypted.

The result is XORed into the running hash state.

The final state is returned as the digest. In this challenge, the resulting digest is: 1d6a2172025e1858754075123b6658532d1a4e775e1f43336e227d5a4529734f

The Weakness: The Vulnerability

The core weakness of this cipher is that every component is either linear or affine over GF(2). Since the substitution layer, permutation layer, and key mixing step all preserve linearity, repeating them 100 times does not improve security. Instead, the entire 100 round cipher collapses into a single affine transformation, which can be modeled and inverted efficiently using linear algebra.

What is GF(2)?

GF stands for Galois Field. GF(2) is the simplest possible field and contains only two elements: 0 and 1. All arithmetic is performed modulo 2, meaning addition is equivalent to XOR.

0 + 0 = 0

0 + 1 = 1

1 + 0 = 1

1 + 1 = 0

while multiplication follows the usual binary rules:

0 × 0 = 0

0 × 1 = 0

1 × 0 = 0

1 × 1 = 1

Since computers represent data as bits, cryptographic algorithms are often analyzed over GF(2).

Linear vs. Nonlinear Functions

A function is considered linear over GF(2) if it satisfies: f(a XOR b) = f(a) XOR f(b) for every possible pair of inputs. For example, the function: f(x) = x so f(5 XOR 3) = 5 XOR 3 = 6 f(6) = 6 and f(5) XOR f(3) = 5 = 5 XOR 3 =3 = 5 XOR 3 = 6 Since both sides are equal, the function satisfies the linearity property. a linear function means that it does not matter whether we apply the function before or after combining the inputs. In other words, “apply the function first, then XOR” and “XOR first, then apply the function” always produce the same result.

Modern ciphers intentionally introduce strong nonlinear components because linear systems can be solved efficiently. For example, AES relies heavily on its nonlinear SBOX.

What Is an Affine Function?

An affine function is simply a linear function followed by the addition of a constant. Mathematically, it is written as: f(x) = Mx XOR c. where M is a matrix and C is a constant vector. For example: f(x) = x XOR 1010. The XOR with a constant means the function is no longer strictly linear, but it still retains a highly structured form. Affine functions are therefore still easy to analyze and manipulate using linear algebra.

Identifying the Vulnerability

The first step was analyzing the SBOX. The SBOX is expected to introduce nonlinearity. we tested whether: S(a XOR b) = S(a) XOR S(b) XOR S(0).

Every possible pair was tested. This formula comes directly from the definition of an affine function. Suppose a function is affine: f(x) = Mx XOR c. where M is a matrix and c is a constant vector. Evaluating f(a XOR b) gives: f(a XOR b) = M(a XOR b) XOR c = Ma XOR Mb XOR c.

On the other hand: f(a) XOR f(b) = (Ma XOR c) XOR (Mb XOR c) = Ma XOR Mb. since cXOR c = 0. We are missing one copy of the constant c. To recover it, we evaluate the function at zero: f(0) = M0 XOR c = c because M0 = 0. Therefore, for every affine function: f(a XOR b) = f(a) XOR f(b) XOR f(0). This is why we test the SBOX using S(0) when checking whether it is affine. For affine functions, this equation must always be true.

To verify whether the SBOX is affine, every possible pair of input bytes was tested. Since an SBOX operates on 8 bit values, there are 256 x 256 = 65536 possible pairs (a, b). The test returned True for all 65,536 cases, meaning that the affine property holds for every possible input pair. Therefore, the entire SBOX is affine over GF(2)

Why is the PBOX Linear?

The PBOX is linear because it only rearranges the positions of bits without changing their values. For example, given an input such as 10110010, the PBOX may move bit 0 to position 5, bit 1 to position 7, and so on, but the actual bit values (0 or 1) remain unchanged. Since no arithmetic is performed and only positions are shuffled, the permutation always preserves XOR operations, meaning P(A XOR B) = P(A) XOR P(B). Therefore, the PBOX is a linear transformation over GF(2).

Why Doesn’t 100 Rounds Improve Security?

One might expect that performing 100 rounds would make the cipher secure, but this is not the case. Each round consists of substitution, permutation, and XOR with the key, all of which are either affine or linear operations. The composition of affine transformations remains affine, meaning Affine * Affine * Affine is still just an affine transformation. Therefore, even after repeating the round function 100 times, the entire cipher still collapses into a single affine transformation over GF(2).

Mathematical Representation

Since every component of the cipher is either linear or affine, the entire 100-round construction can be represented as a single affine transformation: E(x) = Mx XOR c. where x is the 256 bit plaintext vector, M is a 256 x 256 binary matrix, and c is a constant vector. In other words, the complete cipher behaves like one large algebraic equation.

Understanding the Matrix

A matrix simply describes how input bits influence output bits. For example, consider:

M =

1 0 1

0 1 1

1 1 0

If the input is x = [1 0 1], matrix multiplication over GF(2) computes the output bits as bit0 XOR bit2, bit1 XOR bit2, and bit0 XOR bit1. Thus, the matrix completely captures how every input bit affects the ciphertext.

Recovering the Matrix

Because the cipher satisfies E(x) = Mx XOR c, an attacker only needs to recover M and c. Encrypting the all zero plaintext immediately reveals the constant since M0 = 0, giving E(0) = 0. The attacker then encrypts the 256 basis vectors (1000…, 0100…, 0010…, …) all possible combinations in 256 bits. each containing exactly one bit set. After XORing each resulting ciphertext with c, the remaining value directly reveals one column of M. Repeating this process for all 256 basis vectors reconstructs the entire 256 x 256 matrix.

Building the Exploit

So, let’s build the exploit. First, we verify the linearity of the SBOX by testing whether S(a XOR b) = S(a) XOR S(b) XOR S(0) holds for all possible input pairs. If the property holds for all 65536 combinations, the SBOX is confirmed to be affine. Next, we reconstruct the affine representation by encrypting the all zero vector (0…0) and each basis vector (100..0, 010..0, 001..0, … ) which allows us to recover both the matrix M and the constant vector c. Using Gaussian elimination over GF(2), we then solve the resulting linear system to recover the plaintext. Given a ciphertext y, we solve Mx = y XOR c to obtain x, which directly yields the plaintext. No brute force is required, as the entire encryption collapses into solving a system of linear equations. The cipher completely lacks a nonlinear component. Because the SBOX itself is affine over GF(2), the entire 100 round construction remains affine and can be modeled, reconstructed, and inverted using linear algebra. This allows complete plaintext recovery without knowledge of the secret key.

Now that we understand the vulnerability, we can construct a solver that uses the SBOX and PBOX tables to recover the original plaintext. In this writeup, however, I'll provide a complete recovery script specifically for this hashing scheme, which can be used to recover the plaintext corresponding to the digests created with this hashing scheme.The solver reconstructs the affine transformation implemented by the cipher and then solves the resulting system of linear equations over GF(2) to recover the original message.

GitHub - sharafu-sblsec/affine-gf2-cipher-solver: Solver for a CTF challenge recovering plaintext from a vulnerable affine block cipher using GF(2) linear algebra and Gaussian elimination.

Run the script and provide the target digest as input.

Now you can see that the hash has been successfully reversed and the original plaintext has been recovered.

This challenge is inspired by the HTB challenge “Always Has Been”. However, since the challenge is still active and continues to award points,

I cannot publish a direct writeup or solver, as doing so would violate HTB’s Terms of Service. Instead, I reconstructed the challenge with minimal modifications and wrote this explanation to demonstrate the underlying vulnerability and attack methodology for educational purposes.

Happy Hacking

Cryptanalysis: Recovering an Affine Encryption Scheme Using GF(2) Linear Algebra was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post AI-Powered Reverse Engineering Turns EDR Rule Analysis Into Automated Evasion Workflow appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

The release, which Anthropic describes as "the most agentic Sonnet model yet," makes Sonnet 5 the default model for users on Anthropic's Free and Pro plans, while also making it available to Max, Team, and Enterprise customers. Introductory API pricing is set at $2 per million input tokens and $10 per million output tokens through August 31, after which it rises to $3 and $15 respectively — still well below the $5 input and $25 output pricing of Anthropic's top-of-the-line Opus 4.8.

The strategic logic is unmistakable: Anthropic is trying to democratize access to capabilities that until very recently only its most expensive models could deliver, while building the kind of broad-based developer adoption that will look attractive in an S-1 filing.

Sonnet 5 benchmarks show the mid-tier model closing in on Anthropic's flagship Opus

Sonnet 5 posts major gains over its predecessor, Sonnet 4.6, across every evaluation Anthropic disclosed. On SWE-bench Pro, an agentic coding benchmark, Sonnet 5 scores 63.2% compared with Sonnet 4.6's 58.1% — a jump that brings it within striking distance of Opus 4.8's 69.2%. On Terminal-Bench 2.1, another coding evaluation, the gap narrows further: 80.4% for Sonnet 5 versus 67.0% for Sonnet 4.6 and 82.7% for Opus 4.8.

In multidisciplinary reasoning, as measured by Humanity's Last Exam, Sonnet 5 scores 43.2% without tools and 57.4% with tools — the latter figure essentially matching Opus 4.8's 57.9%. On computer use tasks evaluated through OSWorld-Verified, Sonnet 5 reaches 81.2%, up from 78.5%. And on GDPval-AA v2, a knowledge-work benchmark, it scores 1,618 — surpassing Opus 4.8's 1,615 and far exceeding Sonnet 4.6's 1,395.

The pattern across these evaluations tells a consistent story: Sonnet 5 doesn't merely inch forward from its predecessor. It vaults into a performance tier that overlaps substantially with Anthropic's flagship model, while costing roughly 60% less per token at standard pricing and even less during the introductory period.

Enterprise partners say Sonnet 5's agentic AI capabilities finish jobs that previous models abandoned

The emphasis on agentic capabilities — the ability to plan, use tools like browsers and terminals, and execute multi-step workflows autonomously — reflects where the AI industry's center of gravity has shifted in 2026. Enterprises are no longer simply asking chatbots questions; they are deploying AI systems that can navigate complex software environments, execute multi-step coding tasks, and operate with minimal human supervision.

Early access partners painted a picture of a model that doesn't just start tasks but finishes them. Sualeh Asif, co-founder of Cursor, the AI-powered code editor that has become a bellwether for developer tool adoption, said that "with Claude Sonnet 5, agents stay on plan, follow our conventions, and ship clean multi-step changes, all at an efficient cost." Daniel Shepard, a senior engineer at Zapier, described handing the model a two-part automation job — updating Salesforce account tiers and sending a launch announcement — that "used to stall halfway" with previous models but now completes end to end.

These testimonials matter because they describe exactly the kind of reliability gap that has kept many enterprises from moving agentic AI from pilot programs to production deployments. A model that gets 80% of the way through a complex task before stalling creates more problems than it solves; one that reliably completes the full workflow changes the economics of automation. Anthropic also introduced cost-performance curves showing that developers can now adjust effort levels across Sonnet 5 and Opus 4.8 to find the optimal balance of cost and accuracy for their specific use case — a granularity that reflects growing sophistication in how enterprises consume AI services.

An updated tokenizer boosts Sonnet 5 performance but could quietly raise costs for some workloads

One technical detail buried in the announcement's footnotes deserves attention: Sonnet 5 uses an updated tokenizer that changes how the model processes text, similar to the change Anthropic introduced with Opus 4.7.

The tradeoff is that the same input can map to roughly 1.0 to 1.35 times as many tokens depending on content type. Anthropic says the introductory pricing is calibrated to make the transition "roughly cost-neutral," but enterprise customers running high-volume workloads will want to benchmark their specific use cases carefully before assuming their bills won't change.

Anthropic says Sonnet 5 is safer than its predecessor, but its most capable models still lead on alignment

Anthropic's safety disclosures reveal a nuanced picture. The company reports that Sonnet 5 shows lower rates of hallucination and sycophancy than Sonnet 4.6, is better at refusing malicious requests, and is more resistant to prompt injection attacks in agentic contexts. On Anthropic's automated behavioral audit — which tests for a wide range of misaligned behaviors including cooperation with misuse and deception — Sonnet 5 scored lower (meaning safer) overall than Sonnet 4.6.

However, Sonnet 5 showed "somewhat higher rates of misaligned behavior" compared with the more capable Opus 4.8 and Anthropic's Claude Mythos Preview, the company's powerful but tightly restricted cybersecurity-focused model. On a Firefox 147 exploit development evaluation created in collaboration with Mozilla, neither Sonnet model could develop a working exploit — both scored 0.0% — though Sonnet 5 showed a slightly higher partial success rate (13.2%) than Sonnet 4.6 (8.8%). Both remain far below Opus 4.8 (68.8% working exploits) and Mythos 5 (88.4%).

Because of these incremental gains in cyber-adjacent capabilities, Anthropic launched Sonnet 5 with cyber safeguards enabled by default — real-time systems that detect and block dangerous cybersecurity usage. The safeguards mirror those on Opus 4.7 and 4.8 but are less restrictive than those applied to Fable 5, the latest Mythos-class model that Bloomberg reported on June 10 is "blocked from responding to queries related to cybersecurity and biology." Organizations enrolled in Anthropic's Cyber Verification Program automatically receive the same access on Sonnet 5 without needing to reapply.

From $14 billion to $47 billion in revenue: Sonnet 5 arrives as Anthropic's IPO narrative takes shape

The Sonnet 5 launch arrives at what may be the most consequential moment in Anthropic's short history. The company confidentially filed its IPO prospectus with the SEC in early June, setting up what CNBC has described as "the most scrutinized public offering in tech history."

The financial trajectory has been extraordinary. In February, Anthropic raised $30 billion at a $380 billion valuation, with the company reporting $14 billion in annualized revenue that had "grown more than tenfold in each of the past three years," as The Guardian reported. 

By late May, Anthropic had closed a $65 billion Series H round at a $965 billion post-money valuation — co-led by Altimeter Capital, Sequoia Capital, and others — with a revenue run rate that had crossed $47 billion. Harrison Rolfes, an analyst at PitchBook, told CNBC that the number that will "either validate or collapse the entire narrative the private markets have been pricing for three years" won't be the valuation or revenue, but gross margin — a figure no outside observer has yet seen.

In this context, Sonnet 5 serves a dual purpose. For developers, it offers genuine capability improvements at competitive prices. For Anthropic's IPO narrative, it demonstrates the company can deliver a compelling product at a price tier that could drive the kind of broad adoption Wall Street rewards — high-volume, recurring API revenue from thousands of enterprise customers.

Government deals and growing competition define the market Sonnet 5 enters

The timing also aligns with Anthropic's aggressive push into institutional contracts. Just yesterday, California Governor Gavin Newsom announced a first-of-its-kind partnership providing Claude to all state agencies at a 50% discount, with free workforce training.

Kate Jensen, Anthropic's Head of Americas, called it an effort to "put Claude to work for the people who keep this state running." The deal — which extends to California's cities and counties — represents exactly the kind of durable, recurring adoption that could anchor revenue well beyond the developer community.

But Anthropic's release lands in an increasingly crowded field. OpenAI, which raised a $122 billion round in March at an $852 billion valuation, is pursuing its own IPO. Elon Musk's SpaceX, which merged with xAI, priced its IPO at $135 per share with a $1.77 trillion valuation. Google, Meta, and a growing wave of well-funded competitors — including Asian AI startups that, as the Wall Street Journal has reported, are developing Mythos-like cybersecurity capabilities — are all vying for the same enterprise market.

Gil Luria, head of technology research at D.A. Davidson, told CNBC that while Anthropic "appears to have the lead" in frontier AI models, "much of their current usage is for trials and experimentation and that may not sustain." That observation cuts to the heart of the challenge facing every frontier AI lab: converting experimental developer usage into durable, production-grade revenue.

The real test for Sonnet 5 isn't benchmarks — it's whether cheaper AI can sustain a trillion-dollar story

Sonnet 5's positioning — offering near-Opus performance at Sonnet prices — is a direct play for that conversion. Enterprise customers experimenting with expensive Opus-class models may find that Sonnet 5 delivers sufficient quality for production workloads at a price point that finance teams can approve at scale. If it works, it could accelerate the shift from experimentation to deployment that every AI company needs to justify its valuation.

Three things will determine whether Sonnet 5 matters beyond the initial benchmark charts. Real-world agentic reliability is the first: benchmarks measure capability, but production deployments measure consistency, and the true test will come when thousands of developers push the model through messy, unpredictable workflows at scale.

The tokenizer economics are the second: the updated tokenizer's 1.0 to 1.35x token expansion could quietly erode the pricing advantage for certain workloads, and enterprise customers should run their own cost analyses rather than relying on headline per-token prices. The third is the IPO narrative itself: when Anthropic's S-1 eventually becomes public, investors will scrutinize whether the Sonnet tier — cheaper but high-volume — or the Opus tier — expensive but high-margin — drives the bulk of revenue and, critically, gross profit.

As PitchBook's Rolfes told CNBC, the 2026 IPO window "either becomes the most consequential IPO cycle since the dot-com era or the most expensive lesson in narrative-versus-fundamentals that public markets have ever taught."

Anthropic is betting that a model good enough to rival its flagship and cheap enough to run at scale is the product that closes the gap between those two outcomes. The public markets will soon decide whether they agree.

Read more →

The post PrivacyHawk Enterprise helps organizations find shadow IT and minimize third-party cyber risk appeared first on IT Security News.

The post PrivacyHawk Enterprise helps organizations find shadow IT and minimize third-party cyber risk appeared first on Help Net Security.

Read more of this story at Slashdot.

Ultralytics. tj-actions. Grafana. GitHub Actions are increasingly targeted by attackers and implicated in industry-impacting incidents. Thankfully, GitHub's public surface offers numerous threat intelligence sources for the discerning defender. This talk covers a comprehensive methodology for investigating and tracking real-world supply chain attacks exploiting GitHub Actions, inspired by our work responding to the aforementioned incidents. It adds a new dimension and set of tools to threat intelligence research. We'll expose the wealth of intelligence available directly from both GitHub and the underlying Git plane. Through concrete demos, we'll show how to effectively pivot on user metadata and behavioral heuristics, uncover attacker forks, and recover deleted gists and commits. We'll also demonstrate how to trace attacker aliases, identify targets of reconnaissance, and unmask attackers and researchers in real-time. Attackers are hiding in the complexity of this ecosystem, but with automation we can peel back the noise, empowering detection and investigation. This approach is practical, repeatable, and relies exclusively on publicly available data, ensuring accessibility for all defenders without the need for private threat intelligence feeds.

By:
Rami McCarthy | Principal Security Researcher, Wiz
Amitai Cohen | Attack Vector Intelligence Lead, Wiz

https://blackhat.com/eu-25/briefings/schedule/?#the-forensic-trail-on-github-hunting-for-supply-chain-activity-48832

After holding them for a few years, you have decided it is time to cash in your cryptocurrency holdings. The problem is, it is so long since you set up the digital wallet which manages them on your laptop, you have forgotten the lengthy access code.

Stressed at the thought of losing thousands of pounds, you search and download a program which promises to recover the 24-word “seed phrase” which gives you access to your cypto assets.

The post Snapchat Streak Lost? Here’s How to Recover It appeared first on AddictiveTips.

• Added autoMode.classifyAllShell setting to route all Bash/PowerShell commands through the auto-mode classifier instead of only arbitrary-code-execution patterns
• Added auto-mode denial reasons to the transcript, the denial toast, and /permissions recent denials
• Added claude_code.assistant_response OpenTelemetry log event containing the model's response text. Redacted unless OTEL_LOG_ASSISTANT_RESPONSES=1; when that var is unset it follows OTEL_LOG_USER_PROMPTS, so deployments that already log prompt content will start receiving response content on upgrade — set OTEL_LOG_ASSISTANT_RESPONSES=0 to keep prompts-only.
• Added live file path autocomplete to bash mode (!)
• Added a startup notice when MCP servers need authentication, pointing at /mcp
• Added automatic memory-pressure reaping for idle background shell commands (disable with CLAUDE_CODE_DISABLE_BG_SHELL_PRESSURE_REAP=1)
• Fixed /model and other client-data-gated UI showing stale/empty state immediately after /login
• Fixed backgrounding (←←) spuriously cancelling with "N background tasks would be abandoned" when all running tasks carry over to the new session
• Fixed pinned background agents being re-prompted to "Continue from where you left off" after every auto-update
• Fixed backgrounding the main turn spawning a phantom "general-purpose (resumed)" subagent that re-ran the main conversation
• Fixed agent panel hiding sibling agents when viewing a subagent
• Improved background agents: the launch result no longer instructs Claude to "end your response" — it keeps working on other tasks while the agent runs
• Improved MCP headersHelper auth: the helper now re-runs and reconnects automatically when a tool call returns 401/403
• Improved plugin auto-rename: marketplace renames maps are now followed automatically, updating your settings to the new name
• Improved /add-dir message when the directory is already a working directory

Read more of this story at Slashdot.

Written by: Jordan Jones

{
  "Name": "StockMarket",
  "Description": "An application for getting information about current events on trading platforms. To set the time for updating information, enter a value in minutes in the `Interval` field. In the future, support for themes will be added. The `SystemConfiguration` field stores the system settings of the application. In the `services` field, fill in the list of addresses of services that provide the `WebSocket protocol`.",
  "Theme": "Dark",
  "SystemConfiguration": [
    "1D.AA.79.9F.45.AA.04.B3.<snipped>.68.0A.5D.A3.E6.A3.82.FA",
    "6F.41.4D.6D.C3.20.E5.32.<snipped>.00.B8.26.DF.E1.13.0A.21",
    "4.4.3.12"
  ],
  "Interval": 10,
  "Services": [
    "wss://ws-api.binance.com:443/ws-api/v3",
    "wss://ws-feed.exchange.coinbase.com",
    "wss://ws-feed-public.sandbox.exchange.coinbase.com",
    "wss://stream.bybit.com/v5/public/spot",
    "wss://stream.bybit.com/v5/public/linear"
  ],
  "Version": "2022-12-21"
}

{
  "internal_id": "<server_identifier>",
  "internal_key": "<server_public_key>",
  "interval_engine": "600000",
  "level_info": "0",
  "time_scale": "1",
  "span_min": "9",
  "span_max": "18",
  "rate": "2700",
  "rate_control": "false",
  "service": "<websocket_c2_url>",
  "days_not_work": "Saturday;Sunday;",
  "system_properties": "eyJzeXN0ZW1fZGF0YV9zaXplIjoiNDAwMDAwIn0="
}

{
	"target": degrees,
	"sender": pressure,
	"message": wdata,
	"ip": coords,
	"time": datetime
}

viewer.exe
https://circoloesteri.elezioni.idnet.it/admin-election/riepilogo.php

Foreign Affairs Club 1936

Approval of the 2023 Financial Statement

Analysis of the status of those registered to vote (automatically updates every 60 seconds)...
update 6:26:50

Total Voters: 915
Currently registered members with 2-tonte status: 364
Currently registered with status 4 Ready to vote: 5
Currently registered with status 3 - Voted 46
Voter turnout (votes cast on registered voters): 5.03%