BrightByte Technologies is the pseudonym used for a small-to-medium-sized Australian business operating an e-commerce website to sell products and services. The security review uncovered some significant findings and observations that might be overlooked by a developer.
1. The Client
For confidentiality, I will refer to the organisation as BrightByte Technologies. BrightByte is a small-to-medium-sized Australian business operating in the e-commerce sector.
Like many other e-commerce business websites used by small-to-medium-sized businesses worldwide, the environment has evolved over time.
The website used:-
- WordPress
- WooCommerce
- Multiple commercial and third-party plugins
- cPanel basedhosting
- LiteSpeed
- Cloudflare
From the outside, the environment appeared reasonably well maintained.
The website was behind Cloudflare; HTTPS was enabled; WordPress was functioning normally.
2. Why the Review Was Performed
The goal of the review was to identify weaknesses in the website and hosting environment before they could be discovered by an attacker.
The review combined scans using automated tools, configuration analysis and source code review.
Automated tool findings were manually reviewed and validated wherever possible.
This distinction became important later because some of the most alarming scanner results turned out not to be actual vulnerabilities once the installed plugin versions were confirmed.
3. Scope
The assessment covered the externally accessible website and the authorised hosting environment. The review was intentionally non-destructive.
No denial-of-service attacks were performed. No brute-force attacks, credential spraying, destructive exploitation, or testing that could affect real customers was carried out.
The objective was to identify risk without disrupting the client's production website.
4. What I Found
The environment is configured considerably well. In fact, several security controls were already working correctly. FTP service advertised TLS support, and anonymous access was disabled.
A suspected WordPress database backup directory was also protected and did not expose database files publicly.
However, deeper inspection identified three more significant findings, along with several lower-risk observations.
4.1 Outdated WooCommerce Installation
One of the first things I reviewed was the WooCommerce plugin stack. wpscan flagged several plugins and associated historical vulnerabilities.
At a glance, the wpscan result looked concerning.
Rather than treating every vulnerability the scanner listed as a real finding, I verified that most plugin versions are above the vulnerable ranges the scanner identified by logging in to the WordPress administration panel.
However, the WooCommerce plugin was different. The installed version was confirmed as WooCommerce 10.9.4.
The vulnerability data returned during the review identified security issues affecting the WooCommerce version 10.9.4.
- CVE-2026-57777 - Authenticated SQL injection vulnerability.
- CVE-2026-48888 - Unauthenticated Denial of Service (DoS) vulnerability.
I did not exploit either issue against the production environment. The version evidence alone was sufficient to determine that the WooCommerce installation required updating.
This matters because WordPress itself may be fully patched while individual plugins remain vulnerable. This is particularly important with e-commerce environments because WooCommerce is not just another cosmetic plugin. It handles customer accounts, orders, checkouts, payment integration, order data and much more.
A vulnerable component sitting at the centre of the e-commerce stack deserves considerably more attention than a minor informational disclosure.
4.2 Cloudflare WAF Could Be Bypassed
The website was configured behind Cloudflare. When the public hostname was scanned normally, requests were handled through Cloudflare as expected.
Internet ↓ Cloudflare ↓ Origin Server ↓ WordPress
Cloudflare provides many useful security controls, including Web Application Firewall, Rate Limiting, Bot Protection, IP Reputation Controls, DDoS Mitigation, etc. However, during testing, I was able to bypass Cloudflare completely and reach the hosting server directly using the IP address.
This matters because Cloudflare only provides traffic that actually goes through Cloudflare. If an attacker discovers the origin server address and combines it with the above mentioned DDoS attack vector, an attacker can successfully launch a DDoS attack without being subject to Cloudflare protection.
4.3 cPanel Was Protected Only by a Password
This finding is much less technical but carries considerable weight.
Two-factor authentication was not enabled for the cPanel account. At first glance, this may not sound as serious as SQL injection or a web application vulnerability.
But considering that cPanel controls all the server configuration setup and management, the impact of a leaked password is much more severe.
If an attacker obtains a WordPress account, the damage may be limited by the permissions of that account. If an attacker obtains the hosting control panel account, the situation is very different.
Without MFA, anyone who successfully obtains the cPanel password has only one authentication barrier to overcome.
Passwords and usernames can be compromised through phishing, browser malware, credential-stealing malware or previous data breaches.
This matters because MFA substantially reduces the likelihood that a stolen password alone results in account compromise.
4.4 Publicly Accessible Plugin ZIP Files (Observation 1 of 5)
Several plugin installation archives had been left inside wp-content/plugins/. Once a WordPress plugin has been installed, the original ZIP archive is generally not required for the plugin to operate.
Leaving installation packages inside the public web root can unnecessarily expose older plugin releases, commercial plugin packages, source files, and custom modifications. In a worse scenario, manually created archives can also contain configuration files, credentials, backups, or other sensitive material.
The archives should therefore be removed from publicly accessible directories when they are no longer required.
4.5 Unused Node.js Application Files (Observation 2 of 5)
Files belonging to an unused Node.js application were also found on the hosting account. The associated subdomain did not currently have a public DNS record, meaning the application was not reachable through the expected hostname.
But unused software remaining in a production environment is still worth addressing. Abandoned applications are more likely to stop receiving dependency updates, contain forgotten credentials, and become exposed accidentally later.
If the application is no longer required, it should be archived securely and removed from the production hosting environment.
4.6 Large Number of Temporary Zero-Byte Files (Observation 3 of 5)
A large number of zero-byte files with names resembling temporary write-test files were found under wp-content. They looked more like files generated by a plugin or process testing filesystem write permissions and failing to clean them up afterwards.
These files did not appear to represent a direct vulnerability. However, uncontrolled accumulation of temporary files can still create operational problems.
The appropriate response is to identify which process creates them and confirm that stale files are cleaned up correctly.
4.7 Technology and Version Disclosure (Observation 4 of 5)
Public HTTP responses revealed information about the server and the programming language used.
X-Powered-By: PHP/8.5.10 Server: LiteSpeed
The standard WordPress readme.html file was also publicly accessible. Even though this information does not directly compromise a website, it can make reconnaissance easier by helping an attacker understand the technology stack before performing more targeted testing.
Where practical, unnecessary implementation and version disclosure should be reduced.
4.8 Public API and AI-Agent Discovery Endpoints (Observation 5 of 5)
The site's HTTP responses also advertised several endpoints intended for API and AI-agent discovery.
/.well-known/api-catalog /wp-json/webmcp-bridge/v1/manifest /.well-known/mcp/server-card.json /wp-json/mescio-for-agents/v1/openapi /llms.txt /llms-full.txt /agents.txt
The existence of these endpoints was not treated as a vulnerability.
5. Why It Mattered
The most important part of this assessment was not any individual finding. It was how the findings related to each other. Each issue represented a different layer of the environment.
The important part is that chaining these individual findings can lead to a larger issue.
6. How the Risk Developed
There was no evidence that someone had deliberately configured the environment insecurely. Most of the issues appeared to be the natural result of the website evolving over time.
None of these changes feels catastrophic when considered individually. This is how technical debt develops.
And security debt develops in much the same way.
7. Recommended Remediation
The findings were prioritised based on potential impact and ease of remediation. Not every issue requires the same urgency.
7.1 Immediate
- Update the WooCommerce Plugin to the latest version
- Enable cPanel Two-Factor Authentication
- Protect the Origin Server (if the hosting environment permits, restrict traffic to Cloudflare-only IP ranges)
7.2 Short Term
- Remove Plugin Installation Archives
- Remove or Maintain the Old Node.js Application
- Review Public APIs
7.3 Long Term
- Move from reactive security maintenance toward a regular review cycle
8. Outcome
The review did not identify evidence that the website had already been compromised.
The review identified weaknesses that could be addressed before they became part of a real incident.
The assessment also identified opportunities to reduce unnecessary attack surface by removing old plugin archives and abandoned application components.
9. Lessons for Other Businesses
9.1 Security products do not automatically create a secure system
Security should be applied to every layer and maintained.
Cloudflare cannot protect requests that do not pass through Cloudflare. A WordPress security plugin cannot patch an outdated WooCommerce installation.
HTTPS cannot protect a hosting account from a stolen cPanel password.
Good security comes from layers working together.
9.2 Attack surface accumulates quietly
Every production environment gradually accumulates things that are no longer necessary. That is why security reviews should include cleanup and asset discovery, not just vulnerability scanning.
9.3 MFA matters even when everything else looks secure
If your web application is protected by multiple security tools but your hosting panel is protected by only a password, the hosting account may still represent one of the most valuable targets in the environment.
MFA is one of the simplest controls businesses can implement to reduce that risk.
10. When Was Your Environment Last Reviewed?
Most businesses know when their website was last redesigned. Far fewer know when somebody last looked at the environment from an attacker's perspective.
A website can function perfectly while security weaknesses quietly accumulate behind the scenes.
That is exactly why periodic security reviews matter. They are not just about finding vulnerabilities.
