CySecurity News - Latest Information Security and Hacking Incidents

Account security AI Phishing Attacks Browser VPN Security consent Credential Phishing Cyber Attacks cybercriminals FBI Hacker attack

OAuth Phishing Attacks Bypass Passwords by Turning User Consent Into a Security Threat

Cybercriminals are targeting something more difficult to protect with traditional password advice: the user consent. New phishing techniques called OAuth consent phishing allow the intruders to gain persistent access to the targeted accounts without stealing their passwords, according to a recent FBI warning. The bureau’s Internet Crime Complaint Center described the technique in a September 1 public service announcement, noting that it has been observed since late 2025 and is targeting prominent individuals and their families and personal contacts.

The FBI describes OAuth consent phishing as accessing accounts without requiring the user’s password. OAuth is the framework that allows the services to use the familiar “Sign in with” or “Continue with” authentication options. It allows the legitimate third-party applications to request access to the resources like emails, calendars, files, and cloud storage without requiring the users to share their passwords.

The attackers are taking advantage of the legitimate procedure to get account access. The attack typically starts with sending a message that appears to be sent from a trusted contact or service. The victim clicks on the link and enters their credentials on a real login page of a trusted site. The user is then directed to an app authorization screen asking to allow specific permissions such as reading emails or accessing files.

If the victim approves the request, the intruder receives an OAuth authorization token with the permissions granted. This changes the response needed to compromise. Unlike with traditional credential phishing, changing the password will not eliminate the malicious OAuth token. The FBI recommends that the victims revoke the unauthorized authorization through their application security settings. Changing the credentials or using a new MFA code will not remove the granted access. The campaigns can also scale.

In recent months, security researchers have documented 10 to 15 new operations of this type every 24 hours in recent months, with several million attacks recorded during a single four-week period earlier this year. Phishing kits such as Kali365 and EvilTokens have further lowered the technical barrier for attackers. Security tools can help address some of the attack steps, without preventing the user from voluntarily approved malicious permission request.

The network can block known phishing domains, malicious redirectors, and scam infrastructure before the victim reaches them. Dark web monitoring can also alert users if their email addresses appear on cybercrime forums after an account compromise. The change highlights a shortcoming in traditional account-security advice: protecting passwords and MFA remains important, but users must scrutinize the applications and permissions they authorize.

GitLab Email Feature Exposes Critical Security Risk



 

Supply Chain Attack

Code Injection Cyber Security DevSecOps GitLab Security Supply Chain Attack

GitLab Email Feature Exposes Critical Security Risk

GitLab’s “Email work item to this project” feature, intended to simplify issue creation, has been found to expose a serious security vulnerability that allows attackers to push code directly to the main branch and execute CI/CD pipelines. Security researchers at Aikido discovered that the private email addresses GitLab provides contain long-lived authentication tokens that grant far more access than users expect, effectively bypassing traditional security controls like IP restrictions.

Modus operandi

When users click “Email work item to this project” in GitLab, they receive a unique email address containing a glimt- prefixed token that never expires. While GitLab’s interface suggests this address only creates issues within a specific project, the embedded token actually provides account-wide access across all projects the user can reach, both public and private. Attackers who obtain this email address can change the suffix from -issue@ to -merge-request@, attach a code patch, and submit it directly to any branch, including protected ones like main. If the patch modifies .gitlab-ci.yml, the attacker can execute arbitrary CI/CD jobs with the victim’s permissions, potentially exfiltrating secrets or deploying malicious code.

One of the most concerning aspects of this vulnerability is its ability to circumvent IP allowlists and other network-based restrictions. Researchers tested this against private projects configured to accept connections from only a single IP address; while GitLab correctly blocked browser access and git clone commands from unauthorized IPs, it still accepted merge request emails and pushed commits to the main branch. This creates a dangerous blind spot for organizations that believe their IP restrictions provide comprehensive protection, when in reality the email pathway offers an unguarded backdoor into their repositories.

The vulnerability affects every GitLab.com account and all self-managed instances with incoming email enabled, with no option to disable the feature. GitLab has acknowledged the issue but classified it as intended behavior rather than a security bug, making only minor UI updates to clarify that the email addresses can create merge requests in addition to issues. However, these changes still don’t adequately communicate that the token reaches every project in the account, can push code to protected branches, and bypasses IP restrictions entirely. Researchers found over a dozen publicly exposed email addresses in open-source project documentation, many deliberately published by maintainers instructing users where to send bug reports.

Mitigation strategies

Organizations should immediately rotate their incoming email tokens via the personal access tokens page, though this invalidates all project addresses simultaneously. Teams should scan repositories and documentation for exposed glimt- tokens using secret detection tools, treating these addresses with the same caution as API keys or passwords. Additionally, security teams must recognize that IP allowlists alone don’t provide complete protection in GitLab, and should implement additional controls like requiring sender address verification and monitoring for unauthorized merge requests. Until GitLab implements more granular controls or allows feature disablement, proactive token rotation and vigilant secret scanning remain the primary defenses against this attack vector.

A Go Worm Stole MemTensor's CI Tokens and Shipped Backdoored Packages to npm and PyPI



 

supply chain

Cyber Attacks GitHub malicious npm package memOS NPM PyPI supply chain

A Go Worm Stole MemTensor's CI Tokens and Shipped Backdoored Packages to npm and PyPI

On September 23, 2026, an attacker spent roughly five hours poisoning two packages belonging to MemTensor, the company behind the MemOS operating system for AI memory. By the time a researcher flagged the issue on GitHub at 4:17 AM UTC, malicious versions were already sitting at the top of the npm and PyPI registries, ready to install for any developer who ran a plain `npm install` or `pip install MemoryOS` that morning.

The packages hit were `@memtensor/memos-cloud-openclaw-plugin` on npm and `MemoryOS` on PyPI. Security firm SafeDep, which flagged the incident through its threat intelligence monitoring, found that three npm versions, `0.1.21`, `0.1.23`, and `0.1.25`, and one PyPI version, `2.0.34`, all contained the same Go binary: a credential-harvesting implant the attacker internally called `sckit`, built under the module path `supplychain.local/campaign`.

How the Attacker Got Inside the Pipeline

The attacker did not need a zero-day. Instead, they exploited a well-understood weakness in how GitHub Actions jobs share environment state.

The OpenClaw plugin publishes to npm through a GitHub Actions release workflow that reads its publish token from a repository secret. The attacker, operating through a GitHub account called `Memtensor-AI`, pushed a short-lived branch named `sc/release-0.1.21-20260922-cloud`, made a three-line change to a validation script that runs earlier in the same job, then deleted the branch. They repeated this process five times between 00:48 and 02:03 UTC.

The change was precise: it wrote a `BASH_ENV` entry into `$GITHUB_ENV`, which is GitHub's mechanism for passing environment variables between steps. Because Bash reads the file named in `BASH_ENV` before running any non-interactive script, this let the attacker's shell script execute silently before the real publish step. That script called `collectStageZero()` from within the package itself, passed the `NPM_TOKEN` to the `sckit` binary, then deleted itself and exited with a failure code. The publish step failed visibly, so nothing appeared on npm from that run. The token was already gone.

The PyPI compromise used the same `BASH_ENV` trick but through a different entry point. The attacker pushed an unsigned commit to the MemOS repository that replaced the standard build backend in `pyproject.toml` with a custom wrapper called `sckit_poetry_build`. On import, that wrapper injected its own bridge script into the CI environment. The bridge ran only inside the PyPI upload action's container, captured `INPUT_PASSWORD` (the PyPI token), sent it to a server at `10729e014d0e.skyleen[.]fr`, and then exited cleanly. Two hours later, a follow-up commit removed the capture code, and the next tag push uploaded the fully malicious wheel to PyPI using MemTensor's own legitimate credentials.

What the Package Does After Install

The implant activates at runtime, not at install time, so `--ignore-scripts` offers no protection. In the npm plugin, it fires when the OpenClaw gateway starts and again on every memory recall. In the Python library, it starts the first time `configure_logging()` runs, which happens on nearly every import path. The binary launches detached in the background with no output.

Once running, `sckit` scans the entire home directory for credentials. Its target list, visible in its strings and symbol names, covers `.npmrc`, `.pypirc`, `.git-credentials`, `.netrc`, SSH private keys, HashiCorp Vault tokens, and Microsoft MSAL token caches. Two compiled regular expressions recognize both secret-like variable names and token format patterns for AWS, GitHub, npm, PyPI, HuggingFace, Slack, and Stripe. Collected data goes to subdomains of `skyleen[.]fr`, the campaign's control infrastructure, over encrypted channels using X25519 key exchange and XChaCha20-Poly1305.

