Monday, October 12, 2026

Docker Hub security advisory: personal access tokens transferred during account-to-organization conversions

On September 30, 2026, security researchers reported a vulnerability in Docker Hub’s identity and access management through our Vulnerability Disclosure Program. We confirmed the report and deployed a fix to production the same afternoon, less than four hours after receiving it. We then reviewed every account conversion back to the date the flaw was introduced, and on October 2, notified every user and organization owner whose account could have been impacted by this vulnerability. This post explains what the vulnerability was, what it could and could not do, what we found, and what we have changed.

We want to thank Peter Molnar and Krisztian Hozak of mptrdev.com for finding the issue, reporting it responsibly, and coordinating disclosure with us. Their technical write-up is available at ghostpat.com. This issue is tracked as CVE-2026-105445.

Was I or any member of my organization exposed to the vulnerability?

On October 2 at 5:30PM EST, we sent out an email with the subject line “Docker Hub Vulnerability Identified & Resolved” to the limited number of users exposed to this vulnerability. If you did not receive an email, you and any members of the organizations you administer were not exposed and there are no actions for you to take.

What the vulnerability was

Docker Hub lets you convert a personal account into an organization. People do this because Hub has no way to move a repository from one account to another: conversion is how alice/app becomes an organization-owned alice/app without breaking every Docker pull that references it. During conversion, the user names an existing Docker Hub account as the new organization’s owner.

Beginning  August 26, 2024, conversion also re-assigned the converted account’s personal access tokens (PATs) to that new owner. It did this by changing the token’s owner record, without rotating or revoking the token secret. The named owner was not asked to confirm and was not notified. Together, those two gaps made the following possible:

  1. An attacker creates an account and generates a PAT on it.
  2. The attacker converts that account to an organization and names a target user as the owner.
  3. The attacker’s PAT is re-assigned to the target user. The attacker still holds the secret and the PAT remains active now with the target user’s scope.
  4. The token now authenticates to the registry as the target user.

What an attacker could and could not do

Within the scope of the token, a re-assigned PAT acted as the target user at the registry level, meaning an attacker could potentially pull, push, and/or delete images in the target’s repositories and in organizations where the target had access. Because that includes publishing images under a legitimate name, we treated this as a software supply chain risk and rated it critical.

The vulnerability did not give access to the Docker Hub web interface, and it could not be used to change the target’s password, email address, or two-factor settings, or to take over the account.

The exposure window ran from August 26, 2024, 20:33 UTC, until the fix was deployed on September 30, 2026, at approximately [19:10] UTC.

Timeline (all times U.S. Eastern)

  • Sept 30, 11:40 AM: Report received at security@docker.com.
  • Sept 30, ~1:30 PM: We independently reproduced the issue with internal test accounts.
  • Sept 30, ~3:10 PM: Fix deployed to production and verified against the original proof of concept. Conversion no longer transfers PATs.
  • Sept 30, ~3:23 PM: Documentation updated to state that PATs do not transfer and must be recreated by the new owner, with organization access tokens recommended.
  • Sept 30, 4:59 PM: Researchers informed of the fix. Both parties agreed to coordinate disclosure.
  • Oct 2, 5:30 PM: Exposed users and their organization owners notified by email.
  • Oct 8, 3:45 PM: Forced deactivation of all PATs transferred through conversion, except where the account holder opted out.

What we investigated and found

We enumerated every account conversion performed since August 26, 2024 and correlated them with registry authentication logs, Docker Hub usage data, and IAM token records. We looked for any token used under more than one identity, and we examined every push made with a transferred token, about 304,000 in all.

We found no evidence that the vulnerability was exploited.

  • Every push made with a transferred token landed either in the converted organization’s own repositories or in the new owner’s own repositories. None went into an unrelated user’s or organization’s account. In the large majority of cases, the account converted and the account named as owner belonged to the same person or team, which is the normal, legitimate use of this feature.
  • We statically analyzed the highest-risk public images without executing them: images pushed after a conversion where we could not establish that the same person controlled both accounts. We found no malware, cryptominers, command-and-control activity, credential harvesting, persistence, or tampering.
  • We found no evidence that Docker’s own infrastructure or services were affected.

We also want to be clear about the limits of that finding:registry logs show when a token is used, not that it exists, so a transferred token that was never used leaves no trace. For that reason, we did not rely on detection to decide who was exposed. We treated every PAT that moved through conversion during the window as potentially affected, whether or not we saw it used.

What we did for affected users

On October 2, we emailed the limited number of users whose accounts received transferred PATs. Each email listed the in-scope tokens by description and creation date so users could find them in Docker Hub. We separately notified the associated organization owners. On October 8th at 3:45 PM EST, we deactivated the identified transferred PATs. Tokens that their owners asked to keep before the deadline were excluded.

Once again, if you did not receive the above email, no PAT on your account was transferred through this flow. Your account was therefore not exposed to this vulnerability and there is no action for you to take.

What we are changing

The immediate fix removed PAT transfer from conversion entirely. Beyond that, we are now:

  • requiring consent from a user before they are named as an organization owner, and notifying them when it happens;
  • recording an auditable history of every token ownership change, so questions like this can be answered from records rather than inference;
  • reviewing other flows that change credential ownership for the same pattern.

What you can do

Review the personal access tokens on your account in Docker Hub under Account settings, Personal access tokens, and revoke any you don’t recognize or no longer use. For automation that belongs to an organization, use organization access tokens rather than a person’s PAT. If you have questions about this notice, contact Docker Support at app.docker.com/support/contact.

Responsible disclosure works when researchers and vendors treat each other as partners. Peter and Krisztian did that here, and our users are safer for it. If you find a security issue in a Docker product, please report it to security@docker.com.



from Docker https://ift.tt/lMSjJuW
via IFTTT

Ledger Finds Unauthorized Hardware Implant in CryptoBilis-Sold Wallet Amid Fund Theft Reports

Cryptocurrency hardware maker Ledger has temporarily paused sales of its products via Cryptobilis following reports of stolen funds linked to devices sold by the reseller.

On Friday, the company said it was investigating reports of loss of funds from users in Southeast Asia who had purchased products from CryptoBilis. The incident is said to have resulted in losses totaling more than $86 million, according to pseudonymous blockchain investigator Specter.

"We recommend Ledger users who purchased from this reseller in the last 90 days to not initiate set up if you have not done so yet," Ledger said in an X post. "If you have set up your Ledger device, consider moving assets to a new Ledger signer (with new seed)."

The company has since revealed that one of the impacted users' contained an unauthorized hardware implant, and that it's reaching out to impacted users as part of an ongoing probe into the incident. Out of an abundance of caution, CryptoBilis has ceased sales of all hardware wallet inventory until the investigation is concluded.

"Your recovery phrase must be generated by your device when you set it up, and written down by you," CryptoBilis said in an alert on its website. "If your device came with a recovery phrase already printed or written on a card or sheet, or if anyone other than you has seen your recovery phrase, treat your wallet as unsafe."

"Never share your recovery phrase or PIN with anyone. No one from CryptoBilis or Ledger will ever ask for them. Be careful of anyone who offers to recover lost funds; these offers are almost always scams."

In a follow-up update posted on October 11, 2026, Ledger acknowledged that the CryptoBilis incident has impacted a "limited" number of devices, adding all confirmed cases involve devices sold through CryptoBilis.

The company also advised resellers and distributors to source products only through authorized channels and never to restock returned products.

"Also, we strongly advise users not to purchase from unauthorized resellers, where the risk of buying suspicious, counterfeit or modified devices is important as nothing operates under ledger security guidelines," it added.



from The Hacker News https://ift.tt/GwCQO8c
via IFTTT

Critical SonicWall SMA 1000 Flaw Targeted in 135 Exploitation Attempts After Patch

Threat actors have been observed exploiting a recently disclosed critical security flaw in SonicWall Secure Mobile Access (SMA) 1000 appliances within days of public disclosure.

The vulnerability, tracked as CVE-2026-102255 (CVSS score: 10.0), is a case of pre-authenticated server-side request forgery (SSRF) that could allow a remote attacker "to direct the appliance to issue requests on their behalf and reach internal functionality and perform unauthorized operations."

Patches for the flaw were released by SonicWall on October 6, 2026, with versions 12.4.3-03670 (platform-hotfix) and 12.5.0-03082 (platform-hotfix).

The vulnerability has since started witnessing active exploitation attempts, with first signs detected by threat intelligence firms Defused Cyber and Previdian on October 8, 2026.

Data from Previdian shows that a total of 135 attempts have been observed to date from two unique IP addresses located in the U.S. SonicWall has yet to update the advisory to reflect active exploitation of the flaw.

CVE-2026-102255 is the latest vulnerability impacting SonicWall SMA 1000 appliances to come under active exploitation. In June 2026, two other flaws in the same product (CVE-2026-15409, CVSS score: 10.0, and CVE-2026-15410, CVSS score: 7.2) were weaponized as zero-days by a threat actor dubbed UTA0533 to deploy Java web shells and a malware called KNUCKLEBALL.

