MySQL TLS is reported as unavailable on MySQL 8.4 and later

The check returns FAIL saying TLS is not available, on a server where TLS is configured and working. It reads `SHOW VARIABLES LIKE 'have_ssl'` and `have_openssl`. Both were deprecated in MySQL 8.0.26 and removed outright in MySQL 8.4.0, so the query comes back empty on any current MySQL and the check reads that as "no TLS". Check `SHOW VARIABLES LIKE 'tls_version'` instead - a non-empty value means TLS is available - or `SELECT @@ssl_cert`. MariaDB still exposes `have_ssl`, so the old query is only wrong on MySQL.

Docker Content Trust is still rewarded after Docker retired it

The check awards PASS for `DOCKER_CONTENT_TRUST=1`, and treats a host using Sigstore cosign as unsigned. Docker announced the retirement of Docker Content Trust and the notary.docker.io service in July 2025, with full retirement in June 2026. Setting that variable now breaks pulls of Docker Official Images rather than securing them. Verify signatures with Sigstore cosign or Notation. A PASS on this check is not evidence that your images are signed, and following its advice will break your pulls.

OCSP stapling is recommended for certificates that have no OCSP responder

The check warns that stapling is off, and turning it on changes nothing except an nginx warning in the error log. Let's Encrypt stopped including OCSP URLs in its certificates on 7 May 2025 and switched off its OCSP responders on 6 August 2025. With no responder URL in the certificate, `ssl_stapling on` is inert and nginx logs "ssl_stapling ignored, no OCSP responder URL in the certificate". Inspect the certificate for an OCSP URL first (`openssl x509 -noout -ocsp_uri -in cert.pem`). If it is empty, stapling is not applicable and the warning can be ignored. Certificates from CAs that still run responders are unaffected.

The end-of-life version lists are incomplete

A runtime or base image that is past end of life passes the check. Both checks compare against a version list hardcoded when the script was written, rather than querying a source that tracks end-of-life dates. As of August 2026 the following are also past end of life and are not flagged: PHP 8.1, Node.js 18 and 20, MySQL 5.7 and 8.0 (EOL 30 April 2026), PostgreSQL 12 and 13, MongoDB 5.0 and 6.0, Redis 6.x and 7.0/7.2, Ubuntu 20.04 standard support, Debian 10, Alpine 3.13 to 3.20, and Python 3.7 to 3.9. Check your own versions against endoflife.date rather than trusting a PASS here.

Per-container log limits are not seen

The check warns that log limits are unset on a host where every container caps its own logs. It reads only `/etc/docker/daemon.json`. Per-container `--log-opt max-size` flags and Compose `logging:` blocks are invisible to it. If your containers set their own limits, this is a false positive. Confirm with `docker inspect --format '{{.HostConfig.LogConfig}}' `. Setting a daemon-wide default is still worthwhile as a backstop for containers that do not.

MongoDB authorization enabled outside mongod.conf is missed

The check returns FAIL on a MongoDB server that does require authentication. It greps `mongod.conf` for `authorization: enabled`. A server started with `--auth` on the command line, or a replica set using `keyFile` (which implies authorization), has neither line in the config file. Confirm with `db.adminCommand({getParameter: 1, authenticationMechanisms: 1})` or by attempting an unauthenticated connection. If authentication is genuinely enforced, this is a false positive.

A PostgreSQL WAL directory on its own mount is reported as sharing a disk

The check warns that transaction logs share a disk with the data directory, on a server where `pg_wal` is a separate mount point. It treats PostgreSQL WAL as co-located unless `pg_wal` is a symlink. A `pg_wal` that is itself a mount point is not a symlink, so it is misread. Compare the filesystems directly (`df /var/lib/postgresql/*/main /var/lib/postgresql/*/main/pg_wal`) as the MySQL branch of the same check already does. Different devices means the placement is correct.

The separate-netmask form in pg_hba.conf is not matched

The check passes on a server whose `pg_hba.conf` allows connections from anywhere. It matches only the CIDR form (`0.0.0.0/0`, `::/0`, `all`). The separate-netmask form `host all all 0.0.0.0 0.0.0.0 md5` is equally open and is not matched. `include` and `include_dir` directives, supported since PostgreSQL 16, are also not followed. Read the effective rules from the server itself with `SELECT * FROM pg_hba_file_rules;`, which resolves includes and normalises both address forms.

Known issues

8 CtrlOps Audit Checks That Are Currently Wrong

Software moves and check logic drifts behind it. These 8 checks currently report something that is not true on a current system. Each one is listed with the symptom, the cause, the result you should trust instead, and the vendor source. The affected pages say the same thing in place.

Verified August 2026. When a script is fixed, its entry is removed from this page rather than marked resolved, so everything listed here is currently true.

checks with drifted logic

pages affected

157

checks reviewed

Aug 2026

last verified

