Enterprise admins who haven’t yet mitigated a two-month-old vulnerability in apps that incorporate the open source Spring Boot tool could be in trouble: Attempts to exploit the hole are still ongoing.
Spring Boot is a tool helps developers use Java-based frameworks to create microservices and web apps. According to an April report by Amigoscode, a learning platform for developers, Spring Boot “remains one of the most powerful and widely adopted frameworks for Java developers in 2025.”
The flaw was first reported in May after being found in TeleMessage SGNL, an enterprise messaging system similar to Signal that also captures and archives mobile messages.
However, researchers at GreyNoise reported that at least 11 IP addresses were trying to exploit applications containing the vulnerability (CVE-2025-48927) this week alone. On Friday afternoon, after news reports repeated the GreyNoise alert, the number of IP addresses scanning for the vulnerability had jumped to over 1,000.
GreyNoise said over 2,000 IP addresses have scanned for Spring Boot Actuator endpoints in the past 90 days. Of them, 1,582 IPs specifically targeted the /health endpoints, commonly used to detect internet-exposed Spring Boot deployments.
If vulnerable implementations of apps, including TeleMessage SGNL, are found, they could be exploited to steal sensitive data in heap memory, including plaintext usernames and passwords. The hole is serious enough that it was added this week to the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities Catalog.
It isn’t clear how many Spring Boot-related endpoints are still at risk. A GreyNoise researcher this week found that many devices are still open and vulnerable to the exploit.
How Spring Boot is used
GreyNoise says the problem in TeleMessage SGNL stems from the platform’s continued use of a legacy configuration in Spring Boot Actuator in which a diagnostic /heapdump endpoint is publicly accessible on the internet, without authentication.
Mitigating the vulnerability in any application that uses Spring Boot is relatively easy: Block access to all Spring Boot endpoints other than /info and /health.
TeleMessage SGNL is sold by US-based Smarsh, which offers a number of archiving, communication compliance, information governance, and data migration solutions. It isn’t clear how extensively Smarsh is currently marketing TeleMessage SGNL; there is a home page for the application, but no links within it to get more information about the product.
In reply to a CSO query, a Smarsh spokesperson said CVE-2025-48927 was fully remediated in the TeleMessage environment in early May. That remediation has been independently verified by a third-party cybersecurity partner. As a cloud-native SaaS platform, all fixes were applied centrally, the spokesperson said, and no action was required by customers. Any attempts to exploit CVE-2025-48927 since that time have been unsuccessful.
TeleMessage SGLN’s user base is much smaller than Signal’s, notes Ed Dubrovsky, chief operating officer of incident response firm Cypher, so the possible impact of this vulnerability is smaller.
However, he noted, exploitation of the flaw allows remote copying of up to 150MB of data from the app’s heap memory, which, if it includes text messages, “can present a serious concern.
Beware of clone apps
“From a CISO/CSO perspective, the use of clone apps should be discouraged unless there is a very specific reason for such usage,” he added. “The main reason is that as the audience grows smaller, these clone applications do not get nearly enough attention from their developers, increasing risks of zero day and other vulnerabilities.”
“Finally,” he said, “remind users to not re-use logins/passwords and limit information shared in text apps to non-confidential information.”
Robert Beggs, head of Canadian incident response firm Digital Defence, noted other security issues that TeleMessage SGNL users should be aware of that were also reported in May. The US National Institute for Standards and Technology (NIST) reports that this application uses MD5 for password hashing, “which opens up various attack possibilities (including rainbow tables) with low computational effort” (CVE-2025-48931).
MD5 is an outdated encryption method and is known to be insecure, he said in an email. He also pointed out that NIST says these hashed passwords can be accepted by TeleMessage SGNL as an authentication credential (CVE-2025-48925).
“To some extent, TeleMessage SGNL ‘rode on the back’ of Signal’s end-to-end security claims, copying their look and feel for the interface,” Beggs said. Given that fact, he asked, “how does a CISO differentiate third party products from the original products that may have stronger security in place?”
The vulnerabilities highlight a potential risk, he said: A Trojan application operated by a hostile country or organized hacker group that is designed to appear security compliant could surreptitiously collect unencrypted data on the backend. “Governments, financial institutions, and organizations looking to protect intellectual property could be at risk from this type of attack,” he said. “The data could be used as the ultimate insider threat.”
This story has been updated to include a statement from Smarsh.
No Responses