Keep the PHP vulnerabilities in the same PHP version

  • Resolved Groovyx9

    (@groovyx9)


    3 months, 3 weeks ago

    Right now, any php 7 version, including 7.4.33 , will be considered less safe than ANY PHP 8 version … It would maybe be easier to read if you keep the warnings about the vulns in the same php version line…

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Javier Casares

    (@javiercasares)

    Mmm… it should show you only the vulnerabilities applied to your main PHP version.

    If you have PHP 7.4.20, it should show you only the vulnerabilities for PHP 7.4.20+ to 7.4.33, but not show you PHP 8.x or PP 7.3.

    Where is showing that information (the description is from the CVE’s, so may be different from the actual versions)

    Thread Starter Groovyx9

    (@groovyx9)

    The excerpt focuses on latest versions which is normal. When I better checked the CVE’S, they also concerned php from 5.0.0 up to 8.1.29 for CVE-2024-4577 and from 7.3.27 up to 7.4.33 (included) for CVE-2024-5458, so I was wrong. Sorry.

    Vulnerability found
    xxxxxxx

    PHP vulnerabilities

    PHP running: 7.4.33

    PHP 7.4 <= 7.4.33 (unfixed)
    [+] CVE-2024-4577
    [en] In PHP versions 8.1.* before 8.1.29, 8.2.* before 8.2.20, 8.3.* before 8.3.8, when using Apache and PHP-CGI on Windows, if the system is set up to use certain code pages, Windows may use “Best-Fit” behavior to replace characters in command line given to Win32 API functions. PHP CGI module may misinterpret those characters as PHP options, which may allow a malicious user to pass options to PHP binary being run, and thus reveal the source code of scripts, run arbitrary PHP code on the server, etc.

    PHP 7.4 >= 7.4.15 – <= 7.4.33 (unfixed)
    [+] CVE-2024-5458
    [en] In PHP versions 8.1.* before 8.1.29, 8.2.* before 8.2.20, 8.3.* before 8.3.8, due to a code logic error, filtering functions such as filter_var when validating URLs (FILTER_VALIDATE_URL) for certain types of URLs the function will result in invalid user information (username + password part of URLs) being treated as valid user information. This may lead to the downstream code accepting invalid URLs as valid and parsing them incorrectly.

    Learn more about the WordPress Vulnerability Database API at WPVulnerability

    • This reply was modified 3 months, 3 weeks ago by Groovyx9.
    • This reply was modified 3 months, 3 weeks ago by Groovyx9.
    Plugin Author Javier Casares

    (@javiercasares)

    No problem. I had the same concern some days ago, just because the same. ??

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.

Tags