Rapid7 also said it observed threat actors leveraging the flaws to target internet-facing devices and use them as a stealthy initial access vector to execute commands on the operating system and ensure long-term, persistent access.

"Once they established a foothold on the appliance, the actors systematically extracted high-value credentials, active session databases, and Time-Based One-Time Password (TOTP) multi-factor authentication (MFA) seed configurations," the company noted.

"With these harvested resources, the threat actors quickly shifted to lateral movement, pivoting from the compromised appliance directly into the internal corporate network."



from The Hacker News https://ift.tt/oLU14wx
via IFTTT

Attackers Exploit CVSS 10.0 Bricksforge WordPress Flaw Enabling Unauthenticated RCE

A maximum-severity security flaw impacting the Bricksforge plugin for WordPress has come under active exploitation in the wild, according to Patchstack.

The critical vulnerability in question is CVE-2026-85097 (CVSS score: 10.0), which allows unauthenticated attackers to upload and execute arbitrary PHP code on vulnerable WordPress websites, resulting in remote code execution (RCE). The security flaw impacts Bricksforge versions up to and including 3.1.8.9. Patches have been released in version 3.1.8.10.

Bricksforge is a WordPress plugin that's advertised as a "Swiss Army knife" for Bricks, a visual website-building tool for WordPress, with support for animations, advanced forms, and scrolling video sequences.

WordPress security company Patchstack said it detected exploitation efforts targeting the flaw on October 7, 2026, at 9:47 p.m. UTC.

"Bricksforge validates a file's MIME type when it is first uploaded. When a form is later submitted, however, it trusts the file metadata the client sends," Patchstack said. "In particular, it does not validate the 'url' field inside the 'temporaryFileUploads' parameter."

At a high level, the vulnerability stems from insufficient validation of a URL field in the 'temporaryFileUploads' parameter during form submission. An attacker could exploit this loophole to achieve RCE through four steps -

  • Request a valid nonce from the unauthenticated 'bricksforge_regenerate_nonce' AJAX endpoint.
  • Upload a GIF/PHP polyglot: a file that is a valid image but also contains PHP code. It passes the MIME check and lands in the temporary upload directory.
  • Submit a form where the 'file' path points to that validated image, but the 'url' ends in a PHP extension.
  • Bricksforge implicitly trusts the submitted metadata and places the file's contents at the PHP location, leading to the execution of the embedded code when that file is requested.

"An unauthenticated attacker can first obtain a valid nonce via the bricksforge_regenerate_nonce AJAX endpoint, then upload a GIF/PHP polyglot file to the temporary upload directory where MIME type validation is correctly performed," Wordfence said in an advisory for the flaw.

"Subsequently, the attacker can submit a form with a crafted 'temporaryFileUploads' parameter where the server-side file path points to the validated GIF file, but the attacker-controlled url field ends with a .php extension."

Successful exploitation of the flaw could result in arbitrary PHP execution on the server, which an attacker can leverage to seize control of the WordPress site, deploy web shells, read sensitive data, and establish persistent access.

In the attacks observed by Patchstack, threat actors have been observed targeting the Bricksforge REST API form submission endpoint ("/wp-json/bricksforge/v1/form_submit") or the "/wp-admin/admin-ajax.php" endpoint with "bricksforge_form_submit" action along with a crafted "temporaryFileUploads" parameter.

A representative request is as follows -

{
  "temporaryFileUploads": [
    {
      "field": "form-field-file",
      "file": {
        "file": "/var/www/example.com/wp-content/uploads/bricksforge/tmp/img_example.gif",
        "url": "https://example.com/wp-content/uploads/bricksforge/tmp/img_example.php",
        "type": "image/gif"
      }
    }
  ]
}

As specified by Wordfence, threat actors are exploiting a mismatch where the specified "file" argument is a GIF (or a PNG) file, while the actual URL points to a PHP payload.

To get around extension filtering, the exploitation activity makes use of alternate PHP extensions (e.g., .php5, .php7, or .phtml), case manipulation (e.g., .PHP, .Php, or .pHp), and encoded extensions (e.g., .%70hp, %2ephp, or .%2570%2568%2570).

"Two clusters stand out in our telemetry. In the first, 44 IPs sent 56 requests with identical payloads within seconds of each other," Patchstack said. "In the second, three IPs tested 25 variations of PHP extensions and encodings against the same temporary file."

"Both patterns point to automated exploitation over rotating proxies or distributed infrastructure. They do not, on their own, attribute the activity to a single threat actor."

The activity has been recorded from 63 unique source IPs, with six of them accounting for roughly 46% of all requests -

  • 177.75.57[.]20
  • 23.97.62[.]146
  • 84.247.60[.]125
  • 38.154.185[.]97
  • 150.109.16[.]166
  • 153.75.90[.]146

Users are advised to update to the latest version of the plugin (4.0.1) to mitigate the threat. Site owners are recommended to audit incoming requests to the "/wp-json/bricksforge/v1/form_submit" endpoint that contain a "temporaryFileUploads" parameter, as well as repeated form submissions and unexpected PHP files in "/wp-content/uploads/bricksforge/tmp/."

WPC Product Bundles for WooCommerce and Ninja Forms Flaws Exploited

The disclosure comes as threat actors are also abusing cross-site scripting (XSS) vulnerabilities in two unrelated WordPress plugins, WPC Product Bundles for WooCommerce (CVE-2026-93836, CVSS score: 7.1) and Ninja Forms (CVE-2026-94504, CVSS score: 7.1), to deliver a JavaScript payload ("x.js") capable of deploying a backdoor plugin and creating rogue admin accounts.

The plugin features an unauthenticated file manager accessible through a direct request to the plugin's main PHP file. It also creates a WordPress administrator hidden from the Users screen and installs a magic login URL, which authenticates the holder as the site's oldest administrator.

"It is a WordPress post-exploitation and persistence implant designed to execute inside the browser of a logged-in administrator," Patchstack said. "Once triggered, it abuses the victim's authenticated wp-admin session to install a malicious WordPress plugin, create a new administrator account, invoke an additional hidden persistence mechanism, and report the results to attacker-controlled infrastructure."

It's worth emphasizing that while updating the vulnerable plugins (version 8.6.7 for WPC Product Bundles for WooCommerce and version 3.15.4 for Ninja Forms) prevents further exploitation, it does not remove an existing infection. It's essential that site owners audit for hidden administrators by directly querying the database, check the must-use plugin directory, and review web server logs.

WordPress Exploitation Trends in Q2 2026

According to data from Wordfence, a total of 2,073 WordPress-related vulnerabilities were published in the second quarter of 2026, with the number of high-threat flaws jumping 15.2% from the previous quarter to 182. About 573,000 WordPress sites were compromised during the time period.

The top five vulnerabilities targeted by attackers are listed below -

  • CVE-2024-28000 (CVSS score: 9.8) - LiteSpeed Cache <= 6.3.0.1 - Unauthenticated Privilege Escalation
  • CVE-2019-9879 (CVSS score: 9.8) - WPGraphQL <= 0.2.3 - Administrative User Creation
  • CVE-2016-15042 (CVSS score: 9.8) - Frontend File Manager < 4.0 & N-Media Post Front-end Form < 1.1 & - Arbitrary File Upload
  • CVE-2023-28121 (CVSS score: 9.8) - WooCommerce Payments 4.8.0 - 5.6.1 Authentication Bypass and Privilege Escalation
  • CVE-2025-3102 (CVSS score: 8.1) - SureTriggers <= 1.0.78 - Unauthenticated Administrative User Creation

The vast majority of the attacking IP addresses originated from the U.S., followed by Germany, Czechia, Australia, Norway, France, Ukraine, the Netherlands, Switzerland, and Brazil.

"A strong firewall, timely vulnerability patches, and hardened configurations help block malicious traffic before it ever reaches your site," Wordfence said. "Comprehensive scanning helps identify vulnerabilities, malware, or suspicious changes on your site that could signal an attempted compromise. Real-time alerts about critical events, login attempts, and file changes help you stay ahead of threats."



from The Hacker News https://ift.tt/WrxBsKa
via IFTTT

CyberXero Uses Claude Code in Campaign That Stole Over 628,000 Ukrainian Records

Cybersecurity researchers have disclosed details of a two-pronged artificial intelligence (AI)-augmented initial access campaign targeting WordPress sites, e-commerce platforms, and critical infrastructure entities in Ukraine.

The activity, which brings together commodity offensive tools like Cobalt Strike with an AI orchestration layer powered by Anthropic's Claude Code, has been attributed to a Russian-speaking, financially motivated initial access broker codenamed CyberXero. The threat actor is assessed to be active since at least July 2026.

"The operation runs two pipelines at once: a global, automated campaign against WordPress and e-commerce platforms, and a curated, manual campaign against Ukrainian energy and critical infrastructure," SOCRadar said in a report published last week.

The global campaign specifically focuses on known security flaws like wp2shell (CVE-2026-63030 and CVE-2026-60137) and CVE-2026-4815, an SQL injection vulnerability impacting the Support Board WordPress plugin, to seize control of WordPress sites.

