CVE-2026-80428: ILIAS LMS Unauthenticated PHP Object Injection via Shibboleth — Detection and Remediation Guide

A public proof-of-concept exploit has been released for CVE-2026-80428, a critical unauthenticated PHP Object Injection vulnerability in the ILIAS Learning Management System, one of the most widely deployed open-source LMS platforms in European universities, government training programs, and corporate learning environments. The flaw lives in ILIAS's Shibboleth authentication handler and allows a remote, unauthenticated attacker to inject a serialized PHP object, which — with a suitable gadget chain present in ILIAS's bundled dependencies — escalates to full remote code execution on the underlying web server.

Affected versions:

• ILIAS < 9.22
• ILIAS 10.0 through 10.9 (fixed in 10.10)
• ILIAS 11.0 through 11.2 (fixed in 11.3)

This is the worst kind of vulnerability profile for defenders: no authentication required, no user interaction, a public PoC on Exploit-DB, and a target (an LMS) that is internet-facing by design and historically under-monitored. LMS servers frequently hold PII for tens of thousands of students and staff, are federated into institutional identity infrastructure (which is exactly why Shibboleth is enabled), and are often administered by academic IT teams rather than central security operations. If you run ILIAS with Shibboleth SSO enabled — or you're unsure whether Shibboleth is enabled — treat this as an emergency patch event.

Technical Analysis

The Vulnerability

CVE-2026-80428 is a classic PHP Object Injection (CWE-502: Deserialization of Untrusted Data). The vulnerable code path is in the Shibboleth authentication module (Services/AuthShibboleth), which processes attributes derived from incoming HTTP request data during the SSO login handshake. The root cause: user-controllable input reaches PHP's unserialize() without adequate type validation.

Why this matters so much in the PHP ecosystem:

1. Serialized objects are attacker-controlled type confusion. When unserialize() processes attacker input of the form O:<len>:"<ClassName>":..., PHP instantiates an arbitrary class and populates its properties with attacker-supplied values.
2. Magic methods become the trigger. During instantiation and destruction, PHP invokes __wakeup(), __destruct(), __toString(), and similar magic methods. An attacker chains together existing classes (a POP/gadget chain) whose magic methods perform dangerous operations — file writes, eval-equivalents, or command execution.
3. ILIAS ships a rich dependency tree. Like most modern PHP applications, ILIAS bundles dozens of Composer dependencies (Monolog, Symfony components, Guzzle, laminas/zend components, etc.). Historically, gadget chains in Monolog and Symfony have been well documented, which is precisely what makes object injection in a large PHP application reliably exploitable for RCE rather than merely a crash primitive.

