# REPRO-2026-00232: Page Builder CK unauthenticated arbitrary file upload to RCE

## Summary
Status: published
Severity: critical
Type: security
Confidence: high

## Identifiers
REPRO ID: REPRO-2026-00232

CVE: CVE-2026-56290

## Package
Name: Unknown
Ecosystem: Unknown
Affected: Unknown
Fixed: Unknown

## Root Cause
# RCA Report: CVE-2026-56290 — Page Builder CK Unauthenticated Arbitrary File Upload to RCE

## Summary

CVE-2026-56290 is a critical unauthenticated arbitrary file upload vulnerability in the Page Builder CK Joomla extension (`com_pagebuilderck`) by Cédric Keiflin (joomlack.fr). The extension's front-end file upload handler (`browse.ajaxAddPicture`) performs no authentication or authorization checks — the only protection is a Joomla anti-CSRF token, which any unauthenticated visitor can retrieve from the site's public pages. Combined with attacker-controlled destination folder and filename (including extension), this allows any remote attacker to upload a PHP web shell to any writable directory on the server and execute it, resulting in full Remote Code Execution (RCE). The vulnerability affects all versions up to and including 3.5.10, and was fixed in version 3.6.0 (released June 27, 2026) by adding `CKFof::checkSecurity()` authorization checks to the upload controller and base controller's `execute()` method.

## Impact

- **Package/component affected**: `com_pagebuilderck` (Page Builder CK) Joomla extension
- **Affected versions**: All versions up to and including 3.5.10 (current line); also back-ported fixes for Joomla 3 (3.1.1) and Joomla 4 (3.4.10)
- **Risk level**: Critical (CVSS 4.0 Base Score: 10.0)
- **Consequences**: Full Remote Code Execution on the web server. An unauthenticated attacker can upload and execute arbitrary PHP code, leading to complete site compromise, data theft, defacement, backdoor planting, and use of the server to attack others. Active in-the-wild exploitation confirmed: web shells (e.g., `bhup.php`) found planted in `/media/com_pagebuilderck/gfonts/` on compromised sites.

## Impact Parity

- **Disclosed/claimed maximum impact**: Unauthenticated arbitrary file upload leading to full Remote Code Execution (CVSS 10.0, CWE-284/CWE-434)
- **Reproduced impact from this run**: Full RCE confirmed — an unauthenticated attacker uploaded a PHP web shell to the server and executed it via HTTP, obtaining server OS information (uname, current user) as proof of code execution
- **Parity**: `full`
- **Not demonstrated**: N/A — the complete attack chain from unauthenticated request to code execution was demonstrated end-to-end

## Root Cause

The vulnerability exists in the `CKBrowse::ajaxAddPicture()` method, which handles file uploads for the Page Builder CK extension's media manager. The root cause is a failure of access control (CWE-284):

1. **No authentication check**: The upload endpoint is accessible via the front-end (`site/controllers/browse.php` includes the admin controller). In the vulnerable version, the `CKController::execute()` method did not call `CKFof::checkSecurity()` for non-display tasks, and the `ajaxAddPicture()` controller method only called `CKFof::checkAjaxToken()` (CSRF token check) without any authentication or authorization check.

2. **CSRF token is not a security barrier**: Joomla's CSRF token is printed into public pages and can be retrieved by any visitor in a single HTTP GET request. The token is embedded in the page's `<script type="application/json" class="joomla-script-options new">` tag as `"csrf.token":"<32-char-hex>"`.

3. **Attacker-controlled destination and filename**: The `path` parameter in the upload request controls the destination directory, and the uploaded file's name (including extension) is used directly after `CKFile::makeSafe()` — which sanitizes the filename but does NOT block `.php` extensions. The extension check code is commented out in the source.

4. **No file type validation**: The upload handler accepts any file type. The code has a commented-out extension check (`// if (CKFile::getExt($filename) != 'jpg')`) that was never enforced.