The campaign is estimated to have resulted in confirmed exfiltration from four Ukrainian organizations, leading to the harvesting of more than 628,000 records tied to Ukrainian individuals. Other confirmed compromises have occurred in Poland, China, and the Netherlands.

SOCRadar said it discovered the operation after it identified an exposed open directory hosted at "46.21.250[.]135" that leaked the threat actor's live working directory associated with a Linux workstation, including AI session logs, scripts with plaintext tokens, exploitation toolkits, reconnaissance output, AI agent configurations, and exfiltrated victim data. The campaign remains ongoing.

The opportunistic campaign aimed at WordPress and e-commerce platforms is designed for access and payment data, while the second campaign is a lot more targeted and geared towards deep reconnaissance and manual exploitation against Ukrainian energy and utilities, including a heating provider in Kharkiv.

Analysis of the exposed directory shows that a single automated execution scanned 4,708 targets, confirming access to 429 WordPress administration panels, followed by the deployment of 32 web shells in a 61-second window.

The attack architecture is based on a set of eight distinct nodes, including the threat actor's Linux workstation, a provisioning server, monetization infrastructure, payload staging servers, and a scanner that's responsible for identifying targets of interest.

CyberXero is said to have deployed AI in two independent stages of the attack lifecycle -

  • Using Claude Code with a cluster of 51 specialized agents for scanning, exploit chaining, reconnaissance, and post-exploitation. It runs on the attacker's primary workstation.
  • Connected PentAGI, an open-source, self-hosted AI Agent for fully-autonomous penetration testing, to Cobalt Strike through an AI provider API for payload generation and pentest execution. It runs on a Cobalt Strike Team Server.

To get around model refusals, the threat actor has been observed using context-engineering and session-reset techniques, instructing the agent they were running an "authorized pentest on my own infrastructure."

"Model safety controls act on the context of a session, not on the model weights, so a refusal in one session does not carry into the next," SOCRadar explained. "When an agent refused a task, the actor reopened a fresh session, with the authorization framing preloaded and tried again."

"The logs also record genuine refusals that held: across four iterations the model declined to install a backdoor, disable a firewall, move laterally, and deploy a web shell, and in a separate episode it refused a scan four consecutive times and correctly rejected a forged ownership token."

Beyond WordPress and e-commerce exploitation, the campaign involves the exploitation of exposed Redis servers, resulting in the breach of two Chinese entities. Organizations running WordPress, Magento, or PrestaShop, or exposing Redis to the internet, are advised to check for rogue WordPress administrators, WSO web shells, and unexpected entries in ~/.ssh/authorized_keys on Redis hosts.

"The opportunistic pipeline is global and automated, chasing access volume across e-commerce and WordPress with direct monetization through access sales or payment-data theft," SOCRadar said. "The directed pipeline is selective and geographically concentrated, aiming for deep reconnaissance and manual exploitation at Ukrainian critical infrastructure, with no obvious direct-monetization explanation."

Operation Master Targets WordPress and PAN GlobalProtect Gateways

The disclosure comes as SOCRadar also detailed an end-to-end cybercrime operation dubbed Operation Master that revolves around compromising enterprise networks, stealing customer and billing databases, offering a subset of the data for sale on underground forums, and repurposing the data for an automated, multi-tenant invoice fraud platform.

Between April and mid-September 2026, the adversary, who goes by the online alias "masterblack" on cybercrime forums, has been observed orchestrating multiple attack campaigns -

  • Mass Scanning for Palo Alto Networks PAN OS GlobalProtect gateways and exploiting CVE-2026-0257.
  • Probing SonicWall SMA VPN, Fortinet, Keycloak, Microsoft Exchange, and Next.js-on-IIS endpoints.
  • Collecting public developer documentation and software packages, including Brazilian banking API specs, an energy sector OpenAPI schema, a 3CX web client bundle, and account-creation packages, as part of API Reconnaissance efforts.
  • Carrying out automated SQL injection campaigns targeting Brazilian SaaS, CRM, support, education, and financial web applications to steal sensitive data
  • Probing ASP.NET applications via __VIEWSTATE SQL injection to target 21 financial organizations.
  • Exploiting CVE-2022-28368, a remote code execution vulnerability impacting Dompdf.
  • Targeting enterprise Microsoft 365 tenants using device-code phishing and password spraying attacks.
  • Exploiting CVE-2023-7028, an account takeover vulnerability in GitLab, to target an energy company's GitLab instances.
  • Brute-forcing WordPress login pages associated with Japanese enterprises by using a dictionary comprising four usernames and 66 passwords.
  • Deploying tools like GodPotato, Kerberoast, AS-REProast, Evil-WinRM, and exploits like CVE-2021-4034 (aka PwnKit), CVE-2024-1086, and CVE-2020-1938 (aka Ghostcat) for privilege escalation, followed by lateral movement to adjacent systems.
  • Using DNS tunneling, rclone, and SFTP to exfiltrate data from compromised systems.
  • Installing AdaptixC2 for command-and-control (C2).

The threat actor has also run an invoice-fraud engine generating over 2.4 million email, SMS, and WhatsApp messages and 622,666 personalized invoice links targeting Brazilian consumers and corporations before going offline in mid-September. The end goal of the campaign is to trick recipients into making Pix payments.

Out of these, the platform has recorded 169,906 target interactions, potentially leading to R$38.9 million worth of fraudulent invoices. In all, the click-tracked short links held a cumulative invoice value of R$150.4 million.

"Operating across multiple countries, the threat actor compromised critical network infrastructure, including VPN gateways via a GlobalProtect authentication bypass (CVE-2026-0257), while concurrently executing advanced web application exploits, deploying the AdaptixC2 framework, and leveraging an AI-assisted development workflow," SOCRadar said.

"Operation Master highlights a dangerous convergence in the modern threat landscape: perimeter exploits long associated with cyber espionage and ransomware are now being systematically industrialized to fuel automated, localized financial fraud ecosystems."

Like in the case of CyberXero, masterblack is also believed to have heavily leaned on AI agents powered by Claude to develop the intrusion code and exfiltration scripts, while the operator focused on designing the fraud panel code and custom AdaptixC2 extenders.

"Recovered refusal transcripts show the operator repeatedly framing offensive development requests as authorized bug bounty or penetration testing activity while requesting functionality consistent with activity observed elsewhere in the operation," SOCRadar said.



from The Hacker News https://ift.tt/teJS4K1
via IFTTT

Sunday, October 11, 2026

A Cloud Nobody Owns: Sovereign Infrastructure for the Agent Era with Dominic Williams

Brandon interviews Dominic Williams, founder, president, and chief scientist of the DFINITY Foundation, about the Internet Computer and why he set out to build a new back-end compute stack. Williams traces his path from building the kids' MMO Fight My Monster, one of the first serious production users of Cassandra, to decentralized networks and the founding of DFINITY in 2016. He explains the thesis behind the Internet Computer: a stack of software running down to the silicon can never be fully secured, so he wanted a cloud created by a network protocol, where software is tamper-proof, always on, and secure by default without firewalls, patches, or security and sysadmin teams.


Williams walks through how it works. Code compiles to WebAssembly and runs in persistent memory, replicated across independent nodes using Byzantine fault tolerance, so there is no database or file system to connect to, and a misbehaving node, even a "Dr. Evil" one, cannot corrupt the result. Brandon presses on data protection, and Williams points to hardware encapsulation such as AMD SEV-SNP and the ability to choose trusted node providers. He then describes cloud engines, which let an enterprise pick nodes from a marketplace (hyperscalers, independent data centers, or on-prem), reconfigure them without downtime, and avoid vendor lock-in, with payment handled behind the scenes so it looks like a conventional cloud.


On adoption, Williams says data sovereignty is a major driver, citing the U.S. CLOUD Act and governments, such as Pakistan, that want infrastructure they control and can inspect as open source. He describes Caffeine, which builds apps on the Internet Computer from a chat prompt, and Open SaaS, a suite meant to replace siloed SaaS tools with a single AI-aware system. To get started, he recommends pasting the prompt from the skills site into a coding assistant and having it write the back end in Motoko, a language designed for AI agents that guards against data loss when upgrading apps in production. Cloud engine coupons are expected to open up soon.



SHOW: 1070

SHOW TRANSCRIPT: The Enterprise AI Show #1070 Transcript

SHOW VIDEO: https://youtu.be/-H4KS5AMKI8



SHOW SPONSORS:



SHOW LINKS



GUEST BIO


Dominic Williams is the founder, president, and chief scientist of the DFINITY Foundation, the Zurich-based non-profit behind the Internet Computer, which he began developing in 2015 and launched in 2021. A longtime engineer-entrepreneur focused on distributed systems, he previously founded the MMO game Fight My Monster and served as president and CTO of the Palo Alto incubator String Labs.



FEEDBACK?



from The Cloudcast (.NET) https://ift.tt/l7dDGsa
via IFTTT

Saturday, October 10, 2026

The Third-Party Agent Problem: Why Security Built for AI You Chose Misses the Agents You Didn't

