How the Lack of Restricting Public API Access Can Lead to Total Compromise.

Prepared by: Jack Rutherford, Chief Technology Officer & Mike Higgo, Head of Offensive Security
Published: 29 July 2026

Web Application Penetration Testing Reveals Publicly Exposed API Functionality, Leading to Command Execution

This case study demonstrates how restricting access to specific functionality can drastically reduce attack surface and prevent unauthorised modifications.  

A large national medical organisation with offices across Australia sought assurance that its newly created web application was protected from cyber threats. The application captures, stores, and processes a considerable amount of sensitive information that must be securely protected. They needed to understand whether a malicious outsider could potentially access or manipulate the stored data, potentially leading to reputational damage, loss of confidentiality, or more alarmingly, lateral movement to other internal infrastructure.

Triskele Labs was engaged to perform a thorough penetration test to evaluate this risk.

The discovery 

During a routine security sweep, testers used automated toolsets to uncover hidden files, folders and APIs. They found a scheduler API that administrators were unaware of, and had not appropriately hardened or restricted access to. Clues pointed to Flask-APScheduler, a tool that lets developers schedule tasks in Python through a built-in web interface.

Further investigation showed the interface would accept a task that called Python’s os.system function. Submitting such a task let the testers run any command on the underlying server.

 Figure 1: Automated content discovery scan revealing the exposed scheduler endpoint, returning a 200 status where similar paths redirected. 

Figure 2: Source code review linking the endpoint's response data to the flask-apscheduler project on GitHub, confirming the tool behind it. 

The exploitation 

A simple one-line python command was utilised, which, when interpreted by the host, gave direct command line access to the underlying server.

With that foothold gained, the entire application was effectively compromised. As the application was hosted within AWS, the server was also scanned and enumerated, and a file discovered containing AWS instance metadata. This metadata contained a large swath of sensitive information, including AWS secret keys, granting a foothold on the AWS infrastructure owned by the corporation. Once the AWS infrastructure was effectively compromised, it could be used to launch further attacks against other internal network resources.

While our engagement didn’t include further testing within the AWS infrastructure or the internal network (per the agreed upon scope of work), we were able to show that serious compromise was possible through a single exposed API.

The implication 

This wasn't just a single server compromise. The exposed API gave testers a direct path into the AWS environment sitting behind the application, the same infrastructure holding the organisation's sensitive medical data.

Access at this level could have supported far wider attacks: reading or altering patient records, pivoting to other AWS-hosted systems, or disrupting services that staff and patients depend on. For a medical organisation, that risk goes beyond data loss. It touches patient safety and public trust.

Recommmendations: 

This engagement showed how a single unhardened, publicly reachable API can lead to full server and cloud compromise. Triskele Labs recommends that organisations running web applications, particularly those handling sensitive data, consider the following controls:

• Restrict administrative and scheduler functionality to trusted networks. Interfaces such as Flask-APScheduler should never be reachable from the public internet. Administrative APIs should sit behind authentication, network controls, or both, so that only authorised operators can reach them.
• Maintain an accurate inventory of exposed endpoints. Development teams are often unaware of every API their application exposes. Organisations should routinely enumerate their own applications for hidden files, folders, and APIs, and disable or remove any functionality that is not required in production.
• Remove the ability to execute arbitrary system commands. Functionality that permits calls to functions such as os.system provides a direct route to command execution. Where scheduling or similar features are genuinely required, input should be strictly validated against an allowlist, and the underlying interpreter should not be able to invoke operating system commands.
• Enforce IMDSv2 and apply least privilege to instance roles. Exposed AWS instance metadata frequently contains secret keys that let an attacker escalate from a single host to the wider cloud environment. Enforcing IMDSv2 (which requires a session token and mitigates SSRF-style metadata theft) and scoping instance IAM roles to only the permissions genuinely needed significantly limits the blast radius, even after a host is compromised.
• Apply network segmentation between applications and sensitive infrastructure. Segmenting the application tier from data stores and internal resources limits an attacker's ability to pivot once an initial foothold is gained.
• Test regularly. New applications and infrastructure changes continually introduce new exposure. Recurring penetration testing, particularly before and after major releases, helps identify issues such as this before a malicious outsider can exploit them.