Web-application RCE to root and data exfiltration

01 Executive summary

In May 2026 the UPNIX team investigated the compromise of a client's internet-facing web-application server. An attacker exploited an unvalidated file-upload endpoint to achieve remote code execution, then reached root in a single step because the application's service account held passwordless administrative rights. Across two sessions the attacker exfiltrated the application's secrets, a cloud service-account key, operating-system password hashes and a customer personal-data export. No on-host persistence was planted, but the leaked material was itself a lasting exposure. The UPNIX team confirmed the vulnerability was patched and set out the full remediation: privilege separation, secret rotation and host hardening.

02 Environment

A single internet-facing web-application server (a PHP/Laravel application) running a client's SaaS product, with associated development and database hosts.

03 Vulnerability chain

• The application's chunked-upload endpoint trusted a client-supplied header for the file extension, with no server-side validation, and stored uploads under a publicly reachable path — allowing a PHP file to be uploaded and then executed (remote code execution).
• The application's process pool ran as a developer account rather than a dedicated, unprivileged web user.
• That developer account held passwordless administrative (sudo) rights, so a single command escalated the web-level foothold to full root.

04 Timeline (UTC)

05 Exfiltrated material

• The application's full environment file — database credentials, the application encryption key, and numerous third-party API keys.
• A cloud service-account key, with its private key in plaintext.
• Operating-system password hashes (offline-crackable).
• A customer personal-data export of roughly 900 transaction records — names, email and postal addresses, IP addresses and phone numbers (GDPR / PCI scope).

Even though no on-box implant was left behind, these leaks are persistent attack vectors in their own right: the cloud key grants ongoing API access until revoked; the application encryption key allows forging sessions and decrypting data at rest; the customer data can fuel targeted phishing; and the password hashes will eventually crack offline. Remediation therefore centred on rotation, not clean-up.

06 Remediation

Validate file type server-side on the upload endpoint and store uploads outside the web root (the code-level fix was committed during the incident); remove the application account's passwordless sudo and run the process pool as a dedicated unprivileged user; rotate every leaked secret and revoke the cloud service-account key; re-key the application encryption key; patch the host kernel; add a host firewall; and stop exposing data and management services (in-memory store, websocket and monitoring ports) on public interfaces.

07 Lessons learned

• Never trust a client-supplied filename or extension. Validate on the server and store uploads outside the web root.
• Enforce privilege separation. A web application must never run as an account with passwordless administrative rights.
• Assume leaked secrets are compromised forever. Rotate and revoke everything, immediately — a code-level patch is the start of remediation, not the end.
• Put a host firewall in front of every internet-facing server and keep data and management services off public interfaces.
• Handle a personal-data breach as a breach. Scope the exposure, rotate affected credentials, and follow the applicable notification duties.