New TeleMessage SGNL Flaw Is Actively Being Exploited by Attackers – Source:hackread.com

TeleMessage SGNL, a made-in-Israel clone of the Signal app used by US government agencies and regulated businesses, has been found running with an outdated configuration that exposes sensitive internal data to the internet, no login required.

The main cause of the problem is how some deployments of TeleMessage SGNL are using older versions of Spring Boot, a Java-based framework. These versions leave a diagnostic endpoint called /heapdump exposed by default.

When not locked down, this endpoint returns a full memory snapshot of the app, weighing in at around 150MB. These dumps can contain usernames, passwords, session details, and other data that should never be public.

According to cybersecurity researchers at GrayNoise, who identified this exploitation and shared its details with Hackread.com earlier today, say that even though newer Spring Boot releases disable this by default, TeleMessage instances were still running the insecure configuration as late as May 5, 2025.

The vulnerability, tracked as CVE-2025-48927, was added to the US Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalogue on July 14, which also suggests that real-world attacks are already underway.

According to GreyNoise, attackers have wasted no time. As of July 16, at least 11 IPs have been logged attempting to exploit the flaw directly. These are not random pings; they’re specific attempts to retrieve the heap memory from exposed TeleMessage SGNL deployments.

The scanning doesn’t stop there. In the past 90 days, over 2,000 IPs have probed Spring Boot Actuator endpoints in general. More than 1,500 IPs targeted the /health endpoint, often used by attackers to check if an app is built on Spring Boot and potentially misconfigured. This kind of scanning is often a sign that more targeted exploitation could follow.

GreyNoise has created a dedicated tracking tag for this activity. The tag identifies scanning behaviour specific to TeleMessage SGNL instances running with the vulnerable /heapdump endpoint exposed.

TeleMessage SGNL and Cybersecurity Issues

Security flaws can surface in any platform, but the issue with TeleMessage is more serious. This is a service built to protect sensitive communication, used by government agencies and enterprise organisations, yet it was left open because of outdated setup choices.

When a platform selling secure communication is involved, these kinds of misconfigurations can damage more than just systems. But, reputational damage is not new at TeleMessage. Back in May 2025, the platform suffered a massive breach after an anonymous hacker broke into its systems. The attacker accessed backend infrastructure and private user messages, forcing the company to take its website offline.

Just days later, on May 13, the CISA added CVE-2025-47729, the vulnerability behind that breach, to its Known Exploited Vulnerabilities (KEV) list. Then things got worse. Distributed Denial of Secrets (DDoSecrets), a nonprofit known for publishing leaked datasets, archived and indexed the entire stolen dataset on its website. That archive contained 410 gigabytes of sensitive data taken from the breach.

CISA’s Binding Operational Directive

Under its Binding Operational Directive, CISA has instructed all federal agencies to either apply available patches or stop using the affected software by July 22, 2025. While the directive only applies to federal systems, it’s a strong reminder for any organisation using TeleMessage SGNL to act quickly.

Until confirmed patches are applied, the safer approach is to restrict access or temporarily disable the app in environments handling sensitive communication. Nevertheless, researchers are urging organisations using TeleMessage or Spring Boot for internal services to take this seriously and:

• Review all Actuator endpoint exposure

• Disable or restrict access to the /heapdump endpoint immediately

• Block IPs flagged by GreyNoise that are probing for this vulnerability

• Upgrade to a supported version of Spring Boot that uses more secure default configurations