• The plugin’s replacement for robot.txt is in /models/Rewrite.php:2886 in replaceRobots().

    replaceRobots() first requests the isContentHeader() method at /classes/Tools.php:1091 to make a request header determination. It determines whether the currently loaded file has a “Content-Type” and whether its value contains a “text/plain” field, to identify whether it is currently robots.txt.

    However, the plugin developers ignore the possibility of having “Content-Type” in the request header along with “x-content-type-options”.

    If “x-content-type-options” is returned before “Content-Type” when headers_list() gets the request headers and returns the array, then return false in /classes/Tools.php:1107 will terminate and return false when it detects that “x-content -type-options” does not exist in “text/plain”, it will simply terminate and return false, and will not judge the “Content-Type” afterwards.

    Thus isContentHeader() will also return false when there is actually a “Content-Type” field and the value is “text/plain”. eventually the robots.txt replacement will fail

    Workaround: please remove return false in /classes/Tools.php:1107

    • This topic was modified 2 years, 3 months ago by container.
Viewing 1 replies (of 1 total)
  • Plugin Author John Darrel

    (@johndarrel)

    Hi,

    Thank you for the feedback.

    This isn’t a plugin vulnerability but we took your advice and added an extra verification of the XML and TXT files for both Sitemaps and Robots based on REQUEST_URI.

    Please download the last version of the plugin, replace the current version and check again.

    If everything works correctly, please update the review score and if you need any help with the plugin, you can open a support ticket.

    Best regards,
    John

Viewing 1 replies (of 1 total)
  • The topic ‘There is a vulnerability in the processing of robote.txt in this plugin, please’ is closed to new replies.