CVE-2025-24813 — a remote code execution flaw disclosed in March 2025 and added to CISA's Known Exploited Vulnerabilities catalog the same month — is the kind of legacy exposure that can let an attacker turn a routine server compromise into a full takeover of an enterprise AI agent.
CVE-2025-24813 and the perimeter-to-agent chain
The vulnerability on an Internet-facing Apache Tomcat server is not exotic. In the scenario modeled by Zur Ulianitzky and his team at XM Cyber, an unpatched Tomcat instance exposed to CVE-2025-24813 allowed an external attacker to dump cached credentials and compromise an Active Directory (AD) user account. Alone, that is a serious but familiar finding. Connected to the rest of the environment, it becomes the opening gambit in a chained attack that ends with control of an AI agent's knowledge base.
AI agents inherit legacy identity, cloud, and permissions
AI adoption is outpacing many security programs: roughly 71% of organizations are piloting AI agents across enterprise applications, and 31% have moved agents into production workflows. Yet agents authenticate, store, and act through the same identity providers, cloud buckets, Lambda functions, IAM roles, service accounts, and stored credentials administrators have managed for years. As Ulianitzky warns, those dependencies carry whatever security debt existed before the agent went live.
That debt is compounded when organizations grant AI systems higher privileges than humans. Infosecurity Magazine data cited in the source shows 70% of organizations give their AI systems more privileged access than a human in the same role, a configuration associated with a 76% incident rate versus 17% for organizations enforcing least privilege.
The three-stage attack on an AWS Bedrock Co-Pilot
Ulianitzky's modeled enterprise environment centers on a customer-success Co-Pilot hosted on AWS Bedrock that queries customer records exported from Salesforce into an S3 bucket. The chain unfolds in three stages:
- Stage 1 — An S3 bucket becomes a high-value target when Salesforce exports populate production data. Multiple users received overly broad read access to production S3 buckets, including John, the Co-Pilot developer, who did not need production data access. This was a permissions misconfiguration.
- Stage 2 — An externally exposed Apache Tomcat server remained unpatched for CVE-2025-24813. Because the server was joined to Active Directory, an attacker exploiting the flaw could dump cached credentials and compromise an AD account.
- Stage 3 — The compromised AD account abused a Resource-Based Constrained Delegation misconfiguration to impersonate John and access his workstation. John used the AWS CLI to manage the Co-Pilot; the CLI stored AWS access keys on his machine. The attacker harvested those keys and read every record in the production S3 bucket that feeds the Co‑Pilot's knowledge base.
Once the attacker controlled what the Co‑Pilot read and trusted, they effectively compromised the agent without ever attacking the AI stack directly. Three moderate findings — an overprivileged cloud key, an unpatched web server, and an AD misconfiguration — chained into a single critical path to an AI asset.
Why point tools miss chained exposure and what to do instead
Conventional security tooling tends to assess network, identity, cloud, and AI layers independently. An External Attack Surface Management (EASM) tool will flag the Tomcat server. An AD security tool will surface the delegation misconfiguration. A Cloud Security Posture Management (CSPM) product will note the overprivileged S3 access. Each tool may label its finding “moderate,” and remediation can be deprioritized.
Ulianitzky advises treating AI agent dependencies — knowledge bases, storage buckets, Lambda functions — as critical assets and mapping the upstream identity relationships, permissions, and infrastructure that connect to them. When exposure management traces the full path from an unpatched server through AD and cloud infrastructure to the agent’s knowledge base, choke points appear where a single remediation blocks multiple routes to AI assets. If the exposure management platform cannot trace that path, guardrails on the AI layer alone will not close the risk.
What this means for technologists, procurement leaders, and security teams
- Technologists and security teams: Map dependencies for each AI agent back to identity providers, cloud buckets, Lambda functions, and the legacy infrastructure that supports them. Prioritize fixes that sever end-to-end attack chains rather than treating each moderate finding in isolation.
- Affected enterprises and procurement leaders: Treat AI agent assets as critical when assessing vendor posture and buying exposure management tools. Demand visibility that can trace a path from legacy perimeter services into agent knowledge bases before deploying agents into production.
- Adversaries and threat actors: The modeled attack shows that old techniques — exploiting an unpatched Tomcat instance, abusing AD delegation misconfigurations, harvesting CLI-stored keys — remain effective when the environment allows them to reach modern AI assets.
Ulianitzky’s final summation is stark and specific: “Because attackers don't need new techniques to compromise AI agents. They just need the old ones - and an environment that lets them use the old to exploit the new.” The challenge for security leaders is not only securing models and prompts but ensuring the decades of infrastructure that agents inherit do not hand attackers the path to hijack them.
https://thehackernews.com/2026/06/stop-your-legacy-infrastructure-from.html
