Update: see comments below.

Also, perhaps there is a vulnerability if you are using real_escape_string instead of mysql_real_escape_string? Not sure about this one.

Original answer, before knowing this was officially documented:

The use of function real_escape_string with substitution %s within an already quoted string '%s' looks highly suspect.

There could well be a vulnerability if

• if real_escape_string not designed correctly,
• or not used in accordance with its documentation. (mis-used, perhaps with extra quotes ' or something else)

I would highly recommend using a more standard method of solving SQLi in PHP. One that involves ? substitution is best. However there may be another sound encoding method available. Such methods usually add their own quotes internally, in which case adding quotes ' in your code would be unnecessary.

I did notice one other thing about that code. Where does PREFIX come from? If this is user-provided then you obviously have an SQLi vulnerability. On the other hand, if it is simply a hard-coded or well-sanitized value then you are OK with that one.

Update: see comments below regarding proper implementation.

Original answer, before knowing this was officially documented:

The use of function real_escape_string with substitution %s within an already quoted string '%s' looks highly suspect.

There could well be a vulnerability if

• if real_escape_string not designed correctly,
• or not used in accordance with its documentation. (mis-used, perhaps with extra quotes ' or something else)

I would highly recommend using a more standard method of solving SQLi in PHP. One that involves ? substitution is best. However there may be another sound encoding method available. Such methods usually add their own quotes internally, in which case adding quotes ' in your code would be unnecessary.

I did notice one other thing about that code. Where does PREFIX come from? If this is user-provided then you obviously have an SQLi vulnerability. On the other hand, if it is simply a hard-coded or well-sanitized value then you are OK with that one.

The use of function real_escape_string with substitution %s within an already quoted string '%s' looks highly suspect.

There could well be a vulnerability if

• if real_escape_string not designed correctly,
• or not used in accordance with its documentation. (mis-used, perhaps with extra quotes ' or something else)

I would highly recommend using a more standard method of solving SQLi in PHP. One that involves ? substitution is best. However there may be another sound encoding method available. Such methods usually add their own quotes internally, in which case adding quotes ' in your code would be unnecessary.

I did notice one other thing about that code. Where does PREFIX come from? If this is user-provided then you obviously have an SQLi vulnerability. On the other hand, if it is simply a hard-coded or well-sanitized value then you are OK with that one.

Update: see comments below.

Also, perhaps there is a vulnerability if you are using real_escape_string instead of mysql_real_escape_string? Not sure about this one.

Original answer, before knowing this was officially documented:

The use of function real_escape_string with substitution %s within an already quoted string '%s' looks highly suspect.

There could well be a vulnerability if

• if real_escape_string not designed correctly,
• or not used in accordance with its documentation. (mis-used, perhaps with extra quotes ' or something else)

I would highly recommend using a more standard method of solving SQLi in PHP. One that involves ? substitution is best. However there may be another sound encoding method available. Such methods usually add their own quotes internally, in which case adding quotes ' in your code would be unnecessary.

I did notice one other thing about that code. Where does PREFIX come from? If this is user-provided then you obviously have an SQLi vulnerability. On the other hand, if it is simply a hard-coded or well-sanitized value then you are OK with that one.