The binary also carries worm logic. Functions named `findRepositories`, `prepareRemoteNode`, `prepareRemotePython`, and `recursivePublish` describe how it uses stolen credentials to inject itself into other repositories. It plants a GitHub Actions workflow named `runtime-update.yml` and a `.sckit/` directory into reachable projects, turning each victim into a potential carrier. The campaign configuration encodes an expiry date of late October 2026, suggesting the attacker planned a defined window of operation.

Developers Need to Act Now

Anyone who ran an affected version should treat every credential in their home directory as stolen. That includes cloud CLI tokens, SSH keys, and any `.env` files. SafeDep recommends pinning to `0.1.20` for the npm plugin and `2.0.33` for `MemoryOS`, killing any running `sckit` process, deleting the state directories at `$HOME/.openclaw/.cache/runtime` and `$HOME/.memos/.cache/runtime`, and checking any repository with push access for the `runtime-update.yml` workflow file.

The attack sits inside a larger pattern. The first half of 2026 alone produced 37 supply chain attack campaigns and 497 indexed malicious packages, which is 4.5 times the package volume of the entire preceding year. What separates this incident is the operational sophistication: the attacker used the target project's own CI pipeline as the delivery mechanism, left no workflow run logs behind, and built self-propagation directly into the implant. For maintainers who publish from CI, PyPI's trusted publishing removes long-lived tokens from the job entirely. Required reviewers on release environments would have blocked the MemTensor runs before they started.

How We Got AD Admin In Red Teaming With GLM5.3 and RedactProxy



 

red teaming

AI Pentesting AI-powered tool GLM-5.3 pentesting red teaming

How We Got AD Admin In Red Teaming With GLM5.3 and RedactProxy

A client engaged us to red team their internal network. It was fully black box: zero input, no starting credentials, and no guidance on where to begin. The only thing we were given was presence on the internal network. Everything else we would have to find.

We have been using a three-part setup for our external engagements: a large language model driving the testing, RedactProxy protecting client data, and Red Clippy keeping the record of everything the agent did. It has worked well against internet facing targets, so the obvious next question was whether the same stack could carry an internal engagement too. This article is about the first time we took it inside a client's network.

Before doing any of it, we asked the client for explicit permission to run an AI agent as part of the engagement, and we got approval to use it. That authorization mattered, because the tooling only enforces scope as a guardrail. The responsibility for what the agent does stays with the operator.

A quick note on the three tools

The LLM: We used GLM5.3 from z.ai as the reasoning engine, driven through an agentic coding CLI. The model reads the current state of the engagement, decides what to test next, runs tooling from its own shell, and writes up what it finds. We also evaluated Claude for the same role. We had already applied for its Cyber Use Case approval and been granted it, but in practice it repeatedly tripped its own safety guardrails mid-engagement and refused to continue, which left it effectively unusable for hands-on red team work.

RedactProxy: This is a local, two way redaction proxy from the Cyber Security and Privacy Foundation. It helps to keep a client's real data from ever reaching a third-party LLM provider. It sits between the agent and the LLM provider. On the way out it replaces real client values (domains, internal IPs, emails, credentials, hostnames) with stable fake placeholders. On the way back it swaps the placeholders for the real values before the agent sees them. The model only ever sees fakes, but the agent's own tool calls still run against real infrastructure. The same real value always maps to the same placeholder for the life of an engagement, so the model can still reason that two hosts belong to the same organization without ever learning their real names.

Red Clippy: This is a pentest management tool built to be operated by an AI agent, also from the Cyber Security and Privacy Foundation. It helps to solve a simple problem: agents forget. When the context window fills up, the engagement is gone, and the next session rescans hosts and retests things you already ruled out. Red Clippy persists assets, observations, methodology coverage and findings to a local database, and it hands the agent a red team instructions document at the start of every session. So the next run picks up exactly where the last one stopped.

The challenge: a network with no way out

We set out to deploy the stack and immediately hit a wall. The client's internal network is heavily restricted. From inside it we could not reach z.ai, or any other LLM provider, or really anything on the public internet. That is good security on their part, but it broke the obvious plan of running the agent from a machine on their network and letting it call the model directly.

This is where RedactProxy turned out to be useful in a way we had never planned for.

The setup

We built the environment so that the machine touching the client network never touches the internet, and the machine touching the internet never touches the client network. Concretely:

We set up a Linux virtual machine and put it in host only network mode, so it had no route into the internal network at all. For its internet access we used a mobile phone with USB tethering, and we tethered it to the virtual machine specifically, not to the host laptop. We deployed RedactProxy inside that virtual machine and configured it to use z.ai with GLM5.3 as the upstream provider.

On the main machine, the one with presence on the client network, we pointed the red team project's LLM provider setting at the virtual machine's IP and the RedactProxy port. From the point of view of the agent CLI on the main machine, it is simply talking to an LLM provider. In reality every request is going to RedactProxy in the VM, getting redacted, being forwarded out over the phone tether to z.ai, and coming back the same way.

So the two worlds stay separate. The client network side has no path to the internet. The internet side has no path to the client network. The only thing crossing between them is redacted API traffic.

Honestly, the tethering and network separation part could have been done with any proxy. The original point of RedactProxy for us was never connectivity, it was to avoid leaking the client's internal IP addresses and names to the LLM provider. We just had not thought about this second benefit until the restricted network forced the design, and the same tool solved both problems at once.

Running the engagement

With the setup ready, we could finally use the LLM for the exercise. We started by fingerprinting the network, and had the agent document everything it found into Red Clippy: live hosts, services, and observations as they came in.

Then we asked the model to follow the methodology that Red Clippy delivers, and to go beyond it with its own tests where it made sense. It worked through the checklist and started turning up a steady stream of high and critical severity findings across the environment.

One of the early critical findings was a full Active Directory takeover. There was a catch: the exploitation needed at least one low privileged domain user to succeed, and at that point we did not have any credentials at all. Rather than force it, we simply documented the vulnerability in Red Clippy with its precondition noted, and let the agent keep testing everything else. This is exactly the kind of thing that gets lost in a normal agent session, and exactly why the persistent record mattered.

A couple of days later the model found another critical issue: a remote code execution vulnerability in one of the software products they were running, which let us take over one of their machines. We exploited it and gained a shell on that host. We also used the LLM to write a shell for the exploitation process, and using that shell we were able to read files from the server as well as execute commands. From there, two separate paths opened up to Domain Admin.

First route: a password left in a scheduled task

The compromised host held the "run as" passwords for its own scheduled tasks in Windows Credential Manager, protected by keys stored on the same disk. With code execution on the host, we read those keys and decrypted the stored secrets off the machine, which handed back the passwords in plaintext.

Two of them were domain accounts, and both authenticated successfully against a domain controller. One of the two turned out to be a member of Domain Admins, Enterprise Admins and Schema Admins. Recovering that single password was already full control of the directory. Holding it, a directory replication request returned the credential material of the account that underpins Kerberos ticket issuance for the entire domain.

There is no weakness in Active Directory involved in this route. The password of a directory wide administrator was simply left readable on an application server.

Second route: a config file and certificate services

The second path started from something much quieter. An application configuration file on the same host held, in plaintext, the password for one account. That account was also an Active Directory account, but it carried no special privileges in the domain at all. It was as ordinary as a domain account gets.

That was enough. Using that ordinary account, we coerced a domain controller into authenticating to our machine over the print system remote protocol. We relayed that authentication onward to the certificate enrolment web pages, which accepted Windows authentication over an unencrypted connection with nothing tying a login to the connection it actually arrived on.

The certificate authority then issued a certificate in the domain controller's own name. We used that certificate to obtain a Kerberos ticket for the domain controller itself. With that identity, we were able to get the stored password hash of the domain's built in administrator account, and that hash then authenticated successfully against a domain controller, with administrative access to the host.

This route reached the same level of control as the first one, but it started from a credential that had no privilege of its own. We combined the ordinary mail account with the AD weakness the model had documented days earlier, ran the exploit, and made the directory issue us a token. With that token we could access the domain controller and, through it, any other machine we wanted.

One thing is worth making explicit before the takeaways: both these chains were mainly carried out by the LLM. We were just guiding the tool wherever required.

What we took away from it

A few things stood out to us after this engagement.

The persistent record earned its place. The AD takeover finding sat documented and dormant for days, waiting on a precondition we did not meet until much later. In a normal agent workflow that context would have evaporated the moment the window filled up, and we would have rediscovered the same path from scratch, if at all. Because Red Clippy held it, combining the old finding with the newly found low privileged user was a small, deliberate step rather than a lucky re-derivation.

The redaction boundary let us actually use a cloud LLM on a real client's internal estate without shipping their internal names and addresses to a third party. Every host, credential and hostname the model reasoned about was a stable placeholder. The real values only ever existed on our side of the proxy.

And the network design, born out of a restriction we did not ask for, gave us a clean separation we would happily reuse: the machine on the client network never reaches the internet, the machine on the internet never reaches the client network, and only redacted traffic crosses between them over a tether that belongs to neither the host nor the target.

