Unauthenticated Exposure of Active Security Researcher Infrastructure: Remote Code Execution, AI API Key Leakage, and Full Operational Intelligence Disclosure

Executive Summary

During routine passive reconnaissance research, the SDX Shadow Labs research team identified an openly accessible personal security research server - operated, based on its contents, by a professional bug bounty hunter or active security researcher. The server was publicly accessible with no authentication of any kind, running a custom-built, AI-augmented bug bounty operations framework: a self-hosted platform consolidating active vulnerability reports, reconnaissance pipelines, AI-assisted analysis workflows, and operational tooling into a single interface.

The exposure was total. Any unauthenticated actor who navigated to the server's public address gained unrestricted read access to the full operational archive of an active security researcher - submitted and unsubmitted vulnerability findings, live reconnaissance data, AI API keys, and proprietary pipeline configurations. More critically, the platform exposed a fully functional web-based terminal interface directly embedded in the dashboard UI, providing any unauthenticated visitor with interactive Remote Code Execution (RCE) on the underlying host.

The server owner could not be identified. No domain registration, WHOIS record, public profile, or contact information was attributable to the IP address or the platform itself. Without a traceable identity, direct private notification was not possible. This advisory is published as a public notice - with the dashboard screenshot redacted to protect operational data - so that the owner can self-identify their own infrastructure and take corrective action. If you recognize the dashboard in the redacted image attached to this advisory, please secure your server immediately and contact our research team at security@sdxshadowlabs.com.

The following critical exposure categories were identified and documented:

1. Unauthenticated RCE via Embedded Terminal: A web-based interactive terminal, integrated directly into the platform UI, was accessible without any login, session token, or IP restriction, granting arbitrary command execution on the host operating system.
2. Full Operational Intelligence Disclosure: The dashboard presented the researcher's complete active and historical bug bounty portfolio - including high-severity and critical vulnerability details, target system documentation, proof-of-concept notes, and submission timelines for unreported findings.
3. AI API Key Leakage: The platform's settings interface exposed multiple third-party AI API keys in plaintext, including keys for large language model providers integrated into the automated reconnaissance pipeline.
4. Complete Reconnaissance Pipeline Exposure: Custom AI-automated discovery and enumeration pipelines, including their full configuration, target scope definitions, and output history, were readable without restriction.

The server owner could not be identified through WHOIS records, reverse DNS, public profiles, or any other available channel. Direct private notification was not possible. SDX Shadow Labs documented the exposure, left all data fully untouched and unmodified, and has published this advisory as a public notice - the only remaining notification path available. No data was accessed beyond what was necessary to establish the scope of the finding.

No data was exfiltrated. No findings were accessed beyond what was necessary to document the scope of exposure. No exploitation of the RCE vector was performed beyond verification of its existence.

---

Background & Discovery Context

SDX Shadow Labs researchers routinely conduct passive reconnaissance exercises as part of ongoing threat intelligence research and internal attack surface analysis methodology development. This activity does not involve active exploitation of third-party systems and operates within the scope of incidental discovery under ethical research principles.

During one such exercise, a researcher identified an unusual service fingerprint on a publicly routed IP address at an uncommon port. The initial assessment suggested a misconfigured developer environment - a common incidental finding. Deeper inspection revealed the service to be a purpose-built, self-hosted web application: a personal bug bounty operations management platform developed and operated by a professional security researcher.

The platform presented its full interface immediately upon browser navigation - no login prompt, no redirect to an authentication page, and no HTTP-level access control. The absence of authentication was not a bypassed mechanism; there was no authentication mechanism present at the application layer for the primary interface.

---

Technical Findings

Finding 1: Unauthenticated Remote Code Execution via Embedded Web Terminal

Severity: CRITICAL | CVSS 3.1 Score: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

The platform included an integrated terminal emulator - a web-based interactive shell session - embedded directly in the dashboard UI as a standard feature for running reconnaissance commands and managing automated pipeline tasks from a browser. This terminal was accessible at a dedicated route within the application, reachable by any unauthenticated visitor.

Upon navigating to the terminal interface, a fully interactive shell session was presented, running with the privileges of the application service account on the host system. An attacker could:

• Execute arbitrary operating system commands
• Read, modify, or delete files accessible to the application process
• Enumerate the host environment, running services, and mounted storage
• Establish outbound network connections from the host for exfiltration or lateral movement
• Deploy persistent access mechanisms (reverse shells, scheduled tasks, SSH key injection)

