Authenticated code execution via the ILIAS Media Pool

1.Summary

In ILIAS, subtitles can be attached to a media object. For several subtitles at once, there is a way to upload them bundled as a ZIP archive. The application accepts this archive and extracts it in order to get at the subtitle files it contains.

The extraction was unmodified and unfiltered: the archive’s entries were written to a working directory under their original names, without restriction to the expected subtitle extensions, without reducing the names to a bare file name and without neutralising executable files. The only filter skipped metadata entries of the kind some archiving tools add. As a result, any entry whatsoever survived the extraction – including a PHP script.

The location is what matters: the working directory lies below the data directory served by the web server. Normally ILIAS protects this area by routing deep requests through an access control that delivers or denies files instead of executing them. However, because the archive could additionally bring its own .htaccess and the shipped server configuration permits local overrides, this protective redirect could be switched off for that one directory. The placed PHP script was then served and executed by the normal PHP handler.

The prerequisite was a logged-in account with the right to edit a media object – for example, write permission on a Media Pool. That is an author permission that is commonly delegated, not administrative access and nothing that could be reached without logging in.

2.Affected systems

All version lines maintained at the time of the report were affected, in each case up to the release that contains the fix. The fix shipped in the release round of 12 August 2026.

Beyond the version, two properties of the installation determine how well the described path works: whether the data directory is served by the web server at all and PHP can be executed there, and whether the shipped configuration permits local overrides via .htaccess. Both correspond to the usual default state as shipped. That is one more reason to harden these areas, but no substitute for the update.

3.Technical analysis

Prerequisites. A logged-in account with the right to edit a media object – for example, write permission on a Media Pool. No administrative rights, no user interaction on the other side.

The finding does not arise from a single faulty check, but from the combination of two decisions, each taken on its own: an archive from an untrusted source is extracted unfiltered, and this happens in a location that the web server serves and where it executes PHP.

The chain

1. The entry point checks only permissions, not content The interface for uploading multiple subtitles checks whether the caller is allowed to edit the media object. The uploaded archive itself is subject to no content restriction; subtitles are expected, but this is not enforced.
2. The target lies in the served area The archive is moved into a working directory below the data directory that the web server serves – not into an internal storage location that is not served.
3. Extraction is unmodified The extraction preserves the original entry paths. There is no restriction to permitted extensions, no reduction to a bare file name and no neutralisation of executable files. The only filter skips metadata entries from certain archiving tools. As a result, every entry survives the extraction – including a PHP script and a .htaccess.
4. The bundled configuration removes the protection Deep requests to the data directory are normally redirected through an access control that delivers or denies files instead of executing them. The .htaccess placed with the archive switches this redirect off for the affected directory – possible because the shipped server configuration permits local overrides. The placed script is then executed by the normal PHP handler.

4.Impact

At the end of the chain is code execution in the context of the web server user. That is the most severe case a web application knows: whoever executes code at this point can read and modify the instance’s entire data, reach the database credentials via the configuration, establish a persistent foothold and work their way further into the environment from there.

What distinguishes the finding from an unauthenticated takeover is solely the entry ticket: it requires an account with edit rights on a media object. That is not a high bar – author and editorial rights on Media Pools are granted widely in many installations, to people nobody would suspect of taking over the server.

Why there is no CVSS rating of my own here

The impact itself is unambiguous and leaves no room for interpretation: full code execution, the maximum. What differs between installations is reachability – how widely edit rights on media objects are granted, whether the data directory is served and whether PHP can be executed there. A single number captures this juxtaposition of “as bad as it gets once it applies” and “applies more or less easily depending on the set-up” poorly. For prioritisation, the sentence below is more reliable than a score.

Impact in one sentence: full code execution as the web server user, triggered by any account that is allowed to edit a media object.

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, besides this fix, contain further security fixes.

Interim measures if you cannot update immediately

• Restrict edit rights on media objects. The fewer accounts are allowed to edit Media Pools, the smaller the group from which the path can be taken at all. This is the most effective organisational immediate measure.
• Prevent execution in the data directory. The served data area should not allow PHP execution and should not permit local overrides of the server configuration. This hardening removes the basis for the last link in the chain and is effective independently of this finding.
• Renew credentials. If it must be assumed that code has been executed, the secrets stored in the configuration should be treated as compromised – database credentials and setup password first.

Checking for past exploitation

• Foreign files in the data directory. Executable files or .htaccess files below the media object directories of the data area that have no business being there are a clear finding.
• Requests to served data paths in the web server logs – in particular direct requests for script files below the data directory.
• Media objects created and removed again in quick succession, insofar as this can be reconstructed from log data.

If there is reasonable suspicion, the web server user should be treated as compromised: renew stored credentials, invalidate sessions and restore the instance from a clean state.

6.Disclosure timeline

1. 2026-07-14 Identification and report to the vendor Mantis 0048067
2. 2026-08-12 Patch by the vendor ILIAS 9.22, 10.10 and 11.3
3. 2026-09-03 Publication of this Advisory

7.References

• CVE CVE-2026-85135.
• Vendor ILIAS open source e-Learning e.V. – report of 2026-07-14, tracked as Mantis 0048067; fix included in releases 9.22, 10.10 and 11.3 of 2026-08-12.
• CWE CWE-434 – unrestricted upload of file with dangerous type.
• Related SIT-2026-001, SIT-2026-002 and SIT-2026-003 – further findings from the same investigation.
• Policy schweigertIT’s responsible disclosure policy.
• Research Research overview with the running CVE list.