This work was carried out under explicit written authorization from the client, for defensive purposes, as part of a scoped red team engagement.

BigCommerce Merchants Hit in Supply Chain Breach After Ribon App Credentials Were Stolen



 

Supply Chain Attack

Big Commerce Customer Data Data Breach master of malt Supply Chain Attack

BigCommerce Merchants Hit in Supply Chain Breach After Ribon App Credentials Were Stolen

BigCommerce has started alerting merchants that customer data was stolen from their stores after attackers got hold of API credentials belonging to Ribon, a third-party storefront optimization app used by retailers across the platform.

The stolen credentials gave attackers access to customer records inside merchant accounts on BigCommerce between September 13 and September 17. For those four days, they pulled data page by page until the compromised key was revoked. Names, email addresses, phone numbers, and shipping addresses were taken. Passwords and payment card details were not, because BigCommerce stores that information in a separate system.

The breach did not originate inside BigCommerce. It traced back to a system compromise at Fastr, the parent company of Be A Part Of, the firm that develops and operates Ribon and its updated version, Ribon 1.5. Fastr's internal compromise exposed the API credentials those apps held, and attackers used them to walk directly into merchant environments without triggering any alarm at BigCommerce's own infrastructure level.

"On September 17, 2026, Commerce confirmed that API credentials belonging to third-party applications Ribon and Ribon 1.5, owned and operated by 'Be A Part Of,' a Fastr company, had been compromised due to a Fastr system compromise," BigCommerce told SecurityWeek. "This was not a breach of Commerce systems or the BigCommerce platform."

Ribon's own developers noticed the key was being misused on September 16. The access was cut on September 17, and BigCommerce uninstalled the app from all affected stores the same day. Merchants started receiving notifications from BigCommerce on September 18. In some stores, attackers also injected malicious scripts, though BigCommerce has only said this affected a small number of storefronts and has not specified what those scripts were designed to execute.

UK spirits retailer Master of Malt confirmed publicly it was among the merchants notified. In a statement on its website, the company said the attacker accessed its customer database and described what happened in plain terms. "It looks like hackers were able to compromise a BigCommerce Application key held by Ribon, which they were able to use to gain access to customer data held on their system." Master of Malt has reported the incident to the UK Information Commissioner's Office and said the impact may extend to hundreds of other retailers that had Ribon installed on their stores.

That point matters. This was not a breach contained to one retailer or to one retailer's mistakes. Every merchant that had Ribon connected to its BigCommerce store shared the same exposure risk, because every one of them relied on the same third-party credentials that Fastr failed to protect. The total number of affected merchants has not been disclosed. Fastr and Be A Part Of have not issued any public statement. Neither company had responded to media requests for comment as of the time of reporting.

BigCommerce hosts over 1,200 third-party apps and integrations. It told BleepingComputer it is providing log data to support Fastr's investigation. Seattle-based law firm Emery Reddy is already seeking potential claimants, noting that several retailers have begun sending breach notifications to their customers. The firm confirmed the exposed information matches what Master of Malt reported: names, email addresses, phone numbers, and physical addresses.

This incident is not the first time BigCommerce has had to yank a third-party app after attackers used it to reach merchant customers. In late 2024, electronics accessories maker ZAGG disclosed that unknown actors had breached FreshClick, another third-party BigCommerce integration, and injected payment-skimming code into its checkout. That attack ran from October 26 through November 7, 2024, and resulted in the theft of names, addresses, and live payment card data from customers completing transactions on ZAGG's site.

The two incidents differ in method. The FreshClick attack used malicious JavaScript to capture card details at the point of entry, in real time, as customers typed. The Ribon attack used a compromised backend key to query stored customer records directly, without any customer interaction required. No payment data changed hands this time, but the attacker had persistent, authenticated access to customer databases for four consecutive days before anyone pulled the key.

For shoppers at any retailer that used Ribon, names, email addresses, phone numbers, and home addresses are now in someone else's hands. That combination is more than enough to build convincing phishing messages or to attempt account takeover on other services where those same details appear. Affected customers should treat any unsolicited emails referencing their account details or recent orders with skepticism until the full scope of the incident is established.

Arista Warns of Critical Actively Exploited VCO Vulnerability



 

Vulnerabilities and Exploits

Arista Security Patch VCO Vulnerabilities and Exploits

Arista Warns of Critical Actively Exploited VCO Vulnerability

Arista has published Security Advisory 0183 warning of a critical vulnerability in on-premises VeloCloud Orchestrator (VCO), tracked as CVE-2026-93952. The advisory, dated September 22, 2026, assigns the flaw a CVSS 3.1 base score of 10.0, indicating the highest level of severity. The issue is caused by improper input validation and is already being actively exploited, making immediate assessment and remediation essential for affected organisations.

The vulnerability could allow a remote, unauthenticated attacker to access privileged internal functionality and compromise the VCO host. Successful exploitation may affect the confidentiality, integrity and availability of the orchestrator, including data managed by it. Arista said the issue affects on-premises VCO deployments, while hosted and dedicated VCO versions have already been patched. The affected software includes VCO 5.2.3.15 and earlier in the 5.2.x series, 6.1.3.7 and earlier in the 6.1.x series, 6.4.2.7 and earlier in the 6.4.x series, and 7.0.0.2 and earlier in the 7.0.x series.

An affected deployment requires certificate-based authentication between a VeloCloud Edge and VCO, access to the public portion of the Edge authentication certificate, and network access to the VCO web interface. Tenant or operator credentials are not required. Organisations that limit the VCO web interface to trusted administrative networks can reduce exposure, although this should be treated as a temporary defensive measure rather than a complete solution. Arista’s EOS-based networking products and several other listed Arista platforms are not affected by this vulnerability.

Administrators should inspect VCO web-access, backend application and system logs for unusual requests, encoded URL components, references to internal services or unusually high request rates. Other warning signs include unexpected outbound traffic, unauthorized configuration changes, unexplained maintenance actions, command execution, file creation, database exports or access to credentials and certificates. Arista specifically identified suspicious files, the x-vc-opt HTTP header and connections from 142.93.149.77 and 104.248.126.159 as indicators requiring investigation.

Arista recommends upgrading to a remediated VCO release as soon as possible. Fixes are available in VCO 5.2.3.16 and later within the 5.2.3 train, and VCO 6.4.2.8 and later within the 6.4.2 train; fixes for other release trains will be added. Until then, organisations should restrict web access, monitor inbound and outbound activity, review administrator actions and watch for backdoors or webshells. If compromise is suspected, operators should preserve relevant logs and file timestamps before remediation, contact Arista TAC, rotate credentials, validate managed Edge devices and consider rebuilding the orchestrator from trusted sources.

Meta Muse Flaw Lets Attackers Hijack AI Assistant



 

Vulnerability

Account Token Theft AI Assistant Security AI Security Cyber Security Dictation Endpoint Local Privilege Escalation Mac Security MacOS Vulnerability Meta Muse Vulnerability

Meta Muse Flaw Lets Attackers Hijack AI Assistant

The Muse artificial intelligence assistant from Meta has been found to be vulnerable to an attack which allows malicious software to redirect its dictation traffic and control the actions performed by the application if it is locally running malware.

The issue was demonstrated by security researcher Patrick Wardle in a proof-of-concept published on September 21, which demonstrates how an attacker with code execution rights under the user logged into Muse can exploit a hidden configuration in Muse. Wardle has also emphasized that the vulnerability does not provide an initial entry point into a Mac, but rather becomes dangerous after a malicious program or attacker has already been installed on the device.

In addition, Wardle also warned that the attack may be delivered remotely via a ClickFix-style method, in which the victim is persuaded to execute a command without downloading or installing traditional malicious software. The Meta AI agent Muse was launched earlier this month as a personal AI agent capable of interacting with services and applications based on user permissions. Its capabilities include file sharing, email, messaging, calendars, shopping services, and smart-home applications. As a result of these permissions, the malicious process does not have to obtain the same access independently, making them particularly relevant to this attack.

There is a problem with an undocumented Muse preference named endo_voyager_dictation_endpoint that controls the location where voice dictation is processed. The setting can be modified by an application running under the same user account. No additional macOS permission is necessary to modify the setting so that Meta's legitimate endpoint is replaced with an attacker's endpoint.

A redirected endpoint can allow voice input intended for Muse to be sent to a service controlled by the attacker. Testing has demonstrated that both the audio and transcription can be intercepted. Once the input has been captured, the attacker can observe dictated prompts and influence Muse's instructions.

A further significant benefit of the redirected traffic is that the token associated with the user's Muse account can be accessed and used to interact directly with Muse. Wardle demonstrated that the token can be accessed and used directly to access the account's chat history. Thus, malicious code is no longer simply stealing information, but rather abusing the AI assistant itself in order to carry out actions based on the privileges that have already been assigned.

