Potential timing attack in Gammu SMS Daemon for Drupal
About the product:
Homepage: https://www.drupal.org/project/gammu_smsd
Source repository: https://git.drupalcode.org/project/gammu_smsd
Package: composer:drupal/gammu_smsd
Drupal Gammu SMS Daemon is intended to allow a Drupal site to integrate with the Gammu SMS Daemon (smsd) for the sending and receiving of SMS messages.
The program provides: * A web UI for administrates to view/send messages. * A REST API endpoint protected by an administrator chosen token.
Vulnerability info
Note: This is a potential vulnerability based on code review and general accepted security practices. No confirmed full path exploit has been created.
The program provides a REST API located at api/gammu/send
The code server this performs an early check for an Authorization header being provided and matching a configured secret token.
The token check is done with a non-timing safe == comparison in GammuApiController::send(). An attacker with sufficient time, resources, and proximity, could use timing data to assist in determining the underlying access key.
Attack requirements
- Adjacency, or other method of otherwise predictable latency.
Impacted versions
All current published releases are believed to be vulnerable (<= 8.x-1.2). The currently not published 8.x-1.3 release is anticipated to include a fix.
CVE score
CVSS v4.0 Base Score: 2.3 / Low
CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Related CWE's
Additional information
Tested against 8.x-1.2.
The maintainer of the product was contacted through their published vulnerability reporting service. At time of issue opening they were provided the following coordinated disclosure timeline notice
This report is subject to a 90 day disclosure policy. If a fix for this report is made available to users before the end of the 90-day timeline, this report report will become public 30 days after the fix was made available. If no fix is made available this report will become public at the 90 day mark. The timeline may be shortened in response to an increase in public risk.
Timeline
17/05/2026
Report submitted to project through their registered vulnerability reporting service. Report automatically acknowledged by reporting service.
04/06/2026
Inquiry to product maintainer to confirm they have received the report and are working on the issue.
19/06/2026-1
Notice provided to maintainer and reporting service that 30 days elapsed without confirmation from maintainer. Maintainer advised that failure to acknowledge within 2 weeks would result in issue being classfied as maintainer failed to respond to contact requests which is considered an increase risk to the public that may result in early disclosure.
19/06/2026-2
Reporting service advised they were reaching out to the project maintainers through alternative channels.
20/06/2026-1
Maintainer marked issue as complete.
20/06/2026-2
Acknowledge seeing a public commit with the fix. Advised maintainer that report is now considered publicly disclosed. Requested if the maintainer intended to publish a release and/or security advisory.
20/06/2026-3
Reporting service directed maintainer to documentation on their release processed. Reporting service reqeusted confirmation that public fix resolved the security concern.
20/06/2026-4
Informed reporting servive that the commit appears to resolve concerns by using a comparison method that is generally considered time safe.
26/06/2026
Reporting service prompted maintainer with next steps.
27/07/2026
Reporting service requested an update from maintainer.
16/08/2026
Vulnerability disclosed by reporter.
About
This repository contains a collection of files related to various vulnerability disclosures.