The new face of enterprise remote code execution
Enterprise remote code execution today describes a growing class of vulnerabilities that let attackers run arbitrary code on critical systems or developer machines without valid authentication, often by abusing AI components, misconfigured sandboxes, or weak approval flows, and these flaws increasingly span SaaS platforms, VPNs, developer tools, and core data infrastructure.
Seven current cases show one uncomfortable truth: pre-auth RCE and AI-assisted exploitation are outpacing most organizations’ patch discipline. ServiceNow’s CVE-2026-6875 is a sandbox escape in its AI Platform that lets unauthenticated users execute arbitrary code through a pre-authentication endpoint like /assessment_thanks.do, providing a full compromise path to the instance and connected proxy servers. Redis shipped seven security releases after authenticated RESTORE chains in versions 6.2.22, 7.4.9, 8.6.4, and 8.8.0 were turned into working remote code execution exploits that abuse memory flaws in Streams and RedisBloom/TDigest loaders.
This is not a random assortment of bugs. It is a pattern: attackers look for the weakest trust boundary—whether a sandbox, VPN gateway, JSON parser, or AI agent config—and use it to slip unauthenticated or low-privilege code into the heart of enterprise systems.
AI platforms and developer tools: when safety boundaries lie
ServiceNow and AWS sit at opposite ends of the stack, yet both show how AI-enabled workflows are becoming prime RCE targets. On the ServiceNow side, CVE-2026-6875 is a 9.5 CVSS sandbox escape on the AI Platform that lets an unauthenticated attacker run arbitrary code via a pre-auth endpoint, now reportedly under exploitation and patched in multiple family releases such as Brazil EA/GA and Yokohama hotfixes. That is textbook ServiceNow pre-auth RCE: a single web request leading straight to code execution in what was assumed to be a controlled sandbox.
AWS’s Kiro IDE exposes a different failure mode. Hidden text on a web page could cause Kiro to rewrite ~/.kiro/settings/mcp.json, the file that lists Model Context Protocol servers and their start commands, and then run attacker-provided code on the developer’s machine, all without any effective approval step. The agent happily fetched external content, treated a one-pixel white text block as instructions, and used its fsWrite tool to load a malicious MCP server that then executed with full developer privileges. The flaw was present on versions like 0.9.2 and 0.10.16 and confirmed fixed in 0.11.130 after being reported in February and patched by April.
If you are betting your development process on a pop-up that says “click allow,” these incidents should end that experiment. Any agent that can both edit its own configuration and launch tools from it is one prompt injection away from becoming an attacker shell.
Datastores and DevOps: Redis zero-days and GitLab command execution
Core infrastructure is no safer. Redis is now dealing with a RESTORE-centric remote code execution problem that hits four major branches—6.2.22, 7.4.9, 8.6.4, and 8.8.0—after researchers and AI agents produced authenticated RCE proof-of-concept chains for stock deployments. Redis itself warns that the underlying memory flaws may lead to remote code execution. The Streams shared-NACK bug and the RedisBloom/TDigest out-of-bounds writes allowed crafted RDB payloads to gain arbitrary memory access and ultimately call system(). Redis 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5, and 8.8.1 now contain the fixes, with guards added around shared-NACK ownership and loader bounds.
The Redis episode underlines a new reality: AI bug hunting is accelerating discovery. According to one research team, “the disclosure follows another AI-discovered Redis RCE flaw patched in May” and comes from a group that describes itself as AI Agent Research. That is not hype; it is operational pressure. Organizations must now assume that anything exposed with powerful commands like RESTORE, EVAL, and module loaders will be systematically probed by automated agents, not just by humans.
Meanwhile, GitLab operators are learning the hard way that not all dangerous fixes arrive with a CVE label. A flaw patched on June 10 in 18.11.3 allows any authenticated user who can push to a project to gain GitLab command execution by running commands as the git user on self-managed servers that skipped the update. The exploit chains two memory corruption bugs in the Oj Ruby JSON parser, reached through GitLab’s ipynbdiff notebook renderer, which parses repository-controlled .ipynb JSON inside long-lived Puma workers. First, the attacker leaks a heap pointer by abusing a truncated object key; then they use a nesting overflow to overwrite the parser’s start callback and redirect it to system().
Perimeter under fire: Palo Alto GlobalProtect and the illusion of “medium” risk
If your patch backlog still treats “medium” CVSS scores as optional, the Palo Alto GlobalProtect story should change your mind. The flaw tracked as CVE-2026-0257 lets attackers bypass authentication on GlobalProtect portals and gateways and establish unauthorized connections to PAN-OS devices, and its rating has been upgraded to a CVSS 7.8 high-severity issue after evidence of active exploitation. Rapid7’s managed detection team reports successful exploitation across numerous customers and notes that the vulnerability was added to the CISA Known Exploited Vulnerabilities list by May 29, even though they did not see confirmed lateral movement from compromised devices.
This is precisely the kind of Palo Alto GlobalProtect vulnerability adversaries love: a pre-auth pathway into your perimeter that many teams initially dismissed because of a lower score. Attackers started exploiting the flaw around May 17, with multiple waves hitting organizations that had Cloud Authentication Service disabled or GlobalProtect authentication override cookies enabled.
The operational takeaway is blunt. For perimeter devices, you cannot treat CVSS scores as gospel. Anything that affects authentication paths on internet-facing VPNs belongs in your highest patch tier, and you should assume ransomware groups will weaponize such bugs as soon as functional exploits exist.
Patch overload and what security teams must do now
Even if you accept that pre-auth RCE is the new normal, keeping up with enterprise security patches is becoming a full-time crisis. One major vendor has released 1,449 patches in a single quarterly update, a record that reflects both a massive product portfolio and an internal shift to AI-based vulnerability detection. Another has seen its monthly updates balloon to 622 CVEs, more than triple the previous month, and explicitly warns that AI-enabled scanning will keep increasing the volume of security fixes customers must absorb.
This volume alone will drown teams that cling to a flat patch calendar or treat all updates as equal. ServiceNow customers running self-hosted AI Platform instances are already advised to apply their June fixes immediately because exploitation attempts have been observed against CVE-2026-6875. Palo Alto has shipped PAN-OS patches for CVE-2026-0257 and recommends disabling authentication override features to reduce exposure. Redis explicitly instructs administrators to upgrade to the fixed release for their branch and, until then, to revoke RESTORE from accounts that do not strictly need it and block untrusted network access.
The conclusion is uncomfortable but clear. Security programs must prioritize pre-auth RCE and low-privilege GitLab command execution bugs, raise perimeter VPN flaws to emergency status, and accept that AI-driven bug discovery means patch triage, not patch discovery, is now the bottleneck. If your vulnerability process cannot quickly separate the ServiceNow pre-auth RCE, Redis zero-day exploit, Palo Alto GlobalProtect vulnerability, and AWS Kiro prompt injection chain from mundane issues, then you are not running a security program—you are running a queue.