A secondary concern is how conventional endpoint security tools might interpret the activity. The Muse application is a legitimate, signed application, so actions initiated through it may appear to originate from a trusted process rather than directly from malware. Wardle's testing further revealed that access obtained through Muse tokens may extend beyond the compromised computer.

Using the token, the researcher was able to execute commands through Muse on another device since the same account can be used across multiple devices. In testing, the researcher was able to have the assistant on a smartphone report its location, scan for nearby Bluetooth devices, and identify smart home controls.

Meta Releases Hotfix for Muse Zero-Day

The vulnerability has been addressed by Meta with a hotfix for Muse on MacOS. According to David Singleton of Meta Superintelligence Labs, the issue involves a local privilege escalation rather than a remote vulnerability. Moreover, exploitation requires malicious software to have already been installed under the user's account.

By closing the configuration path that Wardle used in his proof-of-concept, the hotfix removes the ability to modify the dictation endpoint. As Meta stated, there was a limited practical risk associated with the attack since it requires the installation of local code. However, the requirement for local code execution does not necessarily exclude realistic attack scenarios. Wardle cited ClickFix-style attacks, in which victims are tricked into executing commands on their own computers.

By employing such a method, one might be able to gain a foothold without having to install conventional malware in order to exploit the Muse vulnerability. A broader concern with artificial intelligence agents that operate with extensive permissions has been highlighted by the vulnerability. As a result of Muse accessing a wide range of system resources and connected services, it may be possible for attackers to use those existing permissions once they have obtained control of the agent, rather than requiring separate access to each protected resource.

In Wardle's testing, he demonstrated that the vulnerability can be exploited for a variety of purposes beyond the theft of dictated information. As part of the proof-of-concept activity, the user was able to take images and create documents on the Mac using Muse, in some cases without being made aware of.

In addition, the research demonstrated that attackers controlling Muse sessions may interact with connected devices, although some actions are limited to the preparation of drafts during testing. This vulnerability does not imply the bypassing of macOS's underlying permission system directly, but rather the abuse of Muse once sensitive capabilities have been granted. As a result, the compromised process may be able to make requests through legitimate, signed applications, potentially making the results harder to distinguish from normal AI-aided operations. Moreover, the dictation system design of Muse contributed to the vulnerability as well. While Apple's dictation capabilities are available on device, Muse transmits voice inputs to Meta's infrastructure for processing.

Wardle argued that this architecture created an endpoint that can be redirected by another local process. Several security and isolation controls have been implemented in the context of Muse, including its dedicated Secure VM architecture and additional safeguards designed to limit agent actions. However, the flaw revealed is not in the cloud environment designed to isolate user agents but in the macOS application itself.

Personal artificial intelligence agents are increasingly being seen as sources of security concerns, particularly those that provide conversational capabilities as well as access to files, devices, accounts, and external services. In the event of an agent weakness, those permissions can be turned into an attack path. However, even if the underlying operating system enforces its normal security boundaries, the agent could potentially act as an attack vector.

Chinese Hackers Exploit ZyXEL Switch Flaw to Steal Data From Nearly 1,000 Devices



 

Hacker attack

Chinese Hackers Critical Flaws Data Breach data security data stealing data vulnerability Hacker attack

Chinese Hackers Exploit ZyXEL Switch Flaw to Steal Data From Nearly 1,000 Devices

A Chinese threat actor has been using the recently discovered vulnerability in ZyXEL GS1900 switches to steal crucial information from the devices around the world, according to GreyNoise, a threat intelligence company.

The vulnerability, tracked as CVE-2026-7273, has a CVSS score of 8.8 and is a stack-based buffer overflow, enabling a remote unauthenticated attacker to execute OS commands via a specially crafted HTTP request.

ZyXEL has issued security updates for ten GS1900 switch models in June. However, according to GreyNoise, the flaw was actively exploited in August, targeting the devices in 48 countries. The threat actors used a Python script, which was significantly obfuscated to hide its purpose, to extract the hashes of the root credentials, configuration, and network information from 996 affected switches.

While the script targeted the GS1900-24 switches with firmware versions 2.10 to 2.90, some of the command-line options in the script contained values related to libc base addresses and global offsets. Therefore, it might be possible that the threat actors could use the same vulnerability to target other firmware versions. The information stolen from the switches also showed that 564 devices were using default credentials. This lets the attackers effortlessly compromise these devices.

On Monday, the US Cybersecurity and Infrastructure Security Agency (CISA) added the vulnerability to its Known Exploited Vulnerabilities catalog. Also, per the Binding Operational Directive 26-04, all federal agencies must remediate this issue within 3 days of its publication. GreyNoise also reported that the same threat actor conducted Ubiquiti attacks, which involved exploiting the zero-day flaws to gain remote access and execute arbitrary code in the devices.

In addition, the attackers used exploits targeting WordPress flaws to launch attacks against small businesses and government entities in July. The attacks entailed a threat actor compromising a Western government organization, stealing over 18000 sensitive documents from the agency’s backend database, and publishing the results on a Matrix communication service.

However, the cybersecurity firm is yet to confirm if any of these attacks were conducted by the same threat actor. Acronis, another cybersecurity firm, previously identified threat actors using the Red Heron hacking group, which primarily used Gitea’s zero-day flaw to target more than 100 organizations worldwide.

Foreign Hackers Got Into Two Colorado Water Systems, Messed With Pump Controls and Killed the Alarms



 

foreign cyber espionage

CISA Cyber Security department of energy FBI foreign cyber espionage

Foreign Hackers Got Into Two Colorado Water Systems, Messed With Pump Controls and Killed the Alarms

Foreign actors broke into the industrial control systems of two small private water utilities in Colorado last month, altered pumping cycles, changed equipment settings, and shut off the alarms that would have told operators something was wrong. The state confirmed the incidents on Friday. It has not named the utilities or the attackers.

Both systems are privately owned and serve fewer than 200 people each. The intrusions happened in late August. According to the governor's office, the attackers disabled remote access, switched off alarms, and changed how water was being pumped before operators caught on and regained control. Water quality and treatment were not affected at either location.

"These were brief incidents and the risks were quickly addressed by the providers themselves, who subsequently alerted the state," said Ally Sullivan, a spokeswoman for Governor Jared Polis. "To our knowledge, treatment processes and water quality were not impacted at either provider."

Colorado officials did not name a suspect. Sullivan said the office "cannot confirm what foreign actors may have been involved," but pointed to a CISA-tracked Iranian-backed group that has been working to access drinking water and wastewater systems across the country. Federal authorities have made no formal attribution in the Colorado case.

Part of Something Bigger

Colorado is the latest state in a list that has now reached at least 12 reporting intrusions into water system controls this year. The EPA says more than 100 drinking water and wastewater systems have been hit in 2026, most accessed through programmable logic controllers, or PLCs, connected to the open internet via cellular modems, often without the utilities realizing it.

The summer's single worst episode came on July 26 and 27, when attackers hit more than 30 communities in Minnesota in what state IT officials called a coordinated assault. At least four cities publicly confirmed disruptions. One plant went offline entirely; others dropped to manual operation. In Georgia, hackers took down a pump station, cutting pressure enough that residents were advised to boil water before using it. No one reported getting sick.

The FBI and EPA issued a joint warning on July 30 describing attackers who remotely changed IP addresses and passwords on exposed controllers, locking operators out. In some cases, the intrusions created conditions where untreated groundwater could have entered distribution pipes.

CISA said it tracked attacks against more than 100 internet-exposed water sector systems in July alone, the majority accessed through PLCs attached directly to cellular modems.

The Group Investigators Are Watching

The most scrutinized suspect is CyberAv3ngers, a threat group formally tied to Iran's Islamic Revolutionary Guard Corps Cyber-Electronic Command. The U.S. Treasury sanctioned six of its senior officials in February 2024. The State Department has offered $10 million for information on the group's activities.

The group has run through four documented phases since 2020. It started by exploiting default passwords on Israeli-made water utility controllers, moved on to deploying custom malware called IOCONTROL against industrial and IoT devices, and this year shifted to actively exploiting an authentication bypass flaw in Rockwell Automation's widely used Logix PLCs. No vendor patch exists for that vulnerability.

Six federal agencies, CISA, the FBI, NSA, EPA, the Department of Energy, and U.S. Cyber Command, warned jointly on April 7 that Iranian-affiliated actors were actively hitting internet-facing PLCs across water, energy, government, and manufacturing sites.

Congress and Industry Push Back

Senators Adam Schiff and Amy Klobuchar introduced the Water Cyber Shield Act in August, which would give the EPA authority to audit utilities and mandate corrective action. The bill authorizes $300 million annually through existing water infrastructure funds.

At DEF CON, the National Rural Water Association launched the Water Watch Center, pairing five managed security firms with small utilities at no cost. The program targets systems serving under 10,000 people, which make up 91 percent of the country's roughly 50,000 community water systems.

