LiveActive security incident?Get immediate response
CVE Record

CVE-2020-26230: Deanonymization of COVID-19 positive users of Radar COVID

Radar COVID is the official COVID-19 exposure notification app for Spain. In affected versions of Radar COVID, identification and de-anonymization of COVID-19 positive users that upload Radar COVID TEKs to the Radar COVID server is possible. This vulnerability enables the identification and de-anonymization of COVID-19 positive users when using Radar COVID. The vulnerability is caused by the fact that Radar COVID connections to the server (uploading of TEKs to the backend) are only made by COVID-19 positives. Therefore, any on-path observer with the ability to monitor traffic between the app and the server can identify which users had a positive test. Such an adversary can be the mobile network operator (MNO) if the connection is done through a mobile network, the Internet Service Provider (ISP) if the connection is done through the Internet (e.g., a home network), a VPN provider used by the user, the local network operator in the case of enterprise networks, or any eavesdropper with access to the same network (WiFi or Ethernet) as the user as could be the case of public WiFi hotspots deployed at shopping centers, airports, hotels, and coffee shops. The attacker may also de-anonymize the user. For this additional stage to succeed, the adversary needs to correlate Radar COVID traffic to other identifiable information from the victim. This could be achieved by associating the connection to a contract with the name of the victim or by associating Radar COVID traffic to other user-generated flows containing identifiers in the clear (e.g., HTTP cookies or other mobile flows sending unique identifiers like the IMEI or the AAID without encryption). The former can be executed, for instance, by the Internet Service Provider or the MNO. The latter can be executed by any on-path adversary, such as the network provider or even the cloud provider that hosts more than one service accessed by the victim. The farther the adversary is either from the victim (the client) or the end-point (the server), the less likely it may be that the adversary has access to re-identification information. The vulnerability has been mitigated with the injection of dummy traffic from the application to the backend. Dummy traffic is generated by all users independently of whether they are COVID-19 positive or not. The issue was fixed in iOS in version 1.0.8 (uniform distribution), 1.1.0 (exponential distribution), Android in version 1.0.7 (uniform distribution), 1.1.0 (exponential distribution), Backend in version 1.1.2-RELEASE. For more information see the referenced GitHub Security Advisory.

HighCVSS 7.4Not KEV-listedUpdated
Glexia's TakeAutomated analysishigh

Security readout for executives and security teams

Plain-English summary

Radar COVID could reveal that a user tested positive because only positive users uploaded diagnosis keys to the backend. A network operator or other on-path observer could spot that traffic pattern, and possibly link it to a real person using subscriber or other identifying data.

Executive priority

Treat as high priority if operating or assessing Radar COVID. The issue concerns sensitive health-status confidentiality, not system takeover, and the documented fix is version-based plus dummy traffic behavior.

Technical view

This is a CWE-200 traffic-analysis privacy flaw in Radar COVID. Affected iOS, Android, and backend versions exposed COVID-positive status through TEK-upload connections made only by positives. Mitigation added dummy backend traffic from all users to obscure upload status.

Likely exposure

Exposure is limited to Radar COVID deployments using iOS versions before 1.0.8, Android versions before 1.0.7, or backend before 1.1.2-RELEASE. The risk is highest where network providers, VPNs, enterprise networks, public Wi-Fi operators, or similar on-path parties can observe traffic metadata.

Exploitation context

The source bundle does not show CISA KEV listing or active exploitation. Exploitation requires on-path traffic visibility; de-anonymization additionally requires correlating Radar COVID traffic with subscriber records or other identifying flows.

Researcher notes

This is a metadata leakage issue, not a cryptographic break of TEKs. Practical privacy impact depends on observer position and access to re-identification data. The provided sources identify fixes but do not provide evidence of active exploitation.

Mitigation direction

  • Upgrade iOS apps to version 1.0.8 or later; prefer 1.1.0 where applicable.
  • Upgrade Android apps to version 1.0.7 or later; prefer 1.1.0 where applicable.
  • Upgrade backend to 1.1.2-RELEASE or later.
  • Verify dummy traffic is generated for all users regardless of diagnosis status.
  • Check the GitHub Security Advisory for any deployment-specific guidance.

Validation and detection

  • Inventory mobile app and backend versions against the affected ranges.
  • Confirm production clients no longer upload only when users are COVID-positive.
  • Review backend telemetry for dummy traffic from non-positive users.
  • Assess whether network logs retain metadata that could identify historical positive uploads.
  • Document any residual privacy risk from retained traffic or subscriber correlation data.
Prepared
Confidence
high
Sources
10

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cwe · medium confidence lookup

CWE-200: Information exposure and cloud metadata lookup

Information exposure and SSRF weaknesses can make discovery, cloud metadata, and credential material review relevant. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.

Open ATT&CK lookup
cve · low confidence lookup

CVE-2020-26230 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
High
CVSS
7.4 (3.1)
Known Exploited
No
Published

Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

1CVSS vectors
0Timeline events
0ADP providers
13Source links

CVSS vector scores

1 official score

We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.

ScoreVersionSeverityVectorExploitImpactSource
7.4CVSS 3.1HighCVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N2.84Primary CVE score

Vulnerability scoring details

Base CVSS 3.1 score

7.4High
CVSS 3.1 vector shape for CVE-2020-26230Attack VectorAttack ComplexityPrivileges RequiredUser InteractionScopeConfidentiality ImpactIntegrity ImpactAvailability Impact

Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Attack Vector
NetworkAdjacentLocalPhysical
Attack Complexity
LowHigh
Privileges Required
NoneLowHigh
User Interaction
NoneRequired
Scope
ChangedUnchanged
Confidentiality Impact
HighLowNone
Integrity Impact
HighLowNone
Availability Impact
HighLowNone

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
RadarCOVIDradar-covid-backend-dp3t-serveriOS version < 1.0.8, Android version < 1.0.7, Backend < 1.1.2-RELEASEListed
Weakness

CWE details

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.

CWE-200 · source CWE mapping

Exposure of Sensitive Information to an Unauthorized Actor

Exposure of Sensitive Information to an Unauthorized Actor represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.