How We Found CVE-2026-42318 in GLPI

Here is the story behind CVE-2026-42318, a vulnerability we recently reported and published in GLPI — how we found an authorization bug, what it does, and why this class of flaw keeps slipping past automated tools.

A side project with a point

Earlier this year we started a focused effort: spend dedicated time reading the source code of widely used open-source software and report what we find. Not for the money — most of these projects do not pay bounties. We do it because finding real bugs in real software is the most honest proof of skill a penetration testing firm can offer. Anyone can list certifications on a website. A CVE with your name on it in the official record is harder to argue with.

CVE-2026-42318 came out of that program. It will not be the last.

Why GLPI

GLPI is one of the most widely deployed open-source IT asset management and service-desk platforms around. Universities, government agencies, and plenty of enterprises run it to track assets, manage tickets, and schedule work. It is a large PHP application with a deep permission model — many roles, many features, many places where a small access-control mistake can hide.

That last part is what makes a tool like GLPI interesting to look at. Complex permission systems are exactly where authorization bugs live. The more granular the roles, the easier it is for one code path to forget to ask the right question.

What we found

While reading through the planning feature, one delete path stood out. GLPI's Planning module lets technicians manage scheduled items on a shared calendar. The action that removes an item takes a reference to the object it is about to delete — but it never confirms that the user making the request is actually allowed to delete that object.

In other words, the code checked that you could use planning. It did not check whether the specific thing you were deleting was yours to delete. That gap is a classic insecure direct object reference, and at the standards level it is CWE-862, Missing Authorization.

The practical effect: a user who only holds planning access — a technician-level account, nowhere near an administrator — could delete arbitrary objects across the whole instance. Tickets. Assets. Records that account had no rights over and no reason to touch. No data theft, but plenty of destruction, in a system other teams rely on to do their jobs.

Coordinated disclosure, done right

We reported the issue privately through GitHub's vulnerability reporting, and the GLPI maintainers handled it the way the process is supposed to work:

• April 24, 2026 — we reported it.
• The team confirmed the bug, assigned CVE-2026-42318, and prepared the fix across both supported release lines.
• June 1, 2026 — the advisory went public and the fixes shipped in 10.0.25 and 11.0.7.
• June 3, 2026 — the CVE record went live on cve.org, crediting us as the reporter.

About six weeks from report to public fix, with the reporter credited. That is what good open-source security collaboration looks like, and the GLPI team earned the credit for it.

Why a scanner would have missed it

Here is the part that matters if you are the one buying security testing rather than doing it.

A vulnerability scanner works by matching what it sees against a database of known issues and signatures. It is good at telling you that you are running an outdated, known-vulnerable version of something. It is useless at understanding intent. A scanner has no concept that "access to the planning calendar" should not also mean "permission to delete the company's asset inventory." That is a business-logic decision, and logic is invisible to pattern matching.

This bug only surfaces when a human reads the code or tests the authorization model by hand — sending the delete request as a low-privileged user and watching it succeed against an object that should have been off limits. That is the difference between an automated scan and a real penetration test, and it is the same gap we find in our clients' own applications all the time. Broken access control is consistently one of the most common — and most damaging — categories of finding in the work we do.

If you run GLPI

Upgrade to 10.0.25 or 11.0.7. If you cannot patch right away, the vendor workaround is to disable delete rights for users' planning access until you can, and it is worth reviewing exactly who holds that access in the meantime. The full advisory has the version details and CVSS breakdown.