Denver Water, which supplies about 1.5 million people across the metro area, told Axios it evaluated the threat after the Colorado disclosure and found its systems unaffected. Federal investigators are working with state officials to determine how the two utilities were accessed.

Cyberattack Hits University of Munich, Exposing Student Data



 

User Privacy

Cyber Attacks Dark Web Data Leak University of Munich User Privacy

Cyberattack Hits University of Munich, Exposing Student Data

Germany’s Ludwig Maximilian University of Munich (LMU) is investigating a significant cyberattack that potentially exposed sensitive student information, including financial aid and health insurance data. The breach, detected on a Wednesday, led the university to disconnect affected servers and engage external cyber security experts while cooperating with law enforcement.

The compromised records reportedly include students’ names, dates of birth, contact details, LMU email addresses, bank account information, and details about their courses of study and prior educational qualifications. In some cases, health insurance numbers and identifiers linked to Germany’s student financial aid program may also have been accessed, along with data related to leaves of absence. However, the university confirmed that examination records, specific course content, and individual academic performance data were not affected.

Operational impact and response

Following the discovery of the breach, LMU took several systems offline as a precaution, temporarily disrupting some internal services. While teaching activities continued uninterrupted, enrollment processes were briefly suspended and are expected to resume with extended deadlines to ensure students are not disadvantaged. Some students reported difficulties accessing university services needed for semester preparation, including course registration and grade viewing. The institution has not disclosed the number of affected individuals or the duration of unauthorized access, and no ransom demand has been publicly confirmed.

Universities remain attractive targets for cybercriminals due to their extensive networks containing vast amounts of personal and financial information across large populations of students, researchers, and staff. Recent ransomware attacks have affected prominent U.S. institutions such as the University of Texas, University of Oklahoma, Stanford University, and the University of Michigan, with several incidents occurring after holiday breaks. Other notable cases include disruptions at the University of Pennsylvania, Columbia University, and Harvard University over the past years.

LMU has enlisted specialists to monitor dark-web forums and other platforms for signs that the stolen information is being circulated or misused. While there is currently no evidence that the data has been altered, deleted, or published, the investigation remains ongoing to determine the full extent of the breach. The attacker has not yet been identified, and the university continues to work with cybersecurity professionals and authorities to secure its systems and protect affected students.

STOMP Backdoor Uses PowerShell for Sensitive Data Theft



 

Windows Backdoor

Clipboard Stealing Command And Control Data Theft malware PowerShell Malware Securonix TASK#STOMP Wi-Fi Password Theft Windows Backdoor

STOMP Backdoor Uses PowerShell for Sensitive Data Theft

An advanced malware campaign known as TASK#STOMP has recently been discovered, which utilizes a PowerShell-based backdoor to collect business documents, Wi-Fi passwords, clipboard data, and screenshots from compromised computers using a PowerShell backdoor. Moreover, the malware also provides attackers with remote command execution and maintains multiple channels for further access. VBScript files are executed via the legitimate Windows Script Host utility wscript.exe in order to initiate the infection.

In spite of the fact that the exact method of delivery has not been confirmed, phishing or social engineering could be considered possible methods of delivering the script. Following the script's delivery, it sets up a set of scheduled tasks resembling legitimate Windows components, establishing persistence.

By naming these tasks Local Credential Manager, Network Audio Service, Windows Display Manager, and Device Credential Handler, malicious activities can be blended seamlessly with normal system activities. Another persistence mechanism places another VBScript file in the Windows Startup folder, enabling it to run when the user logs in.

Upon launching the malware, it executes two PowerShell components. Among these are sys_loader.ps1, which collects documents, gathers system information, steals Wi-Fi passwords, monitors clipboards, captures screenshots, and executes remote commands. Another persistent command-and-control channel, win_conn.ps1, provides additional collection capability as well as a persistent command-and-control channel.

By monitoring each other and restarting the other process if one is disabled, this setup provides redundancy, making it more difficult to remove the malware if only one process is terminated or a single persistence entry is deleted. In addition to hiding execution activities, timestamp manipulations, and cleanup activities, Task#STOMP can also be used for continuous document theft, increasing the difficulty of detection and forensic investigation.

As opposed to collecting only files that are already present on an infected computer, TASK#STOMP monitors the file system for newly created or modified documents. This enables the collection of business files as they appear and change during an active infection. In addition to obtaining Wi-Fi credentials and clipboard contents, the malware targets saved Wi-Fi credentials as well.

With clipboard monitoring, operators can identify information temporarily copied by users, while screenshot capture allows them to view information displayed on a compromised system. By combining these capabilities with remote command execution, Task#STOMP is able to gather more information about user activity than a conventional file-stealing malware.

A separate command-and-control path, Win_conn.ps1, is maintained by TASK#STOMP in addition to data collection. From win_conn_cfg.dat, the component decodes its configuration and connects to attacker-controlled infrastructure at corecloudfileshare[.]xyz and attachmentsharingdrive[.]xyz. Researcher identification of related traffic can be improved by using a hardcoded authentication token for communication.

Parts of network communication are handled by a compiled C# component. During connection times, connections can proceed when certificates are invalid, self-signed, or otherwise mismatched due to the code disabling TLS certificate validation. This reduces the level of protection usually provided by certificate checks and makes it easier for the malware to communicate with its servers. Additionally, TASK#STOMP alters file timestamps and cleans up activity following execution to provide further anti-forensic measures.

According to the researchers, several files have been backdated to January 15, 2024, but that date is not conclusive of when the campaign began. This date was deliberately inserted by the malware, and therefore cannot be regarded as evidence of the age of the campaign. Securonix has not determined why the malware opens a page associated with irantenders[.]com in Chrome, but the page relates to government contracts and tenders in Iran.

Securonix has not established whether the site indicates a specific victim profile or why it is opened. Researchers have cautioned that the domain alone may not be sufficient to confirm the campaign's geographical or sectoral targeting. Securonix has not linked TASK#STOMP to a known threat group. Due to the use of a single compromised system, it is unclear how the overall campaign scope and duration were determined.

The initial delivery method is also unclear, although similar VBScript campaigns suggest phishing involving archive or disk image attachments as a possible route. To detect an infection, researchers recommend examining suspicious Windows Script Host and PowerShell activity that originates from writable locations, newly created scheduled tasks, and instances where PowerShell invokes the C# compiler from .NET C#.

A suspected infection can be investigated with additional evidence from PowerShell Script Block Logging, AMSI telemetry, and scheduled task records.

TraderTraitor Mac Malware Targets IT Firm Through Weaponized Terraform Projects



 

Malware attacks

Backdoors Cyber Attacks Fake Job Ads IT Companies Mac Malware macOS Malware attacks

TraderTraitor Mac Malware Targets IT Firm Through Weaponized Terraform Projects

A North Korean-linked cybercrime group known as TraderTraitor has tied another macOS infection in an IT services company with no cryptocurrency ties to the exploitation of fake job interviews to gain access to developer systems. The second victim, which has been identified as an India-based IT services provider, was targeted through one of the employees’ Apple Silicon MacBook belonging to a DevOps engineer.

The compromised machine was used to manage AWS, OVH and OpenStack environments with the help of Terraform and Ansible, while the account also held cloud credentials and source code access. SentinelOne attributed the breach to the same FLATROOF and ROOFDECK macOS backdoors employed by TraderTraitor in the attack targeting LayerZero Labs that resulted in the $292 million heist from crypto project KelpDAO. Initially detected on March 18 the malicious implants remained undetected until March 29, when they were triggered by the victim launching a workspace within the Cursor development environment.

FLATROOF implant, which has been dropped as SystemUpdate, can be used to execute arbitrary shell commands, terminate processes and steal data. Its capabilities also include harvesting browser information, terminal history, installed applications, running processes, system properties and the macOS login keychain database. ROOFDECK, which was deployed as iSync utility, allows for full command and control over the compromised system while also facilitating reverse shell access, file transfer exfiltration of data, reconnaissance, and persistent access through the use of LaunchAgents.

It also has the capability to read the clipboard content, which may also contain passwords, cryptocurrency seed phrases and two-factor authentication (2FA) credentials. On April 20, which came shortly after the public disclosure of the LayerZero breach, the threat actors deployed a modified version of ROOFDECK while removing the initial implants. The new sample continued to communicate with the C2 infrastructure controlled by the attacker until June 1. “The incident serves as a stark reminder that developer endpoints must always be protected and monitored for suspicious activity,” the report noted.

“These machines can serve as a gateway to cloud infrastructure, source code and deployment resources, which makes them attractive targets even for organizations with no direct involvement in crypto operations.” It added that organizations should carefully monitor developer workstations for anomalous behaviors, including the launch of unsigned binary from the home directory, processes spawned by the development environments, and unusual network connections.