In environments studied for the 2026 State of Agent Security Report, roughly 1,280 third-party products now embed AI. About 282 of them sit behind single sign-on. The other thousand are invisible to identity infrastructure by default, not because anyone hid them, but because an identity stack can only govern what authenticates through it, and most agents never do.

That gap is the clearest expression of a shift the security industry is only starting to name. For several years, "AI security" solved a first-party problem: the company decided to use AI, procured licenses, deployed a model behind a gateway, and security pointed controls at the thing the business had chosen. Agents do not arrive that way. They arrive inside software the enterprise already runs, and they arrive without a decision.

Why the decision point mattered more than the controls

Every control in the first-party toolkit assumes a moment exists: model scanning assumes a model was selected, prompt inspection assumes a gateway was deployed, an acceptable-use policy assumes there was an adoption to accept. That moment gave security a review, a surface to instrument, and an owner to name.

Agents skip the moment. Salesforce's Slack Code, launched in August 2026, lets a user tag a coding agent into any conversation; the agent reads the shared context, writes the code, and opens the pull request. The announcement promises agents "inherit Slack's built-in security model, permissions, and admin controls from day one, without any additional IT lift." Read by a security team, that sentence describes an autonomous actor with reach into GitHub and production infrastructure whose governance is a chat tool's channel membership. There was nothing to instrument, because nothing was adopted.

Three launch vectors, one destination

Security leaders tend to sort agents into two buckets: bought and built. There is a third, and it is the largest. Inherited agents ship inside existing platforms via product updates. Configured agents are an enterprise's own prompts and logic running on someone else's runtime, model, and connectors. Built agents are open frameworks on infrastructure the enterprise owns end to end. The first two account for the overwhelming majority of adoption and are growing exponentially as every major application becomes an agent platform. The third is the smallest and slowest growing, and it is the only one with a repo to scan and a build to gate.

The destination is the same regardless of origin. An agent born in a CRM ends up reading a data warehouse and writing to a ticketing system. An agent assembled on a cloud platform ends up holding tokens into Salesforce, Slack, and Drive. The enterprise application layer is where they all execute, and it has no fixed edges.

Four questions that work on any agent

Every agent has two parts: the model that reasons and the scaffolding around it that turns a model into an actor, deciding what it is wired to, what it may call, and when it acts. Almost none of the risk lives in the model. It lives in the scaffolding and the ecosystem the scaffolding sits inside. Four questions cover it, and none of them ask what the model would do on its own.

Area to review

What it looks like in practice

Identity

Is the agent registered anywhere? Does a named human raise a hand when asked "whose is this?" Or does it silently run as whoever built it?

Permissions

What is it allowed to do, and is that more than it needs? Whose OAuth scopes and roles did it inherit at creation, and did anyone decide that on purpose?

Connectivity

What can it reach, directly and transitively, through the products, grants, data stores, and other agents it touches? This is the blast-radius question, and it is rarely answerable from the agent's own configuration screen.

Activity

What is it actually doing, and is that normal for what it is? Judged by behavior, not by the description in its prompt.

The Connectivity row is where agent security separates from everything the market already sells. A vendor questionnaire, a prompt filter, and a model scanner all evaluate an agent in isolation. Reach is a property of the environment.

The buyers with the most influence have already moved

Patrick Opet, global CISO of JPMorgan Chase, told the software industry in 2025 that the third-party supply chain had become a systemic risk, citing incidents serious enough that the bank had to isolate compromised suppliers in an open letter to the industry. He has since applied the same scrutiny to agents: ideally, an agent gets an identity but no entitlements by default, and IT confirms who it acts on behalf of before it touches anything outside that boundary. When a buyer of that size names agents as a supply-chain risk, the question shows up in everyone else's security questionnaires within a few quarters.

Regulators are moving on the same assumption. The EU AI Act's obligations phasing in through 2026 presume an enterprise can inventory its AI systems, name their owners, and evidence oversight. An organization that cannot enumerate its agents cannot comply.

What a standing capability looks like

The approach that keeps up with fifty agents through spreadsheets and quarterly reviews collapses at five hundred, and five hundred is one product update away from five thousand. What replaces it is a live answer, continuously refreshed, to what is operating, what each agent inherited, what it can reach directly and through chains, what it is doing, and how all of that changed since yesterday.

Some platforms are now built around exactly that map. One leading example is Reco, whose Reco Graph connects every human and non-human identity, application, permission, and agent action into a single live view so that reach, not configuration, is the unit of analysis.

The industry spent a decade building security for the AI enterprises decided to use. The agents they did not decide on are now the larger population. The six-chapter series this analysis draws on, Into the Expanse, covers where they come from, how to govern them, how attackers use them, where runtime belongs, and what to fund first.

Learn more about Reco's agent discovery at reco.ai/platform.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/sgXt6UO
via IFTTT

Anthropic Cuts Live Internet Access for Internal AI Tests After Claude Exploits Injection Flaws

Anthropic on Friday said it's cutting off live internet access for all its internal evaluations following the discovery of new incidents in which its artificial intelligence (AI) models exhibited misaligned behavior and targeted real websites.

The AI company said it identified four broad categories of unintended model actions during evaluations and internal use of Claude -

  • Claude Mythos Preview exploiting SQL or command injection flaws in unspecified third-party software to run commands on a university server, either because its own tools were intentionally limited or because an outside service it needed was unavailable, causing it to use other tools hosted on a third party's site to complete the task.
  • Claude Haiku 4.5 and a non-frontier research model submitting a sensitive form on a real website when it was not authorized to do so. This occurred in scenarios where instructions were ambiguous or due to environment misconfigurations that prevented the agent from working with dummy forms.
  • Claude Mythos 5 bypassing a restriction to reach data (e.g., to identify a location shown in a photo or pull public data that was available from a state agency) that was gated by a token or a fee
  • Claude using URL shortening services to sidestep limits in its fetch tool

Anthropic said it's opting not to name the organizations involved in these incidents to avoid exposing vulnerabilities in their systems, as well as at their request. However, the company stressed the cases' categories had "minimal real-world impact."

Some of the cases targeted websites run by U.S. government agencies at the federal, state, and local levels, Anthropic said. In one run related to the second category, Claude Haiku 4.5 is said to have accessed a web page referencing an unsolved homicide and which included a tip form run by a police department.

Although the model was explicitly instructed not to enter personal data, create accounts, make purchases, or submit anything destructive, it failed to account for form submissions. This led the model to submit a false homicide tip with the text below -

I may have information regarding this case. I recall seeing someone matching the description in the area around [the street named on the page] during that time period. Please contact me if this information is relevant.

It has since emerged that the incident targeted the U.S. Philadelphia Police Department (PPD), and that the incorrect tip was sent through PhillyUnsolvedMurders.com on July 18, 2026. But it wasn't discovered by Anthropic until September 28, 2026. The department was notified on October 7, 2026.

The tip was flagged as spam, 6abc Action News reported. "The company must strengthen its safeguards to prevent similar incidents from impacting city systems without the city's knowledge. The two-month delay in detecting and reporting the incident to the City is unacceptable," the PPD told 6abc.

These cases, it added, were discovered following a review of transcripts that started in July 2026, when it disclosed three incidents where its models engaged in unsanctioned activity and breached three organizations during cybersecurity testing.

Then, last month, it divulged a fourth incident dating back to January 2026 that involved an early version of Claude Opus 4.6, which breached "third-parties after being unable to abort its task."

"Although the impact of these behaviors was minimal and we had already turned off live internet access for some high-risk and cybersecurity evaluations, we have now decided to expand that to include all our internal evaluations until we have confirmed that our security and monitoring measures (described in the remediation section of this post) reliably catch behaviors like these," Anthropic said.

The latest discovery has prompted the AI giant to launch a deeper scan, specifically in environments where Claude has access to the internet. As this investigation continues, Anthropic said it expects to find new instances of unintended behaviors.

The development comes as AI safety concerns have reached a fever pitch in recent months, after it emerged that rogue OpenAI agents broke out of a test environment and breached Hugging Face in July 2026. Since then, a number of cyber incidents have come to light.

As AI model providers showcase increasingly capable and powerful models, their safety practices have come under growing scrutiny, sparking industry-wide warnings about the dangers of models outpacing safety guardrails, calls for a slowdown on AI development, and the need for additional oversight.

Earlier this week, the U.K. Information Commissioner's Office (ICO) said 10 of the leading foundation model developers, including Amazon, Anthropic, Apple, Cohere, DeepSeek, Google, Meta, Microsoft, OpenAI, and Stability AI, have made, or committed to make, changes to their data protection policy.

These range from including clearer transparency information to deploying stronger mechanisms for users to exercise their rights and conducting tougher assessments of safeguards.

"AI has huge potential to benefit our society, but that depends on trust and transparency," Richard Nevinson, director of Technology Regulation at the ICO, said. "But as AI systems operate with greater autonomy, robust data protection safeguards become even more critical."

"Our message is clear: the fact [that] AI agents act with autonomy is not an excuse for poor compliance. If people are to trust AI innovation, they rightly expect to know how their personal information is being protected."



