Penetration testing in practice: a step-by-step look at how an application is compromised
Why Penetration Testing is Crucial for Application Security
Modern applications are built rapidly. Teams naturally focus on functionality, performance, and time-to-market. If a system runs smoothly, it is often considered ready for production.
From a security perspective, however, this assumption can be a significant blind spot.
An application can easily:
function exactly as intended,
pass all functional tests,
meet every business requirement,
…and still harbor vulnerabilities that could allow unauthorized access or compromise.
Penetration testing lets us look at an application from a different perspective—not as a user expecting it to work, but as an expert seeking to understand where it might yield under pressure.
From a Simple Form to Full Compromise (RCE – Remote Code Execution)
One of the examples discussed during our webinar was a recently disclosed vulnerability tracked as CVE-2026-3300 (CVSS 9.8), affecting the Everest Forms Pro plugin for WordPress.
The entry point was remarkably simple:
a publicly available web form,
no login required,
no special privileges needed.
From a business standpoint, this was just a standard, useful application feature.
From a security standpoint, it represented a potential attack vector.
The critical question we must always ask is:
What happens on the server side with the data provided by the user?
In this case, the answer was crucial.
The data processing mechanism (Complex Calculation) evaluated inputs in a way that allowed form values to influence the execution of the underlying PHP code, rather than treating them strictly as data.
This very moment marks the line:
between a standard application bug,
and a critical Remote Code Execution (RCE) vulnerability.
Demo: Witnessing the Exploit in Practice
The video below shows a simplified scenario demonstrating how this vulnerability can be leveraged:
It is worth noting a few key aspects of this demonstration:
no administrative access was required,
no password cracking was involved,
no advanced binary exploits were needed.
The process relied entirely on:
a publicly accessible application feature,
the misplaced assumption that user input would always be safe.
Exposed Secrets and Artifacts as an Entry Point
The second scenario we explored involved exposed artifacts—one of the most common issues uncovered during penetration testing.
A typical case in point:
a publicly accessible backup of a configuration file,
which contains active database credentials.
From the development team's perspective, this might seem like:
a "forgotten file,u201d
a minor house-keeping oversight.
From an external tester's or adversary's perspective, it is:
a direct path to the next phase of the compromise.
This highlights a vital distinction:
the vulnerability: a secret is left in an insecure file,
the impact: the secret grants access to the database and allows data modification.
It is always the actual business impact that defines the real-world risk.
Most Common Vulnerabilities in Web Applications
Based on our hands-on experience in penetration testing, these recurring categories of issues present the most common challenges:
1. Lack of Input Validation
implicitly trusting user-supplied data,
a lack of control over how that data is processed in the background.
2. Outdated Dependencies (CVEs)
known vulnerabilities being leveraged by adversaries,
unpatched third-party libraries and frameworks.
3. Exposed Secrets and Artifacts
forgotten backups,
unsecured configuration files,
hardcoded credentials left in repositories.
4. Unmanaged Use of AI Tools
copying insecure code patterns generated by AI models,
failing to validate AI-generated code before integration.
Penetration Testing and Its Real Business Impact
Effective penetration testing is about much more than simply finding a list of vulnerabilities.
Its true purpose is to answer a fundamental question:
What can actually be achieved with this vulnerability?
Real business risk is only demonstrated when:
access to the system is successfully confirmed,
data modification is shown to be possible,
and a tangible impact on operations can be verified.
…this is what helps leadership prioritize the right fixes.
For an organization, these risks can quickly translate into:
loss of data integrity,
unplanned downtime and system outages,
erosion of customer trust,
compliance and regulatory consequences (e.g., NIS2, ISO 27001).
Application Security Checklist for CTOs and Heads of Engineering
The following checklist serves as an excellent starting point to review your posture before a penetration test:
Attack Surface Management
Do we maintain an up-to-date inventory of all publicly accessible assets?
Are our staging and testing environments strictly isolated from external access?
Secrets Management
Are config credentials and API keys stored completely outside of the codebase?
Do we enforce regular rotation of access keys and secrets?
Dependency Management
Do we actively monitor CVEs in the libraries we depend on?
Is Software Composition Analysis (SCA) integrated into our CI/CD pipelines?
Input Validation
Is all user input validated, sanitized, and parameterized?
Are robust guards against injection attacks active at every entry point?
Secure Development Process
Is security a core part of our peer code reviews?
Are we systematically leveraging SAST and DAST tooling?
Verifying Impact
Can we accurately assess the potential business impact of a given vulnerability?
Do our security evaluations test against logical abuse scenarios, rather than just technical bugs?
Full Webinar Recording
This article only touches on the surface of what was demonstrated.
In the complete recording, we walk through:
the entire penetration testing process from start to finish,
how vulnerabilities are systematically identified,
the journey from finding a simple bug to demonstrating its real business impact.
To access the recording and accompanying materials, please click the link below.
Summary
Most critical vulnerabilities do not stem from a single oversight.
Rather, they are the result of:
recurring anti-patterns,
gaps in development processes,
untested security assumptions.
Building secure applications requires more than just deploying scanning tools; it demands a shift in perspective.
Moving away from:
“does this system work under normal conditions?”
Toward:
“what happens to the system if someone actively tries to exploit it?”