It also recommended conducting regular audits of the Terraform lock files and make sure that the providers listed in them are legitimate before launching unfamiliar coding assignments or repositories.

Claude Code Glitch Erases Years of Bengaluru Heritage Data



 

Technology

AI Mishap Bengaluru Heritage Claude Code Mythic Society Technology

Claude Code Glitch Erases Years of Bengaluru Heritage Data

A critical AI mishap has put years of digital heritage preservation at risk in Bengaluru, after an automated coding assistant inadvertently wiped out substantial archival work. The incident involving Claude Code, an AI-powered development tool, has forced The Mythic Society—a Bengaluru-based nonprofit dedicated to documenting the city’s history—to rethink its reliance on autonomous systems for managing irreplaceable data. This incident serves as a stark reminder of the vulnerabilities that emerge when cutting-edge technology intersects with culturally significant archives without sufficient safeguards in place.

The Mythic Society, which launched its heritage documentation project in 2021, saw years of curated content vanish when Claude Code “went rogue” during a routine update or scripting task. While exact technical details remain under review, reports indicate that the AI agent executed unintended commands that deleted or overwrote critical files. The loss encompasses digitized records, historical narratives, and metadata compiled over nearly five years, representing a significant setback for local heritage conservation efforts. For an organization built on preserving Bengaluru’s evolving identity, the disappearance of such work is not just a technical failure but a cultural loss that cannot be easily quantified.

In the wake of the data loss, The Mythic Society is now allocating approximately Rs 15 lakh to overhaul its backup and recovery infrastructure. This investment aims to prevent similar incidents by introducing redundant storage, stricter access controls, and human-in-the-loop verification for any AI-assisted operations. The society’s leadership has emphasized that while AI tools can accelerate workflows, they must be governed by robust safeguards—especially when handling culturally sensitive and non-replicable archives. The financial commitment reflects both the urgency of restoring lost capabilities and the long-term necessity of building resilient systems that can withstand unexpected technological failures.

The Bengaluru incident underscores a growing concern in the AI era: over-reliance on autonomous agents without adequate oversight can lead to catastrophic outcomes. Claude Code, designed to assist developers by generating and executing code, is not inherently malicious, but its actions must be constrained within well-defined boundaries. Experts suggest implementing layered approval processes, sandboxed execution environments, and real-time monitoring to mitigate risks when AI interacts with production systems or valuable datasets. As organizations increasingly adopt AI to streamline operations, this case highlights the importance of treating such tools as powerful yet fallible assistants that require constant human supervision.

For organizations like The Mythic Society, the path forward involves balancing innovation with prudence. AI can undoubtedly enhance efficiency in digitization, transcription, and metadata tagging, but human oversight remains non-negotiable. The society’s decision to invest heavily in backup systems signals a renewed commitment to preserving Bengaluru’s heritage—with a clearer understanding that technology should serve as a tool, not a trustee, of cultural memory. As AI capabilities evolve, so too must the protocols that protect the irreplaceable work built upon them, ensuring that future advancements support rather than undermine the preservation of history.

Hacker vs. Hacker: ShinyHunters Outsmarts Clop Ransomware Gang



 

ShinyHunters

Clop Ransomware Gang Cyber Attacks Cyber Extortion Hacking Ransomware ShinyHunters

Hacker vs. Hacker: ShinyHunters Outsmarts Clop Ransomware Gang

The extortion group ShinyHunters hacked the dark web leak site run by Clop, one of the most active ransomware operations in the world, defaced it with their own branding, and is now threatening to put Clop through the same extortion process Clop runs on its corporate victims.

The attack happened Friday night, September 19. ShinyHunters found an unauthenticated file upload flaw in Grav CMS, the content management system Clop was running its leak site on, and used it to push a text file directly onto the server. The file read: "THIS SITE HAS BEEN PWN3D BY SHINYHUNTERES #Skids10p - Maybe don't try to threaten us next time." It also linked back to ShinyHunters' own Tor site. The file was confirmed live and downloadable directly from Clop's server.

Hours later, ShinyHunters said they had gone further. A visit to Clop's site showed the entire page replaced with ASCII art of Umbreon, the Pokemon ShinyHunters uses as its logo, and the line "rooting your systems since '19 ;)". The same Umbreon artwork had appeared when ShinyHunters defaced HackForums back in August 2020. Clop's defaced page was still live at the time of writing.

ShinyHunters claimed full access to the server and said they took source code, Grav CMS plugins, and everything stored in the server's /var/log directory, which typically holds authentication logs, system activity records, and the IP addresses of everyone who connected to it. They also claim to have pulled the private keys for Clop's Tor onion service. Those keys are what tie a .onion address to its server. With them, ShinyHunters could host a copy of Clop's site at the exact same onion URL, on infrastructure they control. "We have their onion keys. So if they kick us out it wouldn't matter at all because we control the private keys to host the same exact onion URL," the group said.

The plan is to post an extortion message on their own site and give Clop 72 hours to respond.

The defacement and the uploaded file are independently confirmed. The claims about stolen source code, server logs, and Tor private keys come only from ShinyHunters and have not been independently verified. Clop has not commented.

The dispute behind this attack goes back about a year. In August 2025, Clop quietly began exploiting a zero-day vulnerability in Oracle E-Business Suite, tracked as CVE-2025-61882, a server-side request forgery flaw that gave attackers remote access to enterprise systems without authentication. Oracle did not patch it until October 2025, after Mandiant confirmed active exploitation. By then, Clop had already sent mass extortion emails to executives at dozens of companies, including Cox Enterprises, The Washington Post, Logitech, Michelin, and Estee Lauder.

ShinyHunters says that exploit was originally theirs and that Clop used it without authorization. In October 2025, ShinyHunters, operating under the name "Scattered Lapsus$ Hunters," leaked the proof-of-concept publicly. Oracle confirmed it matched the exploit used in the Clop attacks. ShinyHunters said the leak was deliberate, intended to disrupt Clop's campaign and expose what had been taken from them.

What followed, according to ShinyHunters, was a direct threat from a Clop representative. "During the Oracle EBS campaign they ran and stole from me last year, someone from cl0p personally messaged me and said, and I quote (translated from Russian): I have more money than you and all of your people combined, I'll kill you soon," the group said. Those allegations have not been independently verified.

This is not the first time criminal groups have turned on each other. In March 2025, DragonForce defaced the leak sites of rival operations BlackLock and Mamona. Later in 2026, two groups called 0APT and KryBit hacked and leaked each other's operational data until both were left severely damaged. The difference in the Clop case is the scale of the target. Clop's leak site is the operational center of its entire extortion model, the platform it uses to name victims and apply public pressure when ransoms go unpaid. Losing control of it, and potentially the keys that anchor its onion address, is not a minor disruption.

ShinyHunters' own Tor site went offline shortly after the attack. No connection to Clop has been established.

Researchers Escape OpenAI Codex Sandbox to Run Commands on Host



 

Vulnerabilities and Exploits

AI Coding Agents Codex CLI Codex Sandbox Escape Cybersecurity Heapjack Host Command Execution OpenAI Codex Overpatch Sandbox Vulnerability Vulnerabilities and Exploits

Researchers Escape OpenAI Codex Sandbox to Run Commands on Host

In OpenAI Codex, security researchers have identified two sandbox escape vulnerabilities, one of which allows developers to execute commands on their machine without prompting them. The vulnerabilities, Heapjack and Overpatch, affect different parts of the coding agent's security boundary.

The vulnerability was reported to OpenAI by Accomplish AI on August 12. According to the researcher, Codex fixed both issues within eight days. The more serious Heapjack vulnerability demonstrated that malicious code could move beyond the restrictions imposed by Codex's sandbox, even when the agent was running as a read-only application.

Heapjack Breaks the Sandbox Boundary

The node_repl component installed with Codex Desktop is targeted by heapjack. Although both OpenAI and untrusted agent code are run in separate JavaScript contexts, both operate within the same Node.js process and share the same memory heap, the separation was not sufficiently effective in preventing a security token from coming into contact with an untrusted environment.

By inspecting the process heap, it was possible to obtain the token generated for the trusted context that remained in shared memory. When the token was obtained, the untrusted code could interact with a native parent process outside the sandbox using the communication channel used by the trusted context. As part of the demonstration of the technique, the researchers launched an application outside of Codex's process tree by utilizing the open command.

A Unix socket as well as other system-level interfaces could also be reached through this access. This demonstration was especially important since it occurred while Codex was running in a strict read-only sandbox mode, where the agent was not expected to have any writing access to the wider system.

The attack could be triggered by a seemingly routine development process. The researchers demonstrated a scenario in which malicious content contained in a repository, created by a third party, could exploit the vulnerability after the repository was opened in Codex and a query about its code was made.

Overpatch Expands Write Access

Second, a vulnerability known as Overpatch affects the open-source Codex command line utility, and it takes an alternative route outside the sandbox. The vulnerability affects the application_patch tool used by Codex to modify files.

