SEC Consult Vulnerability Lab Security Advisory < 20260427-0 >
=======================================================================
title: Missing TLS Certificate Validation leading to RCE
product: DeskTime Time Tracking App
vulnerable version: 1.3.671
fixed version: -
CVE number: CVE-2025-10539
impact: medium
homepage:https://desktime.com
found: 2025-05-23
by: Daniel Hirschberger
Thorger Jansen (Office Bochum)
Tobias Niemann (Office Bochum)
Marius Renner (Office Bochum)
SEC Consult Vulnerability Lab
An integrated part of SEC Consult, an Atos business
Europe | Asia
https://www.sec-consult.com
=======================================================================
Vendor description:
-------------------
"A time tracker that won't interrupt your team's workflow. Ever.
DeskTime is an automatic time tracking tool that will help you increase
transparency in your team, enable easy hybrid work, and optimize work hours."
Source:https://desktime.com/
Business recommendation:
------------------------
The vendor did not provide a patch nor a timeline when a fix will be available.
In case you are using this product, please approach the vendor and demand a fix.
SEC Consult highly recommends performing a thorough security review of the
product conducted by security professionals to identify and resolve potential
further security issues.
Vulnerability overview/description:
-----------------------------------
1) Missing TLS Certificate Validation leading to RCE (CVE-2025-10539)
Due to missing TLS Certificate Validation, attackers, who can inject themselves
into the network path between the client and the DeskTime update servers, can
return a malicious executable in response to an update request and achieve
user-level code execution on the client.
Proof of concept:
-----------------
1) Missing TLS Certificate Validation leading to RCE (CVE-2025-10539)
The DeskTime application periodically checks if there is an update for itself.
This is done via an HTTPS URL, but the server certificate is not checked
correctly.
The certificate validation is implemented as follows:
<cert_validation.png>
There are two possibilities to pass the certificate checks:
1. There are no errors during the certificate validation
2. The request was made by the class `HttpWebRequest` and
the used certificate is object of the class `X509Certificate2` and
the SSLPolicyError has the value `RemoteCertificateChainErrors`.
Since 1) is just the regular and correct way to check the server certificate,
2) should be further scrutinized.
The .NET documentation for SSLPolicyErrors shows that this enum has the
following values and meanings:
https://learn.microsoft.com/en-us/dotnet/api/system.net.security.sslpolicyerrors
None = No SSL policy errors.
RemoteCertificateNotAvailable = Certificate not available.
RemoteCertificateNameMismatch = Certificate name mismatch.
RemoteCertificateChainErrors = ChainStatus has returned a non empty array.
This means that as long as any certificate is provided by the server and that it
is issued for the expected hostname, it does not matter if there are any errors
in the validation of the certificate chain.
This effectively allows man-in-the-middle attacks by using self-signed
certificates.
To validate this finding on the machine where DeskTime is installed, the
following steps have to be performed.
Add an entry for `desktime.com` to `C:\Windows\System32\drivers\etc\hosts` and
point it to localhost:
--------------------------------------------------------------------------------
127.0.0.1 desktime.com
--------------------------------------------------------------------------------
Create a listener in Burp Proxy on port `443`, enable `Force use of TLS` and
`Invisible Proxy support`.
<burp_request_handling.png>
Since desktime.com now points to 127.0.0.1 because of the modification of the
hosts file, we have to create a static DNS override in Burp to let the hostname
`desktime.com` resolve to the real upstream IP.
<burp_dns_override.png>
When DeskTime is started now, the Burp HTTP history shows all client requests.
<burp_requests.png>
If the update function is triggered, a request containing the currently
installed version, the userID and some other parameters, is sent to the server.
<update_request.png>
The server responds with the version of the installer that it currently hosts,
as well as a link to that version.
<update_response.png>
If the returned version is greater than the one installed on the client machine,
it is automatically downloaded and installed in the current user context.
By performing the mentioned man-in-the-middle attack, it is therefore possible
to achieve Remote Code Execution.
For example, the following Burp Response Rewrite Rule can be used to
automatically refer the client to another update.
<replace_rule.png>
In this case, the client is redirected to a locally hosted copy of the Windows
calculator `calc.exe`.
<malicious_update.webm>
Since the updater triggers automatically every hour, no user interaction is
necessary to exploit this vulnerability.
Vulnerable / tested versions:
-----------------------------
The following version has been tested which was the latest version available
at the time of the test:
* 1.3.671
Vendor contact timeline:
------------------------
2025-06-26: Contacting vendor throughsupport@xxxxxxxxxxxx;
Vendor asks to send advisory information unencrypted;
We send the advisory.
2025-07-02: Vendor states that this is a duplicate and they are already
aware.
2025-07-03: We ask for a timeline for the remediation and about
assigning a CVE number.
2025-07-17: Vendor responds that it will take some time to patch this
issue.
We respond that we can create a CVE number and ask them
to notify us once the patch is released.
2025-07-18: Vendor informs us that the next public version will include
the fix, but no timeline was provided
2025-09-16: Reserved CVE-2025-10539, asking for a status update;
Vendor responds that this security issue "can't be used under
standard circumstances, and very specific conditions must be met".
It is included in future update, but no timeline provided.
Support agent closes the ticket;
We ask if the advisory can be published since "the vulnerability
can not be exploited under standard circumstances";
Vendor wants to double check with their team.
2025-09-18: Vendor asks for deadline extension.
2025-09-23: We reply that our 50 day deadline was over on 2025-08-15 and
that the industry standard of 90 days will be over (tomorrow)
on 2025-09-24. We add that we can delay the publication if
they can provide a timeline for the fix and if they are not
able to fix it before then for important reasons.
2025-09-16: Vendor has to clarify the release internally.
2025-09-18: Vendor asks what timeframe we can give them.
2025-09-23: We re-iterate our timeframes from the Responsible
Disclosure Policy and note that the 90-day standard
timeframe is over tomorrow.
2025-09-23: Vendor asks internally for timeline but forecasts
end of this year.
2025-10-06: Vendor wants to delay developing a fix since the
probability for exploitation is low, the fix is
scheduled to be delivered in a bigger update in Q1 2026.
2025-10-15: We agree that the vulnerability is not easy to exploit
and lower the risk to medium. Since it is now rated
medium and we assume that the fix is trivial, we do not
agree with waiting until Q1.
2025-11-14: The vendor plans to have a fix ready on 2025-12-08.
2026-03-26: Following up whether everything is fixed by now; explaining delays
on our side. Vendor will clarify progress internally.
2026-04-14: Asking for a status update again. Vendor tells us that the issue
is more complex than expected, they need more time. Informing them
about the planned release on 23rd April, as we have given them
nearly
a year of patching time. Vendor responds that they are taking our
plan into consideration.
2026-04-27: Release of security advisory.
Solution:
---------
The vendor did not provide a patch nor a timeline when a fix will be available.
In case you are using this product, please approach the vendor and demand a fix.
Workaround:
-----------
None
Advisory URL:
-------------
https://sec-consult.com/vulnerability-lab/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SEC Consult Vulnerability Lab
An integrated part of SEC Consult, an Atos business
Europe | Asia
About SEC Consult Vulnerability Lab
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an
Atos business. It ensures the continued knowledge gain of SEC Consult in the
field of network and application security to stay ahead of the attacker. The
SEC Consult Vulnerability Lab supports high-quality penetration testing and
the evaluation of new offensive and defensive technologies for our customers.
Hence our customers obtain the most current information about vulnerabilities
and valid recommendation about the risk profile of new technologies.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Interested to work with the experts of SEC Consult?
Send us your applicationhttps://sec-consult.com/career/
Interested in improving your cybersecurity with the experts of SEC Consult?
Contact our local officeshttps://sec-consult.com/contact/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mail: security-research at sec-consult dot com
Web:https://www.sec-consult.com
Blog:https://blog.sec-consult.com
X:https://x.com/sec_consult
EOF Daniel Hirschberger, Thorger Jansen, Tobias Niemann, Marius Renner / @2026
Attachment:
sec-consult-c-desktime-burp_dns_override.png
Description: PNG image
Attachment:
sec-consult-c-desktime-burp_request_handling.png
Description: PNG image
Attachment:
sec-consult-c-desktime-burp_requests.png
Description: PNG image
Attachment:
sec-consult-c-desktime-cert_validation.png
Description: PNG image
Attachment:
sec-consult-c-desktime-malicious_update.webm
Description: video/webm
Attachment:
sec-consult-c-desktime-replace_rule.png
Description: PNG image
Attachment:
sec-consult-c-desktime-update_request.png
Description: PNG image
Attachment:
sec-consult-c-desktime-update_response.png
Description: PNG image
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/
