Penetration tests often flag common WordPress behaviors like wp-cron.php exposure or open SSH ports as potential risks. While these findings can look alarming, they are frequently expected behavior in standard WordPress and cloud hosting environments.
This guide explains how to interpret these findings, validate whether they are actual risks, and respond with proper technical justification.
Issue Background
A penetration test flagged two items:
- Public access to
wp-cron.php - Open SSH port (port 22) accessible from the internet
The goal was to determine whether these were true vulnerabilities and provide clear technical justification and recommendations.
Diagnosis
wp-cron.php exposure
In WordPress, wp-cron.php is a core file responsible for scheduled tasks such as publishing content, running updates, and executing maintenance processes.
By default:
- It is publicly accessible
- It returns a standard
200 OKresponse - It does not expose sensitive data
This behavior is expected and not considered a vulnerability on its own.
SSH (port 22) exposure
On cloud infrastructure such as AWS EC2, SSH access is typically open at the network level for server administration.
Key points:
- Open port does not equal unauthorized access
- Security depends on authentication and firewall configuration
- SSH is commonly secured using key-based authentication
This is standard practice in cloud environments.
Resolution Steps
1. Validate wp-cron usage
Confirm whether wp-cron.php is actively being used. Many plugins and core features rely on it.
Examples include:
- Wordfence (malware scans, firewall updates)
- Yoast SEO (indexing and SEO processing)
- FileBird (media cleanup tasks)
- Popup Maker (license checks)
- WordPress core (updates, site health, cleanup)
Disabling wp-cron without replacement will interrupt these processes.
2. Decide whether to keep or replace wp-cron
Option A: Keep default wp-cron
Recommended for most sites and requires no changes.
Option B: Replace with system cron
Disable wp-cron and configure a server-level scheduled task.
define('DISABLE_WP_CRON', true);wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1This approach requires server-level access (e.g., AWS EC2).
3. Apply SSH hardening best practices
- Use SSH key-based authentication only
- Disable password-based login
- Restrict access via IP allowlisting (security groups)
Optional:
- Change SSH port
- Use a VPN or bastion host
4. Understand responsibility boundaries
In many setups, infrastructure is managed separately from the WordPress application.
Server-level changes (like SSH restrictions or cron configuration) are typically handled by:
- Cloud provider (e.g., AWS)
- DevOps or IT teams
In these cases, recommendations should be provided rather than implemented directly.
5. Provide clear justification to stakeholders
wp-cron.php: Core WordPress functionality required for scheduled tasks and not a vulnerability by default.
SSH: Standard administrative access point secured through authentication and network controls.
Final Outcome
Both findings were determined to be expected behavior rather than active vulnerabilities. WordPress cron functionality was confirmed to be actively used by plugins and core processes, and SSH access was identified as a standard infrastructure configuration secured through best practices.
Optional hardening recommendations were provided, and responsibility for implementation was clarified based on infrastructure ownership.
Key takeaways
wp-cron.phpbeing public is normal in WordPress- Disabling wp-cron without replacement can break critical functionality
- Open SSH ports are common in cloud environments
- Security depends on configuration, not just exposure
- Always distinguish between application and infrastructure responsibilities
If you need help interpreting penetration test results or securing your WordPress environment, contact Freshy for expert support.