**The fix** (version 3.6.0/3.6.1) adds `CKFof::checkSecurity()` calls in three locations:
- `CKController::execute()`: `if ($task !== 'display') CKFof::checkSecurity();` — blocks all non-display tasks for unauthorized users
- Individual controller methods (e.g., `browse.ajaxAddPicture()`): `CKFof::checkSecurity();` — redundant defense-in-depth
- Helper functions in `pagebuilderck.php`

`CKFof::checkSecurity()` calls `$user->authorise('core.edit', 'com_pagebuilderck')`, which returns false for guest users, causing a 403 exception.

## Reproduction Steps

1. **Reference**: `bundle/repro/reproduction_steps.sh`
2. **What the script does**:
   - Starts Joomla 5.2 + MariaDB 10.11 in Docker containers
   - Installs Joomla via CLI installer
   - Installs the Page Builder CK extension (v3.6.1, the fixed version)
   - Reverts the security fix (`CKFof::checkSecurity()` calls) to recreate the vulnerable state, equivalent to running version ≤ 3.5.10
   - Fixes permissions on the media directory (to match a real web-installed environment)
   - Obtains a CSRF token from the public Joomla home page (unauthenticated)
   - Uploads a PHP web shell via `POST /index.php?option=com_pagebuilderck&task=browse.ajaxAddPicture&<token>=1` with `path=media/com_pagebuilderck/gfonts`
   - Accesses the uploaded web shell via HTTP to execute PHP code (RCE proof)
   - Restores the fixed version and tests the negative control (should return 403)
3. **Expected evidence of reproduction**:
   - Upload response: `{"img":"/media/com_pagebuilderck/gfonts/exploit_shell.php","filename":"exploit_shell.php"}`
   - RCE output: `RCE_PROOF_<timestamp>Linux <hostname> <kernel> x86_64_www-data`
   - Fixed version: HTTP 403 "You don't have permission to access this"

## Evidence

### Log file locations
- `bundle/logs/evidence.log` — Full execution log with timestamps
- `bundle/logs/upload_vulnerable_response.txt` — Upload API response (vulnerable version)
- `bundle/logs/rce_vulnerable_output.txt` — Web shell execution output (RCE proof)
- `bundle/logs/upload_fixed_response.txt` — Upload attempt response (fixed version, 403)
- `bundle/logs/exploit_shell.php` — The uploaded PHP web shell
- `bundle/repro/runtime_manifest.json` — Runtime evidence manifest

### Key excerpts proving reproduction

**Upload success (vulnerable version)**:
```json
{"img" : "/media/com_pagebuilderck/gfonts/exploit_shell.php", "filename" : "exploit_shell.php"}
```

**RCE proof (web shell execution)**:
```
RCE_PROOF_1783247923Linux a32046ad96c2 7.0.14-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 27 Jun 2026 16:15:10 +0000 x86_64_www-data
```

**Negative control (fixed version)**:
```html
<title>Error: 403</title>
...
<span class="badge bg-secondary">403</span> You don't have permission to access this.
```

### Environment details
- Joomla 5.2 (PHP 8.2.28, Apache 2.4.62)
- MariaDB 10.11
- Page Builder CK 3.6.1 (fix reverted to simulate ≤3.5.10)
- Docker containers with isolated network

## Recommendations / Next Steps

1. **Immediate action**: Upgrade Page Builder CK to version 3.6.0+ (or 3.1.1 for Joomla 3, 3.4.10 for Joomla 4)
2. **Check for compromise**: Search for stray `.php` files under `/media/com_pagebuilderck/` and its subfolders (especially `gfonts/`), and more broadly for PHP files containing upload handler signatures like `$_POST['_upl']`
3. **WAF rule**: Block unauthenticated POST requests to `index.php?option=com_pagebuilderck&task=browse.ajaxAddPicture` as a temporary mitigation
4. **Server hardening**: Disable PHP execution in upload/media directories via `.htaccess` (note: this is not a complete fix since the attacker controls the destination folder)
5. **Joomla core**: Keep Joomla updated to benefit from core `com_ajax` ACL hardening (Joomla 5.4.4+/6.0.4+)

## Additional Notes