Attack Chain (Defender's View)

1. Attacker identifies an internet-facing ILIAS instance. Version fingerprinting is trivial via readme.txt, CSS/JS asset paths, or the login page markup.
2. Attacker sends a crafted HTTP request to the Shibboleth login endpoint — typically under /shib_login.php or a path handled by the Shibboleth authentication service — carrying the serialized payload in a parameter or header processed by the module.
3. unserialize() instantiates the attacker's object; the gadget chain fires on __destruct() at the end of the request lifecycle.
4. Code executes as the web server user (www-data, apache, or nginx depending on platform), giving the attacker a foothold for web shell deployment, credential harvesting (including the ILIAS client.ini.php database credentials), and lateral movement into internal networks the LMS can reach.

Exploitation Status

• Public PoC: Yes — exploit code is published on Exploit-DB (exploit ID 52682). Public PoCs for pre-auth RCE in widely deployed PHP applications are historically weaponized within days, including by automated scanning botnets and initial access brokers.
• Active exploitation: With a functional public exploit against an unauthenticated endpoint, assume opportunistic scanning is underway. Universities and public-sector LMS portals are high-volume targets for cryptominers, web shells, and access resale.
• CISA KEV: Check the CISA Known Exploited Vulnerabilities catalog; if added, federal civilian agencies operate under Binding Operational Directive 22-01 remediation deadlines.

Blast Radius

A compromised ILIAS server is not just a defaced website. Expect:

• Credential exposure: database credentials in the ILIAS configuration, and — critically — session data for authenticated users, including instructors and administrators.
• PII at scale: student records, grades, contact data — an immediate GDPR/FERPA reporting event depending on jurisdiction.
• SSO trust abuse: because Shibboleth federates the LMS into institutional identity infrastructure, a compromised service provider can be leveraged for phishing with legitimate-looking login flows or token manipulation.
• Persistence: web shells dropped into the ILIAS webroot survive application upgrades unless specifically hunted.

Detection & Response

The observable indicators for this attack fall into three buckets: (1) serialized PHP object signatures in web requests to Shibboleth endpoints, (2) post-exploitation behavior — the PHP-FPM/Apache worker spawning shells or writing unexpected files, and (3) artifacts — new PHP files in writable directories, modified ILIAS core files.

The request-side detection is high-value but requires full request-body or detailed access-log capture (ModSecurity audit logs, a WAF, or extended IIS/nginx logging). The process-side detection is your safety net: the web server process should essentially never spawn a shell or write executable PHP files at runtime. These rules are written for Linux-hosted ILIAS, which is the dominant deployment model.

---
title: PHP Serialized Object in HTTP Request to ILIAS Shibboleth Endpoint
id: 3f8c2e71-9a44-4b1d-b6f5-7d2e8a1c9034
status: experimental
description: Detects HTTP requests containing PHP serialized object signatures targeting ILIAS Shibboleth authentication endpoints, consistent with CVE-2026-80428 exploitation attempts. Requires web access logs with request detail, ModSecurity audit logs, or WAF logging ingested into the SIEM.
references:
  - https://www.exploit-db.com/exploits/52682
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
  product: linux
detection:
  selection_endpoint:
    cs-uri|contains:
      - 'shib_login'
      - 'shibboleth'
      - 'AuthShibboleth'
  selection_payload:
    cs-body|contains:
      - 'O:%'
      - 'O:+'
      - 'O:8:'
      - 'O:4:'
      - 'unserialize'
  condition: selection_endpoint and selection_payload
falsepositives:
  - Extremely rare; legitimate Shibboleth login flows do not transmit serialized PHP objects in request bodies
level: critical
---
title: Web Server Worker Process Spawning Shell or System Utilities
id: 6b1d9e42-2c87-4f3a-a9d1-4e5f7b2c8015
status: experimental
description: Detects PHP-FPM, Apache, or nginx worker processes spawning interactive shells, downloaders, or reconnaissance utilities — a hallmark of post-exploitation following PHP object injection / RCE such as CVE-2026-80428.
references:
  - https://www.exploit-db.com/exploits/52682
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/php-fpm'
      - '/php-fpm8.1'
      - '/php-fpm8.2'
      - '/php-fpm8.3'
      - '/apache2'
      - '/httpd'
      - '/nginx'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/netcat'
      - '/python'
      - '/python3'
      - '/perl'
      - '/whoami'
      - '/id'
      - '/uname'
  condition: selection_parent and selection_child
falsepositives:
  - Rare plugin or cron-driven maintenance scripts invoked through the application layer; validate against the specific ILIAS installation
level: high
---
title: Web Server Writing PHP Files in Upload or Temp Directories
id: 9c4e7a18-5d32-4b6f-b8a2-1f3d6e9c2074
status: experimental
description: Detects the web server or PHP-FPM process creating PHP files in upload, temp, or cache directories — consistent with web shell deployment after exploitation of an unauthenticated RCE such as CVE-2026-80428 in ILIAS.
references:
  - https://www.exploit-db.com/exploits/52682
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_process:
    Image|endswith:
      - '/php-fpm'
      - '/php-fpm8.1'
      - '/php-fpm8.2'
      - '/php-fpm8.3'
      - '/apache2'
      - '/httpd'
  selection_path:
    TargetFilename|contains:
      - '/data/'
      - '/upload/'
      - '/tmp/'
      - '/var/tmp/'
      - '/cache/'
  selection_ext:
    TargetFilename|endswith:
      - '.php'
      - '.phtml'
      - '.phar'
      - '.php7'
      - '.php8'
  condition: selection_process and selection_path and selection_ext
falsepositives:
  - ILIAS writes cached/compiled templates under its data directory during normal operation; baseline known-good paths per installation and tune accordingly
level: high

KQL — Microsoft Sentinel / Defender

ILIAS is Linux-hosted, so hunt via Syslog/CEF ingestion from the web tier, ModSecurity logs forwarded to Sentinel, or Defender for Endpoint on Linux (DeviceProcessEvents covers the post-exploitation behavior).

// Hunt 1: Serialized PHP object signatures in requests to Shibboleth endpoints
// Assumes web/proxy logs ingested via CommonSecurityLog or a custom web log table
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where RequestURL has_any ("shib_login", "shibboleth", "AuthShibboleth")
| where AdditionalExtensions has_any ("O:%22", "O:+", "unserialize", "O:8:")
    or RequestURL has_any ("O:%22", "O:+", "unserialize")
| project TimeGenerated, SourceIP, RequestURL, RequestMethod, AdditionalExtensions, DeviceName
| order by TimeGenerated desc;

// Hunt 2: Web/PHP worker spawning shells or system tools (Defender for Endpoint on Linux)
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName has_any ("php-fpm", "apache2", "httpd", "nginx")
| where FileName in~ ("sh", "bash", "dash", "curl", "wget", "nc", "ncat", "python3", "perl", "whoami", "id", "uname")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc;

// Hunt 3: Outbound connections from PHP-FPM/Apache workers (C2 or payload retrieval)
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName has_any ("php-fpm", "apache2", "httpd")
| where RemoteUrl !has_any ("ilias.de", "your-cdn.example.com")   // tune to known-good egress
| summarize Connections = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by DeviceName, InitiatingProcessFileName, RemoteIP, RemoteUrl, RemotePort
| order by Connections desc;

Velociraptor VQL

Use this artifact across your Linux web estate to surface post-exploitation process behavior and web shells planted in ILIAS writable directories. Note the ilias/ path assumption — adjust the glob to your document root and external data directory (the ILIAS data dir commonly lives outside the webroot by design, which is a hardening win you should verify).

-- Hunt 1: Web/PHP worker processes with shell or tool children (live state)
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'php-fpm|apache2|httpd|nginx'
   OR Exe =~ '/(php-fpm|apache2|httpd|nginx)$'

-- Hunt 2: Recently created PHP files in writable/upload/temp paths (potential web shells)
SELECT FullPath, Size, Mtime, Ctime, Mode
FROM glob(globs=['/var/www/**/data/**/*.php',
                 '/var/www/**/upload/**/*.php',
                 '/srv/ilias*/**/*.php',
                 '/tmp/*.php',
                 '/var/tmp/*.php'])
WHERE Mtime > (now() - 1209600)   -- created/modified in last 14 days
  AND FullPath !~ 'vendor|libs|src|Services|Modules|setup'
ORDER BY Mtime DESC

-- Hunt 3: Outbound connections held by web server processes (beaconing/payload fetch)
SELECT Pid, Name, Status, RemoteAddr, LocalAddr
FROM netstat()
WHERE Name =~ 'php-fpm|apache2|httpd|nginx'
  AND Status =~ 'ESTABLISHED'

Remediation & Verification Script

Run this on each ILIAS host to establish the deployed version, flag the vulnerable Shibboleth configuration, check for indicators of compromise, and confirm you're on a patched release. The version check is informational — the actual fix is upgrading through the ILIAS release process (code + database update via the setup wizard).

#!/bin/bash
# CVE-2026-80428 — ILIAS verification and triage script
# Run as root or with sudo on the ILIAS web host.

echo "=== CVE-2026-80428 ILIAS Triage ==="
echo

# 1. Locate ILIAS installations and read the deployed version
# ILIAS stores its version in include/inc.ilias_version.php
for f in $(find /var/www /srv /opt -maxdepth 4 -name 'inc.ilias_version.php' 2>/dev/null); do
    echo "[+] Found ILIAS at: $(dirname $(dirname $f))"
    grep -E 'ILIAS_VERSION|ILIAS_VERSION_NUMERIC' "$f"
    echo
    echo "    AFFECTED if: < 9.22, 10.0-10.9 (fix: 10.10), 11.0-11.2 (fix: 11.3)"
    echo
    # 2. Check whether Shibboleth authentication is configured
    CONF=$(find "$(dirname $(dirname $f))" -maxdepth 3 -name 'client.ini.php' 2>/dev/null | head -1)
    if [ -n "$CONF" ]; then
        echo "[+] Checking Shibboleth config in $CONF"
        grep -iE 'shib|auth_mode' "$CONF" || echo "    (no shibboleth references found)"
    fi
done

echo
echo "=== IoC Sweep (last 14 days) ==="

# 3. Look for serialized-object probes in web access logs
echo "[+] Scanning access logs for Shibboleth requests carrying serialized payloads:"
find /var/log -name 'access*.log*' -o -name '*access*log*' 2>/dev/null | while read -r log; do
    zgrep -aEi 'shib_login|shibboleth' "$log" 2>/dev/null | \
      grep -aEi 'O:[0-9]+:|O%3A|O%2B|unserialize' | head -20
done

# 4. Hunt recently created PHP files in writable locations (web shells)
echo
echo "[+] PHP files created/modified in last 14 days in writable/temp paths:"
find /var/www /srv /tmp /var/tmp -name '*.php' -mtime -14 2>/dev/null | \
  grep -vE 'vendor|/libs/|/src/|/Services/|/Modules/|/setup/' | head -50

# 5. Suspicious child processes of web workers in auth logs / audit logs
echo
echo "[+] Checking for shell execution by web user in audit logs:"
ausearch -i -ts recent 2>/dev/null | grep -E 'www-data|apache|nginx' | \
  grep -E 'bash|/bin/sh|curl|wget|nc |python|perl' | head -20

echo
echo "=== Next Steps ==="
echo "1. If version is vulnerable: upgrade to 9.22 / 10.10 / 11.3 immediately."
echo "2. If IoCs are found: isolate the host, preserve memory + disk for forensics,"
echo "   rotate DB credentials, ILIAS admin passwords, and any SSO-related secrets."
echo "3. Confirm the ILIAS data directory is OUTSIDE the webroot and not web-accessible."

Remediation

Patch immediately. Fixed versions are ILIAS 9.22, 10.10, and 11.3. Any instance on an earlier build with Shibboleth authentication enabled must be treated as exposed to unauthenticated RCE with a public exploit available.

1. Upgrade to a fixed release. Apply the vendor update for your branch:

   • 9.x branch → 9.22
   • 10.x branch → 10.10
   • 11.x branch → 11.3

   Follow the official ILIAS update procedure: back up code, data directory, and database; deploy the new code; run the database update through the ILIAS setup. References: the ILIAS release/security announcements at ilias.de and the project's GitHub repository (github.com/ILIAS-eLearning/ILIAS). Monitor the CISA KEV catalog for inclusion and associated federal remediation deadlines.

2. If you cannot patch today — reduce exposure:

   • Disable Shibboleth authentication in the ILIAS administration panel if the login flow can tolerate it (fall back to local/LDAP/CAS auth temporarily). This removes the vulnerable code path.
   • If Shibboleth cannot be disabled, restrict access to the Shibboleth login endpoint (shib_login.php) at the reverse proxy/WAF to known IdP-related IP ranges and authenticated campus VPN users.
   • Deploy a WAF rule blocking requests containing serialized PHP object signatures (O:<digits>:", URL-encoded variants %4F%3A, O:+) in parameters, headers, and bodies destined for Shibboleth paths. This is a mitigation, not a fix — encoding tricks can evade naive rules.

3. Verify your architecture baseline:

   • The ILIAS data directory must live outside the webroot. If it doesn't, fix that this week — it contains uploaded user files and is a prime web-shell landing zone.
   • Ensure PHP's open_basedir restricts the application to its required paths, and disable dangerous functions (exec, shell_exec, system, passthru, proc_open) via disable_functions for the ILIAS pool where application functionality permits. This blunts gadget chains that land on command execution.
   • Run the web tier under a dedicated, unprivileged user with no sudo rights and no writable access to the ILIAS codebase outside designated cache/upload paths.

4. Hunt before you patch, not after. If the instance was internet-facing and unpatched while the PoC was public, assume potential compromise: sweep logs for serialized-payload probes, check for new PHP files in writable directories, review accounts created in ILIAS, and rotate database credentials and SSO-related secrets if any evidence of execution appears. If you're running 9.x/10.x/11.x and Shibboleth is enabled and you find suspicious request bodies — treat it as an incident, not a patching ticket.

5. Longer-term: LMS platforms sit at the intersection of identity federation and mass PII. They belong in your vulnerability management SLA tier for internet-facing criticals (24–72 hour patch target for pre-auth RCE with public exploit), with WAF coverage, centralized log collection that includes request detail on authentication endpoints, and egress filtering so a compromised worker can't freely pull second-stage payloads.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub