Hackers Exploit Signal App Clone Vulnerability to Steal Passwords

A critical security vulnerability in TeleMessageTM SGNL, an enterprise messaging system designed to mirror Signal’s secure communication features, has been actively exploited by cybercriminals since its disclosure in May 2025.

The vulnerability, designated CVE-2025-48927, affects government agencies and enterprises using the platform to archive secure communications, potentially exposing sensitive data including plaintext passwords and usernames to unauthorized access.

The vulnerability stems from TeleMessage TM SGNL continued reliance on outdated Spring Boot Actuator configurations that leave a diagnostic endpoint publicly accessible without authentication.

The problematic /heapdump endpoint, when exposed, can return complete snapshots of heap memory totaling approximately 150MB, containing highly sensitive information that should remain protected.

This security vulnerability represents a significant departure from modern secure development practices.

While newer versions of Spring Boot have addressed this issue by disabling public access to such endpoints by default, TeleMessageTM SGNL deployments continued using the vulnerable legacy configuration well into 2025.

Public security reports indicate that affected instances remained exposed through at least May 5, 2025, creating an extended window of vulnerability for threat actors to exploit.

The enterprise messaging system, modeled after Signal’s architecture, serves critical communication needs for government agencies and large organizations requiring secure, archived communications.

The exposure of such sensitive data through this vulnerability poses serious risks to organizational security, potentially compromising user credentials, communication metadata, and other confidential information stored in system memory.

Signal App Clone Vulnerability

The severity of CVE-2025-48927 became increasingly apparent when the Cybersecurity and Infrastructure Security Agency (CISA) added it to their Known Exploited Vulnerabilities (KEV) catalog on July 14th.

This designation indicates that the vulnerability poses an imminent threat to federal enterprise networks and requires immediate attention from organizations using affected systems.

Cybersecurity firm GreyNoise has been tracking exploitation attempts since the vulnerability’s disclosure, revealing significant threat actor activity:

• Direct Exploitation: As of July 16, 11 distinct IP addresses have been observed actively attempting to exploit CVE-2025-48927.
  
• Reconnaissance Activity: 2,009 IP addresses conducted scans targeting Spring Boot Actuator endpoints over the past 90 days.
  
• Health Endpoint Targeting: 1,582 IPs specifically focused on /health endpoints commonly used to detect internet-exposed Spring Boot deployments.
  
• Monitoring Infrastructure: GreyNoise created a dedicated tracking tag on July 10th specifically for this vulnerability.

The scope of potential targeting extends beyond direct exploitation attempts. Security researchers consider the widespread scanning activity targeting Spring Boot Actuator endpoints as a precursor to identifying vulnerable systems, suggesting that threat actors are conducting systematic reconnaissance to map potential targets before launching attacks.

Organizations Urged to Take Immediate Action

Security experts recommend immediate remediation steps for organizations potentially affected by this vulnerability.

The primary concern centers on Spring Boot deployments, particularly those supporting internal tools or secure messaging environments where the /heapdump endpoint might be inadvertently exposed to internet access.

Organizations should immediately verify whether their Spring Boot deployments expose the /heapdump endpoint to external networks and implement blocking measures against malicious IP addresses identified through threat intelligence feeds.

Critical mitigation steps include disabling or restricting access to the problematic endpoint, limiting exposure of all Actuator endpoints unless explicitly required for operations, and conducting comprehensive reviews of deployment configurations.

The most effective long-term solution involves upgrading to supported versions of Spring Boot where secure configuration defaults are automatically enforced, eliminating the risk of inadvertent exposure of sensitive diagnostic endpoints.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.