Support » Plugin: Cloudflare » v3 is inherently insecure

  • CloudFlare currently issues a single API for an account – which provides full access to manage the account – it’s the equivalent of having the account password.

    Assuming this plugin was deployed and configured on 10 sites, it would only take one of them to be compromised for the CloudFlare account to also be compromised (which could contain 100’s of domains). Given the history of vulnerabilities in WP, themes and plugins – this is pretty much inevitable.

    Following discovery of compromise in a single WP install utilising the v3 plugin, the CloudFlare master API key would need to be reset. Then all other WP sites that have the CloudFlare plugin configured would need updating with the new key.

    A much better approach is deployed by Yoast and their OAuth 2.0 process which allocates to permission for a single domain.

    This could be fixed by CloudFlare in several ways:
    1. Having individual API keys per domain – these API keys can only modify the settings for a single domain
    2. Creating a special process for authorizing the WP plugin to manage the domain for the account it is installed on. The API key (or login) could be used for initial setup, a secret key would be generated to make all further requests but only worked for that domain (scoped requests)

Viewing 9 replies - 1 through 9 (of 9 total)
  • Just curious — do you think the same security concern applies to the v.1.3.x plugin?

    Thread Starter Turn On Social


    It does although previously the plugin allowed configuration of settings without utilising an API key (on v3 the first screen presented forces the user to)

    Hi @turn-on-social,

    While I agree that OAuth 2.0 would be more secure than our current approach I disagree that the plugin is vulnerable. The threat scenario you describe depends on the blog itself being compromised, the security of which is completely separate from that of our plugin.

    If you have a proof of concept for vulnerability in our WordPress plugin we would love if you reported it here:


    Thread Starter Turn On Social


    Fair enough.

    Asking customers to put their global API key in plain text on multiple WP sites seems like a substantial security risk. Much better to isolate it in some way with domain specific API keys for example.

    Just following good security principles.

    HI @jwineman

    Isn’t that a bit like saying if you leave your debit card pin number written on a piece of paper in your wallet locked in a car, then the security of the car is the only issue?

    I would argue that in the instance that the car was broken into it would definitely be your own fault if you left your pin number written down with your bank card.

    Thread Starter Turn On Social


    Good analogy @zandercent!

    In that case, a copy of that pin would be locked in your car, your house, your office and your briefcase. If any one of them were ever opened, this would reveal the pin providing access your bank.

    Not only that, the person who finds the pin would also get access to all the other bank accounts you own – since a master key opens access to all your CloudFlare domains without exception.

    My point is this – if someone hacks your blog then they don’t need your CloudFlare API key, they already have access to your entire site and can do whatever they want.

    No matter what authentication scheme you use you still have to store a secret (API Key, Oauth Token) some where. There is no way to store that secret in a way that isn’t accessible to an attacker who is able to gain root access to your blog.

    Scoped keys don’t fix the vulnerability described above, they just limit the damage. In either case if an attacker hacks your blog they get access to a key that lets them manipulate your domain and in each case the solution is to revoke that key. I say this to point out that OAuth 2.0 is “vulnerable” to the scenario outlined above as well, just to a lesser degree.

    Its important to distinguish between “insecure” (read: vulnerable) and security best practices. In this case the plugin is secure, but could be made more secure by using API keys with more specific scope.


    Hey there,

    I’m part of the security team at CloudFlare and have reviewed the WordPress plugin in the past.

    I totally agree that being able to properly scope API keys to a limited set of functionalities and zones would be a huge improvement. In fact, it is something I have been actively working on for a while now (not just for our CMS integrations, but for the entire cloudflare platform).

    Saying that the application is “inherently insecure” is just not accurate. John hit the nail on the head with a couple of his points. This is not a security vulnerability, but we all agree that it is not consistent with what best practices would dictate. We are always working to improve and provide mature security solutions and this is something we already started working to make better.


    Yeah – just o be clear, I don’t really have much of an opinion on it either way, I just thought the reasoning was a bit off.

    It is true though, one hacked site potentially exposes the key to all of them, no? I kind of consider Cloudflare to be a security company, so best practice not being adhered to is surprising… but I’m certainly not annoyed or anything, just getting involved!!

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘v3 is inherently insecure’ is closed to new replies.