Title: WP CLI being blocked with http code 418
Last modified: May 19, 2021

---

# WP CLI being blocked with http code 418

 *  [danielbair](https://wordpress.org/support/users/danielbair/)
 * (@danielbair)
 * [5 years ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/)
 * When trying to update plugins or themes via WP CLI I am now getting this…
    Fetching
   pre-update site response… -> HTTP status code: 418 -> I’m a little teapot. Warning:
   Failed pre-update status code check (HTTP code 418).
 * wp cli core us up-to-date on my server when I checked.
 * I have checked the error logs on my server, and I don’t see any HTTP code 418
   being thrown, so where is this coming from?
 * I have no problem updating plugins and themes via InfiniteWP though.
 * The page I need help with: _[[log in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fwordpress.org%2Fsupport%2Ftopic%2Fwp-cli-being-blocked-with-http-code-418%2F%3Foutput_format%3Dmd&locale=en_US)
   to see the link]_

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

 *  [Matthew](https://wordpress.org/support/users/atxmatt/)
 * (@atxmatt)
 * [5 years ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-14464289)
 * Hey there, this is the first time I, myself, have ever seen a `418` but it looks
   like this HTTP status code is an April Fools joke.
 * [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418)
 * I don’t think this has anything to do with the iThemes Security plugin.
 * I’d initially want to know the results of appending `--skip-plugins` `--skip-
   themes` to the wp-cli command.
 * Regardless of the results, I would suggest parsing the entire site file system
   for any references of `418` (well, maybe not the ENTIRE site at first but maybe
   start with `wp-content` and then work your way into the rest).
 * Tailing some logs and replicating the issue may help provide some answers. As
   I first mentioned, this is the first time I’ve seen someone use this `418` status
   code so I’m not entirely sure what you should be keeping an eye out for.
 * Hope this helps lead you to some answers.
 *  Thread Starter [danielbair](https://wordpress.org/support/users/danielbair/)
 * (@danielbair)
 * [5 years ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-14474442)
 * The skip-plugins and skip-themes doesn’t help when I am trying to update plugins
   and themes.
 * Here is an example from one of my many sites (all are running iThemes security).
 *     ```
       wp plugin install jetpack --force --skip-plugins --skip-themes
       Installing Jetpack ? WP Security, Backup, Speed, & Growth (9.7)
       Fetching pre-update site response...
        -> HTTP status code: 418
        -> I'm a little teapot.
       Warning: Failed pre-update status code check (HTTP code 418).
       Error: No plugins installed.
       ```
   
 * Again I don’t get this problem when I attempt to update with InfiniteWP.
 *  Thread Starter [danielbair](https://wordpress.org/support/users/danielbair/)
 * (@danielbair)
 * [5 years ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-14474469)
 * The mozilla developer article also says this:
    “Some websites use this response
   for requests they do not wish to handle, such as automated queries.”
 * Also, the 418 exception seems to be in the WP core files…
    “wp-includes/Requests/
   Exception/HTTP/418.php: * Exception for 418 I’m A Teapot responses”
 *  Thread Starter [danielbair](https://wordpress.org/support/users/danielbair/)
 * (@danielbair)
 * [5 years ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-14478215)
 * Ok, I setup a test wp install and was able to discover that this problem only
   exists when the better-wp-security plugin is installed. I am able to use a local
   wp-cli workaround with update-verity disabled for now.
 * This may be an issue with DreamHost and mod_security that better-wp-security 
   is triggering, but there are no 418 error codes in the logs.
 *  Thread Starter [danielbair](https://wordpress.org/support/users/danielbair/)
 * (@danielbair)
 * [5 years ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-14478640)
 * See…
    [https://wordpress.stackexchange.com/questions/103089/why-better-wp-security-plugin-returns-418-im-a-teapot-error](https://wordpress.stackexchange.com/questions/103089/why-better-wp-security-plugin-returns-418-im-a-teapot-error)
 *  [nlpro](https://wordpress.org/support/users/nlpro/)
 * (@nlpro)
 * [5 years ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-14479091)
 * The provided link points to an outdated post (almost 8 years old) and therefor
   it is about plugin code that no longer exists …
 * I’ve done an automated search for 418 in the current plugin code but it doesn’t
   exist.
 * You could try and temporarily disable all plugin modules by adding the line below
   to the wp-config.php file (not sure whether this actually also affects WP CLI):
 * `define('ITSEC_DISABLE_MODULES', true);`
 * Another option is to disable any setting that writes to the .htaccess or nginx.
   conf file. Most of these settings are found in the **WordPress and System Tweaks**
   modules. Basically make sure the iTSec plugin does not add anything to these 
   web config files. Easiest way to do this is to temporarily disable the **Write
   to Files** setting in the **Global Settings** module.
 * +++++ To prevent any confusion, I’m not iThemes +++++
 *  [Matthew](https://wordpress.org/support/users/atxmatt/)
 * (@atxmatt)
 * [5 years ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-14481350)
 * [@danielbair](https://wordpress.org/support/users/danielbair/) I use both free
   and paid versions of iThemes Security. Manage a VPS and WordPress via WPcli/SSH
   and other means and have never run into a `418`.
 * I feel you are looking in the wrong place to diagnose/troubleshoot this issue
   but to echo, I would suggest following the above, [@nlpro](https://wordpress.org/support/users/nlpro/)
   comment, to see if that helps.
 * If you haven’t already, contact the hosting provider support for additional help
   on this.
 *  Moderator [Ipstenu (Mika Epstein)](https://wordpress.org/support/users/ipstenu/)
 * (@ipstenu)
 * 🏳️‍🌈 Advisor and Activist
 * [5 years ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-14483017)
 * A 418 is 100% a DreamHost thing. We use it for a number of things, but basically
   it’s our way to know weird stuff is happening. We incorporated it into our pre-
   flight check so that before we try to update someone’s site, we know for sure
   that it’s up, it’s working, and it’s WodPress.
 * The 418 there means it cannot successfully CURL your site to get headers etc.
 * But… if this is always happening when iThemes is active, it means that something
   iThemes is doing is blocking that CURL check, and preventing the command from
   seeing your site.
 * It very much could be a combo of this plugin (or rather a specific setting in
   this plugin) that is causing the error and, since DreamHost makes use of the 
   teapot, it’s only showing up here.
 * Are there any options in iThemes that would block a call like this:
 *     ```
       // parse URL.
       		$parsed_url = wp_parse_url( $url );
   
       		$timeout = 10;
       		$ch = curl_init();
       		curl_setopt( $ch, CURLOPT_URL, $url );
       		if ( false !== $ip ) {
       			curl_setopt( $ch, CURLOPT_RESOLVE, array( $ip ) );
       			curl_setopt(
       				$ch,
       				CURLOPT_RESOLVE,
       				array(
       					'www.' . $parsed_url['host'] . ':443:' . $ip,
       					$parsed_url['host'] . ':443:' . $ip,
       					'www.' . $parsed_url['host'] . ':80:' . $ip,
       					$parsed_url['host'] . ':80:' . $ip,
       				)
       			);
       		}
       		curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );
       		curl_setopt( $ch, CURLOPT_TIMEOUT, $timeout );
       		$http_respond = curl_exec( $ch );
       		$http_respond = trim( strip_tags( $http_respond ) );
       		$http_code    = curl_getinfo( $ch, CURLINFO_RESPONSE_CODE );
       		if ( in_array( $http_code, array( '200', '302' ) ) ) {
       			return true;
       		} else {
       			return false;
       		}
       		curl_close( $ch );
       ```
   
 * And yeah, I know straight up curl is bad and I’d rather use wp_remote_get, but
   weirdly we needed it to be able to run when that won’t, thanks to some services.
 * `$ip` is passed from the command as the IP of the server, so it’s just asking
   itself. This gets us around situations where someone has a firewall like Cloudflare
   that makes the lookups chancy.
 * `$url` is literally the domain – we just pass it around a lot.
 *  Thread Starter [danielbair](https://wordpress.org/support/users/danielbair/)
 * (@danielbair)
 * [5 years ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-14483054)
 * FYI, I setup a test WP install on my DreamHost server (they are aware of the 
   issue and have disabled update-verify package for now).
 * It was a clean basic WP default install. I then used wp-cli to force install 
   jetpack (without activating it) with no problems with update-verity. Then I used
   wp-cli to install better-wp-security and activate it with no problems. Then I
   tried to install force install jetpack again with wp-cli and then 418 is being
   thrown. This was true for attempts to install or update any other themes or plugins.
 * I did no setup for bettter-wp-security, only the default from activation.
 * I find it strange that there are no server logs for 418 on DreamHost. I have 
   some other websites on DreamHost and did find a couple of 418 in their error 
   logs, but not related to wp-cli or better-wp-security issues (blocked hack attempts).
 *  Moderator [Ipstenu (Mika Epstein)](https://wordpress.org/support/users/ipstenu/)
 * (@ipstenu)
 * 🏳️‍🌈 Advisor and Activist
 * [5 years ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-14486941)
 * Well that one isn’t a server log error, which I get is confusing.
 * This is curl failing which, if it was curl itself, there would absolutely be 
   an error log on the server. On the other hand, if better-wp-security is blocking
   curl from running (which is sounding more and more likely here…) then there’s
   no PHP or error log because WP is just saying “No curl for you!” which isn’t 
   an ‘error’ but a decision :/
 *  [Jon Brown](https://wordpress.org/support/users/jb510/)
 * (@jb510)
 * [4 years, 6 months ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-15083148)
 * FWIW – I’ve been trying to figure out random “Internal Errors” on a DH hosted
   site for months. Never happening to me, but client said it’d happen to people
   in their office at least one a day. I could never recreate it myself.
 * I thought it was being caused by iThemes Sec Pro or CloudFlare, but could never
   definitely figure it out… then today tracked I finally tracked it down to a 418
   error which lead me to this thread. TY [@ipstenu](https://wordpress.org/support/users/ipstenu/).
   I opened a support ticket with DH, hopeful can figure out a way to make them 
   stop.
 *  Moderator [Ipstenu (Mika Epstein)](https://wordpress.org/support/users/ipstenu/)
 * (@ipstenu)
 * 🏳️‍🌈 Advisor and Activist
 * [4 years, 6 months ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-15083346)
 * FWIW the code in CLI is literally **only** in CLI. It won’t impact you doing 
   regular site usage and really only comes into play when you, or something you’re
   using, is trying to hide the ‘source’. We do it to get around broken 3rd party
   DNS (among other neat tricks) so we can update you while (say) Cloudflare is 
   down. But again, only for command line.
 * If you’re seeing it on the front-end (wp-admin or the front-front) then it’s 
   still us (the 418) but unlikely to be this specific code.
 * My guess, since I never got a clear answer from iThemes, is that they’re doing
   something to help prevent a DDoS and it’s causing CLI to think you’re not … you.

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

The topic ‘WP CLI being blocked with http code 418’ is closed to new replies.

 * ![](https://ps.w.org/better-wp-security/assets/icon.svg?rev=3529351)
 * [Kadence Security – Password, Two Factor Authentication, and Brute Force Protection](https://wordpress.org/plugins/better-wp-security/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/better-wp-security/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/better-wp-security/)
 * [Active Topics](https://wordpress.org/support/plugin/better-wp-security/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/better-wp-security/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/better-wp-security/reviews/)

## Tags

 * [dreamhost](https://wordpress.org/support/topic-tag/dreamhost/)
 * [mod_security](https://wordpress.org/support/topic-tag/mod_security/)
 * [wp-cli](https://wordpress.org/support/topic-tag/wp-cli/)

 * 12 replies
 * 5 participants
 * Last reply from: [Ipstenu (Mika Epstein)](https://wordpress.org/support/users/ipstenu/)
 * Last activity: [4 years, 6 months ago](https://wordpress.org/support/topic/wp-cli-being-blocked-with-http-code-418/#post-15083346)
 * Status: not resolved