from The Hacker News https://ift.tt/XmNgA9G
via IFTTT

Friday, October 9, 2026

FBI Arrests Another ShinyHunters Suspect Reportedly Involved in Its Jobs Portal Hack

The FBI has arrested another suspected co-conspirator of ShinyHunters, FBI Director Kash Patel said on October 9 in a post on X.

ShinyHunters is the extortion group that said in September it had breached the FBI's jobs portal and stolen sensitive data on almost all FBI agents and job applicants. The FBI has not named the suspect, and no charges have been made public.

The suspect is a Canadian citizen who was arrested in Pennsylvania, according to The New York Times and CBS News. Both cited unnamed sources.

The Times reported that the arrest was made on suspicion of involvement in the theft of FBI data. A law enforcement source told CBS News that the suspect is believed to have been directly involved in the hack.

An FBI spokesperson declined to comment on the Times report, CBS News said. Patel's post does not say whether the suspect took part in the breach. It calls ShinyHunters "the group believed to be responsible for the recent FBIjobs.gov incident."

Patel also wrote that the FBI will keep working with its partners "to disrupt what’s left of the ShinyHunters group and their associates, no matter where they operate." Other suspected co-conspirators are still free, the law enforcement source told CBS News.

Earlier Arrests in the Netherlands and Jordan

Reuters counts the new arrest as the third made public since news of the breach broke in late September. The FBI said in a statement Reuters reported on October 3 that it had "already worked with partners to arrest multiple subjects."

Where When Made public by Suspect
Netherlands September 15 Dutch police and the FBI A 24-year-old Amsterdam man. Identified to Reuters and CBS News as Pepijn van der Stap. Dutch police have not named him.
Jordan September 29, according to Reuters' sources Reuters, citing unnamed sources. Jordanian state media also quoted an official who confirmed an arrest and gave no name, The National reported . Named by Reuters' sources as Saif al-Din Khader.
Pennsylvania, according to The New York Times and CBS News In the week it was announced, according to CBS News FBI Director Kash Patel Not named. A Canadian citizen, according to the same two outlets.

The man arrested in the Netherlands was taken into custody a week before ShinyHunters announced the FBI breach on September 22. The Dutch police statement, published in Dutch, does not mention the FBI or its jobs portal.

The FBI said in a video statement that he is one of the group's alleged leaders and that Dutch police made the arrest under Dutch law with FBI support. ShinyHunters told The Hacker News that he has no association with the group.

Khader, the suspect detained in Jordan, is cooperating with the FBI, according to Reuters, which cited people familiar with the matter.

The FBI has not said whether the new arrest resulted from that cooperation.

What Was Stolen and How the FBI Says It Happened

A sample of the data that ShinyHunters shared contained extensive personal information on FBI employees, details of sensitive job roles, and psychiatric and medical information, a Reuters analysis found. An internal FBI notice confirmed that hackers obtained employee information, a source told CBS News.

The FBI's review has so far found that the breach resulted from a security failure on a platform managed by an outside organization. It happened after "a contractor failed to implement a security patch explicitly issued to secure the platform," Brett Leatherman, assistant director of the FBI's Cyber Division, told Reuters on October 5. The FBI has removed the contractor.

The FBI did not name the platform or the organization. Two sources told Reuters they are PeopleSoft, Oracle's human resources software, and Accenture. Accenture told Reuters it was "proud to support the mission of the FBI" and did not answer the news agency's questions about the contractor.

ShinyHunters said it targeted the FBI over an advisory from May that it says makes false claims about the group. The advisory describes ShinyHunters as a cybercriminal group that specializes in large-scale data breaches and extortion.

The FBI alleges that the group has breached more than 140 organizations and taken at least $70 million in extortion payments since last year.



from The Hacker News https://ift.tt/r9PeJ65
via IFTTT

P7 DarkSword iOS Exploit Kit Adds Crypto Wallet Data Theft and Remote Commands

Cybersecurity researchers have disclosed details of a previously unseen variant of the DarkSword iOS exploit kit called P7 DarkSword.

"Compared with the variants we usually observe, P7 reduces its on-device footprint, adds on-device keychain and crypto-wallet theft, and adds two way C2 communication with the attacker's infrastructure," iVerify said in a new report published Thursday.

The name "P7" is a nod to the threat actor's use of the "p7_" variable prefix in changes made to the original DarkSword code.

DarkSword was first publicly documented earlier this March by Google Threat Intelligence Group (GTIG), iVerify, and Lookout, detailing its ability to target iPhones running iOS versions between iOS 18.4 and 18.7. The kit was detected in the wild in November 2025.

The toolkit is engineered to chain multiple iOS vulnerabilities to escape the browser sandbox, escalate to kernel privileges, and inject the main payload into SpringBoard, the iOS process that handles app launches and the home screen. The exploit chain is assessed to be a commercial product that somehow landed in a second-hand market, from where it was acquired by financially motivated operators and other threat actors since late 2025.

The exploit kit has been put to use in attacks targeting Saudi Arabia, Turkey, Malaysia, and Ukraine by multiple threat actors, including a Turkish commercial surveillance vendor named PARS Defense via a fake Snapchat-themed website and a Russia-aligned threat actor called Star Blizzard (aka COLDRIVER) using fake invitation lures.

In August 2026, attack surface management platform Censys detailed a campaign mounted by an unknown Chinese-speaking threat actor that involved targeting Apple iOS devices with the exploit kit, in addition to serving an Apple ID decoy sign-in page.

As recently as last month, iVerify said it observed "multiple unsuccessful, likely LLM-assisted attempts to update the framework to support iOS 26.x," fueled by the leak of the exploit kit shortly after its public disclosure. These variants, the mobile security company added, are focused on stability, stealth, and quality of stolen data.

P7 DarkSword represents an evolution in these aspects by eliminating debug logging over HTTP requests and syslog and using browser localStorage to prevent re-exploitation. Unlike prior variants that copied and exfiltrated the keychain database to process on the attacker's infrastructure, the new version extracts keychain data into JSON on the phone prior to exfiltration.

"The implant is injected into the SpringBoard process, which handles all communication with the attacker's infrastructure," iVerify said.

The latest iteration is equipped to poll for commands every 15 seconds, send a "heartbeat" message, send a list of installed applications, and transmit iCloud Keychain information and data from applications like Apple Notes, Photos, and cryptocurrency wallets.

The response to the periodic tasking poll contains commands to be executed on the victim's phone. This includes -

  • execute_command, to execute operating system commands like ls, dir, cat, mkdir, rm, echo, ps, memdump, ipconfig, netstat, and whoami, among others
  • ls, to list directory contents
  • download, to read a file from the device and upload it to the C2 server
  • photos, to upload photo files from "/var/mobile/Media/DCIM"
  • apps, to enumerate app containers and extract bundle IDs
  • exec, to execute arbitrary JavaScript directly inside the implant runtime
  • file_upload, to recursively scan one or more paths and upload matching files
  • basic_info, to send device metadata to the C2 server
  • disk_scan, to recursively scan the filesystem starting from "/,", record metadata for files, directories, and symlinks, and upload the information in the form of a report
  • ios_app_data, to find app sandbox and app-group containers for requested bundle IDs and upload selected app files
  • wallet_scan, to scan for installed wallet apps
  • wallet_extract, to extract wallet-related data for imToken wallet app
  • memo_scan, to upload Apple Notes databases
  • photo_scan, to upload photos from Apple Photos
  • sleep, to modify the beacon polling interval
  • exit, to halt the beacon loop and stop the implant

The disclosure comes as Censys said it identified open directories on five hosts carrying components related to DarkSword and Coruna, another iOS exploit kit uncovered this year as weaponized in attacks aimed at iPhone models running iOS versions between 13.0 and 17.2.1.

"Coruna is the companion payload kit the same ecosystem distributes," Censys said. "Its stages run inside the victim's browser session after DarkSword's exploit stages land, and its wallet-harvesting modules steal crypto recovery phrases, balances, and keystore data from iOS apps. Operators run DarkSword and Coruna together against their own C2 infrastructure."

The five hosts are listed below -

  • 43.134.165[.]205, which serves DS-Fusion v1.0 (aka DarkSword Fusion), a combined package that includes both DarkSword and Coruna in a single bundle
  • 166.88.95[.]90, which operates as a C2 server of the implant and has recorded two real Chinese iOS devices (183.154.173[.]30 and 182.239.114[.]223) polling a beacon page every three seconds for several hours on September 6, 2026
  • 23.148.212[.]237, which serves as an analysis workspace that shows the operator developing exploit chains for iOS 26 (such as for CVE-2026-31001), which are not covered by DarkSword or Coruna.
  • 47.102.192[.]23, which serves as a staging host for the Coruna kit
  • 156.239.230[.]120, which exposes the entire C2 platform and has been observed polling a device on September 15, 2026