01
MySQL TLS is reported as unavailable on MySQL 8.4 and later
What you see
The check returns FAIL saying TLS is not available, on a server where TLS is configured and working.
Why
It reads `SHOW VARIABLES LIKE 'have_ssl'` and `have_openssl`. Both were deprecated in MySQL 8.0.26 and removed outright in MySQL 8.4.0, so the query comes back empty on any current MySQL and the check reads that as "no TLS".
What to trust instead
Check `SHOW VARIABLES LIKE 'tls_version'` instead - a non-empty value means TLS is available - or `SELECT @@ssl_cert`. MariaDB still exposes `have_ssl`, so the old query is only wrong on MySQL.
MySQL TLS EnforcementTransport Encryption
- MySQL 8.4 release notes: removed variables
- MySQL 8.0 deprecation of have_ssl
02
Docker Content Trust is still rewarded after Docker retired it
What you see
The check awards PASS for `DOCKER_CONTENT_TRUST=1`, and treats a host using Sigstore cosign as unsigned.
Why
Docker announced the retirement of Docker Content Trust and the notary.docker.io service in July 2025, with full retirement in June 2026. Setting that variable now breaks pulls of Docker Official Images rather than securing them.
What to trust instead
Verify signatures with Sigstore cosign or Notation. A PASS on this check is not evidence that your images are signed, and following its advice will break your pulls.
Image Signature VerificationImage Vulnerabilities
- Docker: Content Trust deprecation
- Sigstore cosign
03
OCSP stapling is recommended for certificates that have no OCSP responder
What you see
The check warns that stapling is off, and turning it on changes nothing except an nginx warning in the error log.
Why
Let's Encrypt stopped including OCSP URLs in its certificates on 7 May 2025 and switched off its OCSP responders on 6 August 2025. With no responder URL in the certificate, `ssl_stapling on` is inert and nginx logs "ssl_stapling ignored, no OCSP responder URL in the certificate".
What to trust instead
Inspect the certificate for an OCSP URL first (`openssl x509 -noout -ocsp_uri -in cert.pem`). If it is empty, stapling is not applicable and the warning can be ignored. Certificates from CAs that still run responders are unaffected.
OCSP StaplingTLS Configuration
- Let's Encrypt: ending OCSP support
- nginx ssl_stapling directive
04
The end-of-life version lists are incomplete
What you see
A runtime or base image that is past end of life passes the check.
Why
Both checks compare against a version list hardcoded when the script was written, rather than querying a source that tracks end-of-life dates.
What to trust instead
As of August 2026 the following are also past end of life and are not flagged: PHP 8.1, Node.js 18 and 20, MySQL 5.7 and 8.0 (EOL 30 April 2026), PostgreSQL 12 and 13, MongoDB 5.0 and 6.0, Redis 6.x and 7.0/7.2, Ubuntu 20.04 standard support, Debian 10, Alpine 3.13 to 3.20, and Python 3.7 to 3.9. Check your own versions against endoflife.date rather than trusting a PASS here.
End-of-Life RuntimesApplication SecurityEnd-of-Life Base ImageImage Vulnerabilities
- endoflife.date
05
Per-container log limits are not seen
What you see
The check warns that log limits are unset on a host where every container caps its own logs.
Why
It reads only `/etc/docker/daemon.json`. Per-container `--log-opt max-size` flags and Compose `logging:` blocks are invisible to it.
What to trust instead
If your containers set their own limits, this is a false positive. Confirm with `docker inspect --format '{{.HostConfig.LogConfig}}' <container>`. Setting a daemon-wide default is still worthwhile as a backstop for containers that do not.
Container Log LimitsDaemon & Socket
- Docker logging driver configuration
06
MongoDB authorization enabled outside mongod.conf is missed
What you see
The check returns FAIL on a MongoDB server that does require authentication.
Why
It greps `mongod.conf` for `authorization: enabled`. A server started with `--auth` on the command line, or a replica set using `keyFile` (which implies authorization), has neither line in the config file.
What to trust instead
Confirm with `db.adminCommand({getParameter: 1, authenticationMechanisms: 1})` or by attempting an unauthenticated connection. If authentication is genuinely enforced, this is a false positive.
MongoDB AuthorizationAuthentication
- MongoDB: enable access control
07
A PostgreSQL WAL directory on its own mount is reported as sharing a disk
What you see
The check warns that transaction logs share a disk with the data directory, on a server where `pg_wal` is a separate mount point.
Why
It treats PostgreSQL WAL as co-located unless `pg_wal` is a symlink. A `pg_wal` that is itself a mount point is not a symlink, so it is misread.
What to trust instead
Compare the filesystems directly (`df /var/lib/postgresql/*/main /var/lib/postgresql/*/main/pg_wal`) as the MySQL branch of the same check already does. Different devices means the placement is correct.
Transaction Log PlacementConfiguration & Hardening
- PostgreSQL WAL configuration
08
The separate-netmask form in pg_hba.conf is not matched
What you see
The check passes on a server whose `pg_hba.conf` allows connections from anywhere.
Why
It matches only the CIDR form (`0.0.0.0/0`, `::/0`, `all`). The separate-netmask form `host all all 0.0.0.0 0.0.0.0 md5` is equally open and is not matched. `include` and `include_dir` directives, supported since PostgreSQL 16, are also not followed.
What to trust instead
Read the effective rules from the server itself with `SELECT * FROM pg_hba_file_rules;`, which resolves includes and normalises both address forms.
PostgreSQL Allowed HostsLeast-Privilege Permissions
- PostgreSQL pg_hba.conf
- PostgreSQL pg_hba_file_rules view

Audit your fleet

An audit you can check the working of, not just trust

Every threshold CtrlOps applies is published, and so is every place the check is wrong. $7/user/month after a 1 month free trial - no credit card required.

✓ Start instantly·✓ No credit card·✓ No sneaky autorenewals