This represents a complete compromise of the host server - all subsequent findings are therefore contextualized within the assumption that a malicious actor could achieve full system access via this single vector alone, with all further exposures additive.

Proof of Concept (Sanitized): Navigation to the terminal route at the server's address presented an interactive shell prompt with no credential challenge. Standard OS enumeration commands were executed to verify shell access and process privilege level. No further commands were run. Session was terminated and the finding was immediately flagged.

---

Finding 2: Full Operational Intelligence Disclosure - Active Bug Bounty Portfolio

Severity: CRITICAL | CVSS 3.1 Score: 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

The platform's primary dashboard interface presented the researcher's complete bug bounty operational archive. Findings documented at time of discovery included:

• A substantial archive of previously submitted vulnerability reports - complete with target system details, vulnerability descriptions, CVSS classifications, proof-of-concept documentation, disclosure timelines, and program response histories.
• A significant number of high-severity vulnerability drafts in active, in-progress status - findings that had been discovered and documented but not yet submitted to any bug bounty program.
• A smaller set of critical-severity findings - including zero-day vulnerability research - that had not been submitted to any program, vendor, or disclosure channel at the time of discovery.

The potential impact of this exposure to a malicious actor is severe and multidimensional:

To the affected researcher:

• Complete theft of active research representing significant professional effort and financial value
• Fraudulent pre-submission of the researcher's in-progress findings under a different identity, constituting bounty theft
• Exposure of the researcher's operational methodology, tooling signatures, and target selection patterns

To the programs and vendors whose systems are documented in unsubmitted reports:

• Those critical and high-severity vulnerabilities remain undisclosed to the affected vendors, meaning the exposure window for those systems was extended by however long the server remained open
• Any malicious actor who accessed the dashboard before or concurrently with our discovery could now possess working exploit details for unpatched production systems

To the broader security research ecosystem:

• Erosion of trust in responsible disclosure when researchers' own handling of sensitive findings is insecure

In accordance with responsible disclosure ethics, no specific details of any individual finding - including target names, affected systems, or vulnerability specifics - were recorded, retained, or will be included in this advisory. The counts referenced above reflect only what was visually observable in the dashboard summary view during the brief window of documentation.

---

Finding 3: AI API Key Exposure in Plaintext Settings Interface

Severity: HIGH | CVSS 3.1 Score: 8.2 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N)

The platform's configuration and settings interface - also fully accessible without authentication - displayed API key credentials for multiple large language model and AI service providers in plaintext. These API keys were integrated into the platform's automated reconnaissance pipeline to power AI-assisted target enumeration, report drafting, and vulnerability triage.

Exposure of these keys to an unauthenticated actor enables:

• Consumption of the researcher's purchased API quota at arbitrary scale, resulting in financial harm
• Access to any conversation history or stored context maintained by those AI provider accounts
• Potential extraction of sensitive data the researcher had previously submitted to those AI services as part of their research workflow (vulnerability descriptions, target details, report drafts)
• Use of the exposed keys to make attributable API calls - any abuse would be billed to and logged against the researcher's account

Rotation of all exposed API keys was included in the remediation recommendations communicated to the affected researcher.

---

Finding 4: AI-Automated Reconnaissance Pipeline Configuration Exposure

Severity: HIGH | CVSS 3.1 Score: 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

The platform's automated pipeline configuration - including the full architecture of the researcher's AI-augmented reconnaissance workflow - was readable without authentication. This included pipeline stage definitions, integration configurations between reconnaissance tooling and AI analysis layers, scheduling logic, and accumulated pipeline output history.

