.svg)
.svg)
AI agents are already exploiting application vulnerabilities to execute code and gain privileged access. Recent ARTEX investigations describe command injection, server-side template injection, and a compromise that progressed from initial access to root in 12 minutes. [1] [5]
For enterprises, the question is immediate: which code is running in production, and what is that code allowed to do when an attacker reaches it?
Public source code gives AI systems the implementation to study. Public vulnerability research and exploit examples provide additional starting points. When the affected code is reused across applications, an exploitation technique can become relevant to many deployments.
This makes library-level runtime security essential: identify the code that executes, understand the sensitive actions it initiates, and restrict capabilities that it does not need. That is the role of Raven Runtime Code Security.
Real Attacks Are Already Reaching Code Execution
The following reports describe separate operations and evidence sources. Together, they show how agentic tooling is being used to exploit application weaknesses.
Magento: A Public RCE Exploit in ARTEX-Derived Tooling
In October, AhnLab analyzed REAPER, a customized distribution retaining ARTEX's multi-agent architecture. It found a working copy of the public StyleSmuggler exploit for CVE-2026-75650, artifacts indicating that exploitation steps had been performed, and follow-on PHP implant files with command-execution capabilities. These findings came from the operator's environment. [2]
Adobe identifies the vulnerability in Magento Open Source and Adobe Commerce as template-engine injection that permits arbitrary code execution without authentication. Adobe also confirms exploitation in the wild; AhnLab supplies the separate connection to ARTEX-derived tooling. [3]
Sansec's technical analysis explains the mechanism: attacker-controlled PHP content is introduced and then executed through Magento's template-processing workflow. A legitimate application feature becomes a path to code execution. [4]
This case provides a concrete software target, a named vulnerability, and evidence of public-exploit reuse in an operator environment running ARTEX-derived tooling.
Command Injection and Template Injection in ARTEX Campaigns
Check Point's November research examined exposed ARTEX operator databases. In a campaign targeting third-party iOS signing services, it documented agents gaining access through several weaknesses, including command-injection RCE and server-side template-injection RCE. The campaign stole signing certificates and associated passwords. [1]
Command injection lets attacker-controlled input influence operating-system commands. Server-side template injection can turn input intended as data into instructions evaluated by a template engine. Both can bring an attacker to consequential execution inside the application environment.
The report does not identify the affected products, template engines, or CVEs. It does establish that exploitation of these vulnerability classes was part of the observed operation. [1]
Zammad: From an Application Flaw to Root
DIVD, the Dutch Institute for Vulnerability Disclosure, reported that its September intrusion used two Zammad vulnerabilities: CVE-2026-102489, a session-hijacking flaw leading to remote code execution, and CVE-2026-102490, a local privilege-escalation flaw affecting DEB/RPM installations. Its October 31 update identified ARTEX as the framework used and reported 12 minutes from initial access to root. [5]
That interval measures progression through the intrusion. It does not establish how long it took to discover the vulnerabilities or who discovered them.
For defenders, the sequence matters: exploitation of an application flaw can create the foothold for a second vulnerability to deliver greater control. Interrupting a supported sensitive action earlier in that sequence can prevent the next step from succeeding.
Public Source Gives AI Material to Analyze, Test, and Adapt
Magento Open Source and Zammad publish their source code on GitHub. The same transparency applies to many of the libraries and frameworks used inside enterprise applications. An attacker can study a public dependency without access to the enterprise's private application repository. [7] [8]
Source access gives an AI research system concrete material to work with: request handlers, validation logic, dependencies, and the code that processes untrusted data. Public advisories and proof-of-concept exploits add clues and reusable tests. This can reduce the work needed to understand a weakness and develop or adapt an exploitation path.
Horizon3's Zammad research demonstrates this mechanism. Its researchers supplied an AI harness with DIVD's public case information, an indicator-of-compromise script, and the Zammad source repository. The harness identified a potential session-data leak but initially failed to find an unauthenticated trigger. After the researchers directed further fuzzing, it found a request that exposed session cookies. [6]
Horizon3 then demonstrated a path from an administrative session to Ruby code execution through a malicious ERB template. This was a controlled research reconstruction after disclosure. It demonstrates how AI can assist analysis and exploit development using public material; it does not establish how the original attacker discovered the flaw. [6]
The practical consequence is clear: public implementation details and reusable exploit material can become inputs to an automated attack workflow. Open source also gives defenders the same opportunity to inspect, test, and fix the code. The challenge is keeping that knowledge connected to what is deployed and executing.
Shared Code Makes Runtime Context More Important
Applications are assembled from components with different jobs: parsing input, rendering templates, handling authentication, processing files, or communicating with other services. Their code may be shared across many products and deployments.
When the same vulnerable component and relevant conditions recur, an attacker can reuse earlier analysis. Successful exploitation still depends on the target's version, configuration, exposure, and execution path. Those differences make production context essential.
A package inventory establishes what is present. Security teams also need to understand which components execute and which sensitive actions they initiate. A process name alone does not explain which library caused a command launch or why that library needed the capability.
Patching removes known weaknesses. Runtime visibility and enforcement help address the period before remediation and the sensitive actions an attacker may attempt through an unknown flaw. Enterprises need both.
How Raven Connects Runtime Visibility to Prevention
Raven organizes runtime security around the code inside the application: its libraries, functions, call paths, and permitted actions.
Prioritize Using Evidence of Execution
Raven adds runtime context to vulnerability management by distinguishing code that is deployed, loaded, observed executing, and observed executing a vulnerable function in supported workloads. This helps teams focus investigation and remediation on evidence from their actual applications. [9]
Execution evidence is a prioritization signal. A vulnerable function being observed does not by itself prove exploitation, and an unobserved function is not a guarantee of safety.
Attribute Sensitive Actions to the Responsible Code
Raven ADR adds library, function, and call-path context to application behavior. When a workload launches a process or makes an outbound connection, that context helps identify the code responsible and investigate how execution reached the action. [10]
This is especially useful inside a shared process. One component may legitimately launch a worker; another may only need to parse a document. Understanding the caller gives defenders a more precise basis for investigation and control than treating every component's needs as identical.
Restrict Capabilities at the Library Level
In supported workloads, Raven Runtime Prevention applies policy to sensitive actions such as child-process creation and outbound network access at the library level. Teams can preserve capabilities where legitimate operations require them and restrict them for protected libraries that do not need them. [11]
Consider a library protected by a policy that prohibits launching operating-system commands. If an exploit causes an action attributed to that library to reach the supported enforcement point, Raven can block the prohibited action. The decision does not require a signature for each payload or knowledge of which AI framework generated it.
A capability required by one component should not become a free pass for every other component in the process.
This is the connection between monitoring and prevention: runtime context identifies the responsible code; policy limits what that code can do. A restriction can be established before a particular exploit is disclosed and remain relevant when an attacker changes the payload while attempting the same prohibited action.
For any specific exploit, coverage depends on the workload, code attribution, configured policy, and supported enforcement points. The incident reports cited here describe the attacks; they do not report tests of Raven against those incidents.
Put Runtime Code Security into the Response
ARTEX and related frameworks make application exploitation a repeatable workflow. Public source, published research, and reusable exploits supply material that AI systems can analyze and act on. The resulting risk reaches the code running inside enterprise applications.
Security teams need answers to three practical questions:
- Which libraries and vulnerable functions are executing in our production workloads?
- Which code is responsible for process creation and outbound network activity?
- Which sensitive capabilities can we remove from individual libraries while preserving legitimate application behavior?
Raven brings those questions together through runtime visibility, application detection and response, and policy enforcement on sensitive code actions.
Know which code runs. Understand what it does. Control what it can do next.
Explore Raven's Runtime SCA, ADR, and Runtime Prevention to evaluate the execution paths that matter in your environment. [9] [10] [11]
Protect your code at runtime. CVE or no CVE.
Sources
[2] AhnLab ASEC — ARTEX Infrastructure Analysis #4: The Birth of Copy Cat (October 15, 2026).
[3] Adobe — Security update available for Adobe Commerce, APSB26-146 (September 7, 2026).
[6] Horizon3 — Zammad CVE-2026-102489: Session Leak to RCE (October 7, 2026).
[7] Magento Open Source — Official source repository.
[8] Zammad — Official source repository.
[9] Raven — Runtime Software Composition Analysis.
[10] Raven — Application Detection and Response.
[11] Raven — Runtime Prevention.