In workspace-write mode, Codex is intended to limit file changes to the project directory. Researchers discovered that apply_patch, instead of expanding write permissions, could expand them based on paths included in patches. By using a path such as /tmp, the tool was able to treat the root of the file system as an accessible parent directory. In addition to the permission extension, researchers modified .zshrc by creating a symbolic link to the user's home directory so that it would be modified as well.

A successful write was not required for the /tmp entry; its presence extended the permissions granted to the patch operation. A modified shell configuration resulted in a file modification outside of the permitted workspace without an approval prompt. When a new terminal session was launched, attacker-controlled content ran.

Two Flaws, One Security Boundary Problem

It is important to note that though Heapjack and Overpatch affect different parts of the Codex, both expose weaknesses in the way in which the security boundary of the agent was enforced. In the case of Overpatch, the tool responsible for applying changes also determined the scope from which it had access to data.

In heapjack, trust boundaries were similarly compromised, as the token separating trusted and untrusted execution remained accessible in the same Node.js process and memory space as the untrusted code. The findings suggest that AI coding agents can be restricted in other ways than just controlling their abilities to execute commands.

Untrusted agent activity must also be prevented from influencing the mechanisms that enforce those restrictions by the tools, processes and interfaces surrounding the model. On August 12, 2026, OpenAI was notified of the issues, and they were both addressed within eight days by Accomplish, who stated that Overpatch was addressed in Codex CLI 0.149.0, while Heapjack had been addressed in Codex Desktop build 26.818.21641.

A later statement by OpenAI confirmed that both issues had been resolved in August, and that additional measures were being taken to strengthen file-write controls and expand sandbox testing across platforms. These findings emphasize the security challenges associated with maintaining strong isolation in AI coding environments. Codex Desktop and Codex CLI have been updated to address both vulnerabilities.

Four Linux Kernel Flaws Expose Systems to Local Root Exploits



 

Linux

Cyber flaws Cyber Security cybersecurity vulnerabilities exploitable flaws Kernel Kernel Flaw Linux

Four Linux Kernel Flaws Expose Systems to Local Root Exploits

A security researcher has publicly released working exploit code for four Linux kernel vulnerabilities that can allow local users to escalate their privileges to root, giving them the highest level of access on an affected system. The vulnerabilities, dubbed DirtyAH6, TUNderflow, PPPoEject and DiagSpill, were discovered by researcher Asim Manizada and reported to the Linux kernel security team in mid-July.

Kernel maintainers have since released fixes for all four flaws, meaning systems running fully updated kernels are not affected. Manizada published his technical analysis and working exploits on September 18 after coordinating with Linux distributions to give developers time to release patches. There are currently no reports of the vulnerabilities being exploited in real-world attacks. The published exploits were developed for specific kernel builds and can crash systems, making them primarily suited for isolated testing environments.

Despite those limitations, publicly available exploit code increases the risk for systems that have not been patched. Local privilege escalation vulnerabilities are particularly relevant on shared or multi-user systems, where an attacker who has already obtained limited access can potentially use the flaws to gain complete control. Three of the vulnerabilities require unprivileged user namespaces to be enabled.

This Linux feature allows ordinary users to obtain root-like privileges inside an isolated environment and is enabled by default on many distributions. DirtyAH6, tracked as CVE-2026-80844, affects the IPv6 IPsec Authentication Header code. TUNderflow, CVE-2026-81000, affects TUN/TAP virtual network devices, while PPPoEject, CVE-2026-68121, targets PPP over Ethernet code. DiagSpill, tracked as CVE-2026-74469, differs from the other three because it does not require user namespaces or special privileges.

Instead, it requires the SCTP networking module to be available. Two vulnerabilities, DirtyAH6 and DiagSpill, can also be triggered remotely in limited circumstances, although the demonstrated remote impact is primarily system crashes. Manizada achieved remote root exploitation with DirtyAH6 in a controlled laboratory environment after first manipulating the target’s memory. He described achieving the same result remotely without that preparation as extremely difficult. He found no path to remote root with DiagSpill.

All four vulnerabilities are memory-safety flaws affecting different areas of Linux networking code. DirtyAH6 involves an out-of-bounds write in IPv6 IPsec handling, TUNderflow results from an integer wraparound in virtual networking code, PPPoEject is a use-after-free vulnerability, and DiagSpill involves a counter overflow that can result in a large out-of-bounds memory write. The researcher said the flaws were discovered using an AI-assisted process designed to map kernel memory handling and reason about memory layouts.

The Linux fix for DirtyAH6 credits his custom AI tooling in its commit record. Manizada also previously disclosed another Linux kernel privilege-escalation flaw, OVSwrap, in July. Administrators should update to a kernel containing all four fixes. The first stable Linux kernel releases containing the complete set are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. Distribution kernels use their own versioning, however, so users should check security advisories from their Linux distributor to confirm the fixes have been included.

If immediate patching is not possible, disabling unprivileged user namespaces can reduce exposure to DirtyAH6, TUNderflow and PPPoEject. Administrators can also disable AH6, TUN/TAP, PPPoE or SCTP features when they are not required. Manizada recommends patching rather than relying on feature restrictions because alternative exploitation paths may exist.

Critical Orkes Conductor Flaw Exploited for Unauthenticated Remote Code Execution



 

cybersecurity vulnerability

API API Security Vulnerability Critical Infrastructure Cyber Security cybersecurity vulnerability

Critical Orkes Conductor Flaw Exploited for Unauthenticated Remote Code Execution

A critical vulnerability in Orkes Conductor is being actively exploited by attackers, potentially allowing them to execute arbitrary commands on vulnerable systems without authentication. Tracked as CVE-2026-58138 and rated 9.8 on the CVSS scale, the flaw affects Conductor, an open-source enterprise framework used to orchestrate microservices, workflows and AI agents. The vulnerability can be exploited through inline workflow definitions submitted to the platform’s workflow API. The security issue stems from the way Conductor executes scripts within workflows.

Attackers can insert malicious JavaScript or Python expressions into workflow definitions and use them to execute arbitrary system commands. According to Empirical Security, INLINE tasks, along with LAMBDA, DO_WHILE and SWITCH tasks, can evaluate user-controlled JavaScript or Python expressions. Conductor creates the evaluator using a GraalVM context configured with HostAccess.ALL, effectively removing the intended sandbox protections. The attacker-controlled code can then reach the underlying Java runtime and execute operating system commands with the privileges of the Conductor process.

In many deployments, that process runs with root privileges, potentially giving attackers extensive control over the affected system. Authentication does not prevent exploitation by default because the open-source Conductor server does not enforce authentication and leaves its workflow API accessible. An attacker can reportedly send a single unauthenticated POST request to register a malicious workflow containing an INLINE task and trigger its execution. Orkes patched CVE-2026-58138 in June with Conductor version 3.30.2.

However, attackers began targeting the vulnerability after proof-of-concept exploit code was publicly released in early August. Empirical Security identified exploitation attempts in the wild on August 21. Fortinet subsequently blocked approximately 1,300 exploitation attempts between September 8 and September 9 and has issued an outbreak alert warning about continued exploitation. Organizations running Conductor should upgrade to version 3.30.2 or later and limit external access to the platform’s workflow API endpoints.

Security teams should also place Conductor deployments behind firewalls and ensure vulnerable services are not directly exposed to the public internet. Administrators should monitor Conductor instances for suspicious workflow submissions and unexpected command execution. Systems that previously ran vulnerable versions should also be reviewed for signs of unauthorized access or compromise.

An AI Helped Researchers Break Into OpenAI



 

open AI

AI Models Anthropic Claude Opus 4.7 ASLR Claude AI cyber espionage Cyber Security open AI

An AI Helped Researchers Break Into OpenAI

A three-person security research team quietly walked into OpenAI's internal infrastructure last July, submitted a pull request inside the company's private monorepo as proof, and then stopped. The whole operation, from first vulnerability discovery to confirmed repository access, took under 72 hours. The tool that made it possible was not a custom-built hacking suite. It was Claude Opus 5.

The researchers, Harsh Jaiswal, Mohan Pedhapati, and Rahul Maini, work at Hacktron, an AI-assisted security research firm. They published their full technical account on September 13. OpenAI confirmed a fix roughly 14 hours after receiving the initial report on July 25, and paid out a $6,500 bounty on September 1.

The case is one of the clearest demonstrations yet of what skilled human researchers can accomplish when they hand the grinding, iterative work of exploit development to a capable AI model. It is also a story about a mundane but persistent failure: software that depends on unpatched libraries, and login systems that trust services they probably should not.

The Chain That Got Them In

The attack surface was not OpenAI's flagship products. It was the company's public help forum, community.openai.com, which runs on Discourse, an open-source forum platform used by tens of thousands of organizations.

