GLPI Agent: The “No-CVE” That Still Bought Us Domain Compromise Two Years Later

By Javier Medina ( X / LinkedIn)

TL;DR

We identified that a standard compromise of a GLPI server can silently escalate into a Domain Compromise by abusing a default configuration in GLPI agents (<= v1.7.3). These agents run as SYSTEM on Windows and, by default, blindly accept Deploy tasks from the server.

While the vendor refused to assign a CVE, claiming this architectural flaw wasn’t a vulnerability, they silently patched the issue in version 1.8 by disabling these features by default.

If you are running a legacy fleet, your infrastructure remains exposed to a critical lateral movement vector that no vulnerability scanner will detect. Furthermore, if you have the Deploy feature enabled in agent versions > 1.7.3, the risk will be the same.

Mitigate: If a specific endpoint does not strictly require software deployment, disable the Deploy feature immediately. This applies to any agent version. If the feature is present, the risk exists. If you must use Deploy, consider restricting it to standard user endpoints. It should never be enabled on critical assets (DC, PKI, …) or on system administrator workstations. Finally, treat GLPI as Tier-0. Accept that a compromised server means code execution as SYSTEM on all agents.

0# A Story of Lies

October 2025.

We were deep into an offensive engagement for an OT vendor. During the initial offensive phase, we identified a GLPI server exposed on the internal network.

As is often the case with GLPI instances, it didn’t put up much of a fight. We identified a SQL Injection, chained it into a standard Remote Code Execution (RCE), and within minutes, we had a shell on the server as www-data. Standard procedure. We were in.

We started enumerating the environment from the inside. We accessed the GLPI web interface to see exactly what this server was monitoring. And there it was, staring back at us from the native inventory list:

GLPI Agent v1.7.3

Our hearts skipped a beat. According to known databases, the deployed GLPI Agent (v1.7.3) is pristine. No vulnerabilities found.

We smiled. We knew that was a lie.

We knew it was a lie because we discovered this exact vulnerability more than two years ago. We knew it was a lie because we tried to report it. And, now, we knew it was a lie because we’ve watched the vendor decide that silently patching the flaw was a better strategy than admitting they had designed a highway to NT AUTHORITY\SYSTEM on every endpoint in their customers’ networks.

This is the story of our internal VULN-2023-68-03, and how the CVE bureaucracy protects vendors while leaving sysadmins defenseless.

1# The GLPI Trojan Agent

Rewind to September 2023.

During another offensive exercise, we compromised a GLPI server. Nothing groundbreaking there; GLPI and its plugins have a security history that reads like a horror novel.

We achieved RCE on the web server (running as www-data).

Usually, the game pivots here using standard lateral movement. But we noticed something interesting. The GLPI Agent.

In version 10, GLPI introduced a new agent architecture. Analyzing its default behavior (<= v1.7.3), we found a toxic cocktail of bad design decisions:

1. High Privilege: The agent installs and runs, by default, as SYSTEM on Windows.
2. “Deploy” Enabled by Default: The agent installer checked the “Deploy support” feature box by default. This potentially allows to the server to push software or scripts to the clients.
3. Blind Trust: The agent blindly trusts the server’s instructions.

To understand why this is critical, we have to understand the mess of GLPI’s inventory architecture in version 10. This distinction is what the vendor partially used to deny the CVE; and it is exactly what we exploited.

There are two distinct endpoints that handle agents on GLPI:

• The Native Inventory (/front/inventory.php): This is the default built-in server endpoint. It’s designed to be safe (don’t take SQL injections under consideration). So, if an agent tries to ask for a Deploy task (to install software or run scripts), the Native Inventory rejects it. It simply ignores these advanced features. The capability is there in the agent, but the native server endpoint refuses to trigger it.
• The GLPI Inventory Plugin (/marketplace/glpiinventory/): This is the extended endpoint. It must be installed from the plugin store. It’s powerful. It accepts Deploy tasks and can instruct agents to execute arbitrary commands.

So, under common circumstances, the agent wants to be able to deploy software (and execute commands), but the server with native endpoint says: “No”. In short, the gun is loaded but the safety is on.

But here is the magic that changes everything. We have already compromised the GLPI server thanks to the myriad vulnerabilities stored in its code.

So we discovered we could simply modify the server behavior to tell the Agent: “Hey, don’t talk to the boring Native Inventory. Talk to this other endpoint that DOES accept commands“. And of course, not just any agent, but the one someone had left at the DC.

2# Hijacking the Trust Flow

Since we had write access to the webroot (thanks to the initial RCE), we became the GLPI server.

The attack vector was really simple. As we said, all the work is to force agents to talk to the GLPI Inventory Plugin instead of the Native Inventory endpoint.

To achieve this, we modified the native core file /front/inventory.php. We injected a few lines of code to intercept the agent’s Deploy requests and redirect them to the GLPI Inventory plugin endpoint, which we knew would happily serve a malicious payload. Here is the dirty code we used to patch the server on the fly.

// /front/inventory.php modification
if (str_contains($_SERVER['QUERY_STRING'], "Deploy")) {
header('Content-Type: application/json');
// We tell the agent: "Oh, you want to deploy? Go talk to the plugin here:"
die('{"configValidityPeriod":600, "schedule": [{"task": "Deploy", "remote": "http:\/\/192.168.X.Y\/glpi\/marketplace\/glpiinventory\/b\/deploy\/"}]}');
}

We also had to ensure the plugin endpoint was accessible. A quick .htaccess injection in /glpi/marketplace/glpiinventory/b took care of any access controls.

Satisfy any
Allow from all

Executing a payload

With the redirection in place, we went to the GLPI interface and created a deployment task in to the GLPI Inventory Plugin.

The payload? A straightforward domain dominance move. Since the Agent was already running as SYSTEM on the Domain Controller, we didn’t need complex exploits. We simply used native Windows commands (net group "Domain Admins" ... /add) to grant ourselves full administrative rights over the domain.

The logs on the GLPI server confirmed the execution perfectly.

From a low-privilege web shell on a Linux inventory server, we pivoted to Domain Admin on the Windows infrastructure. Zero exploits involved on the Windows side.

Pure unadulterated feature abuse.

3# The “No-CVE” Bureaucracy

With a working PoC and our client’s domain under control, we did the responsible thing. We sent a really detailed report to INCIBE (the Spanish CNA) to coordinate a CVE assignment.

We expected a technical discussion. We got a lesson in corporate semantics.

After months of back-and-forth, on April 22, 2024, the final verdict arrived. GLPI and the CNA rejected the CVE. The reasoning?

“Vulnerability requires source code modification of the application, which, while being a security incident, disqualifies it from CVE assignment.”

Read that again.

They argued that it’s not a vulnerability because, to exploit it, we need to modify files on the server (which we could already do because we had already breached the server).

This is a classic straw man fallacy. It ignores the impact. The vulnerability isn’t that we can write to the server. The vulnerability is that the agent’s insecure defaults allows a low-level server compromise to potentially escalate to a total Domain Compromise, or at least, to a massive Lateral Movement vector. It’s equivalent to saying that leaving the vault keys taped to the bank’s front door isn’t a security flaw because the robber technically has to reach the door first.

In GLPI Agent (≤ 1.7.3), the agent is shipped with a Deploy capability enabled by default that legitimate admins cannot use out-of-the-box, because the native server endpoint ignores it. This is the core contradiction. It’s an initialization of a resource with an insecure default without any doubt (CWE-1188).

We pushed back. We explained they were downplaying a Massive Fleet Compromise vector. The final response?

We agree with your concerns, but GLPI says no, so no CVE. We asked them to add a disclaimer.

A disclaimer. Right. That’ll stop the APTs.

4# The Silent Patch

Here is where the story shifts from disappointing to something similar to negligent.

We didn’t discover this until a few weeks ago. And, honestly, if we hadn’t discovered it, I don’t know if we’d be talking about it. Maybe yes, maybe no. But the point is that now we feel like talking about it.

