An application assessment reveals file upload RCE, Logi access-control failures, and unsafe report scripts, with practical remediation guidance.
The application I tested exposed several paths to remote code execution (RCE), along with a reporting configuration that allowed low-privileged users to execute SQL queries against multiple databases. File uploads, dashboard tools, and report previews each introduced a different security gap.
This assessment illustrates the practical value of offensive security at Cyber Advisors: checking how controls behave together, rather than assuming one protective layer will compensate for another. Below, I explain the findings, the evidence collected, and the changes recommended to address them.
Microsoft Defender detected and deleted the initial ASPX payload during testing. I had encountered similar behavior on earlier assessments: an application permitted code-file uploads, but antivirus protection prevented the uploaded file from remaining on the server.
Using a FuzzDB ASPX command shell as a baseline, I investigated the detection behavior. Certain strings appeared to contribute to detection, but this was an observation from my testing, not a confirmed explanation of Defender's detection logic.
The result highlighted a distinction relevant to penetration testing: detecting one payload does not establish that the upload functionality itself is secure.
The custom file used C# native interop to call a native function and accepted a base64-encoded command that it decoded at runtime. The document's original implementation avoided hardcoding the operating-system command in the uploaded file.
That file was not detected and deleted in the same way during this assessment. This finding is specific to the tested environment; it does not establish a universal bypass of Microsoft Defender or explain how every detection layer evaluates such files.
The application's upload function allowed an ASPX file to be written into a location where the web server could execute it. Three weaknesses combined: permissive uploads, acceptance of an absolute destination path, and detailed error messages exposing installation paths.
On earlier engagements, files had been stored in S3, ASPX uploads had been blocked, or no executable upload location had been available. Here, the application's stack traces revealed enough of its installation structure to identify a suitable destination.
The evidence below shows the initial detection result, the subsequent upload, and the observed execution. It demonstrates why security assessments need to examine the complete path from upload to storage and retrieval.
The test command sent Windows user information to my remote server. That provided evidence of operating-system command execution, rather than simply demonstrating that the application accepted an unexpected file.
Logi's image upload feature provided another route to remote code execution in this application. While creating a visual, I found that the image upload accepted arbitrary files instead of restricting uploads to the image types the feature required.
I reused the custom ASPX file through that upload function. The uploaded file could then be called through the web application, and a test command sent directory information to my remote server.
This was a separate upload entry point with the same essential problem: user-supplied code reached an executable location. Fixing the main application's upload handler alone would leave this second finding unresolved.
For your own testing, include third-party upload surfaces in the review. Cyber Advisors' application security services cover web applications and code review, helping development teams investigate weaknesses beyond the most obvious user-facing forms.
The Logi Web Metadata Builder was accessible to low-privileged application users. Its database functionality allowed those users to execute arbitrary SQL queries against multiple databases, exceeding their intended application access.
I accessed the builder's connections page, opened a metadata definition, and used the query editor to list database tables. Figures 9–11 document that progression.
The demonstrated issue was an authorization failure in this deployment. The builder exposed legitimate database-management functionality to users who did not require it. The evidence does not establish that database contents were modified or that the same configuration exists in every Logi installation.
As part of risk management, evaluate administrative capabilities according to what users can do through them, not simply whether those users have authenticated.
Previewing an uploaded report executed embedded C# code on the server. The application allowed users to upload XML-based .rpx report definitions and open them through its report-editing interface.
I downloaded an existing report and found C# inside its script section. After modifying that section to invoke an operating-system command and uploading the report, clicking Preview triggered the code through the ActiveReport_ReportStart() event.
The reporting-engine name is intentionally left unspecified here. The finding concerns the observed execution of user-supplied report scripts, not a claim about a particular vendor's default configuration.
A report definition can contain more than layout and data-selection instructions. Your review must account for any embedded code that the reporting component executes while editing, rendering, or previewing the report.
The assessment's recommendations addressed upload validation, destination paths, administrative access, and report-script execution. Each requires a separate fix; antivirus detection alone does not resolve these application-level weaknesses.
Allow only the file types needed for each upload feature. Treat document uploads and image uploads as separate validation requirements, and reject files that do not meet the relevant feature's requirements.
Do not accept user-supplied full paths as upload destinations. Use a controlled filename and storage location, and verify that uploaded files cannot be written to arbitrary server directories.
As additional hardening guidance, the OWASP upload guidance recommends defense in depth, including content validation and storage outside the web root where possible. Ensure your chosen storage design prevents uploaded content from executing.
Disable the Logi Web Metadata Builder if the application does not need it. Otherwise, restrict access to privileged users who require its functionality.
Verify the restriction using low-privileged accounts. Configuration reviews and control assessments should examine the effective permissions exposed by integrated tools, as well as the application's normal user interface.
Disable report-script execution when it is not required. Apply the appropriate control for the actual reporting engine and verify that uploaded reports cannot trigger operating-system commands during preview or rendering.
Do not assume that a report's XML format makes its contents inert. In this assessment, the script section remained executable input when the report was previewed.
This assessment showed how multiple integration points can expose distinct paths to server execution and unauthorized database access. A successful antivirus detection at one point did not remove the application's upload, authorization, or report-processing weaknesses.
Include integrated components in your security testing strategy, and validate each remediation independently. Cyber Advisors helps teams turn assessment findings into actionable guidance, while regular testing helps revisit controls as applications change.
Use deployment and integration changes as opportunities to schedule validation. The objective is concrete: confirm what your users can upload, where those files can go, which administrative functions they can reach, and what the server will execute.