CVE-2025-48929 is a medium severity weakness (CVSS 4.0) in the TeleMessage service, through 5 May 2025. Authentication relies on a long-lived credential, not a short lived token, so a stolen one can be reused later. The record names no fix. Ask the vendor, and review how your organisation uses the service.
What's affected
The CVE record says the TeleMessage service through 2025-05-05 is affected, and lists the product under the vendor name Smarsh. The record uses a date instead of a version number, because this is a hosted service and not a package that customers install.
The record's only reference is a Wired article about the service. I did not fetch it, so this post does not repeat any details from it. The record text is brief: authentication is implemented through a long-lived credential, for example not a token with a short expiry, that can be reused at a later date if an adversary discovers it.
No fixed date or version is named in the record. Because the service is run by the vendor, any correction would happen on the vendor's side, and customers would need to ask what changed.
How to check if you're exposed
If your organisation uses TeleMessage products for archiving or messaging, ask your vendor management or compliance team what is deployed and for which users. There is no version command to run, so the check is a conversation and a document review.
Questions to put to the vendor in writing:
- Have the authentication credentials been changed to short lived tokens, and from what date?
- Were existing long-lived credentials revoked or rotated after the date in the record?
- What logs can you obtain to review use of your accounts' credentials?
Internally, list where the service's credentials or API keys are stored. Look in configuration management, secrets stores and device configuration. A credential that sits in many places is easier to find for an adversary.
What to do now
- Find out whether your organisation uses the service, and which systems and people depend on it.
- Ask the vendor for the status of the credential design and for written confirmation of any change.
- Rotate any credentials you control for the service, and store them in a secrets manager.
- Review records of access for unexpected use, and ask the vendor for the access logs that cover your account.
- Consider your own retention and monitoring duties, and discuss with your legal and compliance teams whether to continue to use the service while questions remain open.
Why it matters
The record lists two weaknesses: CWE-613, insufficient session expiration, and CWE-922, insecure storage of sensitive information. The common thread is that a secret which stays valid for a long time becomes more valuable the longer it exists, because every copy of it is a way in.
Short lived tokens limit the damage from theft. If a token expires in minutes or hours, a stolen copy loses its value quickly, and refreshing the token gives the service a chance to check that the user still has access. A permanent credential offers none of that.
The CVSS score is Medium because the vector assumes the attacker first has to obtain the credential, which the record marks as high complexity. This is not on the CISA Known Exploited Vulnerabilities list as far as the record shows. Treat the issue as a vendor risk item, and track the answers you receive.
Quick check
Is there a version I can upgrade to?
No. The record uses a date, 5 May 2025, and describes a hosted service. Any fix is on the vendor's side, so ask for written confirmation.
Why is the score only Medium?
The vector in the record marks the attack as high complexity and limited in impact, because the attacker first needs to obtain the credential.
Sources
Last reviewed: 18 October 2026.
