Unauthenticated PHP object injection in the Shibboleth logout endpoint of ILIAS

1.Summary

ILIAS can integrate Shibboleth as a login method. So that the identity provider can tell the application that a session has ended, there is a back channel: an endpoint that is called not by the browser of a logged-in person but by a third-party server. This endpoint is therefore deliberately exempt from the login requirement – which in itself is correct, because the caller is not someone who could be logged in.

To work out which session to end, the logout handling went through every active session of the instance and passed the stored session data of each to a custom parsing function. That function called unserialize() without using the allowed-classes parameter to restrict what may be created. Stored strings thus became real objects – created on behalf of a caller who had never logged in.

The second part of the finding is the question of how an attacker gets anything into a session in the first place. That, too, worked without an account: another entry point of the application, the LTI integration, stores submitted request parameters in the session and is likewise exempted from the login requirement by the same initialisation. This makes it possible to create an anonymous session with arbitrary content, which then sits in the database.

Objects created during deserialisation are discarded again at the end of the request, and their clean-up methods run as they are. A library class shipped with ILIAS writes a file in its clean-up method, with a path taken from one of its own properties. Via this route, an unauthenticated caller could place a file with content of their choosing below the served directory and then have it executed – code execution as the web server user, without an account, without a token, without any action by a human on the other side.

2.Affected systems

The vulnerable code was checked individually in every version line maintained at the time of the report – not inferred from one line to the others. It is present in all three lines and identical in substance.

Present code and actual triggerability are two different things

The version information above follows the vulnerable code, and for the question “do I need to update?” that is the right basis. When checking the individual lines, however, it turned out that the endpoint does not behave the same everywhere. I record this here because it helps operators with prioritisation – not because it reduces the urgency of the update:

When an instance was reachable in practice

Beyond the version, actual exploitability depends on properties of the operating environment. The main factors for assessing your own installation are: whether PHP's SOAP extension is loaded, whether the endpoint is reachable for the server itself over HTTPS with a certificate it trusts, and whether there is a writable area below the served directory in which stored files are also executed. In a standard installation these conditions can be met; anyone running their instance differently may not have been reachable. This, too, is a snapshot of the configuration and no substitute for the update.

3.Technical analysis

Prerequisites. None. No account, no role, no CSRF token, no interaction on the other side. Two ordinary HTTP requests were enough, to endpoints that must both be publicly reachable for the associated procedures to work.

The finding does not arise at a single point. It arises where two decisions meet, each of which is understandable on its own: an endpoint that must be reachable without login, and a store that an unauthenticated user can fill. Between them sits a function that treats this store as trustworthy.

The four links

1. The endpoint is exempt from the login requirement The central initialisation of ILIAS knows contexts in which no authentication is required. The Shibboleth back channel is one of them, and rightly so: the calling identity provider is not a logged-in user.
2. The logout handling reads all sessions To determine the session to end, all still valid session records were loaded and their stored contents sent one by one through a hand-written parsing function.
3. Deserialisation without class restriction This function called unserialize() without specifying allowed classes. As a result, the stored text can become any object whose class the application knows – including classes from bundled third-party libraries.
4. The content got into the session without login Another entry point, likewise exempt from login, stores submitted request parameters in the session. The anonymous session created this way is saved – and thus read along by the previous step.

The vendor's fix

The vendor removed the endpoint's logout handling in all three lines instead of hardening it. I consider that the right decision: the function was tied to an operating mode that only some instances use at all, and its task – picking the matching local session out of an external notification – can hardly be solved sensibly without looking through all session data. Removed code is the only code guaranteed to contain no more vulnerabilities.

Why the chain held

Here, too, none of the points is a flaw on its own. Only their combination produces the finding:

