CVE-2026-42318: Arbitrary Item Deletion in GLPI via Planning

Voke Cyber found this issue during a manual review of GLPI's source code and reported it through the project's private vulnerability reporting process. The GLPI maintainers confirmed it, assigned CVE-2026-42318, and shipped fixes in versions 10.0.25 and 11.0.7. This page is our advisory writeup; everything below is drawn from the published GHSA and CVE record.

What GLPI is

GLPI is one of the most widely deployed open-source IT asset management and service-desk platforms in use today. Enterprises, universities, and government agencies run it to track hardware and software inventory, manage help-desk tickets, and schedule work. The Planning module is its shared calendar — technicians use it to manage scheduled items like interventions, reminders, and tasks.

Because GLPI is a system of record for IT operations, the data inside it — tickets, assets, and planning entries — is exactly the data other teams depend on every day. That context matters for understanding the impact.

The vulnerability

At its core, this is a missing authorization check (CWE-862) — and an insecure direct object reference (IDOR) in practice.

The delete action reachable through GLPI's planning feature acts on a user-supplied item reference, but it does not verify that the requesting user is actually allowed to delete the target object. The endpoint trusts the identifier the caller sends instead of checking the caller's rights on that specific item.

The result is a privilege boundary that does not hold. Any account with planning access can delete arbitrary objects across the instance — including records it was never granted any rights over. In other words, the application confuses two very different things: "you are allowed to use the planning feature" and "you are allowed to delete this specific object." Only the first is checked.

Impact

The CVSS v4.0 vector tells the story cleanly: VC:N / VI:H / VA:H.

• No confidentiality impact. This is not data theft. An attacker cannot read records they should not see through this flaw.
• High integrity and availability impact. They can destroy data. In a system that other teams rely on, deleting tickets, assets, or planning entries is a direct hit to operations.
• Privileges required: high (PR:H). The attacker needs an authenticated account that holds planning access — a technician-level role, not anonymous internet access. That puts the real-world risk squarely in insider-threat and assume-breach territory: a low-trust internal user, or a single compromised technician account, is enough.

The maintainers rated it High, with a CVSS base score of 7.0.

Affected and fixed versions

• Affected: GLPI 9.5.0 up to and including 10.0.24, and 11.0.0 up to and including 11.0.6.
• Fixed: 10.0.25 (10.x line) and 11.0.7 (11.x line).

What to do

1. Upgrade. Move to GLPI 10.0.25 or 11.0.7. This is the actual fix and the only durable remediation.
2. If you cannot patch immediately, apply the vendor workaround: disable delete rights for users' planning access until you can upgrade.
3. Review who holds planning access. Treat it as a privileged capability. Until you are patched, anyone with that access can delete records well outside their normal scope.

Disclosure timeline

• April 24, 2026 — Reported to GLPI through GitHub's private vulnerability reporting.
• Coordination — The GLPI team confirmed the issue, assigned CVE-2026-42318, and prepared fixes.
• June 1, 2026 — GitHub Security Advisory GHSA-w7mr-3vwm-2j22 published; fixes released in 10.0.25 and 11.0.7.
• June 3, 2026 — CVE-2026-42318 record published on cve.org.

Start to finish, coordinated disclosure took about six weeks. Credit to the GLPI maintainers for a clean, professional process and for crediting the reporter.

Why this matters

This is a permission bug that looks minor on paper and never shows up in an automated scan — yet it lets a low-trust user destroy data across a core IT system. A scanner checks software versions and known signatures. It does not understand that "planning access" should not mean "delete anything." Flaws like this only surface when a human reads the code or tests the authorization model by hand. That is the line between a scan and a real penetration test, and it is the work we do.

For the story behind this finding — from source review to coordinated disclosure — read How we found CVE-2026-42318.

References

• GitHub Security Advisory: GHSA-w7mr-3vwm-2j22
• CVE Record: CVE-2026-42318 (cve.org)
• NVD: CVE-2026-42318 (NVD)
• GLPI project & releases: github.com/glpi-project/glpi

Found and reported by Louis Sanchez, Founder & Principal Security Consultant at Voke Cyber (OSCP, OSWA, CISSP, CCSK).