Server-Side Request Forgery (SSRF) in AltumCode 66Uptime Ping Servers Plugin

Overview

Summary

A Server-Side Request Forgery (SSRF) vulnerability was discovered in the multi-location ping server plugin for AltumCode 66Uptime, a self-hosted website monitoring application. The ping server endpoint accepts unauthenticated POST requests and performs arbitrary HTTP requests, ICMP pings, and TCP connections to any user-specified target. An attacker can exploit this to access cloud instance metadata, steal sensitive credentials, scan internal networks, or direct outbound traffic at third-party targets.

Background

66Uptime supports multi-location monitoring through remote ping servers deployed on separate hosts. These servers receive check requests from the main 66Uptime installation and perform HTTP, ICMP, or TCP checks against the specified target, returning the results to the main application. The ping server endpoint is a standalone PHP script (index.php) deployed to each remote monitoring location.

Vulnerability Details

The ping server endpoint (ping-server/index.php) processed incoming requests without any form of authentication. Any party that could reach the endpoint could submit arbitrary targets for the ping server to connect to. The endpoint supported three check types — website (HTTP), ping (ICMP), and port (TCP) — giving an attacker broad flexibility in the types of requests they could make from the server.

The endpoint path was predictable across all installations (/ping-server/index.php), and ping server hostnames were publicly discoverable through Certificate Transparency logs, DNS enumeration, and services such as Shodan.

Impact

During testing, the researcher was able to retrieve live cloud instance credentials from the metadata service with a single unauthenticated request. This vulnerability affects any cloud provider that exposes an instance metadata service on the well-known link-local address 169.254.169.254, including AWS, Google Cloud Platform, Microsoft Azure, and DigitalOcean. Retrieved credentials could be used to access any cloud service the instance role or service account permitted, potentially including storage buckets, compute instances, databases, and other cloud resources. The scope of damage depends entirely on the permissions assigned to the instance — in a worst case, an attacker could exfiltrate data, spin up new infrastructure, or pivot deeper into the cloud environment.

Beyond cloud credential theft, the vulnerability enables an attacker to:

• Scan internal networks and enumerate services not otherwise accessible from the internet
• Access internal APIs, databases, and administration panels reachable from the ping server’s network position
• Perform port scanning across internal and external hosts via the TCP check functionality
• Direct high-volume outbound traffic at third-party targets, using the ping server as an amplifier for denial-of-service attacks

Installations hosted on internal corporate networks face additional risk. An attacker with access to the ping server endpoint could use it as a pivot point to reach internal resources such as file servers, database servers, printers, management interfaces, and other infrastructure that would otherwise be completely inaccessible from the internet. The ping server effectively becomes an unauthenticated proxy into the internal network.

Any 66Uptime installation using the ping servers plugin on a cloud-hosted or network-connected server was potentially affected. Ping server hostnames were publicly discoverable through Certificate Transparency logs, DNS enumeration, and indexing services such as Shodan, making targeted exploitation straightforward.

Proof of Concept

A single unauthenticated HTTP POST request to a discovered ping server endpoint was sufficient to exploit the vulnerability:

During testing against an AWS-hosted instance, this returned the full IAM role credentials from the instance metadata service. The same technique applies to any cloud provider that exposes a metadata service at this address.

Discovery

This vulnerability was discovered in February 2026 during an investigation into false downtime alerts in a production 66Uptime installation. While troubleshooting the monitoring logic, the unauthenticated nature of the ping server endpoint was identified, leading to the discovery of the SSRF vulnerability.

Disclosure Timeline

Vendor Fix

In version 54.0.0 (main application) and version 2.0.0 (ping-servers plugin), AltumCode added optional API key authentication. Administrators can configure a per-server API key in the admin panel, and the ping server validates the key before processing requests.

Limitations of the Fix

• The API key is optional and defaults to empty. Installations that update without configuring a key remain vulnerable.
• There is no SSRF filtering of internal IP ranges, metadata endpoints, or private network addresses. The API key prevents unauthorized access but does not restrict what authenticated requests can target.
• The API key must be manually configured on both the main application and each remote ping server, with no synchronization or validation mechanism.
• The ping server plugin has no version identifier, making it difficult for operators to confirm they are running the patched version.

Recommendations

Operators running 66Uptime with the ping servers plugin should:

• Update to 66Uptime 54.0.0 or later and ping-servers plugin 2.0.0 or later.
• Configure a strong, unique API key for each ping server — both in the admin panel and in the ping server’s index.php file.
• Implement network-level controls to prevent ping servers from accessing cloud metadata endpoints and internal network ranges (169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
• Restrict inbound access to ping server endpoints by source IP to only the main 66Uptime installation where possible.

Mitigation for Installations Unable to Upgrade

Operators who cannot immediately upgrade should implement network-level controls to block outbound requests from ping servers to internal IP ranges and cloud metadata endpoints. At minimum, block access to 169.254.169.254 and private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) at the firewall or security group level. Additionally, restricting inbound access to the ping server endpoint by source IP to only the main 66Uptime installation will prevent unauthorized use.

References

• CVE-2026-39117
• 66Uptime
• AltumCode
• CWE-918: Server-Side Request Forgery (SSRF)
• OWASP SSRF Prevention Cheat Sheet
• AWS Instance Metadata Service Documentation
• Certificate Transparency 

Credit

This vulnerability was discovered and responsibly disclosed by David M. Mroz of Glimmernet Technologies.

The researcher would like to thank Fabian at AltumCode for his responsiveness throughout the disclosure process.

Contact

For questions about this advisory, contact us

Legal

This advisory is provided “as is” without warranty of any kind. Use of this information constitutes acceptance of risk by the user.

This advisory is subject to our Terms of Service, Disclaimer, and Privacy Policy. For additional legal information, see our Cookie Policy and Impressum.