• An exemption from the login requirement that is correct for its original purpose applies to everything that runs in that context – including processing added later.
• The same initialisation exempts a second entry point from the login requirement, one that writes data. Harmless on its own, in combination half the battle.
• In many applications session data is implicitly considered trustworthy because it comes “from ourselves”. As soon as a login-free path can write into it, that assumption no longer holds.
• The parsing function was hand-written and deserialised without class restriction – the parameter for this has existed since PHP 7.0.
• The processing covered all sessions of the instance, not just the caller's. So it was enough to create a session anywhere at all.
• The bundled third-party libraries provided a class whose normal behaviour on clean-up is to write a file.

4.Impact

At the end of the chain is code execution with the privileges of the web server user. This affects not a single function but the entire instance: all content and courses, all user accounts including password hashes, the complete data set, stored credentials for connected systems and all active sessions. From this point on the installation is no longer trustworthy, and applying the patch alone does not make it so again.

Making matters worse, there is no hurdle to stop an attacker: without an account and without user interaction, the flow can be automated and run broadly against reachable instances once the location is known. That is exactly the difference from SIT-2026-001, where at least a logged-in account with write permission was required.

For context, the counter-check belongs here too: the rating assumes that the environmental conditions named in section 2 are met. They describe an ordinary installation, but not every one. I list them explicitly so that operators can assess their own situation instead of having to trust a number – and because a condition that is not met today may be met tomorrow.

Impact in one sentence: complete takeover of the instance by any caller from the network, without an account and without any action by a human on the other side.

5.Mitigations / workarounds

Update

The decisive and only complete measure is updating to ILIAS 9.22, 10.10 or 11.3. These versions were released on 12 August 2026 and contain further security fixes in addition to this correction.

Interim measures if you cannot update immediately

• Block the endpoint at the upstream web server. The affected file is shib_logout.php from the Shibboleth component (the path differs between version lines; the public CVE entry gives it in full). If you do not use Shibboleth as a login method, you never need this back channel – requests to it can be rejected without side effects, and that is the most effective immediate measure. If you use Shibboleth, you can restrict access to the addresses of your own identity provider.
• Block unused entry points as well. This applies in particular to the entry point of the LTI integration if no external tools are connected. It is the route by which content gets into a session without login, and in a typical installation it is as unused as it is reachable.
• Prevent execution in the data directory. Preventing the web server from executing files stored below the served directory is worthwhile hardening regardless of this finding – and here it is the link that turns writing a file into code execution.

Checking for past exploitation

Both endpoints involved are addressed via ordinary HTTP requests and leave corresponding traces. Useful starting points:

• Requests to shib_logout.php. In instances without Shibboleth there should be none at all; every single hit needs explaining. In instances with Shibboleth, calls from addresses other than those of your own identity provider are suspicious.
• New or modified executable files below the served data directory – compared against a known clean backup, not by gut feeling.
• Unusually large session records in the session table, especially those without an associated user account.
• PHP errors related to SOAP processing or to deserialisation that coincide in time with such calls.

If the suspicion hardens, treat the instance as compromised: take it off the network, secure evidence, rebuild from a demonstrably clean backup, renew all credentials and keys – including those for connected systems – and invalidate all sessions. Resetting passwords alone is not enough if the attacker was able to execute code on the server.

6.Disclosure timeline

1. 2026-08-03 Identification and report to the vendor Mantis 0048152
2. 2026-08-12 Patch by the vendor ILIAS 9.22, 10.10 and 11.3
3. 2026-08-26 Publication of the CVE entry CVE-2026-80428
4. 2026-09-01 Publication of this Advisory

7.References

• CVE CVE-2026-80428 – published 2026-08-26, CWE-502, CVSS 4.0 9.3 (Critical).
• Vendor ILIAS open source e-Learning e.V. – report of 2026-08-03, tracked as Mantis 0048152; fix included in releases 9.22, 10.10 and 11.3 of 2026-08-12.
• Fix Commit f36934a6f937d0fe837ca6e642986458b4069a95 in the vendor's repository.
• CWE CWE-502 – Deserialization of Untrusted Data.
• Related SIT-2026-001 – second finding from the same investigation, fixed in the same releases.
• Policy schweigertIT's responsible disclosure policy.
• Research Research overview with the current CVE list.