See how telemessage compares to other vendors in security performance
TeleMessage TM SGNL contains an exposure of core dump file to an unauthorized control sphere Vulnerability. This vulnerability is based on a JSP application in which the heap content is roughly equivalent to a "core dump" in which a password previously sent over HTTP would be included in this dump.
TeleMessage TM SGNL contains an initialization of a resource with an insecure default vulnerability. This vulnerability relies on how the Spring Boot Actuator is configured with an exposed heap dump endpoint at a /heapdump URI.
TeleMessage TM SGNL contains a hidden functionality vulnerability in which the archiving backend holds cleartext copies of messages from TM SGNL application users.
The TeleMessage service through 2025-05-05 relies on the client side (e.g., the TM SGNL app) to do MD5 hashing, and then accepts the hash as the authentication credential.
The admin panel in the TeleMessage service through 2025-05-05 allows attackers to discover usernames, e-mail addresses, passwords, and telephone numbers.
The TeleMessage service through 2025-05-05 implements authentication through a long-lived credential (e.g., not a token with a short expiration time) that can be reused at a later date if discovered by an adversary.
The TeleMessage archiving backend through 2025-05-05 accepts API calls (to request an authentication token) from the TM SGNL (aka Archive Signal) app with the credentials of logfile for the user and enRR8UVVywXYbFkqU#QDPRkO for the password.
The TeleMessage service through 2025-05-05 stores certain cleartext information in memory, even though memory content may be accessible to an adversary through various avenues.
The TeleMessage service through 2025-05-05 relies on MD5 for password hashing, which opens up various attack possibilities (including rainbow tables) with low computational effort.