Arbitrary reading of server files via the ILIAS SOAP interface

1.Summary

ILIAS offers a SOAP interface through which other systems can create objects – files among them. When creating one, an XML description is passed which, besides title and description, can also specify that the content should be taken from a file already on the server. For an import in which an archive has previously been extracted, this makes sense.

For this specification to remain harmless, it must be resolved against a fixed base directory – namely the directory into which the import was extracted. That is exactly what did not happen on the SOAP path: a base directory was never set. Resolution therefore took place against an empty value, and what was intended as a relative specification thereby became an absolute path.

The application opened the file so designated and stored its content as a regular file object in the target container. From there, it could be retrieved again via the same interface. As a result, a logged-in caller could read arbitrary files that the web server has access to.

The prerequisite was a logged-in account with the right to create a file in a single, arbitrary container. This is no special permission – in many installations it is held by ordinary members or tutors. Administrative access was not required.

2.Affected systems

All version lines maintained at the time of the report were affected, including their respective latest releases. The fix only appeared with the release round of 12 August 2026.

Beyond the version, what matters for your own assessment is whether the SOAP interface is enabled and reachable in the installation at all. Where it is switched off or restricted to known peer systems, the path described was not usable. This is a property of the configuration and no substitute for the update.

3.Technical analysis

Prerequisites. A logged-in account with the right to create a file in a single, arbitrary container, and a reachable SOAP interface. No administrative rights, no user interaction on the other side.

The finding does not lie in a faulty check but in a missing precondition. The file import is built for a flow in which an archive has previously been extracted into a temporary directory. This directory is passed to the import as its base, and all path specifications in the XML are resolved relative to it. As long as that happens, the mechanism is sound.

The chain

1. The entry point checks only the rights, not the content The SOAP method for creating a file checks the session and the right to create a file in the specified target container. The XML description passed in is itself not subject to any restriction.
2. The base directory remains unset The parser for the file description has a base directory for path specifications, which is empty by default. On the SOAP path it is never set – unlike the import paths for which the mechanism is intended.
3. Relative becomes absolute The target path is built by concatenating base directory, separator and specification. If the base is empty, the result begins with the separator – and thus at the root of the file system. The existing sanitisation of the specification defuses backward steps in the path, but does nothing to change this.
4. The content becomes a regular object The application opens the path and copies the bytes into a newly created file object in the target container – with all the properties of a regularly uploaded file, including the ability to retrieve it again.

4.Impact

Anything the web server user has access to was readable. This includes the application’s own configuration files – and with them, among other things, the path to the file storage, the database credentials and the stored hash of the setup password. Equally affected are uploaded contents of other courses to which the caller would have no access through the user interface, as well as operating system files, insofar as they are readable by the web server.

Notable is the chaining with the application’s permissions: whoever can read the configuration knows the storage location of all uploaded files. This turns read access to individual paths into access to the instance’s entire document holdings – without any right in the application ever having been necessary.

The operation does leave traces, however: every file read out is created as a regular object in the target container and is visible there unless it is removed again. For after-the-fact analysis, this is the most important point – see section 5.

Why there is no CVSS rating of my own here

For the other findings in this series, I gave my own score with a complete vector, because it can be recalculated. Here I deliberately leave it open. The impact depends almost entirely on what the web server user is allowed to read in the particular installation – which ranges from “the application’s configuration” to “practically everything on the system”, depending on the assignment of rights and the operating environment. A single number would obscure this range rather than represent it.

For prioritisation, the sentence below matters more than a score anyway: an ordinary account suffices, and what comes out in the end is decided by your server configuration – not by the application.

Impact in one sentence: Read access to arbitrary files reachable by the web server – including the application configuration and all uploaded content – for any account allowed to create a file anywhere.

5.Countermeasures / workarounds

Update

The decisive and only complete measure is updating to ILIAS 9.22, 10.10 or 11.3. These versions were made available on 12 August 2026 and, besides this fix, contain further security fixes.

Bridging measures if you cannot update immediately

• Disable or restrict the SOAP interface. Many installations do not use it at all. Where it is needed, access can be restricted at the upstream web server to the addresses of the known peer systems. This is the most effective immediate measure.
• Review file permissions on the server. The web server user should be able to read the application’s configuration files – but as little beyond that as possible. This hardening is effective independently of this finding.
• Renew credentials. If the configuration may have been read, the secrets stored there are to be treated as compromised – database access and setup password first.

Checking for past exploitation

Unlike many read accesses, something is left behind here, which makes checking after the fact unusually promising:

• File objects with conspicuous content. Every file read out in this way was created as a regular object in a container. Configuration files or system files that turn up as course material are a clear finding.
• Requests to the SOAP interface in the web server logs – in particular from addresses that do not belong to the known connected systems.
• File objects created and deleted again in quick succession, insofar as this can be reconstructed from log data or the Trash.

If there is reasonable suspicion, the credentials stored in the configuration should be renewed and the sessions invalidated.

6.Disclosure timeline

1. 2026-07-01 Identification and report to the vendor Mantis 0048009
2. 2026-08-12 Patch by the vendor ILIAS 9.22, 10.10 and 11.3
3. 2026-09-01 Publication of this advisory

7.References

• CVE CVE-2026-82877 – published on 2026-08-31, CWE-22.
• Vendor ILIAS open source e-Learning e.V. – report recorded as Mantis 0048009.
• Related SIT-2026-001 and SIT-2026-002 – further findings from the same investigation.
• Policy Responsible disclosure policy of schweigertIT.
• Research Research overview with the running CVE list.