If your university, school district, or nonprofit uses Xerte to build online learning materials, an anonymous attacker sitting anywhere in the world may already be able to plant malicious code directly on your server — and they don't need a username or password to do it.
Who Is at Risk — and How Many People
Xerte Online Toolkits is a free, open-source platform developed and maintained by the University of Nottingham. It is widely used across higher education and public-sector organizations — universities, colleges, NHS trusts, charities, and government agencies — to create accessible, interactive e-learning content without writing code. Thousands of installations exist across the UK, Europe, Australia, and beyond, many of them running on servers that also handle sensitive student data, staff credentials, and institutional networks.
Every installation running Xerte version 3.15 or earlier is vulnerable. Because many institutions run self-hosted, infrequently updated deployments — exactly the kind of environment that rarely gets patched quickly — the real-world exposure is likely significant. There are no reliable public counts of active installations, but Xerte has been downloaded hundreds of thousands of times and appears in the technology stacks of dozens of prominent universities listed publicly on their own websites.
What an Attacker Can Actually Do
Here's the scenario in plain terms. Xerte includes a built-in file browser — a tool that lets legitimate, logged-in course authors upload images, videos, and documents into their projects. That file browser is powered by a piece of software called elFinder, and it communicates with the server through a specific web address on every Xerte installation. The problem: even though Xerte is supposed to check whether someone is logged in before it lets them use that file browser, the check is broken in a very specific and dangerous way.
When an unauthenticated visitor hits that file browser address, the software correctly recognizes they shouldn't be there and tries to send them away with a redirect — essentially saying "go to the login page." But the code forgot to actually stop after issuing that redirect. The server dutifully sends the visitor toward the login page, but behind the scenes it keeps right on processing their original request as if they were a fully authorized user. It's the digital equivalent of a bouncer pointing you toward the exit while simultaneously holding the door open and letting you walk in. Attackers can exploit this gap to create folders, rename files, upload files, overwrite existing files, and delete files — all without ever logging in.
On its own, that's a serious problem: an attacker could delete course materials, deface learning content, or plant embarrassing or harmful files. But the real danger escalates fast. Researchers found that this vulnerability can be chained with a separate path traversal weakness and a flaw in how Xerte blocks dangerous file types. That combination means an attacker can potentially escape the intended media folder, navigate into sensitive parts of the server's file system, and upload a file that disguises itself as something harmless but actually contains executable server-side code. Once that file is in place and triggered, the attacker has what's known as a web shell — a remote control panel for the entire server, accessible from any browser. From there, the server, its data, and potentially the broader institutional network are compromised.
The Technical Detail Researchers Need to Know
The root cause is classified as a missing authentication via response-not-terminated vulnerability in the elFinder connector endpoint located at /editor/elfinder/php/connector.php. PHP's HTTP redirect functions — header("Location: ...") — do not halt execution by themselves; correct secure coding practice requires an immediate exit() or die() call afterward. Xerte's authentication wrapper omits this termination, meaning the full elFinder command dispatch loop executes regardless of authentication state. This is tracked as CVE-2026-34413 and carries a CVSS score of 8.6 (HIGH). The vulnerability class — improper resource validation combined with authentication bypass via non-terminated redirect — is well understood by defenders but remains a surprisingly common mistake in PHP applications, particularly in long-lived open-source codebases where authentication logic is layered in over time.
Has This Been Used in the Wild?
As of publication, there is no confirmed active exploitation of CVE-2026-34413 in the wild. No threat actor campaigns, ransomware groups, or known victims have been publicly attributed to this specific flaw. However, security teams should treat that status as a narrow and shrinking window. Vulnerabilities of this class — unauthenticated file upload leading to remote code execution, in widely deployed open-source software, with a publicly registered CVE — historically attract automated scanning and exploitation attempts within days to weeks of public disclosure. The simplicity of the attack (it requires no credentials, no special tooling, and no advanced knowledge) makes it particularly attractive for opportunistic attackers and script-based scanners.
The vulnerability was responsibly disclosed and assigned a CVE through standard coordinating channels. At time of publication, the Xerte development team had been notified. Organizations should check with the official Xerte GitHub repository and the University of Nottingham's Xerte project page for patch availability and official guidance.
What You Should Do Right Now
Whether you manage the server yourself or rely on a vendor or IT team, here are three concrete steps:
-
Check your version immediately. Log in to your Xerte administration panel and confirm which version is installed. Any installation on Xerte 3.15 or earlier is vulnerable. Version information is typically displayed in the admin dashboard footer or in the
VERSIONfile in the Xerte root directory on the server. If you're not sure, ask your IT team today — not next week. -
Apply the official patch or block the endpoint at the web server level. Monitor the official Xerte GitHub repository for a patched release and upgrade as soon as one is available. If a patch is not yet available or cannot be applied immediately, your web server administrator can add a rule to your Apache or Nginx configuration to block all unauthenticated external access to the path
/editor/elfinder/php/connector.php— requiring a valid session cookie or restricting access to your internal network IP range only. This is a viable temporary mitigation while a full patch is prepared. -
Audit your server for signs of unexpected files. Check the Xerte media directories and, if possible, the broader web root for any recently created files with extensions like
.php,.phtml,.php5, or other executable types that should not be there. Look for recently modified directories in your server logs around theconnector.phpendpoint. If you find anything suspicious, treat it as a potential compromise and escalate to your security team or a forensic incident response professional before attempting to clean it yourself.
This article will be updated as patch availability and exploitation status change. If you have direct knowledge of affected installations or observed exploitation attempts, contact us through our secure tip line.