An analysis of the production server's exploit registry has revealed that the DarkSword exploit kit comprises two CVE identifiers not previously documented -

  • CVE-2025-24201, an out-of-bounds write vulnerability in the WebKit engine that could allow an attacker to break out of the Web Content sandbox (Fixed in iOS 18.3.2 and iPadOS 18.3.2)
  • CVE-2025-31200, a memory corruption vulnerability in the Core Audio framework that allows code execution when processing an audio stream in a maliciously crafted media file (Fixed in iOS 18.4.1 and iPadOS 18.4.1)

It's suspected that the open-directory cluster and the 156.239.230[.]120 platform are run by a Chinese-speaking threat actor with an aim to conduct cryptocurrency wallet theft. That said, exactly who is behind is unknown.

"The platform runs a Chinese-speaking exploitation-as-a-service operation," Censys researcher Aidan Holland said. "The admin panel exposes an agent/reseller model, and a copy of the production server recovered 11 victim recovery phrases, 179 device loot directories, and a 75-account control-plane roster."

Censys said it also detected a separate China-based operator running the same kit in the wild against its own C2 server at "66ds[.]lol," while including a new cryptocurrency wallet target (BitKeep) not present in the open-directory set. The findings once again highlight the proliferation of the kit among financially motivated actors.

"The operator behind it sits on Tencent and Shenyang hosting, tied to the operator through a unique self-signed certificate authority," Censys said.



from The Hacker News https://ift.tt/VZ765sO
via IFTTT

Attackers Exploit AhsayCBS Flaws to Deploy XMRig Miners Disguised as Microsoft Edge

Threat actors have been observed exploiting two recently disclosed flaws in the AhsayCBS backup utility to seize control of affected devices and deploy web shells and XMRig cryptocurrency miners.

Details of the flaws are below -

  • CVE-2026-105133 (CVSS v4 score: 5.5) - An improper authentication vulnerability in the checkSysPwd() function in the "com/ahsay/obs/api/ApiStructsAction.java" component.
  • CVE-2026-105134 (CVSS v4 score: 9.3) - An operating system command injection vulnerability in the Replication Receiver component.

A remote attacker could chain the two vulnerabilities to bypass authentication and execute arbitrary commands on affected systems. It's worth noting that CVE identifiers for these flaws were not published until October 4, 2026.

According to Huntress, exploitation efforts aimed at the two flaws began on October 7, 2026, at 11:20 p.m. UTC, with unidentified threat actors weaponizing them to achieve remote code execution on impacted hosts. As of October 8, 2026, five organizations targeted are estimated to have been affected by these flaws.

"Post-exploitation, threat actors are conducting reconnaissance, dropping web shells, planting XMRig cryptominers masquerading as Microsoft Edge, and more," the cybersecurity company said. "They also dropped what appears to be an AI-assisted PowerShell script that monitors the Windows Task Manager and shuts it down if it remains open for too long in the middle of the night."

The cryptocurrency miners have been found to impersonate the Microsoft Edge browser by using the name "edge.exe" to fly under the radar. Also dropped is a PowerShell script ("Taskgmr.ps1") that facilitates cryptomining operations after it's launched via curl.

The script, which is suspected to be written with assistance from an artificial intelligence (AI) tool, packs in anti-analysis checks that stop the mining activity as soon as a victim opens the Windows Task Manager app. It's also configured to terminate the Task Manager at 6 p.m. if it has been left open for more than one hour overnight.

Although the advisories published in the National Vulnerability Database (NVD) state that the issues have been addressed in the latest version of the software (10.3.4), Huntress has since revealed that it's also impacted, essentially turning them to zero-days.

In at least one incident, the threat actors are said to have used the built-in "certutil.exe" binary to download a legitimate-but-vulnerable driver ("WinRing0x64.sys") to the TEMP folder, likely with the aim of gaining kernel-level access to the underlying hardware and optimizing the mining process.

In the absence of a patch, users are recommended to limit access to the management interface and hunt for signs of compromise.

"Organizations should restrict AhsayCBS management interface web access, as the exploit targets the externally accessible web app service on the host," Huntress said. "Access should be limited to trusted IP addresses only or require VPN."



from The Hacker News https://ift.tt/0cKgIAM
via IFTTT

Flax Typhoon Exploits Five Flaws as CISA Sets October 11 Deadline for Federal Agencies

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Thursday added five security flaws to its Known Exploited Vulnerabilities (KEV) catalog, following their abuse by a China-linked threat actor known as Flax Typhoon.

The vulnerabilities in question are listed below -

  • CVE-2015-3306 (CVSS score: 10.0) - An improper access control vulnerability in ProFTPD that could allow remote attackers to read and write to arbitrary files via the site cpfr and site cpto commands.
  • CVE-2021-3199 (CVSS score: 9.8) - A path traversal vulnerability in ONLYOFFICE Docs that can occur when JSON Web Token (JWT) is used, via a "/.." sequence in an image upload parameter and could allow for remote code execution.
  • CVE-2023-22894 (CVSS score: 7.2) - A cleartext storage of sensitive information vulnerability in Strapi that could allow an attacker with access to the admin panel to discover sensitive user details via the query filter.
  • CVE-2016-3081 (CVSS score: 8.1) - A command injection vulnerability in Apache Struts that could allow a remote attacker to execute arbitrary code via method:prefix when Dynamic Method Invocation is enabled.
  • CVE-2015-5477 (CVSS score: 7.5) - A reachable assertion vulnerability in ISC BIND that could allow a remote attacker to cause a denial-of-service via TKEY queries.

The addition of the five vulnerabilities coincides with a joint advisory released by Australia, Canada, Japan, New Zealand, Spain, the U.K., and the U.S. warning of attacks enabled by a China-based cybersecurity company known as Integrity Technology Group.

These operations have been found to target eight security vulnerabilities, including the five listed above, to obtain initial access to organizations and siphon sensitive data. The activity involves exploiting flaws using scanning tools, cross-site scripting attacks, and password spraying on Microsoft Exchange servers, while setting up persistence through VPN software and exfiltrating emails and credentials using scripts.

It's worth noting that the remaining three vulnerabilities already have a place in the KEV catalog -

  • CVE-2014-6278 - GNU Bash operating system command injection vulnerability (aka Shellshock) (Added in October 2025)
  • CVE-2019-11510 - Ivanti Pulse Connect Secure arbitrary file read vulnerability (Added in November 2021)
  • CVE-2021-22205 - GitLab Community and Enterprise Edition remote code execution vulnerability (Added in November 2021)

"Chinese government-affiliated actors continue to position themselves within critical infrastructure networks, including operational technology (OT) systems, with the aim of disrupting critical functions at a future time of their choosing," said Acting Executive Assistant Director for Cybersecurity Chris Butera.

In light of active exploitation, federal agencies are required to apply the necessary patches or discontinue their use by October 11, 2026.



from The Hacker News https://ift.tt/OWPEscS
via IFTTT

The AI Velocity Paradox: Why Security Is Decades Behind AI Ambition

As enterprises race to deploy autonomous AI agents to accelerate business, a new report reveals they are tethered to security architectures built for a different era. The "Horizons of Identity Security" report from SailPoint highlights a critical “velocity paradox,” in which organizations invest in AI-speed business operations while continuing to rely on human-speed security controls, creating a structural failure that legacy approaches cannot solve.

The data shows that while businesses have spent years maturing their identity programs for human employees, those same playbooks are fundamentally broken when applied to the ephemeral, autonomous, and rapidly multiplying world of non-human AI agents.

A Market Stalled at the Starting Line

Despite years of investment in identity and access management, the market's overall security maturity has hit a wall. According to the report, the center of gravity remains firmly planted in the foundational stages, with a combined 60% of organizations still in Horizon 1 ("No Formal Program") or Horizon 2 ("Manual, Tool-Assisted").

The multi-year persistence of this trend reveals a critical insight: the problem isn't a lack of effort, but an architectural ceiling. The operational playbooks built to govern human employees may not scale effectively to govern autonomous agents executing thousands of transactions per minute.

A Tale of Two Maturities: The Human vs. Non-Human Divide

The paradox becomes clearer when looking at the stark division between the maturity of human and non-human identity security. The report’s data reveals two entirely different timelines.

  • Human Identity is Maturing: For human workforces, security programs are progressing. Five years ago, 45% of organizations were at the lowest maturity level (Horizon 1). Today, that number has been cut nearly in half to 23%.
  • Agent Identity is Lagging Dramatically: The opposite is true for non-human and AI agent identities. Today, 54% of organizations sit at Horizon 1 for agent identity security—a worse starting point than for human security five years ago.

This disconnect shows that even organizations with strong capabilities for managing human access are struggling to extend those same standards to cloud workloads and agentic environments. It is a coverage gap, not a competence gap.

Why Old Security Playbooks Fail in the Agentic Era

The core of the velocity paradox is that processes designed for people do not work for machines. The report identifies key structural dynamics that cause this failure:

  • The "Digitization Trap": Organizations in the middle-maturity tiers have successfully digitized human-centric processes like employee onboarding and periodic access reviews. However, applying these same scheduled review cycles to ephemeral machine identities—which may exist for only minutes or seconds—creates severe operational drag and is functionally useless.
  • The Pivot to Machine-Speed Trust: Breaking into the upper horizons of maturity requires a fundamental paradigm shift. Advanced organizations have moved away from manual, ticket-based access decisions. They have replaced standing privileges with continuous, contextual, and automated policy enforcement that operates at machine speed.