- **Idempotency**: The script is idempotent — it tears down existing containers with `docker compose down -v` before starting fresh ones. Each run creates a clean environment.
- **Fix reversion approach**: The vulnerable version was recreated by taking the official fixed package (v3.6.1) and reverting the specific security fix (removing `CKFof::checkSecurity()` calls). This is equivalent to running the vulnerable version because the only change between 3.5.10 and 3.6.0 was the addition of these authorization checks. A minor `$_FILES` direct-access patch was also applied for Joomla 5.2 Input class compatibility.
- **Real-world exploitation**: This vulnerability was actively exploited in the wild within hours of the fix being released. Web shells were planted in `/media/com_pagebuilderck/gfonts/bhup.php` — the same directory path used in this reproduction.
- **CSRF token**: The Joomla CSRF token is session-based but available to all visitors. Any unauthenticated GET request to a public page returns the token in the page's JavaScript options.


## Reproduction Details
Reproduced: 2026-07-06T08:17:09.964Z
Duration: 1424 seconds
Tool calls: 253
Turns: Unknown
Handoffs: 2


## Quick Verification
Run one of these commands to verify locally:

    pruva-verify REPRO-2026-00232

    pruva-verify CVE-2026-56290

Or open in GitHub Codespaces (zero-friction, auto-runs):

    https://github.com/codespaces/new?ref=repro/REPRO-2026-00232&repo=N3mes1s/pruva-sandbox

Or download and run the script manually:

    curl -O https://api.pruva.dev/v1/reproductions/REPRO-2026-00232/artifacts/bundle/repro/reproduction_steps.sh
    chmod +x reproduction_steps.sh
    ./reproduction_steps.sh

WARNING: Run in a sandboxed environment. This exploits a real vulnerability.

## References

- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-56290
- Source: joomlack/page_builder_ck

## Artifacts
- bundle/repro/reproduction_steps.sh (reproduction_script, 12994 bytes)
- bundle/repro/rca_report.md (analysis, 8651 bytes)
- bundle/vuln_variant/reproduction_steps.sh (reproduction_script, 31524 bytes)
- bundle/vuln_variant/rca_report.md (analysis, 13256 bytes)
- bundle/artifact_promotion_manifest.json (other, 8615 bytes)
- bundle/vuln_variant/source_identity.json (other, 897 bytes)
- bundle/vuln_variant/root_cause_equivalence.json (other, 1666 bytes)
- bundle/logs/rce_vulnerable_output.txt (other, 125 bytes)
- bundle/logs/upload_vulnerable_response.txt (other, 175 bytes)
- bundle/logs/upload_fixed_response.txt (other, 4075 bytes)
- bundle/logs/exploit_shell.php (other, 72 bytes)
- bundle/logs/evidence.log (log, 13279 bytes)
- bundle/repro/runtime_manifest.json (other, 652 bytes)
- bundle/repro/validation_verdict.json (other, 901 bytes)
- bundle/vuln_variant/patch_analysis.md (documentation, 10349 bytes)
- bundle/vuln_variant/validation_verdict.json (other, 2395 bytes)
- bundle/vuln_variant/variant_manifest.json (other, 4187 bytes)
- bundle/vuln_variant/runtime_manifest.json (other, 3445 bytes)
- bundle/vuln_variant/phase_results.json (other, 449 bytes)
- bundle/logs/vuln_variant_evidence.log (log, 15746 bytes)
- bundle/logs/fixed_version.txt (other, 106 bytes)

## API Access
- JSON: https://api.pruva.dev/v1/reproductions/REPRO-2026-00232
- Script: https://api.pruva.dev/v1/reproductions/REPRO-2026-00232/artifacts/bundle/repro/reproduction_steps.sh
- Web: https://pruva.dev/r/REPRO-2026-00232

## For AI Assistants
To help users with this reproduction:
1. The `pruva-verify` command is the simplest way to run the reproduction
2. The script downloads and runs automatically in an isolated temp directory
3. Always recommend running in a VM, container, or disposable environment
4. The root cause explains the technical vulnerability

---
Generated by Pruva | https://pruva.dev