Attention : support for WAPT 1.8.2 ended on June the 30th 2022.

There are known vulnerabilities in WAPT dependencies in WAPT 1.8.2 branch. Please upgrade to the latest supported version. CVE listing (non exhaustive) :
  • * python engine : python 2.7 (CVE-2020-10735, CVE-2015-20107, CVE-2022-0391, CVE-2021-23336, CVE-2021-3177, CVE-2020-27619, CVE-2020-26116, CVE-2019-20907, CVE-2020-8492, etc.)
  • * cryptography : openssl : CVE-2022-2068, CVE-2022-1292, CVE-2022-0778, CVE-2021-4160, CVE-2021-3712, CVE-2021-23841, CVE-2021-23840, CVE-2021-23839, CVE-2020-1971, CVE-2020-1968, CVE-2019-1551
  • * python dependencies : cryptography (CVE-2020-36242, CVE-2020-25659), eventlet (CVE-2021-21419), jinja2 (CVE-2020-28493), psutil (CVE-2019-18874), waitress (CVE-2022-31015), lxml (CVE-2021-4381, CVE-2021-28957, CVE-2020-27783, CVE-2018-19787), ujson (CVE-2022-31117, CVE-2022-31116, CVE-2021-45958), python-ldap (CVE-2021-46823)

Changes between versions 1.3 and 1.6 and consequences

PostgreSQL has replaced MongoDB in WAPT

The database MongoDB has been replaced by PostgreSQL with JSON support.

The consequence is that Administrators that have developed reports based on MongoDB will have to adapt their queries.

Nginx is now the only supported web server in WAPT

Introducing Websockets in WAPT brings large benefits:

  • status updates from WAPT agents are instantaneous in the WAPT console;

  • when the Administrator launches immediate actions, it is no longer the WAPT Server that connects to the WAPT agent; the WAPT agent establishes and maintains a permanent connection with the WAPT Server;

  • the Websockets avoid having to have a local listening port on the clients, improving the global security of WAPT equipped Organizations;

  • since it is the WAPT agent that initiates and maintains a connection with the WAPT Server, connections travel through proxies and firewalls in a standard manner;

Nginx is the only web server capable of handling a very large quantity of Websockets. This technology is not something completely trivial to implement and maintain.

As a consequence, support for IIS and Apache in WAPT is abandoned.

Signature hashes are sha256 instead of sha1

Control sums for the list of files in the WAPT package and the signature of the attributes in the control file are now sha256 hashed instead of sha1 hashed to satisfy security requirements of cyberdefense agencies.

As a consequence, all packages must be re-signed and the :file:`Packages` index files of all repositories must be regenerated.

A script allows to massively re-sign all packages on the WAPT Server.

The host packages are now named after the UUID of the host

In versions <= 1.3.xx, host packages are named with the FQDN of the client host.

This poses some problems if the host is joined to another domain, or if the host is not joined to a domain, yet goes from a network to another with different DHCP settings.

In version >= 1.5, the host packages are named after the UUID of the client host, thus resolving the problems described above.

As a consequence, host packages must be re-created and re-signed.

A script on the WAPT Server allows to do this operation automatically.

Code Signing attribute for signing base packages

To differentiate between the roles of Package Deployer and Package Developer, the WAPT agent verifies the Code Signing attribute of the certificate that has signed the package.

If the package contains python executable code, i.e. a setup.py file, then the package must be signed with a certificate having the Code Signing attribute. Otherwise, the package will not install.

As a consequence, it is necessary to generate and deploy a Code Signing Certificate on the WAPT equipped hosts, and re-sign base packages (i.e. software packages) with a Code Signing certificate.

The certificate is deployed during the upgrade of the WAPT agent.