webkund

webkund — Your Web Dev Companion.

Archives for July 2026

When a Routine WordPress Error Uncovered a Real Malware Infection: Lessons from Recovering a Website on IONOS Web Hosting

· · Leave a Comment

Website owners often assume hackers only target high-traffic websites, ecommerce stores, or organizations with valuable customer data. The reality is very different.

A recent incident involving a WordPress website hosted on IONOS demonstrated how automated attacks can compromise even a small business website—and why every WordPress installation deserves a proper security strategy.

It Started With a Simple Critical Error

The website suddenly displayed the familiar WordPress message:

“There has been a critical error on this website.”

At first glance, it looked like an ordinary plugin conflict or a failed update.

The debugging process began by enabling WordPress debug logging, which immediately revealed an unusual fatal error:

Cannot redeclare function get_page()

The error pointed toward a file that should never exist inside a standard WordPress installation:

wp-includes/update-extensions.php

That was the first indication that the issue wasn’t an ordinary WordPress bug.

Discovering the Backdoor

Opening the file immediately changed the direction of the investigation.

Instead of WordPress core code, the file contained a sophisticated PHP backdoor capable of:

  • Uploading and downloading files
  • Editing files directly on the server
  • Browsing the entire hosting account
  • Reading wp-config.php
  • Extracting database credentials
  • Searching for additional WordPress installations
  • Creating additional malicious PHP files

This wasn’t simply malware—it was effectively a remote administration toolkit for an attacker.

A Second Hidden Backdoor

The investigation continued.

Another suspicious file appeared in the WordPress root:

wp-cron.phpwp-update.php

Again, this filename does not belong to WordPress.

Its contents confirmed it was another backdoor related to the same infection.

At this point it became clear that the website had not merely experienced a software bug—it had been compromised.

Restoring WordPress Core

Rather than attempting to edit infected files individually, the recovery followed a safer approach.

The following actions were performed:

  • Deleted the malicious update-extensions.php
  • Deleted the malicious wp-cron.phpwp-update.php
  • Replaced the entire wp-admin directory
  • Replaced the entire wp-includes directory

The replacement was performed using clean WordPress 7.0.2 files uploaded through SFTP using FileZilla.

Importantly:

  • wp-content remained untouched
  • Themes remained intact
  • Plugins remained installed
  • Uploads remained untouched
  • The database remained untouched

Within minutes the website was operational again.

Wordfence Revealed One More Surprise

After restoring WordPress, Wordfence Security was installed and a full malware scan was performed.

The scan reported one critical issue.

Interestingly, it wasn’t another hidden file.

Instead, Wordfence discovered that the Akismet plugin itself had been modified.

Inside one of Akismet’s files, malware had inserted code similar to:

include_once('../../../wp-includes/update-extensions.php');

This meant the attacker had modified a legitimate plugin so that every time Akismet executed, it attempted to load the hidden backdoor.

Deleting the compromised Akismet plugin completely was safer than trying to edit the modified file.

After removal, only routine security recommendations remained.

Wordfence’s ability to compare WordPress core, themes, and plugins against known clean versions is one of its strongest features, making it particularly useful after an incident like this. (Wordfence)

Why Would Anyone Hack a Small Website?

Many website owners ask the same question:

“Why would someone target my website?”

In most cases, they probably didn’t.

Today’s attacks are largely automated.

Bots continuously scan the internet searching for vulnerable WordPress websites.

Once access is obtained, compromised websites may be abused for purposes such as:

  • Sending spam
  • Hosting phishing pages
  • Serving malware
  • Creating hidden administrator accounts
  • Installing persistent backdoors
  • Scanning for additional websites on the same hosting account

Small websites become victims simply because they are accessible—not because they are personally valuable.

A Lesson About Standard Web Hosting

This experience also highlighted an important distinction between standard shared web hosting and managed WordPress hosting.

The website was hosted on an IONOS Web Hosting package rather than an IONOS Managed WordPress plan.

IONOS Web Hosting offers excellent value with features such as SSL certificates, SFTP access, one-click WordPress installation, and solid performance. However, responsibility for WordPress maintenance and security remains largely with the site owner. Managed WordPress plans, by contrast, include automatic WordPress core updates as part of the service. (IONOS)

That doesn’t make standard hosting insecure. It simply means website owners should add their own security layer.

For many WordPress websites, that additional layer includes:

  • Wordfence Security
  • Regular plugin updates
  • Routine malware scans
  • Frequent backups
  • Strong administrator passwords
  • Two-factor authentication

Why Wordfence Is Worth Installing

The free edition of Wordfence includes:

  • Malware scanning
  • File integrity monitoring
  • WordPress firewall
  • Login protection
  • Two-factor authentication
  • Detection of modified WordPress core, plugins, and themes

It also allows website owners to detect unexpected file changes long before visitors notice something is wrong. (Wordfence)

Recovery Checklist

Following the cleanup, these additional steps were completed:

  • Deleted all identified backdoors
  • Restored clean WordPress core files
  • Removed the modified plugin
  • Installed Wordfence
  • Performed a full malware scan
  • Changed administrative credentials
  • Planned security scans for all other WordPress installations hosted on the same account

Final Thoughts

Perhaps the biggest lesson from this incident is that website security isn’t only about large businesses.

Even relatively small WordPress websites can become targets of automated attacks.

Fortunately, recovery doesn’t always require starting from scratch.

A combination of:

  • clean WordPress core files,
  • careful investigation,
  • proper backups,
  • SFTP access,
  • and a trusted security plugin

