Affected versions: php 5.1.4 and older, 4.4.3 and possibly older Cause: when php-s sscanf functions format argument contains argument swap and extra arguments are given like. sscanf('foo ','$1s',$bar) then it reads an pointer to pointer to zval structure past the end of argument array by one. Php developers were notified and response and patching was quick. php bug tracker thread here: http://bugs.php.net/bug.php?id=38322 Vulnearability is fixed in CVS. Exploiting: Attacker needs a double pointer to writable segment in remote binary which can be obtained by compiling a binary based on all info known about remote host and disassembling binary and searching. This exploit first fills php internally cached memory with address of pointer (double pointer) to writable segment. Then by unsetting the variable it frees memory, but does not zero it, so this way we pass our own pointers to sscanf. Now sscanf allocated array has valid element one past the array, sscanf tries to call a function to destruct zval structure. if its 15-th byte isnt anything valid it will default to doing nothing and will continue without errors and returns; sscanf now sets the structure to be of type string and writes pointer to string (it matched from our first argument to sscanf) and strings length to a structure-s value union. the strings address is written to first 4 bytes of structure. knowing this we construct our own binary zval structure of type object. + shellcode + space to match format. So now we have successfully called sscanf for the first time and we got something like ptrptr->ptr->zval-of-type-string in memory zval-of-type-string first 4 bytes point to our object we passed as argument. so now we fill the internal cached memory with just pointer to zval. and free it. when sscanf reads the pointer this time it now moves upwards one level but still dereferences twice. thus acts upon our zval structure of type object. when the destructor function now sees the zval is an object it will read a pointer from our structure to another structure which supposed to contain function pointers. it will call whatever the 2-cond element points to. all elements are 4 bytes long thus address pointed to by structures offset 4 is called. when we give it our ptr-to-zval - 4 it will add 4 bytes to it and dereference it an call whatever is there. and there is address to our constructed zval object so we are executing code from the beginning of our structure. eip-hop-over will help us through unwanted bytes and we are on our way executing our shellcode.