The vendor denied the vulnerability. OK. This was circumstantial bullshit that only mattered to us. If your GLPI server is compromised, you should burn in hell by default. It’s an aggressive position, but hey, that’s life. We’ve got it.

Yet, curiously, on May 15, 2024, mere weeks after closing our report, and while they were telling the CNA that this didn’t matter, they released GLPI Agent 1.8.

And what did we find buried in the doc?

“The base feature is feat_AGENT which is always selected and includes Inventory task. Since v1.8, no other task is selected by default.“

Suddenly, the Deploy functionality, the one enabled by default that let us pivot to the entire domain, was disabled by default.

Why? That’s a good question.

Could it have something to do with the fact that some guys told them several months earlier that it was complete crap and that they had taken over a multinational company’s DC because of this stupidity?

In any case, they changed it up with:

• No security notice.
• No credit to the researchers.
• No CVE.
• No warning to the thousands of admins running v1.7.3 or older with Deploy enabled by default.

They made the attack vector disappear for new installations with defaults options but left every existing installation abandoned. And of course, nowhere do they warn of the risks of installing the agent with Deploy enabled whether necessary or not. Ultimately, if you install a GLPI agent version > 1.7.3, where the risk has been mitigated, over a version <= 1.7.3 where extended features are enabled, these features are not always removed.

5# The Cycle Closes

Which brings us back to October 2025.

We breached our client GLPI Server. We saw GLPI Agent 1.7.3.

We checked CVEDetails just to gloat: GLPI Agent 1.7.3 Vulnerabilities. 0 Vulnerabilities.

Why would they update something that was ‘secure’ and about which no one had issued a security alert?

But we knew things they didn’t know. We exploited the server. We redirected the traffic. BOOM. A new compromise powered by GLPI Agent.

This compromise was sponsored by:

1. An insecure default configuration in any GLPI Agent prior to v1.8
2. A Vendor who preferred burying a flaw to fixing it publicly
3. A CVE System that prioritizes bureaucracy over operational reality

6# Closing Thoughts

If your security posture depends on the presence of a CVE to trigger an action, you are outsourcing your risk model to a bureaucracy system that was never designed to capture every real-world risk.

We prefer impact over paperwork. If we find a flaw, we exploit it to prove the risk, regardless of what the vulnerability database says, because adversaries don’t operate on bureaucracy.

They operate on opportunity and one is usually enough for them.

Mitigation Strategies

Take our advice, the best thing you can do is remove GLPI from your life, but if you still can’t, follow these tips.

Audit your agents

• Identify endpoints running ≤1.7.3.
• Identify endpoints where Deploy support is enabled.
• Treat Deploy as a risk.

Upgrade your defaults

• Move to a current agent version.
• Ensure Deploy/Collect are explicitly opt-in only where truly needed.
• If you don’t use Deploy, remove it. Don’t just ignore it.

Segregate GLPI as a high-risk tier component

• Treat GLPI like a complex web application with a long vulnerability history.
• Segment it aggressively.
• Avoid paths from GLPI to Tier-0 assets (domain controllers, privileged management networks, …).
• If an agent on a Tier-0 system exists at all, it should be the exception and it should not have Deploy capability.

Detection & Forensics

If you suspect abuse or want to harden proactively, focus on this surfaces:

• GLPI server core: any change to front/inventory.php is a red flag (look for injected JSON returning "task":"Deploy" + "remote":"...glpiinventory.../b/deploy/").
• GLPIInventory plugin path: monitor writes under /marketplace/glpiinventory/ or /plugins/glpiinventory/ (especially .htaccess “allow-all” patterns).
• Web/network logs: alert on Deploy patterns: inventory.php?...Deploy... and plugin polling like action=getConfig + task[Deploy], then /b/deploy/?action=getJobs.
• Windows endpoints: glpi-agent.exe spawning cmd/powershell/msiexec/schtasks/... as SYSTEM = likely Deploy abuse; on DC/Tier-0 treat as critical.

We’ll release a small detection pack.

Disclosure Timeline