I had an interesting conversation with a pentester who told me he had found a buffer overflow in Wordpress. The person in question was really adamant that this was true. The client is a bit skeptical about the technical skills of the pentesting firm and asked my opinion.

So the question I have is this: has anyone ever heard that someone found a buffer overflow in WordPress by just making a GET request to some PHP?

My opinion: If this were true, he would have found a buffer overflow in the PHP interpreter, and that would be huge. So I do not think it is true.

EDIT: The BOF was in two places:

  • In a php function build by the client with the same payload as an XSS vulnerability (so something like 123">alert(0);

  • In the wp_session token with just a bunch of A's (~60)

It was all done externally with no access on the server in a routine quick pentest of around 10 different websites...

I'll update after doing an actual code review over the parts that should be vulnerable

EDIT: So I did the code review and it was indeed a BS story. Not only did the BOF's not exist at all, he actually said to have found a SQLi in a part of the code that did absolutely nothing with a database.

But at least the discussion in the comments was very insightfull about possibilities of BOF's these kind of standard platforms and CMS's so I learned a lot! Thanks!

  • 2
    This question needs more details. "a buffer overflow in Wordpress" can be anything and nothing. Be more specific please.
    – Tom K.
    Commented Feb 8, 2018 at 12:16
  • 7
    My 2 pence: it sounds like the overflow is from their derrière more than anything.
    – Polynomial
    Commented Feb 8, 2018 at 13:18
  • 5
    What would "found" mean? He ran an automated pen test on a box, it turned out be be vulnerable to the GHOST vulnerability (rapid7.com/db/modules/auxiliary/scanner/http/…)? The vulnerability is definitely not "in" Wordpress (it's not even in php, but in glibc), but it is exposed by Wordpress's xmlrpc interface. It does not mean he discovered the flaw, just script-kiddied-it.
    – jcaron
    Commented Feb 8, 2018 at 15:19
  • 24
    I'm not sure why it would be "huge" to find a flaw in PHP. It seems to be pretty routine.
    – JimmyJames
    Commented Feb 8, 2018 at 15:41
  • 1
    He might actually not have meant a buffer overflow, but I do recall there being a DOS vulenrability found on worpress not long ago: cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6389 . There might have been a misunderstanding on the terms "buffer overflow"
    – everyone
    Commented Feb 8, 2018 at 16:15

5 Answers 5


As PHP does memory management and a lot of stuff by itself, finding a buffer overflow specifically in WordPress doesn't really make sense to me.

Before discrediting that Penetration Tester, I'd ask him/her for documentation of the finding in question. As he/she works for said client (sounds like it, correct me if I'm wrong), it's his/her job to report such an issue to the client, including a documentation of at least a way to track down/reproduce the issue.

I'm very sceptical, as you say, that he/she only had access to the webservice from the outside. Verifying a low-level issue like a buffer overflow (which is even way beyond the webservice or wordpress in general) is next to impossible from the outside.

Executing one is tricky, even if you have access to the source code, which doesn't seem to be the case (assuming it's not a whitebox test).

P.S.: If you get an answer from the client/pentester, I'd love to hear it. You got me pretty curious for some reason...

  • 2
    On topic: Good advice. It sounds like nonsense to me, and I'd want clarification of where and how they found it. To say they found it in Wordpress sounds specific to that particular application, and that seems like bull to me.
    – Polynomial
    Commented Feb 8, 2018 at 13:17
  • I can't find evidence for "as you say, that he/she only had access to the webservice from the outside". Where is that in the question? Commented Feb 8, 2018 at 14:00
  • 2
    @ThomasWeller the question says "has anyone ever heard that someone found a buffer overflow in WordPress by just making a GET request to some PHP?", meaning the attack is at least made from the outside.
    – Jon
    Commented Feb 8, 2018 at 18:00
  • 1
    Thanks for the reply. I wasn't to forward with details :P. He found it externally with just a GET request using netcat and got a memory dump in his reply. That was all he wanted to share and more or less accused me of being not technical enough to understand it... Next up will be a source code review I'll be conducting for free because I now need to know :P
    – Wealot
    Commented Feb 9, 2018 at 10:28

It could be that he found a buffer overflow in PHP or glibc which can be exploited via Wordpress. For example, 3 years ago there was a hole in gethostbyname() which could be exploited via Wordpress. It is called the GHOST vulnerability.

If you have a very old OS without updates as well as a very old Wordpress that could be true.


As GxTruth mentioned, PHP does memory management. This means anything running on php is basically as secure against buffer overflows as php is (unless you're doing something really crazy).

But php isn't 100% safe from buffer overflows: https://stackoverflow.com/questions/11817576/is-php-buffer-overflow-possible

If this pentester has actually found a buffer overflow, they should be able to tell you exactly how to reproduce it. At that point you should be able to trace that into the code. It may be this is caused by a previously patched version of WP/PHP. Always make sure you are up to date on the latest patches across your whole tech stack.

If it turns this is a bug in the most recent versions, then collect the relevant information and file the appropriate bug reports. You can notify the people who develop php here: http://bugs.php.net/. Make sure to mark your bug as security related. It would also be relevant to read this first: https://wiki.php.net/security. Also, report this to WordPress or any developers of third-party plugins/themes that are affected so they can take steps to mitigate the issue while PHP itself is patched.

And if this is a problem, as curious as we may be to hear what it is, do not report on this publicly until the maintainers of the affected code have a chance to fix it as this will affect many sites across the web and not just yours.


It's probably one of those four:

  • He might not know the proper name, and call something like hashdos a "buffer overflow" because it fills the array to such an extent that it becomes unresponsive or crashes.
  • He might have found a buffer overflow in PHP and, for layman's terms, call it "in Wordpress" because people might not know they run PHP under the hood and only know it as Wordpress.
  • He might have found a buffer overflow for PHP to be exploitable through Wordpress.
  • He might have no clue what he's talking about.

I'd say the latter is by far the most likely.


It is possible he found a buffer overflow in the web server (e.g. Apache HTTPD) itself, instead of in php or your application. For example, https://www.cvedetails.com/cve/CVE-1999-0071/ "Apache httpd cookie buffer overflow for versions 1.1.1 and earlier. ", this CVE crash the apache child instance in case the server uses mod_cookie to modify a cookie in HTTP response. As I remember, if attacker put a long string in the relevant cookie value, it caused the crash.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .