{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "DeskTime Time Tracking App",
          "vendor": "DeskTime",
          "versions": [
            {
              "lessThan": "1.3.674",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "source": "551230f0-3615-47bd-b7cc-93e92e730bbf"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:draugiemgroup:desktime_time_tracking:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "D59E9743-3F8A-46EB-8AAC-F684723EDD63",
              "versionEndExcluding": "1.3.674",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Due to improper TLS certificate validation in the DeskTime Time Tracking App before version 1.3.674, attackers who can position themselves in the network path between the client and the DeskTime update servers can return a malicious executable in response to an update request. This allows the attacker to achieve user-level remote code execution on the affected client."
    },
    {
      "lang": "es",
      "value": "Debido a una validaci\u00f3n incorrecta de certificados TLS en la aplicaci\u00f3n DeskTime Time Tracking anterior a la versi\u00f3n 1.3.674, los atacantes que pueden posicionarse en la ruta de red entre el cliente y los servidores de actualizaci\u00f3n de DeskTime pueden devolver un ejecutable malicioso en respuesta a una solicitud de actualizaci\u00f3n. Esto permite al atacante lograr la ejecuci\u00f3n remota de c\u00f3digo a nivel de usuario en el cliente afectado."
    }
  ],
  "id": "CVE-2025-10539",
  "lastModified": "2026-10-07T09:10:00.160",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 4.8,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "LOW",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.2,
        "impactScore": 2.5,
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2025-10539",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-04-28T14:09:20.701327Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-04-28T09:16:16.187",
  "references": [
    {
      "source": "551230f0-3615-47bd-b7cc-93e92e730bbf",
      "tags": [
        "Product"
      ],
      "url": "https://desktime.com/download"
    },
    {
      "source": "551230f0-3615-47bd-b7cc-93e92e730bbf",
      "tags": [
        "Third Party Advisory"
      ],
      "url": "https://r.sec-consult.com/desktime"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Exploit",
        "Mailing List",
        "Third Party Advisory"
      ],
      "url": "http://seclists.org/fulldisclosure/2026/Apr/20"
    },
    {
      "source": "af854a3a-2127-422b-91ae-364da2661108",
      "tags": [
        "Exploit",
        "Mailing List",
        "Third Party Advisory"
      ],
      "url": "http://seclists.org/fulldisclosure/2026/Apr/21"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "tags": [
        "Third Party Advisory"
      ],
      "url": "https://sec-consult.com/vulnerability-lab/advisory/missing-tls-certificate-validation-leading-to-rce-in-desktime-time-tracking-app/"
    }
  ],
  "sourceIdentifier": "551230f0-3615-47bd-b7cc-93e92e730bbf",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-295"
        },
        {
          "lang": "en",
          "value": "CWE-296"
        },
        {
          "lang": "en",
          "value": "CWE-494"
        }
      ],
      "source": "551230f0-3615-47bd-b7cc-93e92e730bbf",
      "type": "Secondary"
    }
  ]
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "SEC Consult SA-20260427-0",
          "vendor": "Desktime",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "SEC Consult Vulnerability Lab via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "SEC Consult Vulnerability Lab Security Advisory \u003c 20260427-0 \u003e\n=======================================================================\n              title: Missing TLS Certificate Validation leading to RCE\n            product: DeskTime Time Tracking App\n vulnerable version: 1.3.671\n      fixed version: -\n         CVE number: CVE-2025-10539\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0impact: medium\n           homepage:https://desktime.com\n              found: 2025-05-23\n                 by: Daniel Hirschberger\n                     Thorger Jansen (Office Bochum)\n                     Tobias Niemann (Office Bochum)\n                     Marius Renner (Office Bochum)\n                     SEC Consult Vulnerability Lab\n\n                     An integrated part of SEC Consult, an Atos business\n                     Europe | Asia\n\n                     https://www.sec-consult.com\n\n=======================================================================\n\nVendor description:\n-------------------\n\"A time tracker that won\u0027t interrupt your team\u0027s workflow. Ever.\nDeskTime is an automatic time tracking tool that will help you increase\ntransparency in your team, enable easy hybrid work, and optimize work hours.\"\n\nSource:https://desktime.com/\n\n\nBusiness recommendation:\n------------------------\nThe vendor did not provide a patch nor a timeline when a fix will be available.\nIn case you are using this product, please approach the vendor and demand a fix.\n\nSEC Consult highly recommends performing a thorough security review of the\nproduct conducted by security professionals to identify and resolve potential\nfurther security issues.\n\n\nVulnerability overview/description:\n-----------------------------------\n1) Missing TLS Certificate Validation leading to RCE (CVE-2025-10539)\nDue to missing TLS Certificate Validation, attackers, who can inject themselves\ninto the network path between the client and the DeskTime update servers, can\nreturn a malicious executable in response to an update request and achieve\nuser-level code execution on the client.\n\n\nProof of concept:\n-----------------\n1) Missing TLS Certificate Validation leading to RCE (CVE-2025-10539)\nThe DeskTime application periodically checks if there is an update for itself.\nThis is done via an HTTPS URL, but the server certificate is not checked\ncorrectly.\n\nThe certificate validation is implemented as follows:\n\n\u003ccert_validation.png\u003e\n\nThere are two possibilities to pass the certificate checks:\n1. There are no errors during the certificate validation\n2. The request was made by the class `HttpWebRequest` and\n   the used certificate is object of the class `X509Certificate2` and\n   the SSLPolicyError has the value `RemoteCertificateChainErrors`.\n\n2) should be further scrutinized.\n\nThe .NET documentation for SSLPolicyErrors shows that this enum has the\nfollowing values and meanings:\nhttps://learn.microsoft.com/en-us/dotnet/api/system.net.security.sslpolicyerrors\n\nNone = No SSL policy errors.\nRemoteCertificateNotAvailable = Certificate not available.\nRemoteCertificateNameMismatch = Certificate name mismatch.\nRemoteCertificateChainErrors = ChainStatus has returned a non empty array.\n\nThis means that as long as any certificate is provided by the server and that it\nis issued for the expected hostname, it does not matter if there are any errors\nin the validation of the certificate chain.\nThis effectively allows man-in-the-middle attacks by using self-signed\ncertificates.\n\nTo validate this finding on the machine where DeskTime is installed, the\nfollowing steps have to be performed.\n\nAdd an entry for `desktime.com` to `C:\\Windows\\System32\\drivers\\etc\\hosts` and\npoint it to localhost:\n\n--------------------------------------------------------------------------------\n127.0.0.1 desktime.com\n--------------------------------------------------------------------------------\n\nCreate a listener in Burp Proxy on port `443`, enable `Force use of TLS` and\n`Invisible Proxy support`.\n\n\u003cburp_request_handling.png\u003e\n\nSince desktime.com now points to 127.0.0.1 because of the modification of the\nhosts file, we have to create a static DNS override in Burp to let the hostname\n`desktime.com` resolve to the real upstream IP.\n\n\u003cburp_dns_override.png\u003e\n\nWhen DeskTime is started now, the Burp HTTP history shows all client requests.\n\n\u003cburp_requests.png\u003e\n\nIf the update function is triggered, a request containing the currently\ninstalled version, the userID and some other parameters, is sent to the server.\n\n\u003cupdate_request.png\u003e\n\nThe server responds with the version of the installer that it currently hosts,\nas well as a link to that version.\n\n\u003cupdate_response.png\u003e\n\nIf the returned version is greater than the one installed on the client machine,\nit is automatically downloaded and installed in the current user context.\n\nBy performing the mentioned man-in-the-middle attack, it is therefore possible\nto achieve Remote Code Execution.\n\nFor example, the following Burp Response Rewrite Rule can be used to\nautomatically refer the client to another update.\n\n\u003creplace_rule.png\u003e\n\nIn this case, the client is redirected to a locally hosted copy of the Windows\ncalculator `calc.exe`.\n\n\u003cmalicious_update.webm\u003e\n\nSince the updater triggers automatically every hour, no user interaction is\nnecessary to exploit this vulnerability.\n\n\nVulnerable / tested versions:\n-----------------------------\nThe following version has been tested which was the latest version available\nat the time of the test:\n* 1.3.671\n\n\nVendor contact timeline:\n------------------------\n2025-06-26: Contacting vendor throughsupport () desktime com;\n            Vendor asks to send advisory information unencrypted;\n            We send the advisory.\n2025-07-02: Vendor states that this is a duplicate and they are already\n            aware.\n2025-07-03: We ask for a timeline for the remediation and about\n            assigning a CVE number.\n2025-07-17: Vendor responds that it will take some time to patch this\n            issue.\n            We respond that we can create a CVE number and ask them\n            to notify us once the patch is released.\n2025-07-18: Vendor informs us that the next public version will include\n            the fix, but no timeline was provided\n2025-09-16: Reserved CVE-2025-10539, asking for a status update;\n            Vendor responds that this security issue \"can\u0027t be used under\n            standard circumstances, and very specific conditions must be met\".\n            It is included in future update, but no timeline provided.\n            Support agent closes the ticket;\n            We ask if the advisory can be published since \"the vulnerability\n            can not be exploited under standard circumstances\";\n            Vendor wants to double check with their team.\n2025-09-18: Vendor asks for deadline extension.\n2025-09-23: We reply that our 50 day deadline was over on 2025-08-15 and\n            that the industry standard of 90 days will be over (tomorrow)\n            on 2025-09-24. We add that we can delay the publication if\n            they can provide a timeline for the fix and if they are not\n            able to fix it before then for important reasons.\n2025-09-16: Vendor has to clarify the release internally.\n2025-09-18: Vendor asks what timeframe we can give them.\n2025-09-23: We re-iterate our timeframes from the Responsible\n            Disclosure Policy and note that the 90-day standard\n            timeframe is over tomorrow.\n2025-09-23: Vendor asks internally for timeline but forecasts\n            end of this year.\n2025-10-06: Vendor wants to delay developing a fix since the\n            probability for exploitation is low, the fix is\n            scheduled to be delivered in a bigger update in Q1 2026.\n2025-10-15: We agree that the vulnerability is not easy to exploit\n            and lower the risk to medium. Since it is now rated\n            medium and we assume that the fix is trivial, we do not\n            agree with waiting until Q1.\n2025-11-14: The vendor plans to have a fix ready on 2025-12-08.\n2026-03-26: Following up whether everything is fixed by now; explaining delays\n            on our side. Vendor will clarify progress internally.\n2026-04-14: Asking for a status update again. Vendor tells us that the issue\n            is more complex than expected, they need more time. Informing them\n            about the planned release on 23rd April, as we have given them nearly\n            a year of patching time. Vendor responds that they are taking our\n            plan into consideration.\n2026-04-27: Release of security advisory.\n\n\nSolution:\n---------\nThe vendor did not provide a patch nor a timeline when a fix will be available.\nIn case you are using this product, please approach the vendor and demand a fix.\n\n\nWorkaround:\n-----------\nNone\n\n\nAdvisory URL:\n-------------\nhttps://sec-consult.com/vulnerability-lab/\n\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSEC Consult Vulnerability Lab\nAn integrated part of SEC Consult, an Atos business\nEurope | Asia\n\nAbout SEC Consult Vulnerability Lab\nThe SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an\nAtos business. It ensures the continued knowledge gain of SEC Consult in the\nfield of network and application security to stay ahead of the attacker. The\nSEC Consult Vulnerability Lab supports high-quality penetration testing and\nthe evaluation of new offensive and defensive technologies for our customers.\nHence our customers obtain the most current information about vulnerabilities\nand valid recommendation about the risk profile of new technologies.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nInterested to work with the experts of SEC Consult?\nSend us your applicationhttps://sec-consult.com/career/\n\nInterested in improving your cybersecurity with the experts of SEC Consult?\nContact our local officeshttps://sec-consult.com/contact/\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nMail: security-research at sec-consult dot com\nWeb:https://www.sec-consult.com\nBlog:https://blog.sec-consult.com\nX:https://x.com/sec_consult\n\nEOF Daniel Hirschberger, Thorger Jansen, Tobias Niemann, Marius Renner / @2026\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T07:38:51Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Apr/20"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Apr/20"
        },
        {
          "url": "https://blog.sec-consult.com"
        },
        {
          "url": "https://desktime.com"
        },
        {
          "url": "https://desktime.com/"
        },
        {
          "url": "https://learn.microsoft.com/en-us/dotnet/api/system.net.security.sslpolicyerrors"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://sec-consult.com/career/"
        },
        {
          "url": "https://sec-consult.com/contact/"
        },
        {
          "url": "https://sec-consult.com/vulnerability-lab/"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        },
        {
          "url": "https://www.sec-consult.com"
        },
        {
          "url": "https://x.com/sec_consult"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Apr/20"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "SEC Consult SA-20260427-0 :: Missing TLS Certificate Validation leading to RCE in DeskTime Time Tracking App",
      "x_gcve": [
        {
          "recordType": "reference",
          "relationships": [
            {
              "destId": "CVE-2025-10539",
              "type": "related"
            }
          ],
          "vulnId": "GCVE-1988-2026-0237",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Apr/20",
            "automated": true,
            "contentSha256": "e4037d0dfa5b0b431b8c66c39d3b0b13a6f3a23f4d173d3c6ab8c9fcf7aae286",
            "evidenceScore": 7,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Apr/20",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-04-27T10:53:17Z"
          }
        },
        {
          "recordType": "advisory",
          "vulnId": "gcve-1988-2026-0237"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-08T08:13:41Z",
    "dateUpdated": "2026-09-11T07:38:51Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0237"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "SEC Consult SA-20260427-0",
          "vendor": "Desktime",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "SEC Consult Vulnerability Lab via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "*Update 2026-04-28:* The vendor contacted us and now provides a patched version v1.3.674 which can be obtained at the \nfollowing URL:\n\nhttps://desktime.com/download\n\n\n\nOn 4/27/26 12:53, SEC Consult Vulnerability Lab wrote:\n\nSEC Consult Vulnerability Lab Security Advisory \u003c 20260427-0 \u003e\n=======================================================================\n               title: Missing TLS Certificate Validation leading to RCE\n             product: DeskTime Time Tracking App\n  vulnerable version: 1.3.671\n       fixed version: -\n          CVE number: CVE-2025-10539\n \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0impact: medium\n            homepage:https://desktime.com\n               found: 2025-05-23\n                  by: Daniel Hirschberger\n                      Thorger Jansen (Office Bochum)\n                      Tobias Niemann (Office Bochum)\n                      Marius Renner (Office Bochum)\n                      SEC Consult Vulnerability Lab\n\n                      An integrated part of SEC Consult, an Atos business\n                      Europe | Asia\n\n                      https://www.sec-consult.com\n\n=======================================================================\n\nVendor description:\n-------------------\n\"A time tracker that won\u0027t interrupt your team\u0027s workflow. Ever.\nDeskTime is an automatic time tracking tool that will help you increase\ntransparency in your team, enable easy hybrid work, and optimize work hours.\"\n\nSource:https://desktime.com/\n\n\nBusiness recommendation:\n------------------------\nThe vendor did not provide a patch nor a timeline when a fix will be available.\nIn case you are using this product, please approach the vendor and demand a fix.\n\nSEC Consult highly recommends performing a thorough security review of the\nproduct conducted by security professionals to identify and resolve potential\nfurther security issues.\n\n\nVulnerability overview/description:\n-----------------------------------\n1) Missing TLS Certificate Validation leading to RCE (CVE-2025-10539)\nDue to missing TLS Certificate Validation, attackers, who can inject themselves\ninto the network path between the client and the DeskTime update servers, can\nreturn a malicious executable in response to an update request and achieve\nuser-level code execution on the client.\n\n\nProof of concept:\n-----------------\n1) Missing TLS Certificate Validation leading to RCE (CVE-2025-10539)\nThe DeskTime application periodically checks if there is an update for itself.\nThis is done via an HTTPS URL, but the server certificate is not checked\ncorrectly.\n\nThe certificate validation is implemented as follows:\n\n\u003ccert_validation.png\u003e\n\nThere are two possibilities to pass the certificate checks:\n1. There are no errors during the certificate validation\n2. The request was made by the class `HttpWebRequest` and\n    the used certificate is object of the class `X509Certificate2` and\n    the SSLPolicyError has the value `RemoteCertificateChainErrors`.\n\n2) should be further scrutinized.\n\nThe .NET documentation for SSLPolicyErrors shows that this enum has the\nfollowing values and meanings:\nhttps://learn.microsoft.com/en-us/dotnet/api/system.net.security.sslpolicyerrors\n\nNone = No SSL policy errors.\nRemoteCertificateNotAvailable = Certificate not available.\nRemoteCertificateNameMismatch = Certificate name mismatch.\nRemoteCertificateChainErrors = ChainStatus has returned a non empty array.\n\nThis means that as long as any certificate is provided by the server and that it\nis issued for the expected hostname, it does not matter if there are any errors\nin the validation of the certificate chain.\nThis effectively allows man-in-the-middle attacks by using self-signed\ncertificates.\n\nTo validate this finding on the machine where DeskTime is installed, the\nfollowing steps have to be performed.\n\nAdd an entry for `desktime.com` to `C:\\Windows\\System32\\drivers\\etc\\hosts` and\npoint it to localhost:\n\n--------------------------------------------------------------------------------\n127.0.0.1 desktime.com\n--------------------------------------------------------------------------------\n\nCreate a listener in Burp Proxy on port `443`, enable `Force use of TLS` and\n`Invisible Proxy support`.\n\n\u003cburp_request_handling.png\u003e\n\nSince desktime.com now points to 127.0.0.1 because of the modification of the\nhosts file, we have to create a static DNS override in Burp to let the hostname\n`desktime.com` resolve to the real upstream IP.\n\n\u003cburp_dns_override.png\u003e\n\nWhen DeskTime is started now, the Burp HTTP history shows all client requests.\n\n\u003cburp_requests.png\u003e\n\nIf the update function is triggered, a request containing the currently\ninstalled version, the userID and some other parameters, is sent to the server.\n\n\u003cupdate_request.png\u003e\n\nThe server responds with the version of the installer that it currently hosts,\nas well as a link to that version.\n\n\u003cupdate_response.png\u003e\n\nIf the returned version is greater than the one installed on the client machine,\nit is automatically downloaded and installed in the current user context.\n\nBy performing the mentioned man-in-the-middle attack, it is therefore possible\nto achieve Remote Code Execution.\n\nFor example, the following Burp Response Rewrite Rule can be used to\nautomatically refer the client to another update.\n\n\u003creplace_rule.png\u003e\n\nIn this case, the client is redirected to a locally hosted copy of the Windows\ncalculator `calc.exe`.\n\n\u003cmalicious_update.webm\u003e\n\nSince the updater triggers automatically every hour, no user interaction is\nnecessary to exploit this vulnerability.\n\n\nVulnerable / tested versions:\n-----------------------------\nThe following version has been tested which was the latest version available\nat the time of the test:\n* 1.3.671\n\n\nVendor contact timeline:\n------------------------\n2025-06-26: Contacting vendor throughsupport () desktime com;\n             Vendor asks to send advisory information unencrypted;\n             We send the advisory.\n2025-07-02: Vendor states that this is a duplicate and they are already\n             aware.\n2025-07-03: We ask for a timeline for the remediation and about\n             assigning a CVE number.\n2025-07-17: Vendor responds that it will take some time to patch this\n             issue.\n             We respond that we can create a CVE number and ask them\n             to notify us once the patch is released.\n2025-07-18: Vendor informs us that the next public version will include\n             the fix, but no timeline was provided\n2025-09-16: Reserved CVE-2025-10539, asking for a status update;\n             Vendor responds that this security issue \"can\u0027t be used under\n             standard circumstances, and very specific conditions must be met\".\n             It is included in future update, but no timeline provided.\n             Support agent closes the ticket;\n             We ask if the advisory can be published since \"the vulnerability\n             can not be exploited under standard circumstances\";\n             Vendor wants to double check with their team.\n2025-09-18: Vendor asks for deadline extension.\n2025-09-23: We reply that our 50 day deadline was over on 2025-08-15 and\n             that the industry standard of 90 days will be over (tomorrow)\n             on 2025-09-24. We add that we can delay the publication if\n             they can provide a timeline for the fix and if they are not\n             able to fix it before then for important reasons.\n2025-09-16: Vendor has to clarify the release internally.\n2025-09-18: Vendor asks what timeframe we can give them.\n2025-09-23: We re-iterate our timeframes from the Responsible\n             Disclosure Policy and note that the 90-day standard\n             timeframe is over tomorrow.\n2025-09-23: Vendor asks internally for timeline but forecasts\n             end of this year.\n2025-10-06: Vendor wants to delay developing a fix since the\n             probability for exploitation is low, the fix is\n             scheduled to be delivered in a bigger update in Q1 2026.\n2025-10-15: We agree that the vulnerability is not easy to exploit\n             and lower the risk to medium. Since it is now rated\n             medium and we assume that the fix is trivial, we do not\n             agree with waiting until Q1.\n2025-11-14: The vendor plans to have a fix ready on 2025-12-08.\n2026-03-26: Following up whether everything is fixed by now; explaining delays\n             on our side. Vendor will clarify progress internally.\n2026-04-14: Asking for a status update again. Vendor tells us that the issue\n             is more complex than expected, they need more time. Informing them\n             about the planned release on 23rd April, as we have given them nearly\n             a year of patching time. Vendor responds that they are taking our\n             plan into consideration.\n2026-04-27: Release of security advisory.\n\n\nSolution:\n---------\nThe vendor did not provide a patch nor a timeline when a fix will be available.\nIn case you are using this product, please approach the vendor and demand a fix.\n\n\nWorkaround:\n-----------\nNone\n\n\nAdvisory URL:\n-------------\nhttps://sec-consult.com/vulnerability-lab/\n\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSEC Consult Vulnerability Lab\nAn integrated part of SEC Consult, an Atos business\nEurope | Asia\n\nAbout SEC Consult Vulnerability Lab\nThe SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an\nAtos business. It ensures the continued knowledge gain of SEC Consult in the\nfield of network and application security to stay ahead of the attacker. The\nSEC Consult Vulnerability Lab supports high-quality penetration testing and\nthe evaluation of new offensive and defensive technologies for our customers.\nHence our customers obtain the most current information about vulnerabilities\nand valid recommendation about the risk profile of new technologies.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nInterested to work with the experts of SEC Consult?\nSend us your applicationhttps://sec-consult.com/career/\n\nInterested in improving your cybersecurity with the experts of SEC Consult?\nContact our local officeshttps://sec-consult.com/contact/\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nMail: security-research at sec-consult dot com\nWeb:https://www.sec-consult.com\nBlog:https://blog.sec-consult.com\nX:https://x.com/sec_consult\n\nEOF Daniel Hirschberger, Thorger Jansen, Tobias Niemann, Marius Renner / @2026\n\n\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T07:38:52Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Apr/21"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Apr/21"
        },
        {
          "url": "https://blog.sec-consult.com"
        },
        {
          "url": "https://desktime.com"
        },
        {
          "url": "https://desktime.com/"
        },
        {
          "url": "https://desktime.com/download"
        },
        {
          "url": "https://learn.microsoft.com/en-us/dotnet/api/system.net.security.sslpolicyerrors"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://sec-consult.com/career/"
        },
        {
          "url": "https://sec-consult.com/contact/"
        },
        {
          "url": "https://sec-consult.com/vulnerability-lab/"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        },
        {
          "url": "https://www.sec-consult.com"
        },
        {
          "url": "https://x.com/sec_consult"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Apr/21"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "Re: SEC Consult SA-20260427-0 :: Missing TLS Certificate Validation leading to RCE in DeskTime Time Tracking App",
      "x_gcve": [
        {
          "recordType": "reference",
          "relationships": [
            {
              "destId": "CVE-2025-10539",
              "type": "related"
            }
          ],
          "vulnId": "GCVE-1988-2026-0271",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Apr/21",
            "automated": true,
            "contentSha256": "e0bcd8b1d0aa5b88e51391b0fbb72f0c5faf0c842cdb3324ddd8200d350af903",
            "evidenceScore": 7,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Apr/21",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-04-28T06:55:00Z"
          }
        },
        {
          "recordType": "advisory",
          "vulnId": "gcve-1988-2026-0271"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-08T08:13:43Z",
    "dateUpdated": "2026-09-11T07:38:52Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0271"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-10539"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-28T09:16:16Z",
    "severity": "MODERATE"
  },
  "details": "Due to improper TLS certificate validation in the DeskTime Time Tracking App before version 1.3.674, attackers who can position themselves in the network path between the client and the DeskTime update servers can return a malicious executable in response to an update request. This allows the attacker to achieve user-level remote code execution on the affected client.",
  "id": "GHSA-m272-rh3v-6hfm",
  "modified": "2026-04-29T21:31:24Z",
  "published": "2026-04-28T09:34:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10539"
    },
    {
      "type": "WEB",
      "url": "https://desktime.com/download"
    },
    {
      "type": "WEB",
      "url": "https://r.sec-consult.com/desktime"
    },
    {
      "type": "WEB",
      "url": "https://sec-consult.com/vulnerability-lab/advisory/missing-tls-certificate-validation-leading-to-rce-in-desktime-time-tracking-app"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2026/Apr/20"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2026/Apr/21"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}