GLPI Agent 1.18 shipped on 23 June 2026 and 1.19 followed on 4 August 2026. Both are largely security releases. The advisories behind them were published in two waves — 23 June and 27 July 2026 — thirteen entries in total, six of them rated High.
Vulnerabilities in the core and in plugins at least reach someone's desk when the server is updated: there is a plan, a window and a person who signs it off. The agent was installed once during rollout, runs on hundreds of workstations and servers, and nobody has opened it since. In practice it gets patched on a completely different clock than the core.
What 1.18 fixes
- CVE-2026-58199, CVSS 7.7 — SSH option injection in remote inventory, leading to code execution in the context of the glpi-agent process.
- CVE-2026-40936, CVSS 7.7 — unauthenticated path traversal in the ToolBox plugin: an attacker on the network reads any file on the host and deletes it after retrieval.
- CVE-2026-49285, CVSS 7.6 — command injection in the ToolBox plugin's results export through an unsanitised tag_filter field.
- CVE-2026-46615, CVSS 7.3 — the MySQL and PostgreSQL inventory modules pass database names into a shell command without sanitising them.
- CVE-2026-52764, CVSS 7.2 — the same for MSSQL, where the sqlcmd tool is installed on the machine.
- Also MongoDB (CVE-2026-45621), Oracle and DB2 (CVE-2026-52765), path traversal in Tools::Archive (CVE-2026-52768) and a flaw in the Proxy plugin when local_store is enabled (CVE-2026-42187).
What 1.19 adds
Version 1.19 brings two more command injection fixes: CVE-2026-63444 in the deploy task, where the archive filename is supplied by the server, and CVE-2026-63375 in the base folder configuration field of the ToolBox plugin. If you rolled out 1.18 in June, six weeks later there is another reason to go around again.
Where the real risk sits
Most of these flaws share one pattern: the agent treated input from the server, or from the database it was inventorying, as trustworthy. That inverts the direction of attack people normally assume for inventory collection. A compromised GLPI server, or a user allowed to create databases, stops being a single-system problem and becomes code execution on every machine the agent runs on — and it runs with high privileges, otherwise it could not collect the inventory at all.
Exposure is narrowed by the fact that the ToolBox plugin is disabled by default, and several database modules only apply where the mysql, psql or sqlcmd client tools are actually present. That is a reason to verify the scope, not to assume it.
What to check
- The agent versions actually in the field — not the version in your installer package, but what individual machines report. GLPI records it with every inventory it receives.
- Whether the ToolBox plugin is enabled anywhere. If it is and it is reachable on the network, add the Authentication and SSL plugins, or turn it off.
- The database inventory category. If you do not use it, disable it in the agent configuration.
- Machines that have not reported in a long time. An agent that stops sending inventory usually stops updating as well.
For vulnerability management under decree 227/2025, the agent falls in scope exactly as the server does — and it is harder to evidence, because it is hundreds of instances instead of one. A breakdown of agent versions across the organisation is one of the few figures GLPI can produce on its own.