Cybersecurity teaches us an uncomfortable truth:

A strong lock protects the door, but it cannot protect a window that was never secured.

Recently NextStruggle had been attacked with WP2Shell vulnerability, Initial our obvious assumption was that an administrator account had been hacked.

Though website had two-factor authentication (2FA) enabled. Administrator passwords were protected. AWS infrastructure remained secure.

Yet attackers still managed to:

• Create administrator access.
• Change WordPress credentials.
• Install a malicious plugin.
• Deploy a remote command execution backdoor.

The investigation revealed a deeper lesson: security is not only about protecting user authentication. It is about protecting every layer of the application stack.

I have spent more than 20 years working in technology, building and operating large-scale systems, and this incident reinforced one principle I have followed throughout my career:

“Security is a system design problem, not a single feature problem.”

WP2Shell Vulnerability: When WordPress Core Became the Entry Point

Many WordPress compromises happen because of vulnerable plugins or weak passwords. However, the WP2Shell vulnerability was different.

It targeted WordPress core itself.

The vulnerability chain, tracked as CVE-2026-63030 and CVE-2026-60137, combined issues in the REST API batch processing flow and SQL injection behavior to achieve unauthenticated remote code execution. Attackers did not require valid WordPress credentials to begin the attack. (GitHub)

The affected versions included:

(wp2shell)

This changed the security assumption completely.

Previously, many teams believed:

“Our administrator accounts have 2FA, therefore our WordPress installation is protected.”

WP2Shell demonstrated why that assumption is incomplete.

How Did Attackers Bypass WordPress 2FA?

This is the most important question. The attacker did not break 2FA, They avoided it.

The normal attack path looks like:

User Login
     |
     |
Username + Password
     |
     |
2FA Verification
     |
     |
Administrator Access

WP2Shell changed the flow:

Internet Request
        |
        |
WordPress Core Vulnerability
        |
        |
Remote Code Execution
        |
        |
Create Administrator Account
        |
        |
Install Malicious Plugin
        |
        |
Full Website Control

The attacker entered through the application layer, not through the login layer. That is why existing administrator protection did not stop the attack.

The Malicious Plugin: A Digital Backdoor

During investigation, I found a suspicious plugin:

content-tools-4ebb6330ff

At first glance, it looked like a normal WordPress plugin.

It was not. Inside was a remote shell.

The plugin created a hidden REST API endpoint:

/wp-json/wputils/v1/29658dde0444252bab631284

The dangerous part was:

'permission_callback' => '__return_true'

This means the endpoint required no authentication. Anyone who knew the URL could send commands.

What This Backdoor Allowed Attackers To Do

The plugin supported two execution modes.

1. PHP Code Execution

The attacker could send encoded PHP code:

eval(base64_decode($c))

This effectively gave them the ability to execute arbitrary PHP inside WordPress.

2. Operating System Command Execution

The plugin attempted multiple execution methods:

shell_exec()
exec()
system()
passthru()
proc_open()

Depending on server configuration, attackers could execute operating system commands.

This could allow:

• Reading server files.
• Modifying website content.
• Installing additional malware.
• Extracting database information.
• Creating persistence mechanisms.

A Critical Security Observation: The Plugin Was Not The Original Attack

One of the biggest investigation mistakes is focusing only on the malware found. The malicious plugin was the weapon, not the entry point.

The real question was:

“How did the attacker gain the ability to install this plugin?”

In this case, the evidence pointed toward a WordPress core compromise.

The attacker likely followed this sequence:

Exploit WordPress Core - Via default API's
          |
          |
Gain Code Execution
          |
          |
Create Administrator User
          |
          |
Install Backdoor Plugin
          |
          |
Maintain Access

Why AWS Was Not Compromised

A WordPress compromise does not automatically mean AWS compromise. As with security wordpress usually runs on, With its on user permissions.

The attacker had access to:

• WordPress files.
• WordPress database.
• Application execution context.

They did not necessarily have:

• AWS root credentials.
• IAM user credentials.
• AWS access keys.
• Infrastructure permissions.

However, every cloud deployment should verify:

• CloudTrail activity.
• IAM changes.
• New access keys.
• Security group modifications.
• Instance role permissions.

The key lesson:

Application compromise and cloud compromise are connected, but they are not the same incident.

Lessons For Engineering Leaders

1. Authentication Security Is Not Application Security

2FA is essential. But 2FA protects authentication.

It does not protect:

• vulnerable code,
• insecure APIs,
• remote execution flaws,
• database vulnerabilities.

Security requires multiple layers.

2. Patch Velocity Is A Business Capability

With AI advancement, Modern attackers scan the internet continuously. A vulnerability announcement can quickly become an exploitation opportunity.

For internet-facing systems:

• Patch critical vulnerabilities immediately.
• Maintain automated update pipelines.
• Monitor exposed services continuously.

3. Treat CMS Platforms Like Production Applications

Many organisations treat WordPress as “just a website.” That mindset creates risk.

A WordPress installation often contains:

• customer data,
• business content,
• API keys,
• payment integrations,
• internal workflows.

It deserves production-grade security practices.

Incident Response Checklist After WP2Shell

If your WordPress installation was compromised:

Immediate Actions

• ✅ Upgrade WordPress to a fixed version.
• ✅ Remove unknown administrator users.
• ✅ Rotate:
  • WordPress passwords.
  • Database credentials.
  • API keys.
  • Application secrets.
• ✅ Regenerate WordPress authentication salts.

Investigate Persistence

Check:

wp-content/plugins/
wp-content/mu-plugins/
wp-content/uploads/
wp-config.php

Look for:

• Unknown PHP files.
• Modified plugins.
• Suspicious scheduled tasks.
• Hidden administrator accounts.

Review Logs

Analyze:

• Apache/Nginx logs.
• WordPress audit logs.
• AWS CloudTrail.
• WAF logs.

Look for:

• REST API abuse.
• Suspicious POST requests.
• Unknown administrative actions.

My Tech Advice: After more than two decades in technology, my biggest takeaway remains:

Security is not a product you install. Security is a discipline you practice.

The WP2Shell incident is another reminder that attackers do not always break the front door. Sometimes they find an unlocked internal path that nobody was watching.

The organisations that respond fastest are not the ones that never face attacks. They are the ones that built systems ready to detect, recover, and improve.

#AskDushyant

Note: The names and information mentioned are based on my personal experience; however, they do not represent any formal statement.

#TechConcept #TechAdvice #WordPress #WordPressSecurity #WP2Shell #CyberSecurity #WebsiteSecurity #InfoSec #WordPressVulnerability #RemoteCodeExecution #RCE #ZeroDay #IncidentResponse #CloudSecurity #AWS #DevSecOps #ApplicationSecurity #CyberDefense #TechLeadership #SecurityResearch #NextStruggle #AskDushyant #AI #SecureCoding #DigitalSecurity