Discourse allows users to upload images. For most formats, it relies on a tool called FastImage to inspect files before processing them. But FastImage does not support HEIC or HEIF images, the high-efficiency formats popularized by Apple. So Discourse passes those files to ImageMagick instead, which in turn calls an underlying library called libheif to do the actual decoding.

That handoff is where the vulnerability lived. libheif version 1.19.7, the version running inside Discourse's Docker image at the time, contained a heap buffer overflow. A specially crafted HEIC file could corrupt server memory, giving an attacker the ability to manipulate program execution. The flaw is tracked as CVE-2026-32882 and carries a severity score of 8.8 out of 10 in Discourse's own advisory, which classifies the result as remote code execution.

The patch for this bug had been available since libheif 1.22.0, released in May 2026. The CVE existed. The fix existed. But Discourse's Docker image, built on Debian 12, still shipped the old, vulnerable library when the Hacktron team looked in July. Debian had not yet backported the fix into its packaged version. That two-month window between upstream patch and downstream delivery is what the researchers walked through.

Once they had code execution on the Discourse server, the path to OpenAI employee accounts ran straight through the forum's login button. OpenAI's forum offers a "Sign in with OpenAI" option, the same single sign-on system its staff uses for ChatGPT, Codex, and other internal services. With control of the forum server, the researchers could hijack that authentication flow and take over the accounts of any OpenAI employee who had ever used it. The victims did not have to click anything or be online at the time.

Hacktron was explicit in their writeup about what this means: the forum was one path, not the problem. "If any first-party or third-party OpenAI service using the OpenAI SSO was compromised, it would lead to the same access," the team wrote. The identity flaw was OpenAI's, not Discourse's.

After confirming the account takeovers, the researchers used one employee's Codex account, which was connected to OpenAI's GitHub organization, to open a single pull request inside OpenAI's internal monorepo. They read nothing, merged nothing, and touched no customer data. The pull request was the proof. Then they stopped and filed their report.

Where the AI Came In

The libheif heap overflow gave the researchers memory corruption primitives, which is a starting point, not a working exploit. Memory corruption bugs require additional work to become reliable code execution, particularly on modern systems protected by Address Space Layout Randomization (ASLR), a defense that scrambles where code sits in memory to make it harder to redirect program flow.

This is where most vulnerability research slows down. Turning a crash into a reliable, weaponized exploit requires significant expertise, patience, and time. The Hacktron team decided to find out how much of that work an AI could absorb.

They started with Claude Opus 4.8, the previous flagship model from Anthropic. Across multiple sessions, it managed to help develop a working exploit when ASLR was disabled. When they enabled ASLR, matching the configuration of real servers, Opus 4.8 struggled and failed to produce anything reliable.

On the evening of July 24, Anthropic released Claude Opus 5. The researchers started a fresh session.

Within three hours, Opus 5 had produced a working exploit for an ARM64 Mac environment. They asked it to adapt the exploit to x86-64 and to the jemalloc memory allocator configuration that Discourse uses. By 6:00 a.m. on July 25, they had confirmed local code execution through an image upload.

The researchers then placed Claude in what they describe as an autonomous "/goal" loop, pointed at their own Discourse Cloud instance, framed as a capture-the-flag practice target. Opus 5 has guardrails meant to prevent it from writing exploits for real systems, so the team disguised the target. When they checked again at 10:00 a.m., the agent had achieved code execution on their cloud instance on its own, demonstrating access by reading /etc/hosts. They then used the generated exploit on OpenAI's forum and confirmed it worked there too.

The researchers are careful to note that this was not fully autonomous hacking. Skilled human judgment and direction were required throughout. But the gap between what they could accomplish in hours with Opus 5 versus the days or weeks such work might have taken without it was significant.

The cost of the entire Discourse and OpenAI portion of the project: a few days of AI compute and a few hours of human time.

One Bug, Many Targets

The OpenAI breach was not a standalone operation. It was one piece of a broader research campaign Hacktron calls HEIF Heist, a multi-month investigation into how widely the libheif library is embedded in major internet services, and how many of those services were running vulnerable versions.

Over roughly two months, the three researchers say they traced the same class of image-decoding flaws across software used by Slack, Meta, GitHub Enterprise, and web frameworks including Next.js, Astro, and Gatsby. The total cost of the entire campaign was under $3,000 in AI model usage, spread across roughly sixty days of work.

The team found that adapting each exploit to a new target environment generally took only one or two days with AI assistance. They report that the only company that appeared to detect their testing activity was Shopify, even after thousands of test images were sent to various targets and image processors at several of those companies crashed repeatedly under the load.

Not all of the claims have been independently verified. The Next.js vulnerability is confirmed in Vercel's own advisory. libheif's maintainers confirmed a working code-execution exploit against Meta's deployment of the library. The wider claim of successful code execution across the full list of targets has not been corroborated by external sources as of publication.

The HEIF Heist project also surfaced a difference between AI models. For cases where the team had information about the target environment, Claude Opus 5 was the primary tool. For targets where they had almost no prior knowledge of the deployment configuration, they switched to OpenAI's GPT-5.6 Sol, which they found performed better in those conditions. Each major model jump brought a clear capability improvement: Opus 5 succeeded where Opus 4.8 failed, and GPT-5.6 Sol handled blind exploitation scenarios that Opus 5 struggled with.

The report documented Russia-linked espionage operations using Claude to run nearly fully automated phishing campaigns against Ukrainian, European, and diplomatic targets. It described a Chinese group, including operators identified as university students in Hunan province, who used Claude as the core engineering layer of an offensive program that found multiple zero-day vulnerabilities in a major security product. It also described a French-speaking hacktivist who used Claude to attack European political parties, media organizations, and think tanks at a scale that previously would have required a well-resourced team.

Anthropic's core observation across all of those cases was the same observation the Hacktron team made in their own writeup: AI is closing the gap between what a small, budget-constrained team can do and what used to require state-level resources.

The Hacktron team put it plainly: "Work that once required a well-resourced team and months of effort can now be compressed into days."

That assessment lines up with what Anthropic itself told the company's own threat report readers, and with what security researchers have been warning about for the past year. The Hacktron operation is the first time those warnings have been backed by a public, step-by-step technical demonstration against one of the most scrutinized technology companies on the planet.

What Needs to Change

The specifics of the OpenAI fix have not been made public. The company acknowledged the finding through payment and remediation rather than through a detailed disclosure of the login flaw.

On the Discourse side, the forum platform responded fast: they received the report on a Saturday, replied on Sunday, had a fix ready on Monday, and published their advisory on Tuesday. They also added image-processing sandboxing as a hardening measure, running ImageMagick in a restricted environment so that even a successful exploit against the image library cannot directly execute arbitrary code on the host server.

Search This Blog

Sections

Popular Posts

Blog Archive

Labels

Report Abuse

About Me

Footer About

Labels

Showing result(s) for

Popular Posts

Pages

OAuth Phishing Attacks Bypass Passwords by Turning User Consent Into a Security Threat

GitLab Email Feature Exposes Critical Security Risk

A Go Worm Stole MemTensor's CI Tokens and Shipped Backdoored Packages to npm and PyPI

How We Got AD Admin In Red Teaming With GLM5.3 and RedactProxy

A quick note on the three tools

The challenge: a network with no way out

The setup

Running the engagement

First route: a password left in a scheduled task

Second route: a config file and certificate services

What we took away from it

BigCommerce Merchants Hit in Supply Chain Breach After Ribon App Credentials Were Stolen

Arista Warns of Critical Actively Exploited VCO Vulnerability

Meta Muse Flaw Lets Attackers Hijack AI Assistant

Chinese Hackers Exploit ZyXEL Switch Flaw to Steal Data From Nearly 1,000 Devices

Foreign Hackers Got Into Two Colorado Water Systems, Messed With Pump Controls and Killed the Alarms

Cyberattack Hits University of Munich, Exposing Student Data

STOMP Backdoor Uses PowerShell for Sensitive Data Theft

TraderTraitor Mac Malware Targets IT Firm Through Weaponized Terraform Projects

Claude Code Glitch Erases Years of Bengaluru Heritage Data

Hacker vs. Hacker: ShinyHunters Outsmarts Clop Ransomware Gang

Researchers Escape OpenAI Codex Sandbox to Run Commands on Host

Four Linux Kernel Flaws Expose Systems to Local Root Exploits

Critical Orkes Conductor Flaw Exploited for Unauthenticated Remote Code Execution

An AI Helped Researchers Break Into OpenAI

Footer About

Search This Blog

Sections

Popular Posts

Blog Archive

Labels

About Me

Footer About

Labels

Showing result(s) for

Popular Posts

Pages

Menu Item

A quick note on the three tools

The challenge: a network with no way out

The setup

Running the engagement

First route: a password left in a scheduled task

Second route: a config file and certificate services

What we took away from it