Uptime Kuma 2.5.8 removes TCP Port TLS: review certificate monitoring

A green check needs the right meaning

Uptime Kuma released 2.5.8 on October 26, 2026, removing TLS support from the TCP Port monitor because it had not worked as intended. The maintainer says existing TCP monitors become ordinary TCP checks. Teams monitoring websites, APIs and servers should review what their alerts actually establish.

The release separately fixes Docker verification and announces an admin-only remote-code-execution fix. This October 27 report keeps port availability, Docker response validation and administrator security separate; one successful check cannot establish all three.

An open port is not valid TLS

A successful TCP check establishes that a connection can be made to the configured port. It does not itself verify an HTTPS certificate’s expiry, hostname or trust chain. TLS protects connections such as HTTPS; removing it from TCP Port changes what operators should expect that monitor to establish.

For example, port 443 might accept connections while the web application or certificate has a problem. This is an operational example, not a customer test result. A monitor named “website certificate” but configured only for TCP should be reviewed so on-call staff do not misinterpret its status.

For HTTPS websites, review HTTP(s) monitors, the actual target and certificate-expiry notifications. Do not enable ignored TLS errors merely to obtain a green result. Other protocols need protocol-appropriate monitoring rather than an indiscriminate switch to HTTP.

Docker verification needs the expected response

The 2.5.8 notes say Docker verification could miss invalid responses. A transport request completing is not necessarily a valid application-level response, which matters when configuring Docker hosts and container monitors.

Friday Works recommends retesting configured Docker connections and associated monitors after upgrade. Check address, permissions and daemon responses on infrastructure you manage. Do not expose the Docker API publicly or broaden permissions merely to get past verification.

The screenshots show an isolated 2.5.8 instance with loopback addresses and synthetic input. They demonstrate the actual TCP/HTTP configuration fields, not reproduction of the Docker defect or testing of a production environment.

Stay within the published security information

The release identifies GHSA-v2p3-6f5h-6hhf as an admin-only RCE fix. At review time its detailed advisory was not public and returned 404. The release therefore does not establish the complete affected-version range, CVSS score, further exploit conditions or exploitation in the wild.

Admin-only does not make a fix irrelevant: administrator accounts and sessions are sensitive. It also must not be rewritten as unauthenticated RCE. Operators on the 2.5 branch should review their upgrade path to 2.5.8 without inventing an affected range for every earlier release.

Restrict administration access, review accounts and retain access logs according to policy while scheduling the upgrade. Those are Friday Works’ administrative recommendations, not proof of mitigation for an undisclosed mechanism. No exploitation procedure is provided.

Finish with an intentional monitor review

Back up configuration and data using the installation’s supported method, test recovery and pilot the upgrade. Confirm both server and frontend versions, monitor types, alert intent and notification delivery. An unchanged monitor count is insufficient.

For each monitor previously relying on TCP TLS behavior, record the replacement and validate it against an authorized service. Test application behavior, response contents and certificate expiry where those are actual requirements. The immediate goal is to prevent a monitoring gap after a behavior change, rather than to claim that every alert becomes correct automatically.