Ad
Ad
Ad
Tag

Fix

Browsing

Suddenly, there is an unknown post on your WordPress website without your permission, worst of all it appears only on the frontend and can’t be deleted from the backend. This is a nightmare most WordPress users are quite familiar with.

As of the time of writing this article, this a current hack on multiple WordPress websites. I also came across a Reddit user with a similar problem which after helping him I was compelled to write an article for anyone looking for help to remove the unknown post on their WordPress website. In other to solve this mess of a hack you have to understand what lead up to this soft hack on your WordPress website.

Read Now: Increases your WordPress website loading speed by 200%.

The hack

It’s a simple database injection. Due to WordPress dependency on SQL makes it quite easy for hackers to inject codes into the database and gain unauthorized access. This is one of the biggest flaws of WordPress.

These malicious codes are injected through forms, login box, search box literally anything that takes user input. Due to most submissions on a WordPress website ae stored in the SQL database, all the hacker needs is to insert the code in form submission.

With this unauthorized accessto the SQL, post can be inserted or deleted depending on how friendly the hack is.

The solution to remove the unknown post from WordPress and increasing security.

Security

Step 1

Add Depender Plugin by WPMU DEV.
Make sure to change the database prefix from the default “wp”.
Activate limit on login trial.
Change the login URL from /wp-admin/ to another URL of your choice.
Activate the rest of the settings that suit your recommendation.

Step 2

Add Salt Shaker Plugin.
Reset your WordPress salt daily automatically to increase security and reduce vulnerability.

Step 3

Change the login password.

Removing the unknown post on the WordPress Website

Step 1

Head over to the PHPMyAdmin.

Step 2

Find “wp_posts” and click on it.
Note: if you had changed the prefix using the defender plugin it would be the new prefix _posts.

Step 3

Find the injected (unknown) post via post_title. Using the PHPMyAdmin table column post_title, it would be easier to identify.
Once found delete the post.

Conclusion

Due to how vulnerable WordPress, hackers will always find newer ways to gain unauthorized access. Always have a security plugin.

Make sure all other plugins are update and avoid nulled plugins.

Possible solutions to fix  warning: mysqli_real_connect(): (HY000/2002): Connection refused in /var/www/wordpress/wp-includes/wp-db.php

This error (mysqli_real_connect(): (HY000/2002) occurs often when updating major plugins on a WordPress website that uses WP CLI to operate on the site’s database. I did a lot of research on this error to get the best possible solutions just in case someone else comes across this same error.

Here are the three possible solutions:

Solution 1

  • Check to make sure the PHP version installed is up to PHP version 7.
  • Review the wp-config for miss-configuration.
  • Check the MySQL / database start, whether it’s running or not.
  sudo service mysql status
  • If the MYSQL / MariaDB status shows ” Failed to start mysqld.service: Unit not found “, then you need to start up the database again.
 systemctl start mariadb

After which, you restart the WordPress website on your browser, the sites should be back up.

Solution 2

  • Head over to your wp-config.php file.
  • Try using the local server rather than the “localhost”. That means changing “localhost” to “127.0.0.1” at wp-config.php

Refresh the WordPress website after restarting the database, the website should be back online

Visit: The Emotional Computer for computer repairs and services.

Solution 3

If you are using a VPS, chances are that you are running out of memory that’s why this error keeps up showing up.

You should optimize the database of the WordPress website on the VPS using MySQLtuner.

Step 1

Install MySQLtuner

sudo apt-get install mysqltuner

Step 2

Run MySQLtuner

mysqltuner

Step 3

Input the login credencials

login:
password:

Step 4

Below is sample analytics.

Your MySQL analysis would be different.

[OK] Thread cache hit rate: 99% (539 created / 68K connections)
[OK] Table cache hit rate: 69% (274 open / 397 opened)
[OK] Open file limit used: 1% (59/4K)
[OK] Table locks acquired immediately: 100% (4M immediate / 4M locks)
-------- Performance schema -------------
[--] Performance schema is disabled.
-------- ThreadPool Metrics -------------
[--] ThreadPool stat is enabled.
[--] Thread Pool Size: 1 thread(s).
[--] Using default value is good enough for your version 
(10.1.44-MariaDB-0+deb9u1)
-------- MyISAM Metrics -----------------
[!!] Key buffer used: 18.3% (3M used / 16M cache)
[OK] Key buffer size / total MyISAM indexes: 16.0M/123.0K
[!!] Read Key buffer hit rate: 90.0% (20 cached / 2 reads)
-------- AriaDB Metrics -----------------
[--] AriaDB is enabled.
[OK] Aria pagecache size / total Aria indexes: 128.0M/1B
[!!] Aria pagecache hit rate: 86.2% (982K cached / 135K reads)
-------- InnoDB Metrics ------------------
[--] InnoDB is enabled.
[OK] InnoDB buffer pool / data size: 128.0M/53.7M
[!!] InnoDB buffer pool <= 1G and innodb_buffer_pool_instances(!=1).
[--] InnoDB Buffer Pool Chunk Size not used or defined in your version
[OK] InnoDB Read buffer efficiency: 100.00% 
(220631287 hits/ 220633521 total)
[!!] InnoDB Write Log efficiency: 71.98% (1777130 hits/ 2468813 total)
[OK] InnoDB log waits: 0.00% (0 waits / 691683 writes)
-------- TokuDB Metrics ----------------
[--] TokuDB is disabled.
-------- Galera Metrics ---------------
[--] Galera is disabled.
-------- Replication Metrics ----------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] This is a standalone server.
-------- Recommendations -------------
General recommendations:
Configure your accounts with ip or subnets only, 
then update your configuration with skip-name-resolve=1
When making adjustments, 
make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries which have no LIMIT clause
Variables to adjust:
query_cache_size (> 16M)
tmp_table_size (> 16M)
max_heap_table_size (> 16M)
innodb_buffer_pool_instances (=1)

Step 5

From the MySQLtuner analysis, you would need to adjust the MySQL config file(https://naijatochinco.site/etc/mysql/my.cnf) according to the recommendation provided by MySQL tuner.

Restart MySQL server after you have made the necessary changes to MySQL config file

systemctl restart mariadb

Hopefully, these solutions are able to provide help and insight to anyone having a similar problem.