This represents a significant operational security failure independent of the other findings. A sophisticated threat actor (including competing researchers, or a target whose infrastructure appears in the researcher's scope) gains detailed insight into:

• Which reconnaissance techniques and tooling the researcher employs
• The specific infrastructure and services they integrate for AI-assisted analysis
• Their operational tempo and research cadence
• The scope of targets they are actively investigating

---

Root Cause Analysis

The fundamental failure is architectural: the platform was deployed to a publicly routed IP address with no network-level ingress restriction and no application-level authentication implemented on any route.

This is a failure mode specific to developer-built, self-hosted tooling. When a security researcher builds internal tooling for personal use, the implicit mental model is often one of local access - the tool is developed and tested on a local machine where the network boundary provides implicit protection. The deployment of that tooling to a cloud-hosted or co-located server, without a corresponding shift in the security model, removes that implicit protection while the developer's mental model of "it's just my local tool" remains unchanged.

Contributing factors likely include:

• No authentication layer in the initial build - the tool was built for single-user, local use, where authentication adds friction without benefit
• No network egress restriction applied at deployment - no firewall rule, VPN requirement, or IP allowlist restricting inbound access to the server's port
• No automated security monitoring on the researcher's own infrastructure - the server had been running in this state for an indeterminate period prior to discovery

The adversarial mindset that defines high-quality security research does not automatically transfer to the researcher's own infrastructure. This is not a criticism of the individual researcher - it is a structural pattern. The cognitive context of "I am the auditor, not the target" makes it easy to apply rigorous scrutiny to external systems while maintaining a lower bar for personal tooling.

---

Remediation Guidance

The server owner could not be identified for direct private notification. This advisory serves as the notification. If this is your infrastructure, the following actions are required immediately.

Immediate actions:

• Take the server offline or block all public ingress to the port - the application must not be reachable from the internet until authentication is fully implemented
• Rotate all AI API keys exposed in the settings interface across every affected provider - treat all exposed keys as fully compromised
• Review your server access logs for any prior unauthorized access; assume the worst and audit your active reconnaissance targets for any potential downstream exposure
• If any of the unsubmitted findings on the dashboard were accessed by a third party before your remediation, notify the affected programs immediately

Structural remediation:

• Implement strong authentication at the reverse proxy layer (e.g., Nginx auth_basic, HTTP Basic over HTTPS, or an OAuth2 proxy such as Authelia or oauth2-proxy) as a hard gate before any application route is served - do not rely solely on application-level controls
• Restrict network ingress to the server port using a firewall allowlist or place the entire server behind a VPN (WireGuard or similar) - the application should never be directly routable from the public internet
• Disable web-based terminal interfaces entirely in any internet-facing deployment; if you need remote shell access, use SSH with key-based authentication only
• Store AI API keys in environment variables or a secrets vault (e.g., HashiCorp Vault, Doppler, or platform-native secrets management) - never in application configuration that is readable via the UI
• Implement authentication logging and alerting; know when someone accesses your tooling and from where

Contact us: If you are the owner of this infrastructure, please reach out to security@sdxshadowlabs.com for closer ACK.

---

Ethical Disclosure & Methodology

SDX Shadow Labs adheres to responsible disclosure principles across all research activity, including incidental discoveries made outside of commissioned engagements.

Upon identifying this exposure:

• All documentation was limited to what was strictly necessary to establish the nature and scope of the finding
• No data from the server was read in detail, retained, or used for any purpose beyond scoping this disclosure
• The embedded terminal was navigated solely to verify the existence and nature of the RCE vector; no commands were executed beyond confirming shell access; the session was closed immediately
• No data was modified, deleted, or exfiltrated at any point
• Extensive attempts were made to identify the server owner through WHOIS records, reverse DNS, public profiles, platform-specific metadata, and community channels - all were inconclusive
• Because direct private notification was not possible, this advisory is published as a public notice with the dashboard screenshot redacted to protect the researcher's operational data from further exposure
• The redacted screenshot is included solely so the owner can self-identify their own tooling and take corrective action - it contains no readable operational data

This advisory is not published to expose or embarrass an individual. It is published because the server remains live and vulnerable, the owner is unaware, and a security researcher's unsubmitted zero-day findings are sitting exposed to any actor who knows where to look. Publication is the only remaining notification path available.

If you are a member of the security research community and recognize the tooling or dashboard style in the redacted image, please do not attempt to access the server - contact us at security@sdxshadowlabs.com so we can coordinate notification.

Securing the securer is not optional. The adversarial mindset must extend inward.

---

Public Disclosure & Notification Timeline

Advisory Notes

This advisory intentionally omits all operationally sensitive details: the specific IP address and port, the platform name, any details of the vulnerability reports or zero-day findings visible on the dashboard, bug bounty program names, and any other information that could further expose the researcher's operational data or the affected third-party systems documented in their unsubmitted findings.

The redacted dashboard screenshot attached to this advisory is published for one purpose only: to allow the owner to recognize their own tooling and take corrective action. It has been processed to obscure all readable text, target names, vulnerability details, and any identifying information visible in the original.

If you are the owner of this infrastructure: Immediately contact us at security@sdxshadowlabs.com so we can verify remediation and update this advisory.

This advisory will be updated with a remediation confirmation and closure date once the owner is identified and the exposure is resolved.