| Package | Affected versions | Patched versions |
|---|---|---|
| egroupware/egroupware | ≥ 26.0.20251208, < 26.4.20260413< 23.1.20260601 | 26.4.2026041323.1.20260601 |
An authenticated administrator can achieve OS-level Remote Code Execution (RCE) by uploading a malicious eTemplate XML file (.xet) to the VFS /etemplates mount.
The Widget::expand_name() method passes template widget attribute values directly into a PHP eval() call with only double-quote escaping applied - backtick characters are not escaped.
In PHP, backticks inside a double-quoted eval() string execute shell commands. This allows an admin-level user to escalate from web
application access to arbitrary OS command execution on the server.
The vulnerability is located in api/src/Etemplate/Widget.php, Widget::expand_name(): (lines 703–728)
The method is designed to expand PHP variables (e.g., $row, $col,$cont[id]) in widget attribute values for auto-repeat grids. The eval() is triggered whenever $name contains a $ character (line 706). The only sanitization applied before the eval is:
str_replace('"', '\\"', $name)
This escapes double quotes only. Backtick characters are not escaped. In PHP, backticks inside a double-quoted string in eval() are treated as shell execution operators — equivalent to shell_exec(). A widget id of $row\id`` produces:
eval('$name = "$row`id`";'); // executes shell command: id
expand_name() is called from:
form_name()expand_widget()set_attrs()Template::run()The /etemplates VFS path is created exclusively for admin users — it is chgrp'd to Admins and chmod'd to 075 (Admins group has full rwx): class.filemanager_admin.inc.php:95-106
Custom templates in /etemplates take precedence over built-in filesystem templates, meaning a malicious template can silently override any existing application template.
Mitigating factor: The official Docker deployment sets disable_functions = exec,passthru,shell_exec,system,proc_open,popen in php.ini, which also blocks PHP backtick execution (backticks internally call shell_exec). Non-Docker or non-hardened deployments without this setting are fully vulnerable. Dockerfile:47
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freephp.iniThe current master branch in api/setup/setup.inc.php, confirming the vulnerability is present in the latest code as of today. setup.inc.php:14-17
Log in as admin, navigate to Admin → Filemanager → VFS Mounts, and click "Install custom templates". This executes the code in filemanager_admin.inc.php that mounts /etemplates with Admins-group write access.
Create a file named index.xet with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<overlay>
<template id="admin.index">
<grid>
<columns><column/></columns>
<rows>
<row>
<textbox id="$row`touch /tmp/pwned_egw 2>/dev/null`"/>
</row>
</rows>
</grid>
</template>
</overlay>
Upload this file to /etemplates/admin/templates/default/index.xet via the VFS filemanager.
Navigate to the EGroupware admin panel:
https://<target>/egroupware/index.php?menuaction=admin.admin_ui.index
When the template is loaded and beforeSendToClient() runs, form_name() calls expand_name() with $name = '$row\touch /tmp/pwned_egw 2>/dev/null'and$row = 0. The eval becomes:
eval('$name = "$row`touch /tmp/pwned_egw 2>/dev/null`";');
PHP executes the backtick expression as a shell command.
Check that /tmp/pwned_egw was created on the server. For a more impactful demonstration, replace touch /tmp/pwned_egw with id > /tmp/pwned_egw to capture the web server's OS user identity.
Authenticated Remote Code Execution (RCE) via eval() with unsanitized shell metacharacters.
Who is impacted: Any EGroupware installation where:
The vulnerability allows escalation from EGroupware admin-level web access to arbitrary OS command execution as the web server user (typically www-data). From there, an attacker can read configuration files (including database credentials), pivot to other services, or establish persistence. This is not exploitable by regular (non-admin) users. The official Docker deployment is not affected due to disable_functions, but bare-metal, VM, or custom container deployments without this hardening are fully vulnerable.