Title: Potentially vulnerable code
Last modified: September 24, 2018

---

# Potentially vulnerable code

 *  Resolved [tflora](https://wordpress.org/support/users/tflora/)
 * (@tflora)
 * [7 years, 7 months ago](https://wordpress.org/support/topic/potentially-vulnerable-code/)
 * Wordfence (free) has alerted me this morning thusly:
 * “To make your site as secure as possible, the Wordfence Web Application Firewall
   is designed to run via a PHP setting called auto_prepend_file, which ensures 
   it runs before any potentially vulnerable code runs. This PHP setting is currently
   in use, and is including this file:
 * /home/content/75/6813875/html/gd.php”
 * What should I do about this?
 * Thanks for any help you can provide.
 * The page I need help with: _[[log in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fpotentially-vulnerable-code%2F%3Foutput_format%3Dmd&locale=en_US)
   to see the link]_

Viewing 4 replies - 1 through 4 (of 4 total)

 *  Thread Starter [tflora](https://wordpress.org/support/users/tflora/)
 * (@tflora)
 * [7 years, 7 months ago](https://wordpress.org/support/topic/potentially-vulnerable-code/#post-10717919)
 * Further details from within Wordfence:
 * Filename: gd.php
    File Type: Not a core, theme, or plugin file from wordpress.
   org. Details: This file appears to be installed or modified by a hacker to perform
   malicious activity. If you know about this file you can choose to ignore it to
   exclude it from future scans. The text we found in this file that matches a known
   malicious file is: setcookie(‘engine_ssl_
 * The infection type is: Backdoor:PHP/telosupdatingdoor
    Description: Backdoor 
   used to remotely control server
 * How to eliminate this? I have several backups I can use to restore if needed.
 *  [CB](https://wordpress.org/support/users/cbrandt/)
 * (@cbrandt)
 * [7 years, 7 months ago](https://wordpress.org/support/topic/potentially-vulnerable-code/#post-10726061)
 * Hi [@tflora](https://wordpress.org/support/users/tflora/),
 * The messages you received are quite worrying, but if you just clean the hack 
   without taking some other precautions, it may come back.
 * When I faced a hacking on my website years ago (it was not a WP website), the
   most frustrating thing was to have to repeatedly do the clean up, because the
   hackers had somehow obtained my credentials and kept coming back.
 * So I suggest you go through a list of preventive actions before you run a restore
   operation. (I’m assuming here that yours is a small website maintained by just
   one person, you). In that order:
 * 0) Consider taking your website offline while you fix the problem. For each visitor
   your website will lose, it will certainly lose a lot more should Google label
   it “unsafe”. Also, you don’t want the malware to spread, and you don’t want the
   hackers to continue exploiting your website. You should count on your hosting
   provider to help you put the site on maintenance mode. Ideally, while in maintenance
   mode, all your URLs should return a 503 HTTP response, as that’s what Google 
   recommends. Also, they must include a rule that allows you (via IP address) to
   access your website while on maintenance mode.
 * 1) Disable all extensions/themes/addons on the web browser you normally use to
   access your WP dashboard. This will avoid that next steps be accessed by the 
   hackers should they have made use of a browser extension exploit.
 * 2) Change your email accounts’ passwords. All of them. This will prevent that
   the hackers get access to information generated by next steps in case they were
   able to obtain your email credentials. For each email account:
    a) pick a strong
   password b) enable 2 factor authentication (2FA) (<<THIS IS VERY IMPORTANT)
 * 3) Go to your hosting provider.
    a) change your password b) change your FTP password
   c) change any keys you may have set for SSH access. d) enable 2FA. e) remove 
   any FTP accounts you (or the hacker) may have created. On your cPanel or equivalent
   dashboard, look for FTP accounts and remove any account that is not yours. f)
   enable SFTP, since FTP is not secure. Do not ever use plain FTP again.
 * 4) Go to your domain registrar (if not the same as your hosting provider)
    a)
   change your password b) enable 2FA
 * 5) Download and save in a secure location your website access log files from 
   your hosting server. This may be needed later to investigate how the hacking 
   was done.
 * At this point, if you are so inclined and know of the consequences of doing so(
   including losing content recently added or modified etc), go ahead and perform
   a restore to a date you are confident your site was clean.
 * Alternatively, you can follow Wordfence’s own instructions on [how to clean a hacked website](https://www.wordfence.com/docs/how-to-clean-a-hacked-wordpress-site-using-wordfence/).
   Wordfence has a great KB with many other articles that may help you, just open
   this page and follow other links.
 * After the restore/clean-up is done:
 * 6) Go to your WordPress Dashboard
    a) change your password b) remove any admin
   accounts other than your own. If you need to have more than one admin account,
   with multiple people having access as admin, change their roles temporarily to
   subscriber. Remember, this is a crisis! Then ask them to go through the extensions/
   addons/passwords clean up suggested here before you grant them access as admin
   again. c) change the cryptographic “salts” on wp-config.php. There are many resources
   on the web that teach you how to do it. But be careful, as this is an operation
   that may render you site inaccessible. One blog that [explains how to do it is this](https://www.wpmyweb.com/wordpress/change-wordpress-security-salt-keys.html)(
   there are others available, just google it) This is very important, because after
   you change your passwords, a hacker may still have access to your admin area 
   until you change the salts. If you don’t know, just ask someone you trust for
   help. d) update WordPress e) update your theme f) update all your plugins to 
   their latest version NOTE: in case your theme and/or plugins come from a repository
   other than wordpress.org, you should take the opportunity to also change your
   password and enable 2FA if available in your repository service, such as themeforest
   etc.
 * 7-a) If these changes apparently solves your problem, DON’T FORGET to make your
   website available again. Re-scan you site using Wordfence.
 * 7-b) If these changes do not solve your problem, or if the hack comes back after
   a few hours/days/weeks, consider paying a reputable web security firm to do the
   website cleaning for you ([Wordfence offers this service](https://www.wordfence.com/wordfence-site-cleanings/),
   and so do some of its competitors)
 * I wish you good luck!
 *  [wfasa](https://wordpress.org/support/users/wfasa/)
 * (@wfasa)
 * [7 years, 7 months ago](https://wordpress.org/support/topic/potentially-vulnerable-code/#post-10733176)
 * Hi [@tflora](https://wordpress.org/support/users/tflora/)!
 * It’s not super common that malware would insert itself using auto_prepend_file
   but it’s certainly possible. My recommendations are
 * 1. Firstly, reach out to your web host and inquire about this. Make sure they’re
   not the ones who have implemented this on your system. If they are, you need 
   to inquire about them how you can utilize the auto_prepend_file PHP value to 
   include both the gd.php file and the wordfence-waf.php file. The latter is the
   Wordfence Firewall bootstrapper which makes the Wordfence Firewall load before
   any other PHP code loads on your site.
 * 2. If they have no idea what gd.php is you would at that point need to investigate
   the file manually and make a judgement call on whether it looks like malware 
   or if it’s something that could have been left behind for some other reason. 
   If it’s malware, you’ll need to proceed to clean and secure the site.
 * If you want me to look at the gd.php file I’d be happy to do so. Just download
   it using FTP/SSH or any file browser your web host provides and email it as an
   attachment to [asa@wordfence.com](https://wordpress.org/support/topic/potentially-vulnerable-code/asa@wordfence.com?output_format=md).
   Make sure you include your forum username so I know who the email is coming from.
 * Thank you!
 *  [wfasa](https://wordpress.org/support/users/wfasa/)
 * (@wfasa)
 * [7 years, 7 months ago](https://wordpress.org/support/topic/potentially-vulnerable-code/#post-10786030)
 * Hi [@tflora](https://wordpress.org/support/users/tflora/),
    Since we haven’t 
   heard from you for a while I’m going to go ahead and resolve this thread for 
   now. If you have any other questions or concerns at any point, feel free to start
   a new thread. Thank you!

Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘Potentially vulnerable code’ is closed to new replies.

 * ![](https://ps.w.org/wordfence/assets/icon.svg?rev=2070865)
 * [Wordfence Security - Firewall, Malware Scan, and Login Security](https://wordpress.org/plugins/wordfence/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/wordfence/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/wordfence/)
 * [Active Topics](https://wordpress.org/support/plugin/wordfence/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/wordfence/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/wordfence/reviews/)

 * 4 replies
 * 3 participants
 * Last reply from: [wfasa](https://wordpress.org/support/users/wfasa/)
 * Last activity: [7 years, 7 months ago](https://wordpress.org/support/topic/potentially-vulnerable-code/#post-10786030)
 * Status: resolved