CVE-2026-12116: Xerte Online Toolkits antivirus path RCE
TL;DR - Critical RCE in Xerte Online Toolkits via abuse of the antivirus binary path setting. - Xerte 3.14 and 3.15 are implicated; a fix exists, but the exact fixed release was not verified from retrieved source text. - Treat internet-exposed Xerte instances as urgent patch-and-review targets.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-12116 |
| CVSS | 9.8 (Critical) |
| Attack vector | Network, based on NVD severity and description of remote upload/execution flow |
| Privileges required | Not conclusively verified from retrieved source text |
| Patch available | Yes, fix references exist via vendor advisory and public commit |
CVE-2026-12116 is a critical remote code execution issue affecting Xerte Online Tools, also referred to by the project repository name Xerte Online Toolkits. The NVD description states that an attacker can abuse the antivirus binary path in tool server settings, change it to a PHP interpreter, then upload PHP data that is executed on the server.
The most important operational detail is that this is not a generic file upload bug. It is an execution-path manipulation issue: a configuration value intended to point to an antivirus binary can allegedly be redirected to a PHP interpreter. That makes this especially important for defenders because even environments with normal upload controls may still be exposed if this server-side setting is reachable and improperly validated.
What Is This Vulnerability?
At a technical level, the bug appears to stem from unsafe handling of a server-side configuration parameter: the antivirus binary path used by Xerte when processing uploaded content or related file handling operations. According to the NVD description, an attacker can change that path to point to a PHP interpreter rather than a legitimate antivirus executable. Once that substitution is in place, attacker-supplied PHP content can be uploaded and then executed.
That root cause maps most closely to improper validation of executable path configuration combined with dangerous invocation of uploaded content. In other words, the application trusts a configurable path too much and later uses it in a way that can execute arbitrary data. The impact is full remote code execution in the context of the web application or service account, which can lead to web shell deployment, data access, lateral movement, or full host takeover depending on the server’s permissions.
Technical Notes
The exact implementation details were not fully available from retrieved advisory text during this session, so defenders should avoid assuming the issue is limited to one UI workflow. If the antivirus path is stored in application configuration, database settings, or administrative preferences, review all places where that value can be changed and all code paths that invoke it.
A simplified conceptual abuse chain looks like this:
1. Attacker gains access to modify tool server settings
2. Antivirus binary path is changed from AV executable to php/php-cgi
3. Attacker uploads PHP-formatted payload as data handled by that path
4. Application invokes configured "scanner" path against uploaded content
5. PHP interpreter executes attacker-controlled content
Who Is Affected?
Based on the available evidence, the affected product is The Xerte Project’s Xerte Online Toolkits. The NVD description uses the name “Xerte Online Tools,” while the linked repository and project naming indicate “Xerte Online Toolkits.” For practical asset inventory and patching work, administrators should search for Xerte deployments under both names.
The version information is only partially verified from retrieved materials. What is supported by the vendor advisory title is that Xerte 3.14 and 3.15 are directly implicated in the security update context. However, the exact full affected range, including whether all builds within 3.14 and 3.15 are affected or whether earlier releases are also vulnerable, was not conclusively confirmed from source text retrieved in this session.
| Product | Affected versions | Fixed version |
|---|---|---|
| Xerte Online Toolkits | At minimum, versions 3.14 and 3.15 are implicated by the vendor security update title | Not conclusively verified from retrieved source text |
Because the precise fixed version number could not be extracted from the sources available in this session, defenders should assume that any Xerte 3.14 or 3.15 deployment may require immediate vendor guidance review and upgrade action. If you run an older unsupported release, do not assume safety simply because it was not named in the partial data. Validate against the upstream advisory and commit history before treating any version as unaffected.
CVSS Score Breakdown
The published CVSS base score is 9.8 Critical. That score is consistent with a remotely reachable RCE that can be triggered without meaningful user interaction and that results in high impact to confidentiality, integrity, and availability. Even without the exact vector string retrieved from the NVD tool response, a 9.8 score strongly suggests a worst-case internet-facing exploitation scenario.
What is not verified here is the full official vector string and each submetric value. The retrieved NVD response included the score and severity, but not the vector. That means defenders should avoid repeating an exact vector string unless they obtain it directly from a primary source. Still, from an operational risk perspective, the difference is minor: a web application flaw enabling attacker-controlled code execution through configuration abuse should be handled as an emergency change window event.
The subcomponents that most likely drive the score are the network attack path and full system impact after successful exploitation. The uncertain component is Privileges Required because the available description does not definitively say whether an attacker must already have administrative access to modify the relevant server setting. If that setting is admin-only, real-world exploitability may depend on prior compromise or credential abuse. If it is more broadly exposed, the risk is even higher.
| CVSS element | Assessment |
|---|---|
| Base score | 9.8 |
| Severity | Critical |
| Attack complexity | Not verified, but likely low if the setting is exposed and upload flow is straightforward |
| User interaction | Not verified; none is suggested by the description |
| Privileges required | Unknown from retrieved source text |
| Impact | Consistent with full CIA impact due to remote code execution |
Exploitation Status
As of the research context provided, CISA KEV does not list CVE-2026-12116. That means there is no CISA-confirmed evidence from this check that the vulnerability is being exploited in the wild. This should not be interpreted as low risk. KEV absence is not proof of safety, especially for newly published critical RCEs.
A public fix commit and a public GitHub issue exist, which means technical details may become easier for attackers to operationalize. However, a standalone working public proof of concept was not verified from the sources retrieved for this article. Likewise, active exploitation in the wild is not verified from the available data.
State the status this way in internal reporting:
- Public PoC: Not verified
- Confirmed in-the-wild exploitation: Not verified
- CISA KEV listing: No
That combination should still trigger fast remediation. Newly disclosed critical web application RCEs often move from advisory to weaponization quickly once patch diffs and issue discussions are public.
Technical Notes
Because a public commit is referenced, defenders should assume that exploit development is possible even if no packaged PoC has been verified. Patch diff analysis is often enough for adversaries to identify the vulnerable code path.
defender assumption model:
- No confirmed exploitation != no attacker interest
- Public patch commit lowers reverse-engineering effort
- Internet-exposed Xerte servers should be prioritized for containment, patching, and review
How to Detect It
Detection should focus on three areas: changes to Xerte server settings, suspicious file upload behavior, and downstream command execution indicators involving PHP interpreters where antivirus tooling should normally appear. Because the precise internal log locations and field names were not verified from the retrieved advisory text, defenders should start with host, web server, and application-adjacent telemetry.
If you have centralized logging from Apache, Nginx, PHP-FPM, auditd, EDR, or process creation monitoring, look for unusual parent-child relationships where the web server or PHP worker launches php, php-cgi, or similar binaries in connection with upload activity. Also review administrative actions around configuration changes in the Xerte application, especially any change to an antivirus or scanning path.
Technical Notes
Example log and detection ideas:
Suspicious process creation pattern
Parent process: apache2, httpd, nginx, php-fpm
Child process: php, php-cgi, /usr/bin/php
Context: follows file upload or admin settings change
Linux auditd search example
ausearch -x php -ts recent
ausearch -x php-cgi -ts recent
ausearch -p $(pgrep -f 'apache2|httpd|php-fpm')
EDR or SIEM query concept
process.parent.name IN ("apache2","httpd","nginx","php-fpm")
AND process.name IN ("php","php-cgi")
Web access log hunting
grep -Ei 'upload|settings|server.*setting|tool.*server' /var/log/apache2/access.log
grep -Ei 'upload|settings|server.*setting|tool.*server' /var/log/nginx/access.log
YARA-like content triage for suspicious uploads
Look for uploaded content containing:
<?php
system(
shell_exec(
passthru(
eval(
If you do not have application-level logs showing changes to the antivirus binary path, perform a current-state review of the configuration immediately. Compare the configured path against a known-good antivirus executable location. Any value pointing to php, php-cgi, or a writable path should be treated as a likely indicator of compromise or at minimum a severe misconfiguration.
Mitigation and Patching
The primary mitigation is to apply the vendor-provided security update associated with Xerte 3.14 and 3.15. A fix is clearly indicated by the public commit and the vendor advisory. However, the exact fixed version number was not conclusively verified from retrieved source text in this session. Because of that, the safest instruction is to upgrade to the latest vendor-recommended release that includes the security update for 3.14/3.15 after validating against upstream release notes.
If you cannot patch immediately, reduce exposure around the vulnerable execution chain. Restrict access to any administrative interface capable of modifying tool server settings. Validate the current antivirus binary path and lock it down through file permissions, configuration management, and monitoring. If possible, disable or tightly constrain upload workflows until patching is complete. Also consider restricting outbound and local execution privileges for the web service account to limit post-exploitation options.
Technical Notes
Generic Linux validation and hardening steps:
Check for suspicious PHP interpreter path usage
grep -RinE 'php|php-cgi' /var/www /etc 2>/dev/null
Review likely Xerte configuration areas
find /var/www -type f | grep -Ei 'config|settings|tool'
Restrict web service account shell execution where feasible
ps aux | grep -E 'apache|www-data|nginx|php-fpm'
Upgrade approach Because package names and installation methods vary by Xerte deployment, use the project’s official documented upgrade path rather than a guessed package command. If your deployment is Git-based, a controlled update may resemble:
cd /path/to/xerteonlinetoolkits
git fetch --all --tags
git log --oneline --grep='1543\|8ef20628f80bd88bd1fe3e5844a9116a910086b7'
Then follow the vendor upgrade instructions to move to the release containing the security update. If you manage Xerte through configuration management, pin the fixed release after confirming it from the project advisory.
Workaround guidance if patching is delayed
1. Limit admin access to trusted IPs only
2. Disable or monitor uploads
3. Validate antivirus binary path is a legitimate AV executable
4. Alert on any change to that setting
5. Hunt for web shells and unexpected PHP execution
In the absence of the exact fixed version number from retrievable source text, do not defer action waiting for perfect metadata. Patch to the latest safe upstream release verified by the Xerte Project and document that the exact fixed build must be confirmed directly from the vendor advisory.
References
The primary source for the vulnerability description is the NVD record for CVE-2026-12116, which states that Xerte Online Tools allows RCE through the antivirus binary path in tool server settings. That wording is the foundation for the technical explanation in this article and is the most authoritative retrieved description available here.
Additional references show that a fix and project-level discussion exist. These are important both for patch validation and for understanding how quickly exploit development could follow disclosure. Because the vendor advisory content itself was not fully retrievable in the research context, administrators should consult it directly before finalizing patch version decisions.
- NVD record for CVE-2026-12116
- Xerte Project repository:
thexerteproject/xerteonlinetoolkits - Fix commit:
8ef20628f80bd88bd1fe3e5844a9116a910086b7 - GitHub issue:
#1543 - Vendor advisory: Xerte 3.14 and 3.15 important security update
- CISA KEV catalog status check: not listed as of 2026-07-09
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
For further reading on incident response, check out our Incident Response Checklist for Small IT Teams and learn how to Prioritize Critical Vulnerabilities.