The False Compromise: "Balance" Is Not a Strategy

When faced with the conflict between moving fast and staying secure, nearly half of the market (49%) claims to "balance both equally." However, the report’s data suggests this is a false compromise.

A stated posture of "balance" without the underlying operational capability to enforce it is not a strategy; it is a stall. Organizations are caught in the paradox: They have an AI-speed ambition but a human-speed foundation, leaving them unable to move decisively. This is where most of the market currently sits, waiting for an architectural shift that can resolve the paradox.

The ultimate conclusion is clear: Securing the autonomous enterprise does not require rebuilding from scratch. The immediate priority is for organizations to extend their proven governance disciplines to cover the unmanaged non-human identities operating across their digital estate, unifying them into a single fabric that can finally match the speed of AI.

For additional perspective on how identity maturity is evolving in the age of AI, SailPoint’s “Horizons of Identity Security” report explores the trends, gaps, and capabilities shaping the path forward.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.



from The Hacker News https://ift.tt/Lj1k3ue
via IFTTT

Citrix Patches Critical NetScaler Flaw That Could Enable RCE in SAML Deployments

Citrix has released patches for yet another critical security flaw impacting NetScaler ADC and NetScaler Gateway that could result in remote code execution or denial-of-service (DoS) under certain conditions.

"CVE-2026-107406 is a memory overflow vulnerability that may lead to remote code execution or denial-of-service under specific configuration conditions," Citrix said.

The vulnerability carries a CVSS score of 9.5 out of 10.0. There is no evidence that the issue has been exploited in the wild. Citrix has credited Michael Tucker, Chew Keong Tan, and Alex Bernier of the JPMorgan Chase XOR Team, along with Maxim Suhanov, for discovering and reporting the flaw.

Successful exploitation hinges on the NetScaler deployments being configured as a SAML identity provider (IdP) or service provider (SP). Customers can determine if their instances meet the criteria by checking the configuration for entries like below -

  • SAML SP: add authentication samlAction
  • SAML IdP: add authentication samlIdPProfile

The issue impacts the following versions -

  • When configured as a SAML IdP -
    • NetScaler ADC and NetScaler Gateway between 14.1-73.37 and 14.1-73.41, inclusive
    • NetScaler ADC 14.1-FIPS between 14.1-73.37 FIPS and 14.1-73.41 FIPS, inclusive
    • NetScaler ADC and NetScaler Gateway between 13.1-64.23 and 13.1-64.28, inclusive
    • NetScaler ADC 13.1-FIPS between 13.1-NDcPP 13.1-37.279 and 13.1- 37.282, inclusive
  • When configured as a SAML SP or SAML IdP:
    • NetScaler ADC and NetScaler Gateway before 14.1-73.37
    • NetScaler ADC 14.1-FIPS before 14.1-73.37 FIPS
    • NetScaler ADC and NetScaler Gateway before 13.1-64.23
    • NetScaler ADC 13.1-FIPS before 13.1-NDcPP 13.1-37.279

"Secure Private Access Hybrid deployments using NetScaler instances are also affected by the vulnerability," Citrix warned. "Customers need to upgrade these NetScaler instances to the recommended NetScaler versions to address the vulnerability."

The shortcoming has been addressed in the versions below -

  • Citrix NetScaler ADC and Citrix NetScaler Gateway 14.1-73.46 and later releases
  • Citrix NetScaler ADC and Citrix NetScaler Gateway 13.1-64.29 and later releases of 13.1
  • Citrix NetScaler ADC 14.1-FIPS 14.1-73.46 FIPS and later releases of 14.1-FIPS
  • Citrix NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1.37.283 and later releases of 13.1-FIPS and 13.1-NDcPP

The development comes as three different flaws in NetScaler ADC and NetScaler Gateway appliances (CVE 2026-88771, CVE 2026-88772, and CVE 2026-88779) have come under active exploitation in the wild.



from The Hacker News https://ift.tt/6SNPe3l
via IFTTT

Thursday, October 8, 2026

Top 10 Free VMware Alternatives (Excluding Microsoft)

This list below is no mean to be an exhaustive. Yes, there are literally dozens of viable alternatives to VMware which has become too expensive for vast majority of users. The question is not when to migrate elsewhere, but which platform to chose and will my existing backup infrastructure be compatible. It is fairly often that businesses have the hands tightened by compliances, legal rules etc. so they have to keep their backup platform for ever (or at least until the vendor supports it) to be able to recover archived data.

Many businesses still have not decided where will they go and most likely, after the end of VMware support, they will keep running aging vSphere with less and less security. This is very dangerous path because we live in a cyberwar era and your data is the gold the hackers want to steal.

So, without further wait, let’s have a look at our FREE virtualization platform selection. But before that, we’ll talk about special case, which is Microsoft.

The Risk of “All Eggs in One Basket” and the VMware Exodus

Yes, the Broadcom’s acquisition of VMware started an avalanche of interest in other virtualization platforms.  The reasons behind this are the transition to a subscription-only model, the retirement of perpetual licenses, and the bundling of products into VMware Cloud Foundation (VCF). Those reasons have forced organizations to reconsider their dependency on a single vendor.

While Microsoft Hyper-V is often cited as the immediate alternative due to its inclusion in Windows Server licenses, relying on it exclusively presents a strategic risk: putting “all your eggs in the same basket.”

  • The Microsoft Monoculture: Migrating from VMware to Hyper-V simply swaps one proprietary vendor lock-in for another. You remain dependent on a single ecosystem for licensing, support, and roadmap decisions.
  • Licensing Complexity: While Hyper-V appears “free” with Windows Server Datacenter editions, the true cost emerges when factoring in System Center for management, Azure Arc for hybrid consistency, and the per-core licensing model that can escalate quickly for high-density hosts.
  • Strategic Fragility: As seen with Broadcom, vendor priorities can shift overnight. Diversifying your infrastructure stack with open-source or multi-vendor solutions mitigates the risk of future licensing shocks and provides leverage in negotiations.

Lesser-Known Alternatives

Beyond the mainstream options, platforms and niche players like CubeCOS (for GPU/AI workloads) and HPE Morpheus VM Essentials (for hybrid management) also offer specialized value but may lack the broad community support of the open-source leaders. Especially VM Essentials from HPE might be interesting for come businesses already using HP hardware.

The top 10 list

The following top 10 free alternatives focus on open-core or fully open-source platforms where the software is free, updates are free (well, Proxmox says their software is free, but they do charge for access to their enterprise, e.g. “stable” repo), and you only pay for optional support.

By having an option to use free software with support, the savings can be spread to train your IT staff and reinvest into new hardware. It avoids vendor lock-in, and ensures long-term sustainability.

1. Proxmox VE

 

A screenshot of a computer AI-generated content may be incorrect.

 

Proxmox is very popular platform.

  • Architecture: Debian-based Linux integrating KVM (VMs) and LXC (containers).
  • Container Support: Excellent. Native LXC support for lightweight system containers.  For modern apps, it excels at running Kubernetes clusters inside KVM VMs, with CSI drivers to expose Ceph storage directly to pods.
  • Backup Support:
    • Veeam: Yes (Native). Fully supported since Veeam v12.2 (2024) with agentless backups, CBT (incremental), and instant recovery.  Note: LXC containers are not supported by Veeam, only KVM VMs.
    • Nakivo: Yes (Native). Full agentless support added in Nakivo v11.  Certified by Proxmox.
  • Best For: SMEs needing a balance of legacy LXC containers, modern K8s clusters, and enterprise backup integration.

Proxmox download here.

Our article about migration to Proxmox or XCP-NG is here.

2. XCP-ng by Vates (Fr).

 

A screenshot of a web page AI-generated content may be incorrect.

 

  • Architecture: Community-driven fork of Citrix Hypervisor based on the Xen hypervisor.
  • Container Support: Good (VM-First). No native container engine. Uses RunX to run containers as lightweight, isolated Xen VMs (VM-level security for containers). Kubernetes runs in VMs with Xen Orchestra CSI for storage.
  • Backup Support:
    • Veeam: Yes (Native). Officially supported as of Q2 2026 (Veeam v12.3+).  Provides agentless backups and incremental support.
    • Nakivo: Limited. Primarily relies on agent-based backups inside the VM or generic drivers; no deep native Xen Orchestra integration yet.
  • Best For: Security-conscious environments needing strong isolation for multi-tenant container workloads and native Veeam support.

Link for download XCP-NG hypervisor is here.

My article on StarWind blog is here.

3. SimpleVM (by Thinware)

 

A computer screen with blue and white icons AI-generated content may be incorrect.

 

