Check your osCommerce website
Enter your store domain to start a passive security assessment. The scanner will identify public application signals and check selected endpoints and configuration.
This public scan does not exploit vulnerabilities or access private application files. Further verification requires ownership confirmation or explicit authorization.
Why legacy osCommerce stores need targeted security checks
Many osCommerce installations have been running for years. Some have accumulated custom code, third-party integrations and modifications that were never part of the original platform.
This makes security assessment more complicated. A vulnerability may exist in a specific controller or file-processing function, rather than in a component that a generic scanner recognizes.
Our initial security profile focuses on osCommerce 2.0 (incl. forked TrueLoaded) / osCommerce 4.0 installations and five vulnerability classes identified and addressed during real remediation work.
Five osCommerce vulnerability classes we check
V1. Path Traversal and Arbitrary File Access
CWE-22 – Improper Limitation of a Pathname to a Restricted Directory
Image-processing endpoints can become an attack vector when user-controlled file paths are not properly validated.
The investigated application exposed this risk through:
image/cachedimage/path
Unsafe path handling combined with filesystem operations can potentially allow access outside the intended image directory or unauthorized file writes.
The remediation introduced strict relative-path validation, executable-extension restrictions and protection against symlink-based writes.
V2. Insecure API Authentication
CWE-798 – Use of Hard-coded Credentials
CWE-204 – Observable Response Discrepancy
Hardcoded API keys and weak comparison logic create unnecessary authentication risks.
In the investigated implementation, a shared key was used across separate installations, with a non-constant-time comparison.
The remediation replaced the hardcoded value with locally
stored configuration, introduced hash_equals()
and rotated the exposed credentials.
V3. Remote Code Execution Through Upload Directories
CWE-434 – Unrestricted Upload of File with Dangerous Type
An upload directory should not be a place where executable server-side code can run. If an attacker manages to upload a PHP file into an executable directory, the consequences can be severe.
The investigated remediation hardened:
uploads/images/tmp/
It introduced execution restrictions and rules to prevent PHP execution and suspicious polyglot filenames.
V4. Local File Inclusion in Product Configurator
CWE-98 – Improper Control of Filename for Include/Require Statement
CWE-22 – Path Traversal
Product configurators sometimes need to load customer-provided or dynamically generated image files. If a filename supplied through a request is used without proper validation and directory containment checks, unintended files may be accessed.
The affected functionality involved:
catalog/product-configurator-frameupload_filename
The remediation introduced filename sanitization and
realpath() containment checks to keep file
access inside the permitted directory.
V5. Administration Log Vulnerabilities
CWE-79 – Cross-site Scripting
CWE-78 – OS Command Injection
Administration tools can become an attack vector when they process attacker-controlled data.
The investigated log checkout functionality contained:
- Stored XSS in DataTables output.
- Unsafe shell command construction using an IP address.
- Insufficient validation of IP address data.
- Missing-record handling that could break administration requests.
The remediation introduced output encoding, input validation, safe shell argument handling and additional error guards.
How the osCommerce security checker works
1. Application fingerprinting
The scanner examines public application signals, URL patterns, HTML structure and HTTP responses to identify the platform and determine which checks may be relevant.
2. Public security checks
The passive profile examines selected endpoints, sensitive-file exposure, version disclosure, HTTPS and security headers. The results identify observable exposure and vulnerability classes that require further verification.
3. Authorized verification
A platform fingerprint cannot establish whether a particular source-code vulnerability is present. Extended checks are designed to verify the actual application behaviour after ownership or testing authorization has been established.
4. Security remediation
Once a problem is confirmed, our team can investigate the affected code, prepare a targeted patch and verify the fix.
Why we built this osCommerce security checker
We have been working on real security incidents involving legacy osCommerce-based ecommerce systems. The work has required more than blocking suspicious HTTP requests.
We addressed vulnerabilities across application controllers, upload configuration, authentication and administration functionality. Some fixes required coordinated changes across several files and careful verification to preserve existing store behaviour.
These findings form the starting point for our osCommerce security check registry. As new vulnerability patterns are investigated and verified, additional checks can be introduced.
Frequently asked questions
Does this checker support every osCommerce version?
The initial profile focuses on TrueLoaded / osCommerce and known application patterns. Support for other forks and versions depends on their identifiable signals and available checks.
Can the public scan confirm that V1–V5 are patched?
No. The public scan cannot inspect private application source code. It identifies relevant platform signals and potential exposure. Definitive patched/vulnerable classification requires appropriate authorized verification.
Does the checker exploit vulnerabilities?
No. The initial public version uses passive fingerprinting and non-invasive HTTP checks. Extended verification is a separate stage requiring proof of ownership or explicit authorization.
Can an outdated osCommerce store still be secure?
Yes. Age alone does not determine security. Older installations need to be assessed against their actual code, modifications, integrations and server configuration. Applying generic updates without understanding custom code can also break existing functionality.
Can you investigate an already compromised osCommerce store?
Yes. We can investigate suspicious application changes, administrator accounts, exposed credentials and known vulnerability paths. A complete investigation may also require server-level access and review of hosting logs.
Need an osCommerce security assessment?
If your store has been targeted, or you want to assess the security of a legacy installation, contact our team. We can investigate the application, identify vulnerable code paths and help implement the necessary fixes.