pyfiscan fingerprints the web apps on your server and tells you what is stale

It reads the filesystem, it does not probe the network

The About section describes pyfiscan as a free web-application vulnerability and version scanner that can be used to locate out-dated versions of common web-applications in Linux servers, and the example use case is hosting providers keeping eye on their users' installations to keep up with security-updates. What it actually does is read files on the machine where it runs, which is the point worth understanding before you deploy it. The requirements state Python 3, the Python modules PyYAML, docopt and chardet, and a GNU/Linux web server, and testing is done mainly with GNU/Linux Debian stable, with Windows not currently supported. So the picture is a script that walks a known set of installation paths, recognises the product and version from what it finds there, and reports what it sees. That is a different job from a network scanner that probes ports and banners, and it has a different privilege profile, since it is reading local files that a web server user can usually read anyway.

Fingerprints are YAML, and you are expected to write them

The design decision that makes the tool extensible is that fingerprints are easy to create and modify as the user can write those in YAML-syntax. The repository layout confirms the mechanism, with a yamls/ directory holding the fingerprint definitions and a templates/ directory for the alert templates, alongside the Python modules. The top level is a small script collection, with pyfiscan.py as the entry point, detect.py for the detection logic, database.py, file_helpers.py, issuereport.py and mailer.py, plus requirements.lst, a roadmap.txt and a testfiles/ directory with fixtures and a tests.py. Splitting detection from the reporting is what makes the YAML approach work, because the fingerprint is data and the code that consumes it does not change when you add a product. The templates/ directory is the same idea applied to email, since the alert body is a template rather than a string in the code, and the mailer.py module is what renders and sends it.

Around seventy products, and the end-of-life list is longer

The detection list covers more than eighty products, and the shape of it is telling. It is almost entirely PHP and Perl era web applications: Abantecart, ATutor, b2evolution, BigTree CMS, Bugzilla, Centreon, Claroline, ClipperCMS, CMSimple, CMSimple_XH, CMSMS, Collabtive, Concrete5, Coppermine, Cotonti, Croogo, CubeCart, Dolibarr, Dotclear, Drupal, e107, Elefant CMS, EspoCRM, Etherpad, flatCore CMS, FluxBB, Foswiki, FUEL CMS, Gallery, Gollum, HelpDEZk, HumHub, ImpressCMS, ImpressPages, Jamroom, Joomla, Kanboard, KCFinder, LiteCart, Magnolia, Mahara, MantisBT, MediaWiki, Microweber, MiniBB, MODX Revolution, MoinMoin, MyBB, Nibbleblog, Open Source Social Network, OpenCart, osDate, ownCloud, Oxwall, PBBoard, phpBB3, PhpGedView, phpLiteAdmin, phpMyAdmin, Piwigo, Piwik, PmWiki, Postfix Admin, Redaxo, Redmine, Roundcube, SaurusCMS, Serendipity, Shaarli, Shopware, SMF, Spina CMS, SPIP, SQLiteManager, SquirrelMail, TestLink, TikiWiki, Trac, Vanilla Forums, WikkaWiki, WordPress, Zenario, Zenphoto and Zikula. One entry carries an opinion, OpenCart with the note that it recommends not to use this software. The second list is the more valuable one for a hosting provider, because it names specific end-of-life versions with the dates they went out of support.

End-of-life detection is where the list gets long

There is a separate section for software that is end-of-life, and it is dated rather than vague. Bugzilla 4.2 has been end-of-life since 2015-11-30, Drupal 6 since 2016-02-24, Gallery 1, and the Joomla line with 1.5 since 2012-04-30, 1.6 since 2011-08-19 and 1.7 since 2012-02-24, plus 2.5 with no date given. The MediaWiki entries run from 1.18 to 1.37, with dates for most, 1.26 since 2016-11-20, 1.27 since 2019-06-06, 1.28 since 2017-11-01, 1.29 since 2018-06, 1.30 since 2019-06-06, 1.31 since 2021-09-30, 1.32 since 2020-01-23, 1.33 since 2020-06-24, 1.34 since 2020-11-30, 1.36 since 2022-06-03 and 1.37 since 2022-11-30. There is also SaurusCMS and a run of ownCloud versions from 4 through 8.2. For a provider with thousands of hosted sites, this is the payload of the tool, since an out-of-support version is a security problem that no amount of patching will fix.

Installation is a virtualenv and a requirements file

The installation section is a short sequence of commands on a Debian style system:

sudo apt install python3 python3-pip git virtualenv
git clone https://github.com/fgeek/pyfiscan.git && cd pyfiscan
virtualenv -p python3 venv
source ./venv/bin/activate
pip3 install -r requirements.lst

The virtualenv step is not decoration, because a scanner that runs on a schedule against a hosting platform is exactly the kind of thing you do not want to pollute the system Python with, and because the requirements list includes docopt and chardet alongside PyYAML, none of which belong on a shared server. There is also a BlackArch Linux package, which is where a tool like this tends to get its first users, since that distribution packages a large set of security utilities. The README does not document a scheduler configuration, so if you intend to run this periodically you are wiring that yourself, and the email alerting is the part that makes a periodic run useful rather than noisy, since a report nobody reads is the same as no report.

The notes explain what a false positive looks like

The Notes section is short but it is the section that tells you how to read the output, and most of it is about installations that look like vulnerabilities but are not. For Gallery, the note is that it is not installed when config.php is missing. For Coppermine, it is not installed when include/config.inc.php is missing. For Piwigo, not installed if local/config/database.inc.php is missing. For Claroline, not installed when platform/conf/claro_main.conf.php is missing, and the installation pages request that the user remove the claroline/install/ directory. For phpBB with an unknown version, the open installation is not a vulnerability since the web interface asks the user to authenticate by inserting random data into a file. The ownCloud note gives the exact status output to match, and the Joomla notes cover the random SQL table prefix in 2.x, the removal button in 3.x, the configuration.php file created during installation, and a robots.txt containing the word Joomla. Those are the details that stop a scanner from crying wolf on a fresh install.

Editorial conclusion

Adopt pyfiscan when you administer a server hosting several web applications and want a scheduled check for installations that have fallen out of support, and you are comfortable writing a YAML fingerprint when a product is not covered. Do not adopt it as a network vulnerability scanner, because it inspects files on the machine it runs on rather than probing remote services. Verify first which of the listed products your estate actually runs, that your Python and module requirements are present, and that the fingerprint you write matches how the product is installed on your system, since a wrong path means a silent miss rather than an error.

Frequently asked questions

Official sources

1. fgeek/pyfiscan on GitHub
2. Issues
3. README