can restore a compromised website while preserving its content and functionality.

For anyone running WordPress on a standard hosting plan, investing a small amount of time in proactive security is far easier than responding to a compromise later.

Recommended Resources

How a GitHub Codespace Stuck on “Setting up your codespace” Was Solved Without Buying a New Laptop

· · Leave a Comment

There are moments when a technical problem seems to point towards failing hardware. A slow laptop, an old operating system, or an aging browser often becomes the first suspect. However, real-world troubleshooting frequently tells a different story.

This article walks through a real troubleshooting session where GitHub Codespaces refused to load on one Windows laptop while working perfectly on another device connected to the same Wi-Fi network. Instead of replacing the laptop, a systematic investigation revealed that the real culprit was a simple DNS configuration.

If you ever encounter a similar problem, this guide may save you hours of frustration—and possibly thousands of rupees.

The Problem

A GitHub Codespace opened normally on one device but remained stuck on the message:

Setting up your codespace

The issue occurred consistently on an HP Windows laptop.

Interestingly,

  • GitHub itself opened normally.
  • The user could log in successfully.
  • Chrome and Microsoft Edge both showed the same behaviour.
  • The same GitHub account worked perfectly on another device using the same internet connection.

This immediately suggested that the problem was probably not with GitHub.

First Thoughts

Many people would naturally assume:

  • The laptop is too old.
  • Windows is outdated.
  • The browser is incompatible.
  • It’s time to purchase a new computer.

That would have been an expensive mistake.

Instead of replacing hardware, the issue was investigated step by step.

Step 1 – Rule Out Browser Problems

Both browsers were tested.

  • Google Chrome ❌
  • Microsoft Edge ❌

Since both browsers behaved identically, it became unlikely that Chrome itself was responsible.

Step 2 – Check Proxy Settings

The following command was executed:

netsh winhttp show proxy

Result:

Direct access (no proxy server)

This ruled out proxy configuration as the cause.

Step 3 – Open Browser Developer Tools

Chrome Developer Tools (F12) were opened.

Initially, the Network tab showed several failed requests.

The important observation was that JavaScript files from GitHub’s asset server were failing to load.

This meant the browser could not download files required to start Codespaces.

Step 4 – Investigate DNS Resolution

The next step was checking whether GitHub domains could be resolved.

The command

nslookup github.dev

worked successfully.

However,

nslookup assets.github.dev

returned

Query refused

This was the first major clue.

The DNS server was refusing requests for one of the domains required by GitHub Codespaces.

Step 5 – Don’t Jump to Conclusions

At this stage, it would have been very easy to conclude that

  • Windows was corrupted,
  • the browser was broken,
  • or the laptop had become obsolete.

None of those assumptions were correct.

The evidence pointed towards DNS.

Good troubleshooting always follows evidence rather than assumptions.

Step 6 – Change DNS Servers

Instead of using the default DNS supplied by the internet provider, the DNS servers were changed to Cloudflare.

Preferred DNS

1.1.1.1

Alternate DNS

1.0.0.1

This can be configured from

Network Adapter
→ Properties
→ Internet Protocol Version 4 (TCP/IPv4)

Step 7 – Flush the DNS Cache

After changing DNS, the following command was executed:

ipconfig /flushdns

This removes cached DNS entries so Windows begins using the new DNS server immediately.

Step 8 – Verify the Fix

Running

nslookup assets.github.dev

now returned valid IP addresses instead of “Query refused.”

This confirmed that the DNS issue had been resolved.

At this point, GitHub Codespaces was finally able to download the JavaScript files required to start.

Lessons Learned

Several valuable lessons came out of this troubleshooting exercise.

1. Never blame the hardware first

An older laptop does not automatically mean faulty hardware.

Many software and networking issues produce symptoms that resemble hardware failures.

2. Compare with another device

Since another device worked on the same internet connection, GitHub itself was quickly ruled out.

Comparisons like this dramatically reduce troubleshooting time.

3. Browser Developer Tools are incredibly useful

Opening the Network tab revealed that JavaScript files were failing to download.

Without that clue, troubleshooting would have taken much longer.

4. DNS problems can appear in unexpected ways

Most people think DNS only affects opening websites.

In reality, modern web applications often depend on multiple domains.

If even one required domain cannot be resolved, the entire application may fail.

5. Work systematically

Rather than guessing, eliminate one possibility at a time.

In this case, the following possibilities were ruled out:

  • Browser
  • GitHub account
  • Internet connection
  • Proxy
  • Hardware

Only then did DNS become the obvious suspect.

Commands Used During Troubleshooting

Check proxy

netsh winhttp show proxy

Check GitHub domain

nslookup github.dev

Check GitHub assets

nslookup assets.github.dev

Flush DNS cache

ipconfig /flushdns

Final Thoughts

One of the biggest mistakes people make during troubleshooting is assuming that the most expensive explanation is the correct one.

When software refuses to work, it’s tempting to think:

“My laptop has become too old.”

In this real-world case, that assumption would have been completely wrong.

The solution wasn’t a faster processor, more RAM, or a new computer.

It was simply replacing an uncooperative DNS server with a reliable public DNS provider.

A few minutes of careful investigation solved a problem that could easily have resulted in an unnecessary laptop purchase.

Good troubleshooting is one of the most valuable technical skills you can develop. It saves time, reduces frustration, and often saves money by preventing unnecessary upgrades.

Start building your digital presence with webkund. Contact Us