New and easy to use, simple hypervisor, with a nice UI. SimpleVM is built directly on KVM with a hardened operating system base that maintains strong compatibility with RHEL ecosystems. This choice provides excellent driver support, security features (including SELinux), and long-term stability.

  • Architecture: Lightweight, KVM-based Type-1 hypervisor built on a hardened RHEL-compatible kernel.
  • Container Support: Basic (VM-Only). No native container runtime.  You deploy modern apps by creating Linux VMs and installing Docker/Kubernetes manually. Relies on standard KVM performance.
  • Backup Support:
    • Veeam: Yes (Generic KVM). Supported via Veeam’s generic Linux KVM plugin.  No branded plugin yet, but fully functional for KVM VMs.
    • Nakivo: Yes (Generic KVM). Supported via Nakivo’s standard KVM module.
  • Best For: Organizations wanting a simple “ESXi-like” experience who already own Veeam/Nakivo licenses and want to use them immediately via generic KVM support.

Download SimpleVM here.

4. oVirt

 

A screenshot of a computer program AI-generated content may be incorrect.

 

  • Architecture: Centralized management platform for KVM hosts (upstream for Red Hat Virtualization).
  • Container Support: Moderate. No native container runtime. Historically tightly integrated with OpenShift (OKD), providing flexvolume drivers for dynamic storage provisioning for K8s clusters running on oVirt VMs.
  • Backup Support:
    • Veeam: No (Native). No dedicated plugin.  Requires agent-based backups inside VMs.
    • Nakivo: No (Native). Requires agent-based backups.
  • Alternative: Vinchin Backup & Recovery is the industry standard for native, agentless oVirt support.
  • Best For: Enterprises running Red Hat OpenShift who need dynamic storage provisioning but must use Vinchin or agents for backup.

Download oVirt here.

5. Oracle Linux Virtualization Manager (OLVM)

 

A diagram of a server AI-generated content may be incorrect.

 

  • Architecture: Based on oVirt and KVM, optimized for Oracle Linux.
  • Container Support: Moderate. Optimized for running Oracle Container Runtime and Kubernetes on Oracle Linux VMs. Integrates well with Oracle’s ecosystem for containerized DBs.
  • Backup Support:
    • Veeam: No (Native). No dedicated plugin.  Requires agent-based backups.
    • Nakivo: No (Native). Requires agent-based backups.
  • Alternative: Vinchin Backup & Recovery explicitly supports OLVM with agentless backups.
  • Best For: Shops standardizing on Oracle Linux for both database and container workloads, willing to use Vinchin or agents for backup.

6. Harvester (SUSE Virtualization)

 

A screenshot of a computer AI-generated content may be incorrect.

 

  • Architecture: Modern Hyperconverged Infrastructure (HCI) built on KubeVirt, Longhorn, and Rancher.
  • Container Support: Native/Best-in-Class. Built on Kubernetes. Treats VMs as pods.  Manages VMs and Containers in the same interface (Rancher). Uses Longhorn for cloud-native storage shared by both.
  • Backup Support:
    • Veeam: Yes (Via Kasten). Standard Veeam B&R does not connect directly. Veeam Kasten provides native support for Harvester (KubeVirt) to backup VMs as Kubernetes objects.
    • Nakivo: No. No dedicated KubeVirt/Harvester connector.
  • Best For: Cloud-native teams wanting a single platform for both legacy VMs and modern microservices, using Veeam Kasten for protection.

7. Apache CloudStack

 

A blue and white cloud computing website AI-generated content may be incorrect.

 

  • Architecture: Full Infrastructure-as-a-Service (IaaS) platform orchestrating pools of hosts (KVM, Xen, VMware).
  • Container Support: Orchestration. Does not run containers directly; provisions massive clusters of VMs to host containers. Can automate deployment of hundreds of K8s worker nodes.
  • Backup Support:
    • Veeam: No (Direct). Must backup underlying hypervisors (KVM/Xen) directly or use agents inside VMs.
    • Nakivo: No (Direct). Same as Veeam.
  • Best For: Service Providers offering “Kubernetes as a Service” who manage backup at the hypervisor or guest level.

8. OpenStack

 

A screenshot of a computer AI-generated content may be incorrect.

 

  • Architecture: Modular collection of services (Nova, Neutron, Cinder) primarily using KVM.
  • Container Support: Integrated (Magnum). Includes Magnum, a native service that deploys and manages Kubernetes clusters as first-class resources via API. Deeply integrated with OpenStack Networking and Storage.
  • Backup Support:
    • Veeam: Yes (Via Plugin). Dedicated Veeam Backup for OpenStack plugin integrates with the API to backup Cinder volumes and VMs.
    • Nakivo: Limited. Supports some environments but often requires specific configuration or agents.
  • Best For: Large clouds needing an API-driven “Container Infrastructure Service” alongside traditional VMs.

9. QEMU (with libvirt)

 

A screenshot of a computer AI-generated content may be incorrect.

 

  • Architecture: Generic emulator and virtualizer, often the backend for KVM.
  • Container Support: Manual. No native management.  Commonly used with KubeVirt (to run VMs inside K8s) or as the backend for custom K8s deployments via scripts.
  • Backup Support:
    • Veeam: Yes (Generic KVM). Supported via the generic Linux KVM plugin (requires libvirt access).
    • Nakivo: Yes (Generic KVM). Supported via Nakivo’s KVM module.
  • Best For: Developers building custom platform engineering tools or embedded edge devices.

10. Xen Project (Standalone)

 

A person pushing a stack of boxes AI-generated content may be incorrect.

 

  • Architecture: The original Type-1 hypervisor.
  • Container Support: High Security. Ideal for running Kata Containers or RunX, where every container is a distinct Xen micro-VM. Provides highest isolation for untrusted workloads.
  • Backup Support:
    • Veeam: No (Direct). Veeam supports XCP-ng and Citrix Hypervisor, but not the raw upstream Xen Project without a management stack.
    • Nakivo: No (Direct). Similar limitations; requires a supported distribution like XCP-ng.
  • Best For: High-security environments and public cloud providers needing micro-VM isolation.

Final Recommendation

  • For “Drop-in” VMware Replacement: Proxmox VE or SimpleVM.  Both offer native or generic support for Veeam and Nakivo, ensuring your existing backup strategy works immediately. Proxmox adds native LXC containers; SimpleVM adds simplicity.
  • For Cloud-Native/Kubernetes Focus: Harvester. It unifies VMs and containers natively, though apparently you must adopt Veeam Kasten for enterprise backup (for containers).
  • For Oracle/Red Hat Shops: OLVM or oVirt.  Be prepared to use Vinchin for agentless backups or rely on agents inside the VMs for Veeam/Nakivo.

Final Words

The list is not exhaustive because there are more hypervisors, clones and alternatives. But hey, if you try every single one from this list you will get my respect. The change from VMware is not easy, but is necessary if you don’t want to pay what you will never use (the whole VMware bundles). If VMware would bring back option of individual products instead of bundles, the situation would not be like it is.

Each company is different. While one needs and already heavily invested into NSX and/or needs some advanced features that the alternatives does not offer, then they probably must just stay where they are and pay the price.

FAQ

What are some free alternatives to VMware?

The article covers 10 options: Proxmox VE, XCP-ng, SimpleVM, oVirt, Oracle Linux Virtualization Manager, Harvester, Apache CloudStack, OpenStack, QEMU with libvirt, and Xen Project. They range from traditional hypervisors to cloud and Kubernetes-focused platforms.

Is Proxmox VE a free VMware alternative?

Yes. Proxmox VE is a Debian-based virtualization platform that combines KVM for virtual machines with LXC for containers. The software can be used for free, with paid enterprise repository access and support available separately.

Which VMware alternatives support Veeam?

According to the article, support differs by platform. Proxmox VE has native Veeam support, XCP-ng is listed with native support, SimpleVM and QEMU/libvirt can use generic KVM integration, Harvester works through Veeam Kasten, and OpenStack can use a dedicated Veeam integration. Other platforms may require guest agents or alternative backup products.

Which VMware alternative is suitable for Kubernetes environments?

Harvester is focused on cloud-native environments and combines KubeVirt, Longhorn, and Rancher. It manages virtual machines and containers through the same Kubernetes-based environment. OpenStack can also deploy and manage Kubernetes clusters through Magnum.

What is a simple VMware alternative for traditional VM workloads?

The article highlights Proxmox VE and Thinware SimpleVM as options for organizations looking for a more direct VMware replacement. Proxmox adds LXC container support, whereas SimpleVM focuses on a simpler, ESXi-like KVM experience.

Which VMware alternative is best suited to Oracle environments?

Oracle Linux Virtualization Manager is based on oVirt and KVM and is optimized for Oracle Linux. The article positions it for organizations standardizing on Oracle Linux for database and container workloads.

Do all VMware alternatives support containers natively?

No. Container capabilities vary considerably. Proxmox VE includes native LXC support, Harvester is built around Kubernetes, and platforms such as SimpleVM, oVirt, and QEMU/libvirt rely more heavily on VMs or external container tooling.

What should organizations check before migrating from VMware?

The article places particular focus on existing backup compatibility, container requirements, ecosystem dependencies, and advanced VMware features already in use. Some organizations may still need VMware when they depend heavily on features that alternatives do not provide.



from StarWind Blog https://ift.tt/gVUI4kC
via IFTTT