Skip to content
Heist/ feed
Back to feed
Medium

Security advisory

Type: advisorySources: OSVCVE: CVE-2020-4060

In LoRa Basics Station before 2.0.4, there is a Use After Free vulnerability that leads to memory corruption. This bug is triggered on 32-bit machines when the CUPS server responds with a message (https://doc.sm.tc/station/cupsproto.html#http-post-response) where the signature length is larger than 2 GByte (never happens in practice), or the response is crafted specifically to trigger this issue (i.e. the length signature field indicates a value larger than (2**31)-1 although the signature actually does not contain that much data). In such a scenario, on 32 bit machines, Basic Station would execute a code path, where a piece of memory is accessed after it has been freed, causing the process to crash and restarted again. The CUPS transaction is typically mutually authenticated over TLS. Therefore, in order to trigger this vulnerability, the attacker would have to gain access to the CUPS server first. If the user chose to operate without authentication over TLS but yet is concerned about this vulnerability, one possible workaround is to enable TLS authentication. This has been fixed in 2.0.4.

Products
Not specified
Affected versions
Not specified
Fixed versions
Not specified
CVEs
CVE-2020-4060
Confirmed fixed CVEs
Not specified
Updated in this feed
31 Oct 2026, 11:13 UTC · Revision 1

Source evidence

CVE-2020-4060

core-osv · Original source

Published 22 Jun 2020, 16:15 UTC

In LoRa Basics Station before 2.0.4, there is a Use After Free vulnerability that leads to memory corruption. This bug is triggered on 32-bit machines when the CUPS server responds with a message (https://doc.sm.tc/station/cupsproto.html#http-post-response) where the signature length is larger than 2 GByte (never happens in practice), or the response is crafted specifically to trigger this issue (i.e. the length signature field indicates a value larger than (2**31)-1 although the signature actually does not contain that much data). In such a scenario, on 32 bit machines, Basic Station would execute a code path, where a piece of memory is accessed after it has been freed, causing the process to crash and restarted again. The CUPS transaction is typically mutually authenticated over TLS. Therefore, in order to trigger this vulnerability, the attacker would have to gain access to the CUPS server first. If the user chose to operate without authentication over TLS but yet is concerned about this vulnerability, one possible workaround is to enable TLS authentication. This has been fixed in 2.0.4.

osv:CVE-2020-4060
Complete source record
{
  "id": "d49477dcee46dce6ecb474ab238eae861f030c03bb1b367b5a8db390d869521d",
  "url": "https://osv.dev/vulnerability/CVE-2020-4060",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "CVE-2020-4060",
    "summary": "In LoRa Basics Station before 2.0.4, there is a Use After Free vulnerability that leads to memory corruption. This bug is triggered on 32-bit machines when the CUPS server responds with a message (https://doc.sm.tc/station/cupsproto.html#http-post-response) where the signature length is larger than 2 GByte (never happens in practice), or the response is crafted specifically to trigger this issue (i.e. the length signature field indicates a value larger than (2**31)-1 although the signature actually does not contain that much data). In such a scenario, on 32 bit machines, Basic Station would execute a code path, where a piece of memory is accessed after it has been freed, causing the process to crash and restarted again. The CUPS transaction is typically mutually authenticated over TLS. Therefore, in order to trigger this vulnerability, the attacker would have to gain access to the CUPS server first. If the user chose to operate without authentication over TLS but yet is concerned about this vulnerability, one possible workaround is to enable TLS authentication. This has been fixed in 2.0.4.",
    "evidence": "osv:CVE-2020-4060",
    "products": [],
    "severity": "medium",
    "structured": {
      "id": "CVE-2020-4060",
      "aliases": [
        "CVE-2020-4060",
        "GHSA-v9ph-r496-4m2j"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://github.com/lorabasics/basicstation",
              "type": "GIT",
              "events": [
                {
                  "introduced": "0"
                },
                {
                  "fixed": "817e6e1e7f0c3affce078bac7b060ba675043664"
                }
              ],
              "database_specific": {
                "extracted_events": [
                  {
                    "cpe": "cpe:2.3:a:semtech:lora_basics_station:*:*:*:*:*:*:*:*",
                    "range": [
                      {
                        "introduced": "0"
                      },
                      {
                        "fixed": "2.0.4"
                      }
                    ],
                    "source": "CPE_RANGE"
                  }
                ]
              }
            }
          ],
          "versions": [
            "v2.0.3",
            "v2.0.2"
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2020-4060.json"
          }
        }
      ],
      "modified": "2026-10-20T10:53:28.624263044Z",
      "provider": "osv",
      "references": [
        "https://github.com/lorabasics/basicstation/security/advisories/GHSA-v9ph-r496-4m2j"
      ],
      "provider_metadata": {}
    },
    "related_cves": [
      {
        "value": "CVE-2020-4060",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 384345,
  "published_at": "2020-06-22T16:15:11.557+00:00"
}